   Is it sinful to draw as I update?
  Hey everyone,I'm working on a 2d top down shmup (using C++ and SDL), and my main game loop is currently set up in a somewhat traditional fashion: I update the position of all of the objects, and then I draw them all.If I'm worried about the cost of iterating through containers (I'm considering using linked lists), is there any reason NOT to just draw each item immediately after I update its position, check for collisions, etc? It seems intuitive to avoid iterating through the same list multiple times in a row, but I never really see things like this implemented when I read about game loops.Thanks in advance!   
  I can list a few reasons just from the top of my head:*you have to draw in a specific order: for example for transparency/batching. This order has probably nothing to do with the order of updating objects.*You want a better game loop ("fixed timestep" for example), so your display will have to be separated from the update. (because there may be more updates than displays or vice versa)*sometimes you have to do some iterations in the update: for example calculate position -> collision check ->alter position*avoiding spaghetti/messy/unmaintainable code*multiple iterations will cost negligible time. The weather will have more noticeable effect on the speed probablyI'm sleepy, and not a programmer, so just a few reasons.   ;  One problem is object dependencies and interactions... If you'll draw before something is updated by something else it'll look off.   ;  Edit: What szecs said about batchingAlso, if you want to implement some form of culling system (scene graph, quad tree etc) it would pay to split your draw and process calls. That way you can process to see if an object is on screen, and then draw all those objects seperately. For a shmup this isn't generally a huge problem, but if you wanted to make something bigger it would be.   ;  The actual cost of the list iteration itself should be a tiny fraction of total execution (unless you're using some poor implementation). Of course, for example spatial locality of memory accesses could perhaps be improved by accessing the same data in short order. However, these are low level details and the probability that they'll matter is about 0%. (Most probably a 2D shooter isn't going to be hindered by performance in the first place; if it turns out to be there are other areas of the code where to look first.)In general though, keep logic and rendering separated, you'll regret it otherwise. Code is more simple, and as has already been mentioned some more advanced aspects require separate rendering code.   ;  I can only see drawing and updating at the same time as an issue if you were using hardware acceleration, like OpenGL or DirectX, especially if you're drawing large amounts of objects. If you're just using software rendering, I think it should be just fine.EDIT: As Beyond_Repair said, it's BEST to keep it separate, since it'll come back to haunt you as your project gets larger.   ;  Just look at the dependency of ships and bullets:- you can't update and draw ships first, because later in the same update a bullet might blow one up- you can't update and draw bullets first, because later in the same update a ship might run into one and it will blow upThe "cost" of iterating through an array of items is negligible. BTW, it is even slower (though still negligible) to iterate through a linked list.   ;  It will cause you a world of pain. Trust me.You're also not going to save anything significant by only doing one "iteration". The amount of work involved in going from one element of a linked list to the next is tiny compared to the amount of work you do with each element.   ;  You could make the cost even less influential by getting ( boost? ) or implementing a suitably unrolled list.Make sure each node begins at (address%64 == 0) and is an integer fraction of 64.(de facto L1 cacheline size it would seem. Need to find that out / platform )If you can, you might even go for composition instead of aggregation. That way you could potentially avoid some needless cache misses at the cost of less entries / bundle.Im not actually too familiar with SDL, but I assume some laws of nature still apply...If thats the case, you might sort the objects you want to render according to their textures while you are doing the "update" run.After that, just render all objects sharing the same texture reference with a single call. Works nicely on DirectX world by messign with vertex buffers.Not sure about SDL though.   ;  Thanks for everyone's replies.  I figured there were a number of good reasons not to do this (since I never see game loops implemented this way in tutorials and examples), but it's really helpful to know WHY this is never done.  Much appreciated!   