> From: Ralph Versteegen <[email protected]> > Sent: Wednesday, December 30, 2009 12:36 PM > > 2009/12/31 Mike Caron <[email protected]>: > > 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 <[email protected]> > > Date: Thu, 31 Dec 2009 07:11:41 > > To: <[email protected]> > > Subject: Re: [Ohrrpgce] SVN: jay/3256 New backend interfaces, > > updated. Added GFX_PREFERENCES as a preference s > > > > 2009/12/29 <[email protected]>: > >> 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 _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
