Multithreading and window events problem

Problems building or running the engine, queries about how to use features etc.
Post Reply
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Multithreading and window events problem

Post by Antodologo »

Hi

We have managed to run Ogre in a separated thread without many complications for our game Kromaia (we can explain how we did it later on if you are interested). The game logic (including physics) runs in a thread and another thread is used just to call RenderOneFrame function. All this seems to work flawlessly.

The problems have started for us when using alt+tab or alt+f4 (and other similar inputs).

Somehow, when we use alt+tab on full screen and go back to the game, the screen is completely black. Of course we use messagePump (yes we looked through all the forums we could find :D). It works perfectly when not using multithreading. We don't know if there is a problem if the device is lost while rendering or something like that. Despite of the screen being black, the game is "playable". You can play the game without seeing anything and even RenderOneFrame is called, but nothing is rendered on screen.

Alt+f4 is not as critical as alt+tab for us, but we suppose it suffers from a similar problem. Maybe the information related can help solve both problems. Using alt+f4 crashes the game in full screen and in a window. It seems to crash looking for the window that has been just closed.

This is the callstack if you are curious:

RenderSystem_Direct3D9_d.dll!std::_Tree<std::_Tmap_traits<Ogre::D3D9RenderWindow *,Ogre::D3D9Device::RenderWindowResources *,std::less<Ogre::D3D9RenderWindow *>,Ogre::STLAllocator<std::pair<Ogre::D3D9RenderWindow * const,Ogre::D3D9Device::RenderWindowResources *>,Ogre::CategorisedAllocPolicy<0> >,0> >::_Lmost() Line 1281 + 0x3 bytes
RenderSystem_Direct3D9_d.dll!std::_Tree<std::_Tmap_traits<Ogre::D3D9RenderWindow *,Ogre::D3D9Device::RenderWindowResources *,std::less<Ogre::D3D9RenderWindow *>,Ogre::STLAllocator<std::pair<Ogre::D3D9RenderWindow * const,Ogre::D3D9Device::RenderWindowResources *>,Ogre::CategorisedAllocPolicy<0> >,0> >::begin() Line 556 + 0xc bytes
RenderSystem_Direct3D9_d.dll!Ogre::D3D9Device::getPrimaryWindow() Line 1122 + 0x12 bytes
RenderSystem_Direct3D9_d.dll!Ogre::D3D9Device::validateFocusWindow() Line 819 + 0x2b bytes
RenderSystem_Direct3D9_d.dll!Ogre::D3D9Device::validate(Ogre::D3D9RenderWindow * renderWindow=0x0164b7a0) Line 805
RenderSystem_Direct3D9_d.dll!Ogre::D3D9RenderWindow::_beginUpdate() Line 771 + 0x12 bytes
OgreMain_d.dll!Ogre::RenderTarget::updateImpl() Line 100 + 0x12 bytes
OgreMain_d.dll!Ogre::RenderTarget::update(bool swap=false) Line 541 + 0x12 bytes
OgreMain_d.dll!Ogre::RenderSystem::_updateAllRenderTargets(bool swapBuffers=false) Line 112 + 0x22 bytes
OgreMain_d.dll!Ogre::Root::_updateAllRenderTargets() Line 1386 + 0x1c bytes
OgreMain_d.dll!Ogre::Root::renderOneFrame() Line 966 + 0x8 bytes


We suppose Ogre manages this kind of things somewhere and we are breaking the order using multithreading, but we don't know where to start looking or how to solve it. Any ideas?

Thank you so much in advance ;)
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Re: Multithreading and window events problem

Post by xavier »

Antodologo wrote:Hi

We have managed to run Ogre in a separated thread without many complications for our game Kromaia (we can explain how we did it later on if you are interested). The game logic (including physics) runs in a thread and another thread is used just to call RenderOneFrame function. All this seems to work flawlessly.
Until you access the device from a thread other than the one that created it. You cannot create Ogre on one thread and call renderOneFrame() from another.

