Sign in to follow this  

A game loop idea.. Stack..

This topic is 3587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Well mostly wanted to figure out what would be the best way to do my game loop. For the most part i was thinking of makeing an STL list with pointers to the game functions so i can just add to the stack all the things that need to be done for innstance a good reason for this would be you have a function that is recursive and draws an menu coming onto the screen. by useing a stack i can push on the next movment of the menu piece and then just push on the update fucntion to draw everything. But however i think mabye thats more suited to DirectDraw rather then OpenGL But needless to say i do see may advantages to useing a stack for one after every one call to the stack you can check for input and make sure there are not Errors and act accordingly 2 you can still check for user input say if they hit escape because they want to quit or what not. also a good thing for sound as an event may happen that pushs onto the stack to play a certain sound.. Anyways one down side all the functions going onto the stack would need to be of the same type and take no paramaters or the same as the paramters of the Function Pointer. Anyways im just looking for a more elgant way to do the game loop that is powerful and more flexable then the standard ones you find in tutorials like as Nehe's OpenGL tuts. Any thoughts or sugestions please feel free to post them. Regards Jouei.

Share this post


Link to post
Share on other sites
I may just be ignorant, but I prefer a traditional game loop's structure. They seem elegant to me in their simplicity.

Why does the stack have anything to do with the menu moving? Why wouldn't a call to UpdateMenu (or whatever) be able to handle all the menu animation and input handling.

Once you query the input on a frame, the input values aren't going to change. You can reuse those values at any point in that frame, meaning you should only have to check for an escape button press in one location. Plus you should only ever query the physical input device once per frame and store the information which you can then use in your game loop (don't check the physical device everytime you want to see if a button is pressed).

I may just be missing something, but what does your method do that simply calling update methods sequentially in a game loop function can't?

Share this post


Link to post
Share on other sites
Well your actualy right about that -.^ i don't mind the tradiational game loop. At all i just wanted to see if there were any better ways to do and why.
Just Exploring other options and there pros and cons thats all. the stack was just my idea and i have skimmed through one or to books that do touch on the same kind of idea.

Regards Jouei.

Share this post


Link to post
Share on other sites
Im not dissagreeing im simply just trying to get some oppions and other thoughts. Because there is allways more then one way of doing things i never sead it was bad or liminted just sead i wanted to know what else was out there and offered up an idea and though of my own to start it off.

Regards Jouei.

Share this post


Link to post
Share on other sites
In my opinion, this idea does actually have merit. I haven't tried it, but I've been tossing similar ideas over in my head for awhile now, to deal with the issue of parallism. You'd probably end up using a stack where you don't NECESSARILY pop off the top, and have to take into account what operations you can safely parellize, but if you've got half a dozen independant operations that can go on at the same time (ie, moving a GUI box around while changing the background picture displayed or whatever), this sort of scheduling starts looking attractive, when compared with the linear way your typical game loop functions.

You can throw stuff onto the stack (that is, schedule things to occur), and then just have an intelligent scheduler that is capable of making decisions about how you dispatch jobs. I'd like to see someone work on something like this, because I don't have a multicore CPU, unfortunately.

Share this post


Link to post
Share on other sites
I agree with that statement. Having a scheduling step where you can just push a bunch of jobs into a scheduler and have it run them in parallel (you'll have to provide the scheduler with dependencies though since many jobs can't be run before others are completed) is great. I don't really see it as a stack though. The scheduling module should be able to prioritize the jobs, and run them independently of when they're requested to be scheduled.

I also don't believe that this will really affect the game loop since the jobs will most likely be smaller tasks such as:

-pose players
-update bullets
-update explosions



rather than:

-run Update loop
-run Update input
-run Render


Feel free to counter any of my points, I don't do too much parellelization or vectorization in my current job so I may have missed some important points.

Share this post


Link to post
Share on other sites
Well Dragon an idea would be simply to have items on the Stack Expire after a certain amount of time. The only problem with that would be you would have to go through the whole stack and check what its expire time is and then execute it. So if you get a larger stack then checking it every frame to see if an item had exprired and needs to be Run.

I suppose to do a basic implementation of it would not be to hard however it still is run in a linear way.

No your right i don't think the effect would be much Differnt.
As i sead it was just an idea that iv taken a fancy too lol.

Regards Jouei.

Share this post


Link to post
Share on other sites
Quote:
Original post by Jouei
Well Dragon an idea would be simply to have items on the Stack Expire after a certain amount of time. The only problem with that would be you would have to go through the whole stack and check what its expire time is and then execute it. So if you get a larger stack then checking it every frame to see if an item had exprired and needs to be Run.

I suppose to do a basic implementation of it would not be to hard however it still is run in a linear way.

Regards Jouei.


