Yes I know he didn't mentioned or even indicated that he wants multithreading but the reason why I sugested this way is for him to be actually able to implement multithreading in the future if he needs it. Besides even if you have singlethreaded application you can benefit from this kinda approach all depending on what kinda game you are developing.
I didn't say that TRenderer should have acces to all applications data. What I sad is that TRenderer has acces to some ingame map data using which it can then calculate where certain images must be rendered.
@Dan now this is the bad advice. What are you suggesting is that he only moves the low-level methods used for rendering to seperate part and then calls theese from withing the game part. Your suggestion doesn't really seperate rendering part from game part since half of the work for rendering the scene is stil inside the game part.
Now when peepole decides to seperate the rendering portion of the game from the actuall game part is mostly becouse they want to be able to execute game part more often than rendering part.
For instance let us say that you have a game where you also want so do some physical simulation. What you will wan't is that physical siumulation part of the is executed quite often (maybe every millisecond). But due to rendering complexity you are not capable of executing rendering part so often. So in this case you would want rendering part and game part to be seperated and compleetly nondependant of each other.
And yes while using of multiple threads in this case would be best option becouse this way you can harnes the full power of moderndays computers it is not necessary. You can still process all of this in one thread which would still need to execute game part more often.
Bookmarks