My first design question is "is this static partitioning really necessary, from a performance perspective?"
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Re: Multithreading and window events problem

Post by Antodologo »

Wow, we weren't expecting that.

So, what are the restrictions then? If we create Ogre in the same thread that calls RenderOneFrame() is there something more we won't be able to do from the other thread?

About your design question, if you ask if Ogre could be created on the same thread that calls RenderOneFrame(), yes, we just wanted to execute in a separate thread the minimum possible. This was the first try and it worked perfectly... for some time :D

I will come back here when I have results ;)

Thank you for your prompt answer
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Re: Multithreading and window events problem

Post by xavier »

You can enable various levels of thread support by rebuilding Ogre but none of them are going to let you, for example, safely manipulate SceneNodes from another thread. Ogre can only be made thread-safe in terms of background resource loading.

My point about the static partitioning is that you almost certainly do not need to split your app into multiple threads.
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Re: Multithreading and window events problem

Post by Antodologo »

That sounds quite worse. According to our own tests it seems to work as long as the scene nodes are not modified while rendering. But we haven't played enough time yet to assure anything.

About our motivations... It is somewhat complex to explain, but I know you like the subject so... here we go ;)

At the start of our project we decoupled rendering from physics. We are able to run graphics at 60FPS and physics at 200FPS (for example) using the same thread. That is nice, but there are some things we can't do and we feel we "need" them.

The first reason we found to use multithreading was VSync. Using Vsync seems the best for graphics, but the buffers swap is blocking, and we want to update our physics while the render is waiting for the VSync. Why waiting doing nothing? We couldn't find a way to use a "non blocking" Vsync, so multithreading was a possible solution to this.

The second reason is that our render is really expensive. Maybe because of our lack of knowledge about graphics and how to optimize some things. We use of the glow shader from the examples and that really hurts our performance. Without it the framerates are incredibly high, but the visuals are just the opposite. The result is that render is slow and we suspect CPU is just waiting for graphics to finish (and we have confirmed it with our multithreading test). With just two threads the performance is increased at least x2 (more than that according to our tests depending on computers and performance on each computer). For example in my own computer I had about 45/50FPS for graphics and for physics because I couldn't reach the 60 FPS for graphics and 100 FPS for physics I wanted. With the two threads I am playing at 100 FPS for graphics and 100 FPS for physics and there is even some CPU left.

The third reason is obvious. Almost every computer nowadays has 2 or more CPUs, why not use multithreading to use as many CPUs as possible? Our only bottlenecks are graphics and physics. Physics are quite fast and our game engine is invisible in our profiles. We just need to make the rendering from a separate thread to reach the best performance we can.

Anyway, we accept suggestions and criticism ;)

Thank you for your interest :D
User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2703
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 51

Re: Multithreading and window events problem

Post by syedhs »

I think you can still get the performance (2x vs the non-threading approach) simply by making sure the physics is running at different thread, that is all. Ogre should be created and run from one thread (main thread), and physics (which run in different thread) is continuously checked in main thread. Probably the rough loop can be written to something below:-

Code: Select all

while (doesn't exit the games) {
timeAccumulation = timeAccumulation + time;
    if (timeAccumulation > 0.01667) {
         -> start the physics calculation (run in different thread)
         timeAccumulation -= 0.0016667;
         physicsRun = true;
    }
-> run your game logics
-> Ogre::renderOneFrame
-> if (physicsRun == true) {
        wait for physics to finish calculation (if not completed yet)
        update the scene nodes etc..
    }
}
It is something like that. The main thing is we instruct physics to start calculating (and then physics run the calculation in different thread). Then we do our own chores.. only after that we checked back the physics result and wait till done. That way, physics is running concurrently with your game chores (logic, rendering, script etc).
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Re: Multithreading and window events problem

Post by xavier »

Antodologo wrote:Almost every computer nowadays has 2 or more CPUs, why not use multithreading to use as many CPUs as possible?

Most physics packages are now optimized internally for multithreading, so you get it "for free", and it scales at runtime up to the number of cores or HW threads on the system.

