Object Processing
I''m working on an overhead scrolling shooter, and I''m starting to work on the object processing code. I have a linked list set up that holds the objects, and I have it sorted so it''s easy to process only the objects currently in view. But I have one question about what would be considered an "acceptable" design method. I can either traverse the list once, and move the objects and draw them at the same time, or I can traverse it twice, once to move them and again to draw them. The second method would let me have seperate sections of the main loop to process objects and to draw them, which is what I did in my last game, and what most people seem to do, but it would be slower too. Is it an OK thing to do to draw the objects after processing them, thereby not drawing everything at the same time, or is it best to stay away from that and draw everything at the same time (I guess, from a design perspective)?
I''m thinking it wont make any difference, but I just wanted to get your opinions on it.
------------------------------
Jonathan Little
invader@hushmail.com
http://www.crosswinds.net/~uselessknowledge
I would do drawing and updating (moving) of the sprites in completely different threads. Set the animation thread to sleep or yield afterward and it should give you smooth animation, and relatively consistent timing.
But if I make another thread, and set it to sleep after it stops drawing, then what''s the point in having another thread at all? Plus, I don''t want there to be conflicts with the updating functions changing coordinates or anything in the enemies, and then the drawing functions drawing them before they are totally updated. (I don''t know all that much about multithreading )
Flipcode has a couple of good tutorials on creating safe thread classes. Try looking in the tutorials section.
Andrew
Edited by - acraig on 4/20/00 5:31:17 PM
Andrew
Edited by - acraig on 4/20/00 5:31:17 PM
OK, I''ll look up that info on multithreading. But before I jump into that... Back to the original question. Would it be an OK thing to do to just draw the objects as I process them?
Well, I think that it''s safer to update then draw. I''m not sure about your game, but in my games updates in one object can cause the state of other objects to change. (ex: the lever was thrown so the door now appears open.) It may not seem like a big deal, but if the door was updated/drawn before the lever then it would take slightly different amount of time than if it was updated/drawn after the lever. However, this may not apply to an shooting scroller.
I think I agree that it''s safer to draw everything after updating, after thinking about it.. Although for this game I don''t think it would effect anything all that much. The thing is, if I process enemies, then I process the player''s weapons and I find that one of the enemies was killed, the enemy wont be drawn as killed until the next time I process the enemies anyway, so it would still be drawn alive..
Maybe I''ll try it this way first, then change it if it doesn''t fit.
Thanks!
Maybe I''ll try it this way first, then change it if it doesn''t fit.
Thanks!
Aack! No offense to the previous posters, but I really think multi-threading this particular aspect of your game would be a bad idea
You really wouldn''t gain much - each thread would need to traverse the list seperately. I say only traverse the list once. I''m sure you can come up with a way to both update and draw the objects at the same time.
You really wouldn''t gain much - each thread would need to traverse the list seperately. I say only traverse the list once. I''m sure you can come up with a way to both update and draw the objects at the same time.
It''s best to draw the objects all at the same time as
1) if you have a crash in drawing to the screen, it''s easier to track where it''s happening;
2) Keeping them apart I''ve been able to debug functions without initializing the graphics (DirectX and maybe others)
Below is a section I inserted before the DX init
...
Actor *pDef = new Actor();
LoadActor("vikeevil.hpc", pDef);
pDef->PlaceActor( 10, 16);
pActorList->AddHead(pDef);
SortOnPhasing(pActorList);
pActive = pPCSet[5]; // errik
pActive->LaunchAttack(pDef, 0);
for (int count = 0 ; count < 200; count++)
pActive->DoAction(pActive, 0);
InitDirectX();
3) you track better what is displayed on top of what
4) it gives your game a more modular aspect
ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, Tile editor, diary, 3D Art resources at
Check out my web-site
1) if you have a crash in drawing to the screen, it''s easier to track where it''s happening;
2) Keeping them apart I''ve been able to debug functions without initializing the graphics (DirectX and maybe others)
Below is a section I inserted before the DX init
...
Actor *pDef = new Actor();
LoadActor("vikeevil.hpc", pDef);
pDef->PlaceActor( 10, 16);
pActorList->AddHead(pDef);
SortOnPhasing(pActorList);
pActive = pPCSet[5]; // errik
pActive->LaunchAttack(pDef, 0);
for (int count = 0 ; count < 200; count++)
pActive->DoAction(pActive, 0);
InitDirectX();
3) you track better what is displayed on top of what
4) it gives your game a more modular aspect
ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, Tile editor, diary, 3D Art resources at
Check out my web-site
Debugging is not a concern, since I''m running a multiple monitor thing now, so I can use the VC++ debugger, and track where problems are very easily. I am now implementing it to process and draw individual parts at the same time (as in process and draw enemies, then process and draw powerups, etc.) because that way I only have to traverse each list once, and I''m more concerned with performance than modularity.
Thanks everyone!
Thanks everyone!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement