[Ohrrpgce] SVN: jay/3270 gfx_directx backend, v1.6a; and backend interfaces, update. Added messag

[Jay Tennant]

Sent this to the wrong address... :s
Resending...

> From: Mike Caron <caron.mike at gmail.com>
> Sent: Thursday, December 31, 2009 3:54 PM
>
> Jay Tennant wrote:
> >> From: Mike Caron <caron.mike at gmail.com>
> >> Sent: Thursday, December 31, 2009 3:29 PM
> >>
> >> subversion at HamsterRepublic.com 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
> >>> ohrrpgce at lists.motherhamster.org
> >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> >> --
> >> Mike
> >> _______________________________________________
> >> Ohrrpgce mailing list
> >> ohrrpgce at lists.motherhamster.org
> >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
> >
> >
> >
> >
> > _______________________________________________________
> > Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
> > http://www.doteasy.com
> > _______________________________________________
> > Ohrrpgce mailing list
> > ohrrpgce at lists.motherhamster.org
> > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
> --
> Mike



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