Re: [AD] END_OF_MAIN removal patch for msvc

[Paul Suntsov <siegelords_abode@xxxxxxxxxx>]

If I may butt in, but reducing choice and forcing people into a single (and flawed when it comes to games, in my opinion) paradigm only to remove a single macro is not the right solution.


--- On Tue, 11/18/08, Stefanos A. <stapostol@xxxxxxxxxx> wrote:

> From: Stefanos A. <stapostol@xxxxxxxxxx>
> Subject: Re: [AD] END_OF_MAIN removal patch for msvc
> To: tfjellstrom@xxxxxxxxxx, "Coordination of admins/developers of the game programming library Allegro" <alleg-developers@xxxxxxxxxx>
> Date: Tuesday, November 18, 2008, 5:39 PM
> On Tue, 2008-11-18 at 14:48 -0700, Thomas Fjellstrom wrote:
> > On November 18, 2008, Peter Wang wrote:
> > > On 2008-11-18, Thomas Fjellstrom
> <tfjellstrom@xxxxxxxxxx> wrote:
> > > > Wait, didn't allegro specifically go to
> an event loop and whatnot to get
> > > > around this little problem? al_init()
> initializes any internal lib state,
> > > > and the event loop gives allegro time to
> "do its thing" when needed
> > > > without having an explicit
> al_update_allegro(); api.
> > >
> > > No, that's not what the event system was
> designed for and that's not how
> > > it works.
> > 
> > Probably not.
> > 
> > So whats the alternative then? Try and be too clever?
> or just export a simple 
> > update function?
> > 
> > What do you prefer?
> > 
> > > Peter
> > >
> > >
> 
> If I may make a suggestion, it might actually be better to
> make the
> event system mandatory. I am not up to date with the
> current A5 API (I'm
> only familiar with the old design docs), but in pseudocode
> this would
> look something like:
> 
> int main(void)
> {
>     al_init();
> 
>     AL_WINDOW* window = al_open_window(...);
>     al_register_event(window, AL_MOUSE_INPUT, [callback]);
>     al_register_event(window, AL_WINDOW_RESIZE,
> [callback]);
>     al_register_event(window, AL_WINDOW_CLOSE, [callback]);
>     al_register_event(window, AL_WINDOW_IDLE, [callback]);
>     al_run_events(window);   // Blocks until al_exit.
> 
>     return 0;
> }
> 
> In this case, the game loop fits perfectly inside the
> AL_WINDOW_IDLE
> event handler:
> 
> void idle(Window* window, [callback args])
> {
>     while (al_is_window_idle(window))
>     {
>         // Here goes the game loop, which looks like A4.
>     }
> }
> 
> Advantages of this design:
> 1. The event loop runs alongside the user code just fine -
> no hacks.
> 2. Clean and consistent API.
> 3. Fits modern APIs (e.g. XNA, where Shawn is working now,
> follows the
> exact same model).
> 4. Fits the way modern operating systems work.
> 
> Disadvantages:
> 1. Paradigm shift from A4.
> 2. Event-based only.
> 3. Can only be emulated in older operating systems, e.g.
> DOS (does
> anyone even care anymore?)
> 
> I know there have been extensive discussions about the A5
> api, so feel
> free to disregard any of this. However, my experience from
> coding a
> similar library is that this is the way to go.
> 
> (The library is OpenTK, which is pretty much Allegro for
> Mono/.Net.
> Indeed, Allegro has proved a great source of information.)
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> -- 
> https://lists.sourceforge.net/lists/listinfo/alleg-developers