Archived

This topic is now archived and is closed to further replies.

hammerstein_02

Bad programming practice or good idea?

Recommended Posts

If anyone has seen my posts recently, this is simply a continuation.. I am on a steep learning curve here. Ok.. I have my basic program ideas worked out, have started to design the code structure, but am trying to find the most efficient way of updating all the items in my game. I am going to have an entity manager that will contain all the items in my program, no matter where they are on the map.. If they are on screen, my program will draw them. But all the objects need their details updating, moving to new positions etc (looking to create a resource management game (Railroad Tycoon, A-Train (if anyone remembers that)) obviously I have no dreams of creating Sid Meirs masterpiece or Maxis excellent game.. but I do want to create something I can call mine.. I have looked at threads and think that a background process reading through my entity managers list of objects is the way to go. What I do is in my class (I have tested with a counter program) is initiate the thread and allow to pause it. I have a static member function called Update (or whatever I call it) and create a copy of my object outside of the class. In my initialisation code for the thread I do:
  
void cMyDoSomething::Initialise()
{
	copyObj = this;

	hProcess1 = CreateThread(NULL,0,(LPTHREAD_START_ROUTINE)cMyDoSomething::Validate,NULL,0,&iID);
}
  
I do realise that I can''t create more than one of my classes this way as I will simply make the newest class be the copy.. I think.. Firstly, is this idea feasible and / or sensible? and secondly, is there a more simplistic approach I should be taking? Thank-you for your time..

Share this post


Link to post
Share on other sites
This probably isnt (IMHO) a very good way to do it. While your thread is updating all the objects, any other piece of the program (eg: the graphics routine) cannot rely on the state of objects being constant (Unless you use a mutex per object which is probably silly).

If the entity changes while the graphics routine is halfway through drawing it, the picture of the entity might end up in two pieces.

Worst case: A train blows up and dies while the user has it selected. The main program still thinks the pointer to the train is valid, and if it tries to perform an operation it, (eg: order it to do something) your program will become unstable.

So your main program cannot safely deal with any of the entities while the thread is running. This means it will probably be idle while the thread is running, in which case multithreading the entity physics is a waste.

(Exception: If:
A) You plan to run the code on a multi-processor or hyperthreading CPU.
B) You plan to use multiple threads for the update (physics) cycle.
C) The physics cycle takes a lot of time.

Then, with trepidation, you might try to code a multithreaded physics engine)


The typical way to do this is update all objects (in whatever sequence you like), from the main process/thread once per cycle.

(See the article game development 101 or something in the interactive tutorials section)

You can use multithreading for graphics, sound, network and input a lot better than for game physics, although graphics might also require some work to make it multithread-safe.

Share this post


Link to post
Share on other sites
Isn''t it going to be inefficient though, updating all the objects each cycle? In theory I could have say 20 or 30 trains on my game map, plus the towns which will need their details updating. I was looking at the thread approach because it seemed logical to check all the items in the background. I do see your point though, and will obviously try to find another way. Can any of you tell me how you do this? There has to be an efficient way..

Thanks for your time.

Share this post


Link to post
Share on other sites
You could maintain 2 copies of the attributes for the object. Define the attributes in a structure, so you dont have to actually define them twice. Then have a pointer to the most up to date version. Then once updating is done, change the pointer (which atomic action). Sure it uses more memory, but you end up using a similar arangement if you want to all the objects to update, with out causing Object A basing its actions on Object B old state, and Object C basing it actions on the new state.

Share this post


Link to post
Share on other sites
quote:
Original post by hammerstein_02
Isn''t it going to be inefficient though, updating all the objects each cycle? In theory I could have say 20 or 30 trains on my game map, plus the towns which will need their details updating.

20 or 30 is a trivial amount. Worry about it when you hit 1000.


[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

Share this post


Link to post
Share on other sites
Updating the graphics is trivial. If it''s 2D, then you just bit-blast the animation frame into place (takes almost negative time with a 2D accellerator).
If it''s 3D, then you need to render the train every frame anyway.

The stable/reliable/robust way to implement the physics, is to run the physics calculations at a fixed rate. You can still update the graphics flat-out, but every frame you check and see how many physics updates you need to do (could be 0, 1, or more).


The biggest problem with those games, is the train AI. It''s kinda like chess. You can determine the best move... if you can wait thirty minutes for the answer.

I believe efficent & correct path-finding is your primary CPU concern.

ggs, that''s an atomic sycronization method, and I think it is a good method if one wanted to tackle a multiple-processor engine. But it requires a 3 sets of attributes to pipeline & avoid any locks. One is being rendered (can''t update it), second is being updated (can''t render it), third provides a buffer between each operation so neigher one has to wait for the other to complete.

Share this post


Link to post
Share on other sites