2010/1/1 Mike Caron <[email protected]>: > Jay Tennant wrote: >>> >>> From: Mike Caron <[email protected]> >>> Sent: Thursday, December 31, 2009 3:29 PM >>> >>> [email protected] wrote: >>>> >>>> jay >>>> 2009-12-31 13:25:13 -0800 (Thu, 31 Dec 2009) >>>> 801 >>>> gfx_directx backend, v1.6a; and backend interfaces, update. Added >>>> message system to gfx backend, though I don't know how to declare void >>>> pointers in freebasic (gfx.new.bi, gfx.new_x.bi). Also added another >>>> callback sent at backend initialization: DefGfxMessageProc(). This function >>>> will handle all messages that the backend doesn't understand. It is >>>> implemented by the engine. >>> >>> As far as pointers go, 'Any' is equivalent to 'void'. So, "foo as Any >>> ptr". Obviously, cannot be dereferenced without a cast of some kind: >>> >>> cptr(foo, integer ptr) >> >> Ah. I'll get to work on fixing the interfaces. >> >>>> gfx_msg.h defines the different messages that may be sent. More can be >>>> added, but they include support for all backend's different functionality >>>> (including fb's bit depth, border, sdl's zoom, etc.). >>>> >>>> "Get" style messages are allowed and defined, too. >>>> >>>> Also added command line options functionality back into the >>>> gfx_directx--now that a messaging system is in place, these commands are >>>> parsed and sent to the new interfaces. >>> >>> I still don't know that I find the idea of messages attractive. How close >>> are these to Windows messages? Is there a queue? Do you need to maintain a >>> message pump? Can you Send Messages, or just Post them? >> >> It's a blocking send call, much like window's SendMessage(). I suppose we >> could build a message queue, especially if the backends work on their own >> thread. But a blocking call is probably better (and easier). > > Okay. Just... I still don't see the need for this at all. Windows uses > messages to facilitate communication between arbitrary programs who > could have any kind of internal structure. > > I don't think the backend system is so complex as to warrant this solution, > especially for something like command line parsing. > > A better idea would be the one I suggested yesterday, which I can now flesh > out seeing as I am now at a keyboard: > > Function ParameterExists(param as string) as integer > Function GetParameter(param as string) as string > > The command line is parsed into key/value pairs which are stashed somewhere > and recalled on demand. > > -foo bar > > key = foo > value = bar > > -baz "The rain in spain" > > key = baz > value = The rain in spain > > etc. > > As for different options being intended for different backends... What's the > problem? If backend A doesn't know what "zoom" means, it won't ask for it. >
I like that this completely removes the mystery of whether gfx_setoption may/should be called before or after gfx_init. However, it also completely removes the ability to set an option at an arbitrary time, meaning it can't be used for preferences, since we couldn't create a configuration menu when preferences are edited live. We'd need to something else to the interface, which is sounds like it will be just like either gfx_setoption, orJay's message passing. Or call gfx_close followed by gfx_init, but that seems bad to me. Also, my complaint was that invalid command line options wouldn't be noticed, but I guess that's ok. While I don't remember ever seeing a unix program which ignored invalid arguments, I guess it's the norm for windows programs. However, prehaps we should then remove all the shorthand arguments like s, z, and b - they're potentially ambiguous. w and f can stay, they're not parsed by the backend. _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