DX11 is the first 3D API that supports "real" multithreaded access to the device; all lower hardware is still single-threaded (even if you build with "multithreaded" on -- that just enables mutexes internally in the API, which serves only to serialize access to the device).

Static partitioning limits you to two threads -- how well are you going to take advantage of an 8-core machine when you are only using two of them?

This is a common mistake that many developers make -- the first tool they reach for is thread management and it's generally the wrong one.
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Re: Multithreading and window events problem

Post by Antodologo »

@syedhs

Yeah, that is the idea, but we don't need to execute physics in a separate thread, we need to execute the complete control loop without having to wait for rendering to finish. The difference with your approach is that we don't need physics to be updated concurrently with game logic. Physics needs to be updated only if game logic apply changes (applying new forces to objects for example). Of course logic could be executed in a separated thread and synchronize with physics, but we don't need so many threads, we just need to avoid render blocking our game update.

Note that if we execute render and game logic in the same thread, our game logic framerate is the graphic framerate and we don't want that. We want to render the minimum times per second and to update (game logic and physics) the maximum times per second. So the natural "partition" is: graphics in a thread and everything else in the other one.

We want the game to be as fluent and responsive as possible so we need to update input, control (think of AI and other gameplay controls) and physics (to apply control changes) as frequently as possible. The problems we can face are about our "control part" trying to modify the "render part" (scene nodes and so on). We have a synchronization mechanism to manage that, but we have no idea if it will be enough. Stay tuned :D :P

Thank you for your suggestion ;)
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Re: Multithreading and window events problem

Post by Antodologo »

@xavier... Can't get your point.

Physic packages can do whatever they want on the inside, I don't care, but I don't want my game logic to wait for the rendering part to finish. If physics are fast I will be able to increase my physics frames per second, that is not a reason not to execute render in another thread. If I can execute 1000 FPS for my control part but the render blocks my CPU 99% of the time, I will update my physics at 10FPS (and probably at random intervals). Why not moving the render to another thread and let control update at a constant rate without interruptions?

DX11 is something I am not using and I won't use for some time but, anyway, as with the physics, that is not a reason not to use multithreading. If DX11 is faster than DX9 but I still have to wait for it to finish rendering to update my control I can't see any difference. I don't want the game to use all the CPUs available, I just don't want to wait doing nothing while the work (rendering in my case) gets done. I don't even need graphics to render faster than 60 FPS as long as they don't block my control loop 60 times a second.

Yeah, I am using two threads, because I need them, if I needed 8 I would try to use them too, but there are several problems with that. I will try to sell my game, and I want it to be playable in every computer I can. This "static partition" not only improves performance in computers with 2 or more cores, it improves performance in 1 core computers, just because, as I said before, CPU seems to be waiting to render (or GPU) to finish. There are not many 8 or 16 cores computers out there right now as there are not many using DX11 (at least in percentage), and we want to sell the game as soon as possible and to as much people as possible.

Take into account we are "indie", we don't want to make the "next game engine", we don't want to use as many cores as possible, we just want to use the computer resources as efficiently as possible with the minimum effort. We don't have time to spare. If 2 threads increase performance 100% it is interesting, if 2 more threads increase performance a 20% that is not interesting for us. Be pragmatic, my friend ;)

I understand what you are trying to avoid, but I would prefer to use your knowledge for suggestions and advices instead of a general criticism to multithreading :D

Threads are useful and I told you why before. If you think I am wrong in any of the points just tell me, but in our game with current libraries and computers I think we need multithreading.

Instead of convincing everyone that lands in the forums about how evil threads are, I would love to see a list of the things to do when using multithreading with Ogre. Or a list of what not to do. Looking at the forums it seems nobody has made it work completely. If it is completely impossible it would be nice to know too, as well as a reason why it is impossible.

But don't tell me thread management is a mistake, tell me that threading Ogre is a horrible pain if you want. But pointing me (and everyone else) to the problems I (they) will face is more useful :P

