Good or Bad Idea: C++ OpenGL Application using PureMVC?
-
I'm working on an OpenGL application in C++. I have some code already written, but it's becoming a fairly complex project, and I want an easy way to scale it. I heard about MVC (I know I was exposed to MVC concepts when I learned OpenGL) and I read that graphics applications used MVC long before web. I don't know whether that was just the OpenGL part or if the whole application was being referred to. I'm thinking about the whole application, so I looked up MVC framework for C++ and found PureMVC, which looked pretty good, albeit with little to no tutorials and examples in C++. So I'd like to know, is this a good idea? More specifically: 1. would this cause the programme to take up extra system resources and cost FPS (or would it go faster), 2. is the PureMVC framework known to be stable or buggy (can I rely on it not to break my programme), 3. is it even good practice to use a second MVC in addition to the MVC used in OpenGL via GLM, 4. is PureMVC known to work on Ubuntu, 5. and if none of that is a problem, where can I find appropriate tutorials and examples to speed up the learning curve, preferably for MinGW/MSYS/Eclipse if they have compilation and linking instructions, 6. or is there something better than PureMVC I should use instead, which compiles on Windows and Ubuntu and is good for graphics applications? Thanks.
-
I'm working on an OpenGL application in C++. I have some code already written, but it's becoming a fairly complex project, and I want an easy way to scale it. I heard about MVC (I know I was exposed to MVC concepts when I learned OpenGL) and I read that graphics applications used MVC long before web. I don't know whether that was just the OpenGL part or if the whole application was being referred to. I'm thinking about the whole application, so I looked up MVC framework for C++ and found PureMVC, which looked pretty good, albeit with little to no tutorials and examples in C++. So I'd like to know, is this a good idea? More specifically: 1. would this cause the programme to take up extra system resources and cost FPS (or would it go faster), 2. is the PureMVC framework known to be stable or buggy (can I rely on it not to break my programme), 3. is it even good practice to use a second MVC in addition to the MVC used in OpenGL via GLM, 4. is PureMVC known to work on Ubuntu, 5. and if none of that is a problem, where can I find appropriate tutorials and examples to speed up the learning curve, preferably for MinGW/MSYS/Eclipse if they have compilation and linking instructions, 6. or is there something better than PureMVC I should use instead, which compiles on Windows and Ubuntu and is good for graphics applications? Thanks.
Need to cover some basics which you haven't mentioned which is always slightly scary 1.) I assume you are talking new OpenGL that is 3.0+ not old style OpenGL Old style has the glBegin glEnd etc the new style you can't do anything without a shader and you drag all the function implementation pointers yourself. 2.) On the new OpenGL, GLM is one library you can use for matrix and maths stuff that ultimately ends up out on the shader in a sort of MVC setup. 3.) PureMVC is aimed at breaking the processing up via a predictable framework generally so you can thread it or use multicores. I take it your current code is a linear application so not something you can port easily to PureMVC you need to design it differently from the start. The next problem is PureMVC can be problematic in some situations like you have a client app interface sitting on a server which really has all the models. So the model view is handed to the client via the server. Lots of CAD programs and network games work that way and PureMVC is limited to what it can do. You can sort of shim it but you lose much of the effect and there are better techniques. So can you start with a basic what OpenGL version and how your app is setup (models are where?) and when you say scale up what do you mean (more users, more processor cores)?
In vino veritas
-
Need to cover some basics which you haven't mentioned which is always slightly scary 1.) I assume you are talking new OpenGL that is 3.0+ not old style OpenGL Old style has the glBegin glEnd etc the new style you can't do anything without a shader and you drag all the function implementation pointers yourself. 2.) On the new OpenGL, GLM is one library you can use for matrix and maths stuff that ultimately ends up out on the shader in a sort of MVC setup. 3.) PureMVC is aimed at breaking the processing up via a predictable framework generally so you can thread it or use multicores. I take it your current code is a linear application so not something you can port easily to PureMVC you need to design it differently from the start. The next problem is PureMVC can be problematic in some situations like you have a client app interface sitting on a server which really has all the models. So the model view is handed to the client via the server. Lots of CAD programs and network games work that way and PureMVC is limited to what it can do. You can sort of shim it but you lose much of the effect and there are better techniques. So can you start with a basic what OpenGL version and how your app is setup (models are where?) and when you say scale up what do you mean (more users, more processor cores)?
In vino veritas
Thanks for the advice. When I was talking about scale, I was talking about my codebase. I was getting to the point where I had more than a few things working to together. I'm not confident in the way I'm organising it, and I'm having a little trouble even visualising how to put it all together efficiently and effectively. I thought MVC might make all that go away. Something handling multiple cores for me would be plus, which I think PureMVC is supposed to do. It sounds like PureMVC is a bad idea for a game though, I guess I'll do it the normal way. Thanks.
-
Thanks for the advice. When I was talking about scale, I was talking about my codebase. I was getting to the point where I had more than a few things working to together. I'm not confident in the way I'm organising it, and I'm having a little trouble even visualising how to put it all together efficiently and effectively. I thought MVC might make all that go away. Something handling multiple cores for me would be plus, which I think PureMVC is supposed to do. It sounds like PureMVC is a bad idea for a game though, I guess I'll do it the normal way. Thanks.
I will assume you are working with new OpenGL 3.3+ (If you aren't you need to switch now) you will have what amounts to a pile of Function pointers you will have got with wglGetProcAddress. Usually what you need to do is first start with that and put them in a class or object. Then build functionality on the class/object interface because you have everything contained. If you aren't comfortable with doing it yourself then use a library like GLEW which will wrangle all the function pointers for you. GLEW isn't great because you can't extend it easily but it's better than nothing. If you haven't wrangled all the function pointers into a sort of API that is where you start. Once you do that at a minimum you will be able to attach/change shaders and apply the matrixes to that class/object and it will store internally whatever it needs. I usually set the class/object creation to take a window handle being the window you want to bind the OpenGL onto. The reason for doing that is when you run multiple windows each window will have it's own render context so you might as well bind the window into your object at construction. If you are using just one main OpenGL window the step will seem to have little benefit but the moment you start with multiple OpenGL windows you will get why you do it.
In vino veritas