Re: [AD] generic game loop

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


I would not agree to put a game loop into allegro. AddOn is fine: Did you
have a look at my GameFramework in the depot? There's a game loop already,
using C++ (don't see a point to not use C++ anyway). 

Another point is: A game programmer HAS to understand the game loop to work
properly with it (as I see it). So the learning goes better if he writes the
loop himself, maybe taking a copy from an example (I copied from Lennart
Steinke's book). 

BTW I totally agree to get 4.2 out with highest priority... 


> I'm of two minds here (if that's indeed a saying). On the one hand, I see 
> where this would benefit new users and help them get going properly. On 
> the other hand, it is not something I would ever use myself (mainly 
> because I already have my own module for such a thing).
> 
> I think it would be ideal for a module in the demo game and a prime 
> candidate for the Allegro+addons distribution discussed. I don't think it 
> fits well with the likes of install_allegro(), set_gfx_mode() and such 
> since it's a lot highter level.
> 
> Things to consider: how does it allow the user to specify the update rate?
> Would it be possible to lock to a specific graphical framerate instead of 
> a logic rate? Is the user code able to query the current value of the time
> counter? How does the user specify that the graphics need to be updated at
> the next opportunity (does he call a function that sets a flag, say 
> request_graphics_update(), whenever the logic dictates that a graphics 
> update will be needed)?
> 
> > The reason I think this could be in Allegro is a) the question of how to
> > do correct timing loops comes up again and again
> 
> Well, that means it should be in the FAQ... which it already is ;)
> 
> > b) im sure many users  
> > get the timing loop suboptimal even if they know what it is and c) it 
> > reminds them of the "correct" way to structure games by seperating 
> > drawing and logic code.
> 
> Good points.
> 
> > I can see a critiscm be "This is a basic part of games that people 
> > should know how to do and doesnt belong in a graphics library." but this
> > is exactly the point, its so common( or should be ) that it might as 
> > well go in a game library, which Allegro is supposed to be.
> 
> Yes - but as a `supported addon' or whatever name we would choose to give 
> to addons that are bundled with the larger Allegro distribution.
> Let's get 4.2 out of the way first though.
> 
> Evert
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> -- 
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
> 




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/