Main > Software Forum

Triggering a real knocker for Q*bert SOFTWARE SOLUTION

<< < (4/5) > >>

RandyT:

--- Quote from: AaronGiles on August 15, 2006, 08:42:34 pm ---So I went ahead with this plan and implemented it the other day. It got a little more complicated than I initially thought because you are pretty limited in what you can pass between applications using Windows messages, but I got it working pretty well. The LED code is no longer in MAME. Instead I created a sample code application called ledutil.exe that you can run in the background. It listens for the "led0", "led1", and "led2" outputs, and controls the keyboard LEDs that way. You can also use that code as a starting point for more complex output management.

--- End quote ---

Aaron,

I'd like to start by saying the usual, "Thanks for all that you do" and this applies in spades for this addition.

But I'd also like to make the observation that the communication scheme seems a little unnecessarily complex.  If I understand correctly, the following is approximately what happens (CAUTION: I'm big on metaphors. :) )

1: MAME broadcasts an "open for business" message to everyone in the world.
2: MAME waits for interested customers to subscribe to the service
3: MAME then sends a "gizmo" without telling the customer what it is.
4: The customer then asks MAME what the "gizmo" is.
5: MAME then identifies the "gizmo"
6: The customer then remembers the name of the "gizmo", in case MAME sends another one.
7: If the customer doesn't want anymore "gizmos", it can "unsubscribe" at any time.
8: When MAME closes shop, it sends an "out of business" message to everyone in the world.

So, I guess my question is: why so many steps?  Why not use the following (more metaphors);

1: MAME looks for customers who have already expressed interest when it "opens for business"
2: MAME sends them the "gizmo", with everything the customer needs to know about it.
3: The customer can lose interest at any time.
4: MAME can inform only it's interested customers that it is "out of business."

or, in less abstract terms;

1: Use the FindWindow API function to find open (but most likely hidden) windows  with a very specific name. IE. MAME Output Receiver
2: Use the FindWindowEX API function to get the handle of the only textbox on that form and use the SendMessage API with WM_SETTEXT to send the output name and state information to it.  This will trigger a text change event so that the the outputs can be acted upon by the 3rd party software/hardware.
3: The client can close the "MAME Output Receiver" window when it is no longer interested in receiving output data from MAME (or just stop acting on it.)
4: MAME can send a "MAME Exit" command to all open "MAME Output Receiver" windows to allow them to reset, if required.

Is there some major functional disadvantage to the simpler approach that I'm not seeing?

Thanks,
RandyT


AaronGiles:

--- Quote from: RandyT on August 19, 2006, 12:43:58 pm ---Is there some major functional disadvantage to the simpler approach that I'm not seeing?

--- End quote ---

Yes, you will lose signals with your proposed approach. What happens if multiple outputs are changed at the same time? We will try to change the edit box text twice and lose the first input. Or what happens if the listener app doesn't get around to noticing the change before another change happens? Without any kind of acknowledgement cycle, you will lose inputs your way. And adding an acknowledgement system will just complicate it back to about the same level the current system is.

You could argue that the problem might be avoided by using SendMessage, which waits for the message to be processed, but I deliberately don't want to do that because then MAME would be stuck waiting for some other application to do something. The current model from MAME's perspective is very easy: fire and forget, completely asynchronous except when an ID to string mapping is requested, which should only be the first time a signal is reported.

Also, FindWindow only has a means for you to locate one window. What if multiple clients want to be supported? That's why I prefer that clients contact MAME to register when they come up. The current implementation supports multiple clients.

Howard_Casto:
Agreed.  I can see the people complaining when they can't get "application x" to work only to discover that they installed your ledutil in the startup folder.  This way lots of stuff can interface at once. 

Still having trouble with the copymemory part though, it might be vb thing, I don't think it likes the dataformat you've saved the string in. 

I've gotta agree with randy on the settext thing.  I don't think it should be used constantly, but immediately upon bootup mame should send registered clients all the output names followed by their id numbers.  Since the game hasn't started yet, it shouldn't effect emulation.  Also remember, that you can also send settext to the commandline string, so no textbox necessary. 

As-is it seems to cause some minor issues. For example, say you are handling warlords.  All the lights flash at once, so when you get the first light you ask mame for the name and it seemingly "forgets" about the rest.  So for the first flash or two you don't get a totally accurate output.  This only happens with games that flash stuff quickly, unfortunately most do flash stuff quickly.

At the very least, when mame sends that startup call it would be nice to get the total number of outputs along with that hwnd message, then an array to store the data can be built and filled as input changes come in. 

RandyT:

--- Quote from: AaronGiles on August 19, 2006, 03:40:29 pm ---
--- Quote from: RandyT on August 19, 2006, 12:43:58 pm ---Is there some major functional disadvantage to the simpler approach that I'm not seeing?

--- End quote ---

Yes, you will lose signals with your proposed approach. What happens if multiple outputs are changed at the same time?

--- End quote ---

I had thought that perhaps a single string representing multiple outputs could be used, somewhat along the lines of what Howard had suggested earlier.  This approach allows for output changes to be reported in parallel, rather than serially.


--- Quote ---We will try to change the edit box text twice and lose the first input. Or what happens if the listener app doesn't get around to noticing the change before another change happens?

--- End quote ---

I can understand that concern, but I would hope that the listener app would be fast enough to catch the commands and perhaps spool them if it was necessary.  If the app were slow enough to miss commands, I'd have to wonder if the output states would continue to have relevance due to the lag in the app actually being able to act upon them. 

Also, is it possible for an application to receive a system message so quickly that it fails to execute the code that is programmed to fire when the event is triggered (IE.a Text_Change event?)  Are these not queued as well?


--- Quote ---The current model from MAME's perspective is very easy: fire and forget, completely asynchronous except when an ID to string mapping is requested, which should only be the first time a signal is reported.

--- End quote ---

I agree that whatever the solution, it should be "fire and forget" from the perspective of MAME.  I would also like to second the idea of getting the ID definitions out of the way before game time.  I had thought that perhaps MAME could generate a file on demand with all currently defined outputs and their associated ID's for import into the listener software ahead of time.  I don't really know if that approach is tenable, but there would be no surprises or need to interrupt flow.


--- Quote ---Also, FindWindow only has a means for you to locate one window. What if multiple clients want to be supported? That's why I prefer that clients contact MAME to register when they come up. The current implementation supports multiple clients.

--- End quote ---

This is true.  I suppose each listener app could use a specific prefix to identify it and a unique suffix (app name) to differentiate it, but it might be a trick to get all of the window names and find the ones of interest.  I'm not well versed in low level OS function, so I don't know for certain what is even possible there.  Just thinking out loud in case anyone finds any value in it....

RandyT

Howard_Casto:
Randy I've been testing and some of the games send data insainly fast.  I mean insainly fast, like 1ms, possibly less fast.  Particularly the games with flashing coin lights like digdug.   I think making an app that would be too slow to keep up, even with buffering is more likely than you think. 

Which is why I was concerned about the current method of getting the id tag after the fact. 

I'm wondering if this step is even necessary.  I know nothing is standardized YET but might it make more sense to have the idnum for led1 be the same for every game and just include a id3tag-like list of all the possible names based on the idnumber?  You are using a 5 digit number, so it isn't like we are going to run out of tags.  More could be added as more types of labels are added. 

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version