I assume that "endScene()" waits for the video card to finish drawing the scene before returning from the function ? Or am I completely misunderstanding "beginScene" and "endScene" ?
I'm trying to figure out whether there's any way to perform other programming tasks while waiting for the frame to be drawn by the video card, and (related to this) I'm likewise looking for a painless way to allow the main loop to perform tasks such as loading or generating new 3D objects while stuff is simultaneously being displayed dynamically on the screen - in Java you'd run multiple threads, but C++ has no built-in support for that and Irrlicht is not thread-safe.
To clarify what I'm trying to do: rather than giving the user a long "Please wait..." screen at startup and pausing the program whenever new terrain needs to be generated as the user moves around, I would like to do this type of task as "transparently" as possible while a dynamic moving scene is still being displayed on the screen. One way is (presumably) to perform these tasks in small portions which are defined in a "scheduler" array - e.g., if you need to add 1000 new 3D objects, place 1000 entries in the array and let the main loop just process a few entries per cycle, based on the desired frame rate and estimated video delay. But : 1) is there any way to do this while the video card is drawing the current frame? 2) Are there any potential problems that I'm not aware of? 3) Is there a better way?
Running program code while the video card draws the scene?
Download a thread library, I like to use pThread.
Then simply make a thread for your game logic. You'll have to use a semaphore every time you access irrlicht properties.
Edit / warning: it might take ages if you don't know what you're doing, C++ threads can be nasty. Will the pay off for investing two weeks (or longer) be worth it for your game?
Then simply make a thread for your game logic. You'll have to use a semaphore every time you access irrlicht properties.
Edit / warning: it might take ages if you don't know what you're doing, C++ threads can be nasty. Will the pay off for investing two weeks (or longer) be worth it for your game?
And keep in mind that you have to do all graphic calls from the same thread. So for example loading a mesh in a different thread doesn't work bc this loading also trys to upload textures to the graphics card. And of course you are tempering with the mesh cache. so you will have to create some special loading routines when you want to load meshes from diferent threads.
We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by renovation:tinkering,improving,planting flower beds.
-
Radikalizm
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
In my experience I've learned that just throwing a threading library at a program dealing with real-time/dynamical situations without implementing a decent framework around it will turn out to be a complete mess
I made a thread a while ago about using a task-based work stealing multithreading implementation which can be fit into irrlicht with some engine hacking (thread found here : http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=42488)
You could easily implement resource loading tasks which could run while other game logic/drawing is executed
This method might not be the best out there, but it's clean, manageable and will automatically scale to any amount of CPUs
I made a thread a while ago about using a task-based work stealing multithreading implementation which can be fit into irrlicht with some engine hacking (thread found here : http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=42488)
You could easily implement resource loading tasks which could run while other game logic/drawing is executed
This method might not be the best out there, but it's clean, manageable and will automatically scale to any amount of CPUs
