RE: [AD] 4.3 graphic drivers

[gil04@xxxxxxxxxx]

Quoting Robert Ohannessian <ROhannessian@xxxxxxxxxx>:

> I seem to remember a couple of threads on the topic, a few years back...
> 
> I personally would vote for strings instead of #defines. This code
> doesn't need to be fast, since it's done just once at init time.


are strings any more safer ?
they offer potential for more problems.
i thought the point of structured programming languages like C was to make
things more robust.

as to 4.3 graphics drivers,  i'd really like to see a DirectX driver that offers
more video card accelerated functions.



> 
> Also, I'd like to pass an array to Allegro instead of registering the
> functions individually.
> 
> For example:
> 
> 	static const AL_VTABLE_1_0 my_vtable[] = {
> 		{ "init",  1.0, my_init  },
> 		{ "exit",  1.0, my_exit  },
> 		{ "vsync", 1.0, my_vsync },
> 		{ NULL,      0, NULL     }
> 	};
> 	
> 	GFX_VTABLE *al_vtable = create_gfx_vtable();
> 	register_gfx_vtable_1_0(al_vtable, my_vtable);
> 
> 
> Where AL_VTABLE_1_0 is something like:
> 
> 	typedef struct AL_VTABLE_1_0 {
> 		const char *function_name;
> 		float version; 
> 		void *func_ptr;
> 	};
> 
> Where 'function_name' is the name of the vtable entry. If the vtable
> prototype for that function changes, a new name should be issued.
> Allegro could then potentially implement a compatibilty layer.
> 
> 'version' is the behavior version # of the function implemented by the
> user. This way, if the behavior of a function has changed (slightly) but
> the prototype hasn't, this lets add-ons tell Allegro which behavior they
> support. Allegro could optionally do some work behind the add-on's back
> to trap and fix some old broken behaviors.
> 
> 'func_ptr' is just a pointer to the user function implementing the
> vtable.
> 
> AL_VTABLE_1_0 and register_gfx_vtable_1_0() are versioned in case we
> ever decide to change the vtable registration procedure or struct.
> 
> 
> 
> > -----Original Message-----
> > From: alleg-developers-admin@xxxxxxxxxx [mailto:alleg-
> > developers-admin@xxxxxxxxxx] On Behalf Of Peter Wang
> > Sent: Wednesday, November 09, 2005 9:25 PM
> > To: alleg-developers@xxxxxxxxxx
> > Subject: Re: [AD] 4.3 graphic drivers
> > 
> > On 2005-11-09, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> > > A while back there was a big discussion on allegro.cc on the merits
> and
> > > lack thereof for using vtables and miscellaneous other issues
> > (personally
> > > I think vtables are good and a powerful tool if used properly).
> > > Anyway, Thomas Harte suggested that it would be a good idea to have
> > > functions for creating drivers and setting vtable functions at run
> time
> > > (relevant post:
> > > http://www.allegro.cc/forums/view_thread.php?_id=531456#target).
> > >
> > > Not only will this make it easier for addon writers to write and
> > maintain
> > > code (because nothing gets broken if the driver struct is never
> touched
> > > directly and we change the struct), it's also going to be easier for
> us.
> > > Right now if we add a function to the vtable all sourcefiles on all
> > > platforms need to be edited, which is error-prone and can lead to
> > > oversights.
> > >
> > > Attached is a proof-of-concept patch against current new_api_branch.
> > There
> > > are some things that need to be worked out and rewritten for this to
> > work
> > > elegantly but so far I already find this useful. I was able to
> permute
> > the
> > > vtable entries and recompile without breaking anything (as long as I
> > used
> > > the X11 driver). I think it would be good to have a system like
> this.
> > >
> > > Thoughts/suggestions?
> > 
> > The idea is fine, but you're throwing out type safety which is
> crucial.
> > I would prefer something simpler, like this:
> > 
> >    static AL_DISPLAY_DRIVER drv;
> > 
> >    void _xwin_create_display_drivers(void)
> >    {
> >       _al_construct_display_driver(&drv);
> >       drv->init = _xwin_gfxdrv_init;
> >       drv->exit = _xwin_gfxdrv_exit;
> >       ...
> >       _al_construct_display_driver_finalise(&drv);
> >    }
> > 
> > _al_construct_display_driver() would clobber the structure it was
> passed
> > to all zeros.  _al_construct_display_driver_finalise() would check
> that
> > all the mandatory fields had been properly filled it or abort the
> > program (since that constitutes an internal implementation error).
> > 
> > The downside compared to your system is that permuting vtable entries
> > would break ABI compatibility in the case of 3rd party drivers.  IMHO
> > that's not important.  It would have broken anyway if the function
> > protypes or semantics changed, which is something much more desirable
> > for us to do than simply reordering vtable entries.
> > 
> > Peter
> > 
> > 
> > 
> > -------------------------------------------------------
> > SF.Net email is sponsored by:
> > Tame your development challenges with Apache's Geronimo App Server.
> > Download
> > it for free - -and be entered to win a 42" plasma tv or your very own
> > Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> > --
> > https://lists.sourceforge.net/lists/listinfo/alleg-developers
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
> 


--