OR you could propose an alternative. "I have a game that takes too much time rendering and blocks my control loop, even more if I use Vsync. What do I do? PS: I don't want to wait to the future when all my problems will have disappeared with the hardware/software that they promise we will have". I think you get it.

Thank you for your time ;)
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Re: Multithreading and window events problem

Post by xavier »

Antodologo wrote:instead of a general criticism to multithreading :D
I am not criticizing multithreading -- I am trying to describe how your approach to it is limited and non-scalable. I'm sorry if you can't understand that.

It's your product -- do what you want.
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Re: Multithreading and window events problem

Post by Antodologo »

But I don't want (nor need) a scalable solution, I just want a solution. Do you know one not involving threads? Saying multithreading is not a perfect solution doesn't help :P

On the other hand (and despite your pesimism :mrgreen:) your help has been unvaluable for us. Creating Ogre in the thread that calls RenderOneFrame() completely removes all the problems with alt+tab and alt+f4. The game seems to work perfectly now even with window events.

We have to run some stress tests and make sure everything is working right and the game never crashes. But the first tests are just perfect.

If this finally works I will have to write an article here or something to show it is possible to use threads with Ogre :D

THANK YOU ;)
User avatar
stealth977
Gnoll
Posts: 638
Joined: Mon Dec 15, 2008 6:14 pm
Location: Istanbul, Turkey
x 42

Re: Multithreading and window events problem

Post by stealth977 »

@xavier:

I do understand your comment about scale-able threading. But what i really cant figure out is integrating OGRE into a scale-able solution:

Since most of OGRE functionality is straightforward and non-scaleable, how can one turn ogre into jobs and execute parallel? Yes there is a solution like Antodologo did, like putting OGRE's most heavy part into a separate thread, or even executing renderOneFrame() can be made a job, but both of them are not scalable solutions, since at one point, all else will need to wait for that heavy job to be completed, in order to sync (which would be another very heavy operation since we cant copy data into OGRE's very much scattered data layout...

So, what do you suggest? Whats the best way to integrate OGRE into a scaleable solution, how to quickly sync with OGRE if we wanted the rendering to be run as a job? (I am asking this since sync is a non-threaded operation and max_scaleability depends on minimum sync time)
Ismail TARIM
Ogitor - Ogre Scene Editor
WWW:http://www.ogitor.org
Repository: https://bitbucket.org/ogitor
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Re: Multithreading and window events problem

Post by Antodologo »

Hi again! :D

After two weeks playing without a crash I must say that renderOneFrame() can be executed in a separate thread safely. There are some "forbidden" operations you must avoid or delay, but if render is too slow or you need a better performance, it can be the way to go. As I said before, even with one core, our performance has increased (and quite a lot, shaders seem the main reason) because our game logic was waiting for the render to finish needlessly.

I will try to write something for everyone out there thinking about multithreading and Ogre, at least to cover the basics. I already know there is some interest but if there is a real interest I could write a detailed article.

On the other hand our solution is quite complex, we use a queue for "material operations" that don't affect game logic and virtual functions to manage data that affects game logic (position, orientation, scale and opacity). We use different update frequencies for graphics and logic too, as we needed it before multithreading to improve our logic framerate (at least over 100 fps) while keeping our graphics at 60-100fps

And about this...
stealth977 wrote:@xavier:
Yes there is a solution like Antodologo did, like putting OGRE's most heavy part into a separate thread, or even executing renderOneFrame() can be made a job, but both of them are not scalable solutions, since at one point, all else will need to wait for that heavy job to be completed, in order to sync (which would be another very heavy operation since we cant copy data into OGRE's very much scattered data layout...
First of all, nothing needs to wait until renderOneFrame() has finished. Render "should be" (that is our approach) decoupled from game logic so that no one needs to wait for render to finish. We use render as a way to show the player what is happening and nothing more. Rendering in a separate thread allows us to render as fast as needed (there is no need to update graphics above the VSync limit) while logic is updated in the other thread without knowing anything about when rendering starts or finishes.

