[Ohrrpgce] SVN: jay/3256 New backend interfaces, updated. Added GFX_PREFERENCES as a preference s

[Jay Tennant]

> From: Ralph Versteegen <teeemcee at gmail.com>
> Sent: Wednesday, December 30, 2009 12:36 PM
> 
> 2009/12/31 Mike Caron <caron.mike at gmail.com>:
> > Just out of curiosity, what's wrong with something like:
> >
> > GetPrefInt(name as string, optional section as string = "default") as integer
> >
> > Etc.
> >
> > --
> > Mike Caron
> 
> Called from within the backend?
> 
> Seems fine, but
> 1) the backend can parse its own damn ints
> 2) nothing is said about identifying which commandline options are for
> the backend.
> 
> Maybe we should do something like the cc linker options style of
> passing on options:
> game -gfx sdl -G,-zoom,3 foo.rpg
> or
> game -gfx sdl -( zoom 3 -) foo.rpg

I think it's a bad idea to make the backend parse command line. Perhaps a messaging system could be adopted, ie:
int gfx_SetPreference(UINT msg, UINT paramOne, VOID* pparamTwo);

Then we can define messages differently, ie:
#define OM_WIDTH 0x1
#define OM_HEIGHT 0x2
#define OM_ZOOM 0x3
#define OM_VSYNC 0x4
...etc...

paramOne could contain a 32bit value, and pparamTwo could contain a void pointer. It's just like windows messaging:
LRESULT __stdcall WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam);

with messages:
WM_SIZE
WM_KEYDOWN
...etc...

Any messages the backend doesn't know, it ignores, returning FALSE. If it processes the message, it returns TRUE.

For that matter, we could call the function gfx_SendMessage(), and allow other messages to be sent, such as:
gfx_SendMessage(OM_SETZOOM, 2, 0);
gfx_SendMessage(OM_GETZOOM, 0, (VOID*)&nInteger);

I think this is a much more flexible system then the command line options.

> > -----Original Message-----
> > From: Ralph Versteegen <teeemcee at gmail.com>
> > Date: Thu, 31 Dec 2009 07:11:41
> > To: <ohrrpgce at lists.motherhamster.org>
> > Subject: Re: [Ohrrpgce] SVN: jay/3256 New backend interfaces,
> >        updated. Added  GFX_PREFERENCES as a preference s
> >
> > 2009/12/29  <subversion at hamsterrepublic.com>:
> >> jay
> >> 2009-12-28 16:02:34 -0800 (Mon, 28 Dec 2009)
> >> 146
> >> New backend interfaces, updated. Added GFX_PREFERENCES as a preference structure. Added interfaces: gfx_SetPreferences() and gfx_GetPreferences().
> >> ---
> >> U   wip/gfx.new.h
> >>
> >
> > Wait, I don't think that this is a good idea. The more complicated
> > idea of a list of key-value pairs is much more flexible. Most of the
> > things that you've put in GFX_PREFERENCES are gfx_directx specific,
> > and you've left out things from other backends, like zoom. And it's
> > clearly beneficial to be able to add a new option to a backend without
> > having to update all the backends.
> >
> > Using key-values pairs doesn't mean having to use gfx_setoption or
> > similar. We could modify gfx_Get/SetPreferences to work on an actual
> > list.
> >
> > Also (in response to the next commit), yes, parsing command line
> > options and reading preferences is very similar, and the intention was
> > to read preferences and then pass them to the backend with
> > gfx_setoption, but if gfx_setoption is removed, we would still need
> > some way to figure out which commandline options should be sent to/are
> > parsed by the backend. What's the plan if you remove gfx_setoption, to
> > hardcode a list of options for the graphics backend? I've been
> > thinking that we should go down this route anyway, though it seems
> > undesirable.




_______________________________________________________
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
              http://www.doteasy.com