I notice it’s idiomatic to have separate drawing and updating methods for objects in XNA. I’m guessing that I’m expected to have a list of objects, and loop through that list twice, one in the main Update method and once in the main Draw method. Is that really the case? Because that seems extremely inefficient, and indeed this is what I was doing in my old game engine (Not based on XNA, MonoGame or any related framework), in which, after I combined their Update and Render methods, my engine could support several times the objects it used to when the methods were called through two iterations.
Is it considered normal to essentially iterate through all the game objects twice? Or is there a better way to handle that? Should I just call everything’s Draw method in the Update loop?
Do you want game logic to be affected by FPS? Because that´s how you get your game logic bound by fps and I can´t imagine something more unprofessional than that. Having separate update and draw loop is correct approach.
It is not a big deal to iterate through some hundreds or thousands of items twice.
Update affects Draw, because it is possible that the first object should not be drawn because of a special game logic, but if you instantly called Draw after the first Update, you would draw somthing that you should have.
It is perfectly possible that an object should only be Updated, but not Drawn. In a perfect world, you would only draw those objects that can be seen on the screen, however you may need to update all of them, or some of them, or…well…none of them. It all depends on your game logic.
I know about drawing and not updating, and vice versa. I just put a conditional in my object’s main update method, which worked pretty well. But I guess I’ll try separating their methods again and see how well it performs in my engine’s rewrite.