structuring in MFC
-
Hi, I am new to MFC and work on a physical simulation application. I am a bit insecure on how to build up the program and would be thankful for any advise. The simulation shall be updated as often as possible. The update of the simulation then affects the viewing data (vertices and polygons etc) displayed using OpenGL. The framerate of the viewupdate shall be fixed to around 12/sek. 1.Where is best, most natural, to put the simulationupdate-call? Is it in a CWinApp derived class´s Idle-Event-handler? In that case, how do I get a pointer to the CDocument-derived class that holds the simulation-data? 2.Where is best to put the view-update-call, i.e the call that updates the viewing data and then redraws the display-window? Is it in a timer-event of a CView derived class? Thanks/JoNy JoNy
-
Hi, I am new to MFC and work on a physical simulation application. I am a bit insecure on how to build up the program and would be thankful for any advise. The simulation shall be updated as often as possible. The update of the simulation then affects the viewing data (vertices and polygons etc) displayed using OpenGL. The framerate of the viewupdate shall be fixed to around 12/sek. 1.Where is best, most natural, to put the simulationupdate-call? Is it in a CWinApp derived class´s Idle-Event-handler? In that case, how do I get a pointer to the CDocument-derived class that holds the simulation-data? 2.Where is best to put the view-update-call, i.e the call that updates the viewing data and then redraws the display-window? Is it in a timer-event of a CView derived class? Thanks/JoNy JoNy
The simulation shall be updated as often as possible. This leaves only one option: put the simultation-update code into separate worker thread. The framerate of the viewupdate shall be fixed to around 12/sek. Isn't it contradictory with previous requirement? I mean, if you're going to display 12 frames per second, why do you need maximum speed in the data-update code? Tomasz Sowinski -- http://www.shooltz.com
-
The simulation shall be updated as often as possible. This leaves only one option: put the simultation-update code into separate worker thread. The framerate of the viewupdate shall be fixed to around 12/sek. Isn't it contradictory with previous requirement? I mean, if you're going to display 12 frames per second, why do you need maximum speed in the data-update code? Tomasz Sowinski -- http://www.shooltz.com
Thanks, no it is not contradictory since I am not interested in sync between physical simulation and the view of it. If the simulation iterates 100 times/sek and the view of it 12 times/sek that means that the action (i.e every tiny little change)occurs faster than what is possible to show. But the thing with physical simulations is that it has to take all those small steps to reach a certain point. How do I create separate worker threads? Are there any good articles on it? Thanks again /JoNy
-
Thanks, no it is not contradictory since I am not interested in sync between physical simulation and the view of it. If the simulation iterates 100 times/sek and the view of it 12 times/sek that means that the action (i.e every tiny little change)occurs faster than what is possible to show. But the thing with physical simulations is that it has to take all those small steps to reach a certain point. How do I create separate worker threads? Are there any good articles on it? Thanks again /JoNy
How do I create separate worker threads? AfxBeginThread in MFC, _beginthread, _beginthreadex in C/C++ Runtime library. There's also CreateThread if you're playing directly with Win32 API, but it's not recommended if your thread use standard C/C++ functions (they need to be initialized on per-thread basis; CreateThread is a Windows function that doesn't know anything about C/C++ library). search for these function names, I'm sure MSDN has lot of multithreading samples. Here at CodeProject look at 'Threads, Processes and IPC' section. Tomasz Sowinski -- http://www.shooltz.com