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

Thu Dec 31 14:35:40 PST 2009

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.

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

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.

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