192 replies to this topic

[highrise]

hey guys

I was just reading a thread over at gpinball, and they were talking about getting FP to communicate with external programs. There were some interesting ideas, and they got me thinking about extending them - and so I have this theory, which would, I think, allow you to run ROMs in FP.

So here's the idea. Firstly, in FP you set up a small image grid, consisting of small squares which can be black or white, one for each of the number of switches you need to send data out from. This would display the state of all the switches by being either on or off. Basically it would be like a little checkerboard in the corner. An external program would monitor this tiny part of the screen for changes, to know when a switch was hit, and it could then send this switch data to pinmame.

At the same time, the switch data sent from pinmame (i.e solenoid controls), would be encoded into simulated key presses - FP can read keypresses internally, and if you came up with a binary system for this, something which 'faked' keypresses, you could send it data for any switch. If you used a special system like having 'alt' pressed or whatever, it's possible it would not interfere with normal key presses. By using combinations of only a few keys, you could send quite a lot of data fairly quickly.

So basically the theory is that FP communicates with the outside word via the screen, and you can communicate with FP using the keyboard. So if you can translate these into something which talks to VPM, you will have two-way communication and thus ROM support.

I'm not absolutely sure if this whole thing would work quickly enough, but I think the theory itself is sound. Thoughts?

Edited by highrise, 04 January 2011 - 04:48 PM.

[settingsons]

hey guys

I was just reading a thread over at gpinball, and they were talking about getting FP to communicate with external programs. There were some interesting ideas, and they got me thinking about extending them - and so I have this theory, which would, I think, allow you to run ROMs in FP.

So here's the idea. Firstly, in FP you set up a small image grid, consisting of small squares which can be black or white, one for each of the number of switches you need to send data out from. This would display the state of all the switches by being either on or off. Basically it would be like a little checkerboard in the corner. An external program would monitor this tiny part of the screen for changes, to know when a switch was hit, and it could then send this switch data to pinmame.

At the same time, the switch data sent from pinmame (i.e solenoid controls), would be encoded into simulated key presses - FP can read keypresses internally, and if you came up with a binary system for this, something which 'faked' keypresses, you could send it data for any switch. If you used a special system like having 'alt' pressed or whatever, it's possible it would not interfere with normal key presses. By using combinations of only a few keys, you could send quite a lot of data fairly quickly.

So basically the theory is that FP communicates with the outside word via the screen, and you can communicate with FP using the keyboard. So if you can translate these into something which talks to VPM, you will have two-way communication and thus ROM support.

I'm not absolutely sure if this whole thing would work quickly enough, but I think the theory itself is sound. Thoughts?

Really nice idea from you highrise and the Gopinball guys. Not sure if you saw my screenshot generator I posted over Christmas but I think the principals I used could achieve something close to what you describe.

Basically the script is written in AHK rather like Hyperpin's FPLaunch wrapper. Where FPLaunch launches Future Pinball and waits for the FP window to close, my screen capture utility actually launches Future Pinball and monitors the process. Actually what happens is after FP launches my script waits for control to come back to it (once the FP tables is loaded), then I grab the area of screen specified in the ini file, dump it to files, etc. waits a few seconds to do other stuff like generate XML and then tells FP to exit by sending key presses.

We could easily adapt this to capture a small specified area of the screen and read pixel colours every n milliseconds, and send keypresses to FP (which is what I do in the screen capture util). There is even a method PixelGetColor in AHK although maybe there are better options. A prototype proof-of-concept should be easy to knock up.

Got to collects kids now, so will give it some thought.
EDIT: Just got back but have to go out again - wife given me orders!
Wouldn't the area of the screen to capture be tricky to determine. ie: depending on display mode, etc. Maybe works in cabinet mode only? I don't know FP scripting at all. Also from the FP script can window messages be read? Or can the FP script read from the filesystem? Cheers

Edited by settingsons, 04 January 2011 - 06:23 PM.

[highrise]

hey man, that sounds interesting. I think the thing to do here is try and get a few more people on board, people who know pinmame and FP especially well. But I think essentially what we need is some kind of external program which would effectively translate screen data into the Component Object Model, and then from the COM into keypresses.

I don't know enough about coding to build such a thing, but my thoughts on it are as follows:

- a small area of the screen could easily be used to create a binary stream. Although initially I was thinking of it being in black and white, it could be 8, 16 or even 32 bits per pixel, as long as FP could output it clearly. I think it is likely that you would need to tell the system what resolution you were running in, but that could be saved on the user's machine. Potentially you could create a set of say, 32 images, and have a small grid of 10 x 10 of such images. That would effectively allow you to have 400 bytes of data on screen at once. If that was outputting at 24 frames a second, thats 9600 bytes, or about 10k per second. I don't know if that is fast enough for pinmame, but I think it might be.

on the reverse side, I was thinking that the binary stream could be made up of key presses - if you can 'reserve' 64 different keys, that would allow you to send 8 bytes per keypress. I don't know how much data the keyboard buffer can handle at once. But in truth I think the amount of data that a table gets sent by a rom is fairly minimal.

