Sent this to the wrong address... :s Resending... > From: Mike Caron <[email protected]> > Sent: Thursday, December 31, 2009 3:54 PM > > 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.
True, the backend is not to be a complex entity. I agree with simple interfacing. Yet I'd have to disagree in that messaging (without queues) is a simple solution. More so than string 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. Is this parsing that the engine is doing? If so, how would the parsed info make it to the backend? If not, does the backend implement those functions--thus manage the parsing? How does a backend "ask" for an option? There aren't any callbacks currently that support that ability. Are you proposing a new callback? Or are you referring to the current mechanism of returning 0 if the backend doesn't understand the string? Serializing data is fine. A bug may appear if a backend parses string differently. If the engine were to understand the string request, it could alert the backend of possible options in a definite key and value, as gfx_SendMessage() proposes. This is also moving in the direction of .ini files that save preferences. The gfx_SendMessage() method allows values to be returned. Currently, there isn't another method that returns possible option values. > >>> --- > >>> U wip/gfx.new.bi > >>> U wip/gfx.new.h > >>> U wip/gfx.new_x.bi > >>> U wip/gfx_directx/source/gfx_directx.cpp > >>> U wip/gfx_directx/source/gfx_directx.new.cpp > >>> U wip/gfx_directx/source/gfx_directx.new.h > >>> U wip/gfx_directx.dll > >>> A wip/gfx_msg.h > >>> _______________________________________________ > >>> Ohrrpgce mailing list > >>> [email protected] > >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > >> -- > >> Mike > >> _______________________________________________ > >> Ohrrpgce mailing list > >> [email protected] > >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > > > > > > > > > > _______________________________________________________ > > 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 > > -- > Mike _______________________________________________________ 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
