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.

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?

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.

If the game loop was not the best idea yet, then it would not be used in almost all game programming books.

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.

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.

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.

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.

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.

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.