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

Jay Tennant hierandel8 at crazyleafgames.com
Thu Dec 31 15:12:43 PST 2009 

> From: Mike Caron <caron.mike at gmail.com>
> Sent: Thursday, December 31, 2009 4:35 PM
> 
> Jay Tennant wrote:
> >> 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.
> 
> Did you mean complex? Messaging is more complex, IMO, than parsing a 
> command line.

Maybe complexity is relative. I've been working with window's messaging a lot, so I find it easy. I don't do as much string parsing, so I find that more complex, especially when you consider character case, matching closest strings (in case the user misspelled), etc.

> >> 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.
> 
> No, this is a proposed system whereby the OHR core parses the command 
> line, and the backends ask the core for the different options.
> 
> Yes, the messaging system allows for the core to query the backend for 
> information. But, there's other ways to do it. Just add functions to 
> query the information!
> 
> Messaging is a complex solution which works for windows because it's a 
> standard method of interprocess communication. It works so well that a 
> program written in 1986 on Windows 2.0 can send messages to a program 
> written today under Windows 7, even though the programs look nothing 
> alike internally.
> 
> In fact, this was a requirement in the design plan: Since Microsoft does 
> not control all possible applications that will run on Windows, they 
> need a very general solution to communication.
> 
> We don't have this restriction since we control all the backend 
> interfaces. If we need to query information, just query the information! 
> No need for an additional level of indirection.

Perhaps if gfx_SendMessage() changed its name to gfx_GetState() and gfx_SetState()? Really, gfx_SendMessage() is sending a command to the backend to either get or set a value. Bundling both gfx_GetState() and gfx_SetState() functions in gfx_SendMessage() helps clean up interfacing. gfx_SendMessage() is intended for use with parsed command line and parsed ini config files. After the engine determines the option, it sets it. Is it the name that throws you?

A very simple concept. Regarding the level of abstraction, the current system of the engine sending strings to be parsed in the backend is the same thing as parsing strings in the engine, then sending the result.

Taking a look at removing gfx_SendMessage(), what interfaces shall we replace it with? Perhaps gfx_SetZoom(), gfx_GetZoom(), gfx_SetWindowSize(), gfx_GetWindowSize(), etc. I think that's too many interfaces--cluttered, difficult to add in new backends, and difficult to track bugs. Perhaps gfx_SetValue(int key, int value) and gfx_GetValue(int key, int value)? Clean, much easier to maintain, and easy to add in new backends and track bugs. The cleaner the interfaces, the more structured the development. What do you propose?

> DISCLAIMER:
> 
> I am not advocating total transparency between backends and the core. 
> I'm just saying that we have the flexibility to change the interface 
> between the backends and the core at will.

I advocate a strong division between the engine and the backend. Certain, definite interfaces may be used to communicate the entities, but the entities should be largely separate. To be honest, I'd prefer if the backend would load it's own preferences/options from a resource it maintains--restrict the engine from knowing much at all about the backend. But that's not too practical considering the other backends and command line options.

> >>>>> ---
> >>>>> 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 
> > 
> > 
> > 
> 
> -- 
> Mike 




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

More information about the Ohrrpgce mailing list