Our implementation needs no "sync operation". So we lose almost nothing (just the virtual calls and the delayed operations over materials in a queue), we never wait to the other thread and we don't need sync. I can't see any disadvantage of our approach other than the work it needs to get it done. :wink:

Hope I have time to write about all this soon. But are you really interested in the details? Who knows :lol:
crancran
Greenskin
Posts: 138
Joined: Wed May 05, 2010 3:36 pm
x 6

Re: Multithreading and window events problem

Post by crancran »

Antodologo, did you ever get a chance to write up on your solution to multithreading?
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Re: Multithreading and window events problem

Post by Antodologo »

Hi!

Well, at least now there are two people interested :lol: I will try to write a short description of what I did and how to avoid some of the pitfalls I found. Take into account it will be a partial soltion, but it should help someone out there.

I would say for the record that we have been using this kind of multithreading for 5 months without any problems. But the initial change can be hard, you will know how hard soon :wink:
hoppelmoppel
Greenskin
Posts: 107
Joined: Tue May 10, 2011 12:33 am
x 3

Re: Multithreading and window events problem

Post by hoppelmoppel »

My solution was to do a granular sync with the scenemanager mutex when it was necessary to updade a scenemanager object. I must admit that I had to sync the complete renderoneframe call to prevent Crashes ... dunno why. But I also created some kindmof an editor where there are some longer tasks to process in parallel. Beside of this i also used a workqueue for task processing.
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Re: Multithreading and window events problem

Post by Antodologo »

hoppelmoppel wrote:My solution was to do a granular sync with the scenemanager mutex when it was necessary to updade a scenemanager object. I must admit that I had to sync the complete renderoneframe call to prevent Crashes ... dunno why. But I also created some kindmof an editor where there are some longer tasks to process in parallel. Beside of this i also used a workqueue for task processing.
Sorry I don't understand the granular sync part :P We have not faced that.

About the crashes on the renderOneFrameCall... I hope our "article" will help you understand (if you don't know what we know already :D). Basically, you can't touch Ogre's scene graph when the other thread is rendering, if you delete a scene node using one thread while the other thread is rendering (on renderOneFrame call) it will crash in a "strange" way. We will try to list several crash reasons we have found, but, of course, there will be more we don't even know about yet.

And about sync, we have a queue for some functions too, to delay the call until the render has finished. On the other hand, we synchronize positions and orientations using the physic part on every graphic update.


The "article" is getting longer than expected, it seems it will be quite "hardcore" an extensive. We just hope it is clear enough for those who want to try something similar themselves ;)
hoppelmoppel
Greenskin
Posts: 107
Joined: Tue May 10, 2011 12:33 am
x 3

Re: Multithreading and window events problem

Post by hoppelmoppel »

I would say there is a "fine" missing. So I mean, I am using a fine granular lock which protects the scene manager from concurrent accesses. Basically I am using the internal scene manager lock "OGRE_LOCK_MUTEX( m_pOgreSceneManager->sceneGraphMutex );" for protecting the scene manager. It was necessary to lock down the complete renderoneframe call and every one which would affect the scenemanager directly, like creating/modifying nodes.
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Re: Multithreading and window events problem

Post by Antodologo »

hoppelmoppel wrote:I would say there is a "fine" missing. So I mean, I am using a fine granular lock which protects the scene manager from concurrent accesses. Basically I am using the internal scene manager lock "OGRE_LOCK_MUTEX( m_pOgreSceneManager->sceneGraphMutex );" for protecting the scene manager. It was necessary to lock down the complete renderoneframe call and every which would affect the scenemanager directly, like creating/modifying nodes.
Yeah, OK. I supposed you meant that, but there are so many possibilities with programming... :D

We wanted to avoid that solution, because it means that every access to the scene manager blocks one of the threads and makes the application single threaded (again) until the render has finished. We wanted the renderOneFrame call to be executed without interruption as it is the most "expensive" (and ""atomic"") call for us.