feel free to drop me a pm if you'd like to talk some more, I will see if I can get a few other guys interested. One of the early solid state machines might be worth a look at. It would certainly be quite exciting if we were able to get it to communicate with pinmame.

[settingsons]

Sounds like a innovative design you have there highrise, but like you say you need the input of people who know the technologies well. I thought I would throw in the AHK idea because I only dabbled with it over Christmas as was impressed with the way it can interact with windows, etc. and compiles into a small executable. There could well be much better options. It will be interesting read some more ideas on this. Cheers

Vic

[blur]

great job guys!
actually since you can't control vpinmame com object from FP, you need man in the middle that will be able to create and control vpinmame control object on one side and comunicate with FP on the other side.


We had situation like this in our company, ancient application compiled, no source, only some scripting capabilities. It had to comunicate with the world. Of course it didn't know anything about tcpip also.

In the end we used communication through files o the disk, and we wrote another application in C++ that did communication over network on one side and from file on the other. It looks stupid but it helped us a lot. And once you put a system like that in function you can rest, no matter how stupid it is. This for example allowed us to dump all ancient x25 cards (that worked only on some ancient 10 years old pcs) and switch to tcpip.

So, wish you good luck. FP could really use some push up, specially now that we found that long expected step forward was actually step back

[Rawd]

I love what you are trying to do, and I think it is innovative and cool.

I hope it works!

[FDSystems]

Back to the Future!
& the future seems promising & brillant.

[destruk]

The Cat in the Hat Knows a Lot About That!

[highrise]

well, you know me, I'm mostly an ideas guy, I have to get other people to implement them haha. Hopefully some of you guys with a bit more coding experience might like to give it a go. I mean, if we could get a working system that communicated between FP and Pinmame, then the floodgates would open up, lots of new tables would be possible. I'm not even that fussed about playing them, it would just be fun to see if it could be done really.

[Greywolf]

Apparently, someone actually got FP to speak directly with the PinMame COM quite some time ago. Apparently it's possible, because if it weren't, it also wouldn't be able to run VBS in any way, shape or form. At least that is what I am given to understand.

[destruk]

Apparently, someone actually got FP to speak directly with the PinMame COM quite some time ago. Apparently it's possible, because if it weren't, it also wouldn't be able to run VBS in any way, shape or form. At least that is what I am given to understand.

Yeah too bad that was before FP had ramps and arcade render mode. It would be really useless to run an expired FP version now without those two features even with VPM.

[highrise]

this program was recommended to me for one side of the equation. It seems pretty interesting to me. I think it might be possible to use it to recreate an attract mode in FP, controlled by pinmame. Who knows pinmame and the COM object well enough to have a crack at it?

http://www.autoitscr...it3/index.shtml

Edited by highrise, 05 January 2011 - 11:00 AM.

[light66]

It should be possible to do this type of communication, just made a quick test, but if it's usable is another question.
I wrote a program to communicate with VPM a while ago so that part should'nt be too hard.
I'll continue the investigation tomorrow when i'm back from work, if noone else does

light

[highrise]

ok guys here is what you might call a 'proof of concept' system. Basically I have come up with a system which allows me to control 128 switches within FP using simulated keypresses, via an external script. So basically, you can send signals to the table from the outside world and have them effects things on the table.

It's an interesting 'prototype', but it's not very efficient - I would say that in its current form it is not nearly quick enough for pinmame. However, it is a step, and with interest from more experienced coders, we may be able to find a way of increasing the rate at which the data is sent.

In this demo, you will be able to see how an external script controls a light array. To run it, you will need to install AutoIT. Once you've done that, you simply run the table, press Alt-TAB to get out of FP temporarily. Then you run the script, and then click back to FP. When you do, hey presto, the script will send data to FP which in turn controls the lights.

The table and script are attached.

Here is how it works. To send a control signal to the table, I use a single byte of data for each instruction. The first seven bits of the byte tell the system which switch number it should be controlling (0 to 127), and the last bit tells it to switch it on or off.

To send this data to FP, I convert the 'byte sized' instruction into a hex number which can be anywhere from 00 to FF. To send this number to FP it simply simulates it being typed in, in hex, on the keyboard. So to send the number 255, it sends two keypresses - "FF". VP then takes those keycodes, and translates them back into an instruction, which it then executes, lighting up the appropriate lamp.

I'm actually quite pleased with the simplicity of this system, but as I said, I don't think it is fast enough. But hopefully some more skilled coders can take a look and find ways to improve it. I was thinking for example that by using 64 different keycodes instead of just 16, that we could send more instructions per keypress.

Anyway, see what you think. It's an interesting innovation I think. The obvious next step is to see if this can be linked into pinmame, which could then potentially send attract mode data to a table built in FP.

Attached Files

•  lightcontrol.zip   33.8KB   23 downloads

Edited by highrise, 06 January 2011 - 01:40 AM.

[sza]