I have no idea what that has to do with what I was talking about, but if you see a place for that, go for it. I was speaking more about a situation where as game element are dirtied (the player hits a key, his character's pose now needs to be updated) you push elements onto the stack that can then be parallized later. With a situation like this, the entire stack is always emptied every frame, it can just be done in parallel rather than the usual serial method in modern loops.

Share this post


Link to post
Share on other sites
Ahh my mistake i miss understood but you do got a valid point there as well.
Im glad i got some kind of posative feed back on the Idea i was alo intrested in any other ideas other pepole have.

Regards Jouei.

Share this post


Link to post
Share on other sites
The idea of a function stack isn't as absurd as it sounds... and it's not a new idea either, having been used extensively in the pre-windows days. One of my favourite implementations was the function ring-buffer; essentially a closed-ring stack. The program iterated continuously around the ring buffer until there were no more elements, in which case the program terminated. Functions were added to or removed from the ring as dictated by functions already in the ring.

This architecture was particularly useful for GUI design and for handling user inputs in real time systems... which perfectly describe current games! ;)

Of course, when you think about it, the ring-buffer is very much like an adaptive game loop.

Cheers,

Timkin

Share this post


Link to post
Share on other sites
Thanks for the input Timkin i never claimed i came up with it first :p or that it was orgianly mine it was just a though about wether or not it would be useful enough for me actualy try and implement one in my New game im doing.

Yet again thanks.
Regards Jouei.

Share this post


Link to post
Share on other sites
This approach is the basis of Pro-actor design.

Actors post commands to be executed to dispatcher. Dispatcher maintains a thread pool (can be single thread) and whenever a thread is a available, it takes the next command from the queue and passes it to thread.

For a solid implementation of multiplexer you can use Boost::ASIO. While primarly intended for network programming, it has a fully functional standalone dispatcher.

Primary benefit of this is that threads will be used invoked optimally, trying to keep CPU busy as much as possible.

Basic programming model is simple. Create resources, post desired action with callback to dispatcher. Once the dispatcher is ready it'll invoke your callback. At that point, you can release the allocated resources.

This results in fine-grained multiplexed logic. This in turn guarantees responsiveness, good CPU utilization and remains scalable.

Downsides are inverse programming model (everything is done exactly "the other way round" as with traditional programming) which is somewhat hard to explain. A more difficult problem is lack of "sequentiality". Since everything is event driven, it's hard to maintain consistent global resources, such as world timer. Another downside is considerable overhead, which means that it's not practical to execute really small actions (increase int value, for example). Typically, you should aim to execute on the order of 10,000 - 100,000 actions per second. Less means you could use a conventional model, more means you'll have too much overhead. This last figure varies greatly, and it will scale well upwards - on multi-core processors you can assume 1 million or more.

This type of programming model is excellent for concurrent programming since it naturally minimizes shared state, possibly removing need for locks completely.

Share this post


Link to post
Share on other sites
Just to add my 2 cents -

I've spent a lot of time thinking about this over my career, and like most design decisions, I've come to the conclusion that there isn't really one "right" answer to it. Like everything else, it depends on what your goals are for the game you're working on.

What Antheus said is totally true. Decentralized models of execution for handling computation for your game are really useful for parallel architectures. But they come at some high costs. On my first game, I used some function pointer mechanisms to control logic flow, and it started to get really hairy. Debugging and tracing program flow became far more difficult, and we ended up regretting the decision in the end.

For my second game, we went in the exact opposite direction, and just coded everything linearly. Of course, this was really inflexible, and by the time we were adding triggers and more complex effects, the design didn't hold up very well.

3 more projects later, and I'm using a hybrid approach. I have a simple game loop function plus a special "ProcessManager" class which supports a more flexible way of registering new things to happen on each frame. That way, I can control the order in which the big nasty subsystems need to be updated, and my little one off effects can be dynamically added to the update path with very little hassle, if I'm willing to pay a small performance cost for them. It's working pretty well for us so far...

Basically, the ProcessManager just maintains a list of "BaseProcess" pointers, where BaseProcess has a virtual Update() function and an "ImDone" boolean which the ProcessManager checks every frame to kill the Processes off. Child classes to BaseProcess just need to know to set ImDone to true to have the ProcessManager clean them up. Any subsystem that wants to register new processes can take the ProcessManager in as a parameter and add processes to it. Then the hardcoded Update loop can decide when the process manager will actually get Updated, thereby controlling when all the Processes will be Updated. The solution isn't rock solid (handling parameters to the BaseProcess Update() function is a bit of a dirty Hack) but with some care, we're getting most of the benefits of both worlds - easily traceability on the big complex subsystems, and dynamism on small simple event-type processes. A huge benefit is integration with our level tool - designers can place level-specific processes using our level building tool, and out ProcessManager can create them when the level is loaded, but we still get to code most of the "techy" parts of the game in a straight procedural fashion.

Uh... sorry if that got longwinded. Hope it helps, though! :)

Share this post


Link to post
Share on other sites
There are good ideas here, but beware making things too complicated. This approach can become like obsessing over making the best possible glue, nails, etc. without caring about your building materials. The important thing is to make sure that the functionality of your game is properly organized (factored) so that you can drop it into either a plain or a fancy game loop depending.

In particular, pay attention to making sure that updating and rendering logic are separated. You should be able to redraw everything, or any given thing, on the screen without changing the "state" of any of the objects. (In C++, the compiler can help you a little here, if you take advantage of the 'const' keyword.)

Share this post


Link to post
Share on other sites

This topic is 3587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this