We have delayed every call that results in creating/deleting/modifying nodes using a queue that gets executed once the renderOneFrame call has finished. But there can be problems with that solution depending on how the rest of the code is planned. If you create an object whose node does not exists yet... How do you get its position right after creation? We use the physic part for that, as all we use in our game is physical and the physic part is independent from Ogre. But it could be done storing the "last known position" in your "object" implementation (with its own problems :P)
hoppelmoppel
Greenskin
Posts: 107
Joined: Tue May 10, 2011 12:33 am
x 3

Re: Multithreading and window events problem

Post by hoppelmoppel »

Antodologo wrote:We wanted the renderOneFrame call to be executed without interruption as it is the most "expensive" (and ""atomic"") call for us.
As I already wrote above, I've locked down the renderoneframe call by locking the scene managers internal mutex. Afaik the mutex is locked already by default within "SceneManager::_renderScene" if threading is enabled. But from my experience this isn't enough. I had still some crashes within "SceneManager::_renderVisibleObjects" .. so I decided to lock down the whole renderoneframe call. By locking before rendering a frame, every modification call to the scene manager in a parallel thread should be safe now.

I also thought about delaying the modifcations to a point when the frame rendering was finished .. but I decided the descibed way is nicer ;). I created some kind of an editor app, where it's possible to add tens of thousands of plant nodes at one time .. and executing this task manually over many frames didn't seem to be the proper way to me.
Last edited by hoppelmoppel on Mon Dec 19, 2011 2:14 am, edited 1 time in total.
hoppelmoppel
Greenskin
Posts: 107
Joined: Tue May 10, 2011 12:33 am
x 3

Re: Multithreading and window events problem

Post by hoppelmoppel »

Antodologo wrote:If you create an object whose node does not exists yet... How do you get its position right after creation? We use the physic part for that, as all we use in our game is physical and the physic part is independent from Ogre. But it could be done storing the "last known position" in your "object" implementation (with its own problems :P)
The question is .. why do you need the position .. if the node doesn't exist yet? But .. the easiest solution would be to keep track of the position in an external way. A simple heap object would do it :)

If you are searching for a complicated way .. you can check this out :D http://www.ogre3d.org/forums/viewtopic.php?f=11&t=67937
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Re: Multithreading and window events problem

Post by Antodologo »

hoppelmoppel wrote:
The question is .. why do you need the position .. if the node doesn't exist yet? But .. the easiest solution would be to keep track of the position in an external way. A simple heap object would do it :)
I think we are getting too specific on details for this thread :D Maybe we should open a new thread or continue with private messages ;)

The answer to that question is "because there are multiple threads, the object exists for the control but not for the graphics". I mean, with our solution, there are two threads: one thread with all the game logic and another thread just with the renderOneFrame call. If the game logic thread creates an object , the node creation would be delayed until the graphic thread has ended rendering. The logic continues execution and the object creation has "finished" except for the graphic part (the node creation). That means that several logic frames can be executed before the render has finished, but for the game logic the object already exists because it was created before. That is why you can need its position, because the object has been created, maybe, some logic frames before, but the scene manager is yet unchanged, because rendering has not finished yet. And that is why you need the position to be in the "logic part" of the game.

Anyway, wait for the big "article" and, I hope, it will be easier to understand our point.
hoppelmoppel wrote:If you are searching for a complicated way .. you can check this out :D http://www.ogre3d.org/forums/viewtopic.php?f=11&t=67937
Nice project, but we already have our own "complicated thing" :wink: http://krakenempire.com/kromaia/media.html :lol:
User avatar
Antodologo
Halfling
Posts: 46
Joined: Tue Jul 13, 2010 4:05 pm
x 5
Contact:

Re: Multithreading and window events problem

Post by Antodologo »

We have posted a "brief" description of our multithreading implementation in our blog. I have created a new thread here to comment the post:

http://www.ogre3d.org/forums/viewtopic.php?f=5&t=68155

We hope you all can understand now what we have done and why :wink:
Post Reply