ok guys here is what you might call a 'proof of concept' system. Basically I have come up with a system which allows me to control 128 switches within FP using simulated keypresses, via an external script. So basically, you can send signals to the table from the outside world and have them effects things on the table.

It's an interesting 'prototype', but it's not very efficient - I would say that in its current form it is not nearly quick enough for pinmame. However, it is a step, and with interest from more experienced coders, we may be able to find a way of increasing the rate at which the data is sent.

In this demo, you will be able to see how an external script controls a light array. To run it, you will need to install AutoIT. Once you've done that, you simply run the table, press Alt-TAB to get out of FP temporarily. Then you run the script, and then click back to FP. When you do, hey presto, the script will send data to FP which in turn controls the lights.

The table and script are attached.

Here is how it works. To send a control signal to the table, I use a single byte of data for each instruction. The first seven bits of the byte tell the system which switch number it should be controlling (0 to 127), and the last bit tells it to switch it on or off.

To send this data to FP, I convert the 'byte sized' instruction into a hex number which can be anywhere from 00 to FF. To send this number to FP it simply simulates it being typed in, in hex, on the keyboard. So to send the number 255, it sends two keypresses - "FF". VP then takes those keycodes, and translates them back into an instruction, which it then executes, lighting up the appropriate lamp.

I'm actually quite pleased with the simplicity of this system, but as I said, I don't think it is fast enough. But hopefully some more skilled coders can take a look and find ways to improve it. I was thinking for example that by using 64 different keycodes instead of just 16, that we could send more instructions per keypress.

Anyway, see what you think. It's an interesting innovation I think. The obvious next step is to see if this can be linked into pinmame, which could then potentially send attract mode data to a table built in FP.

Works like a charm, unfortunately it interferes with the flippers, it seems to me that every fake keypress generates FuturePinball_KeyReleased event putting flippers down. But may be of some use for attract mode maybe.... but f this is easier to realize with small script to recording all attract sequence from pinmame into a text file and just paste the text into fp script.

Edited by sza, 06 January 2011 - 11:38 PM.

[highrise]

ah, that's interesting. I guess there may be a way to overcome that, I don't know.

[settingsons]

Hey Highrise, looks like you made great progress since I last caught up in the forums. Congratualtions man and well done!

I haven't had time to try out your demo because been working long hours, etc. however I saw that you mentioned you were concerned whether it was fast enough. I guess the delay is most likely on FP side (maybe the VPF or GoPinbll gurus will know better), however there might also be a configurable delay between keystrokes sent by AutoIt. The reason I say this is the tool I used (AutoHotkey) is a direct descendant of AutoIt (or it may be the reverse but they share some source code), and I know AHK has commands to set the keypress delay, etc.

The commands might be different in AutoIT, but in AHK there are these (so you may find equivalents):

SetKeyDelay
MaxThreads 20
UseHook On

I haven't seen your demo working, so maybe the above is irrelevent, but thought it worth mentioning as I won't be freed up to try anything for a while.

Best of luck mate,

Vic

[highrise]

Hey Highrise, looks like you made great progress since I last caught up in the forums. Congratualtions man and well done!

I haven't had time to try out your demo because been working long hours, etc. however I saw that you mentioned you were concerned whether it was fast enough. I guess the delay is most likely on FP side (maybe the VPF or GoPinbll gurus will know better), however there might also be a configurable delay between keystrokes sent by AutoIt. The reason I say this is the tool I used (AutoHotkey) is a direct descendant of AutoIt (or it may be the reverse but they share some source code), and I know AHK has commands to set the keypress delay, etc.

The commands might be different in AutoIT, but in AHK there are these (so you may find equivalents):

SetKeyDelay
MaxThreads 20
UseHook On

I haven't seen your demo working, so maybe the above is irrelevent, but thought it worth mentioning as I won't be freed up to try anything for a while.

Best of luck mate,

Vic

cool - that is quite interesting. I also see that autoit supports 'keyup' and 'keydown' which means it may be possible to control switches by a single keypress rather than two. That would speed it up quite a lot I guess.

What I really need is someone who understands pinmame to see if we can translate the data.

[highrise]

I see there is a command in Auto it which lets you change the key delay but I am struggling to get it to work in a script. ANyone know the correct syntax?

http://www.autoitscr...ItSetOption.htm

[highrise]

ok guys, I made some progress.

Firstly, I used an au3 file to reduce the time between keypresses. This increased the speed by 200-300% I think. Still a bit slow but not bad.

Also I looked into the keyboard issue. There is a problem with using the shift keys - as you might imagine, it causes the keycodes to get confused. It may be possible to eliminate this issue, but for now I set the flipper keys to be 'S' and 'L', and told the switch controller to ignore these keys when building its codes.

The result was that the flippers worked fine whilst the lights were running. So it's a good step.

Next up I am going to see about using keydown as well as key up, and see what happens when I send unicode characters to FP as well.

Here is a second demo of what is discussed above.

Attached Files

•  lightcontrol2.zip   34.8KB   29 downloads