Jay Tennant wrote:
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.
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
[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
--
Mike
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
