quote:
But I also mentioned that this is utterly impractical in a well designed OOP based engine. As you basically have to break all the design rules of the engine
I don''t see the slightest problem. As Vincoof said, there is no generic miracle way. Each type of engine has it''s own optimal implementation. And if you design it flexible enough, there''s no problem to include such a feature.
quote:
And you cannot redesign an engine so that half way through rendering an object (a lens flare), it will stop to let all the physics, gameplay cpu stuff go ahead.
Why not ? Works very well for me. Good thread synchronisation is all you need. Of course, you have to include those possibilities (grpahics/physics/AI hooks) from the beginning on, otherwise you are right, it might be difficult to add.
quote:
The only thing you could do is to put the rendering on a seperate thread, but this is not a good thing, as you may well get overlap of updated, and non-updated data, which would lead to a lot of potential crash situations when objects are being destroyed.
You put your physics in a seperate thread. If you get overlap, means that your physics data isn''t double buffered, wich is a design flaw. And if you get crashes, than you don''t have a good thread management. If done properly, there is absolutely no problem in multithreading those two points.
quote:
as I said, it''s ok for demos, but not in larger projects.
I use it as part of a very complex commercial 3D engine. No problems, so far.
