16 replies to this topic

[BilboX]

[EDIT]

 Moved in "Work in Progress section".

 

Current State:

 

  // DRIVERS

 // Status: Not Applicable to UP?

  public static extern Result PRDriverWatchdogTickle(IntPtr handle);  

 

// Status: DONE (Seems to work correctly)

  public static extern Result PRDriverGetState(IntPtr handle, byte driverNum, ref DriverState driverState);

 

 // Status: DONE (Seems to work correctly) 

 public static extern Result PRDriverUpdateState(IntPtr handle, ref DriverState driverState);

 

// Status: TODO ? (Is it applicable?)

  public static extern Result PRDriverUpdateGlobalConfig(IntPtr handle, ref DriverGlobalConfig driverGlobalConfig);

 

// Status: DONE (Seems to work correctly)

  public static extern void PRDriverStateDisable(ref DriverState state);

 

// Status: DONE (Seems to work correctly)

  public static extern void PRDriverStatePulse(ref DriverState state, byte milliseconds);

 

      // Status: DONE (Seems to work correctly)

  public static extern void PRDriverStateSchedule(ref DriverState state, UInt32 schedule, byte cycleSeconds, bool now);

 

      // Status: TODO

  public static extern void PRDriverStatePatter(ref DriverState state, UInt16 millisecondsOn, UInt16 millisecondsOff, UInt16 originalOnTime);

 

      // Status: TODO

  public static extern void PRDriverStatePulsedPatter(ref DriverState state, UInt16 millisecondsOn, UInt16 millisecondsOff, UInt16 patterTime);  

 

    // Status: TODO (Used?)

  public static extern void PRDriverFuturePulse(IntPtr handle, byte driverNum, UInt16 milliseconds, UInt16 futureTime);

 

          // Switch & Event Methods //

 

   // Status: DONE (Seems to work correctly)

  public static extern int PRGetEvents(IntPtr handle, [In, Out] Event[] events, int maxEvents);

 

      // Status: TODO (Is it applicable?)

  public static extern Result PRSwitchUpdateConfig(IntPtr handle, ref SwitchConfig switchConfig);

 

      // Status: DONE (Seems to work correctly)

  public static extern Result PRSwitchUpdateRule(IntPtr handle, byte switchNum, EventType eventType, ref SwitchRule rule, DriverState[] linkedDrivers, int numDrivers, bool drive_outputs_now);

 

      // Status: TODO   public static extern Result PRSwitchGetStates(IntPtr handle, [In, Out] EventType[] switchStates, UInt16 numSwitches);

 

              // DMD Methods // 

 

  // Status: DONE (Rough implementation for standard DMD)

  public static extern Result PRDMDDraw(IntPtr handle, byte[] dots);

 

  // Status: DONE (Rough implementation for standard DMD)

  public static extern Result PRDMDUpdateConfig(IntPtr handle, ref DMDConfig config);  

 

[/EDIT]

 

Hi. I just looked at NetProcGame and tried to figure out which will be the better way to plug in UP.

 

Think I found but it is going to tak ea while. And I a m not sure about the result, mostly in terms of performances...

Will see. But indeed, this nice framework already includes a lot things for orignal tables...

Edited by BilboX, 16 July 2015 - 08:35 AM.

[chepas]

 

But indeed, this nice framework already includes a lot things for orignal tables...

 

Yes this nice framework is actually the BEST framework for any pinball table so far I've used, whether you're re-theming onto an existing game or original game.

 

You wouldn't have to use every part of it but take a look at things like the "trough". Maybe extending some methods into the subway for this, like ball searching, ball save system (with early save switches), and keep a better track of balls.

 

Modes are a great way to manage a game with a set priority and how the dmd builds layers.

 

Base mode priority 0

Score layer priority 1

TargetsMode = 2

Bumpers = 2

Multliball = 10

 

Multiball could contain switchcallbacks for the Leftinlane along with the base mode but you should also be able to stop this switch from continuing through the lower modes.

 

The way other scripting for FP or VP original games always rely heavily on a whether a lamp state is on/off. This isn't good but instead include an UpdateLamps that you can use in every mode that gets called by the base and updates all UpdateLamps.

 

Mode:Multiball

 

void UpdateLamps

{

 if (isActive)

  multiballLamp.state = true)

else

 multiballLamp.state = false

}

 

If this mode was active and enabled it could get called from BxOriginalTable.UpdateLamps() (when you choose too) , which runs all updatelamps in modes if active

 

Relying on game variables rather than game lamp states.

 

Nice one.

Edited by chepas, 11 July 2015 - 04:45 AM.

[BilboX]

Well, I will not enter too deep in NetProcgame, but just link where it has to.

 

Actually, UP will be seen by NetProcGame "almost" as a Proc Device. This is the simpler way to connect and worth a try because everything in Netprocgame would be available.

So you would have a "regular" UP script defining the "hardware" part of the machine, and the netproc script defining the "logic" of the game.

 

The benefit will be that just recompiling the netproc script with regular NetprocGame dll will allow to switch to a REAL pinball machine.

 

The topp of the top would be to interface not just on NetProcGame, but to do a custom pinproc.dll. This way, both C# NetProcgame AND regular Python libprocgame would be compatible. Maybe will it come later, because it's a bit harder to do.

 

I hope this will work good enough and that I will manage time to do it...

[chepas]

Wow, yeah if you want to take it up 10 levels, by all means do . That would be awesome to work on a game in UP and port over and use on a real board.

 

Already tried the dll myself before asking, but presuming we can't import any dll.

 

Main thing netprocgame has been missing for me is a way to use a "FakePinproc", so I always stuck to python.

 

You did know there is a bridge for regular pyprocgame using pinmame? It was suggested to me that I register up to your "GUID" and try that way for python. I saved myself the time because I know your pinmame.dll is custom. Hooking up to the python code through COM or OSC would maybe be an easier way.

Sub LoadVPM(VPMver, VBSfile, VBSver)
    On Error Resume Next
    If ScriptEngineMajorVersion<5 Then MsgBox "VB Script Engine 5.0 or higher required"
    ExecuteGlobal GetTextFile(VBSfile)
    If Err Then MsgBox "Unable to open " & VBSfile & ". Ensure that it is in the same folder as this table. " & vbNewLine & Err.Description
    Set Controller=CreateObject("VPROC.Controller")

class Controller:
    """Main Visual Pinball COM interface class."""
    _public_methods_ = [    'Run',
                'Stop',
                'PrintGlobal']
    #_reg_progid_ = "VPinMAME.Controller" #original supplied name conflicts with the visual pinmame dll
    #_reg_clsid_ = "{F389C8B7-144F-4C63-A2E3-246D168F9D39}" #original supplied class id matches vpinmame.dll
    _reg_progid_ = "VPROC.Controller" #rename to Visual PROC Controller
    _reg_clsid_ = "{196FF002-17F9-4714-8A94-A7BD39AD413B}" #use a unique class guid for Visual PROC Controller
    _public_attrs_ = [  'Version',
                'GameName', 
                'Games', 
                'SplashInfoLine',
                'ShowTitle',
                'ShowFrame',
                'ShowDMDOnly',
                'HandleMechanics',
                'HandleKeyboard',
                'DIP',
                'Switch',
                'Mech',
                'Pause',
                'ChangedSolenoids',
                'ChangedGIStrings',
                'ChangedLamps',
                'GetMech',
                'Sys11']
                
    _readonly_attrs_ = [    'Version', 
                'ChangedSolenoids',
                'ChangedLamps',
                'ChangedGIStrings',
                'GetMech']
    
    Version = "22222222"
    ShowTitle = None
    ShowFrame = False
    ShowDMDOnly = False
    HandleKeyboard = False
    DIP = False
    GameName = "Game name"
    switch = [True]*128
    lastSwitch = None
    Pause = None
    Sys11 = False
    ACrelayNumber = 12
    
    game = None
    last_lamp_states = []
    last_coil_states = []
    last_gi_states = []
    
    mechs = {}

    HandleMechanics = True
    GameIsDead = False
    ErrorMsg = "Python Failed -- check the log"

Edited by chepas, 11 July 2015 - 10:41 AM.

[BilboX]

Yes i saw and dwonloaded everything to do that but I'll go the c# way...

 

I will post advancement on this topic.

If you have some test NetProcGame.game.controller game, corresponding machine.json and some dmd file already running in standalone (with real p-roc device), that will help me a lot.

I would then not have to learn fully the NEtProcGame API...

 

Thanks for your help. Continue converting tables

[chepas]

Sweet, you won't regret it

Someone was working on a game that used Unity for display, I'm presuming with netproc. They could help you there. I'll give him a message for you and point this way.

[mocean]

If you would like help getting the Python variant working, let me know. It is advantageous to do so for many reasons, certainly one of which is the fact that games such as Cactus Canyon Continued are running on top of PyProcGame. The VPCOM bridge is already providing a significant subset of the VPinMame COM API that is expected by Visual Pinball; it couldn't be much work for someone (me!) to adapt things to work for Unit3D. I also have Python code to test a game against if we have a simulation of T2 (!), SoF, Earthshaker or F-14 in Unit3D.

Edited by mocean, 11 July 2015 - 10:14 PM.

[chepas]

I have an F-14 but missing em kicker. It needs some work but will do the job. They have a T2 regardless.

[BilboX]

If you would like help getting the Python variant working, let me know. It is advantageous to do so for many reasons, certainly one of which is the fact that games such as Cactus Canyon Continued are running on top of PyProcGame. The VPCOM bridge is already providing a significant subset of the VPinMame COM API that is expected by Visual Pinball; it couldn't be much work for someone (me!) to adapt things to work for Unit3D. I also have Python code to test a game against if we have a simulation of T2 (!), SoF, Earthshaker or F-14 in Unit3D.

 

Go if you want and if it is not much of integration than changing the VPinMame.Controller to *.Controller, because I am integrating NetProcgame. Download T2, everything is setup on the "Hardware" side.

If we manage to do it, we will then provide both python AND C# linking... But remember, I just want the Python to be a VPM "ghost"... Good luck, and thank you!

[mocean]

Okay, I changed the ProgID and the clsID in the Python COM bridge to the VPinMame values:

    _reg_progid_ = "VPinMAME.Controller" #original supplied name (as as visual pinmame dll)
    _reg_clsid_ = "{F389C8B7-144F-4C63-A2E3-246D168F9D39}" #original supplied class id matches vpinmame.dll

 

T2 crashes; output is this:

========== OUTPUTING STACK TRACE ==================

(0x006F0069) ((module-name not available)): (filename not available): (function-name not available) + 0x0
(0x04E63B6B) (Mono JIT code): (filename not available):  (wrapper cominterop) VPinMameTypeLib.ControllerClass:get_Version () + 0x3b (04E63B30 04E63B7C) [046B4E70 - Unity Root Domain] + 0x0
(0x04E625E1) (Mono JIT code): (filename not available):  (wrapper cominterop-invoke) VPinMameTypeLib.ControllerClass:get_Version () + 0x21 (04E625C0 04E62601) [046B4E70 - Unity Root Domain] + 0x0
(0x04E5DF71) (Mono JIT code): (filename not available):  BxVPMTableManager:InitVPM (string,int) + 0x69 (04E5DF08 04E5E1C6) [046B4E70 - Unity Root Domain] + 0x0
(0x04E546A1) (Mono JIT code): (filename not available):  t2_l8_TableManager:Init () + 0x89 (04E54618 04E54C54) [046B4E70 - Unity Root Domain] + 0x0
(0x04E5448B) (Mono JIT code): (filename not available):  Script:Init () + 0x53 (04E54438 04E544A5) [046B4E70 - Unity Root Domain] + 0x0
(0x04DAF549) (Mono JIT code): (filename not available):  (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) + 0x41 (04DAF508 04DAF59D) [046B4E70 - Unity Root Domain] + 0x0

Is that a failure to find the COM get_Version() or some function thereafter?  If it's a failure to get the Version attribute, then it's clearly failing at the very first COM API call...  

 

Thanks!

- Michael

[BilboX]

Which version of VPM is it based on?

UP Beta is based on 2.6 with DIL exported.

Maybe the wrapper is for another version. As there where new functions since, maybe this comes from here.

 

You can try with the "alpha" version of UP and T2... 

[BilboX]

Okay. I have some news.

 

So far, I did most important Drivers functions, Switches functions and DMD functions. (Check edited first post for Status).

Rules seems to work too. So, to be clear, I managed to have an attract mode working (base dmd + lightshow), flippers (Activable/Unactivable), Slingshots, etc...

 

I don't see why there would be other problems with NetProcGame higher level classes, as pretty much everything is integrated.

 

TImings can be slightly different than on real hardware of course, mainly because I used Coroutines...

 

I hope I understood all the internal mechanisms...

 

BUT, I am afraid DMD's update will be veeeeeeery long for bigger ones (Width*Height*SubFrames)!!!. Maybe some C dll would be helpfull there... neeeds to be tested.

 

Will be available in next release for test purposes...

 

 

PS: Don't know how Color DMD's are working....

[chepas]

Nice one Bilbox good work!

 

Are you referring to the display controller on the board?

 

One thing the netprocgame never had was a "fake desktop", you would have  a better idea then, this is why I offered to send you a python version of a game so you could see how it works with external display like pygame or panda3d.

Hope Micheal can give you some more information, but what you have to understand is, I don't think many people used the (dot matrix) display controller directly from the board. Basically need your own inside unity.

Can you import all the yaml configs?

 

It will be cool to hook up to the FP light sequencer you have imported and create p-roc lampshows from this. This is hard from VP because the light sequencer is different from the actual lamp states, so you can't log the sequencers on/off state.

Edited by chepas, 16 July 2015 - 09:10 AM.

[BilboX]

Duh oO.

 

For NetProcGame, it is not yaml but json, am I right? If yes, then it works. It creates drivers, switches and rules...

 

I did not "imported" Light sequencers but recreated one based on FP exposed functions (was a long work BTW). As it is geometrically based sequencers, it is, indeed, simpler to use.

So you would like to run a "FP Like" sequencer then record it to generate the "lampshow" files?

[chepas]

Machine configs (switch, lamp,coil) & lampshows are yaml in any game I have seen, including all of mine.

 

In the netprocgame he has a yaml serializer anyway?

 

Yes, I'm saying that whatever LampSequencer function you have ported or made your own , will be very easy to log them to yaml or json, whichever you decide to use.

 

Lamp1 | .     . ...    .   .   ....   .. 

Lamp2 |    ..    .   .  .   . ...   .. 

CoilFlash| ..    ...  . .  . .  . .  . . .

 

http://pyprocgame.pi...w#lampshowtrack

 

It would be great as a make do lampshow generator. I have toyed with making them with a timeline before in an app but that was a while back and never finished. Doing by hand is a PITA and most of my games miss a few because it is a boring process.

 

Probably wouldn't even need netprocgame to do this anyway, but haven't tried the sequencer yet.

[mocean]

Sorry to have dropped off on this. Just went to revisit it.

The VPROC.Controller is a much older VPinMAME interface and does not support the methods provided in 2.6.

https://github.com/j...whatsnewVPM.txt

My interest is in support for the "full-color" PyProcGameHD/SDL2 fork and I'm not sure how I would implement these methods in many cases. My "dots" (pixels) are 32b each for color and not backed by an easily accessed per-pixel data structure, since they are assembled and composited directly in the GPU as textures.

I could probably support these dmdPixel functions for transitional dmd display in PyProcGame, but that's a lot less fun than PyProcGameHD.

Running against the alpha did not work either. I don't know enough about Unit to make sense of the crash reports to understand where the failure was, and trying to debug the issue in the alpha version is probably pretty pointless anyway.

I'll try to provide some empty stubs for these methods and see what happens, but I'm not very optimistic.

[chepas]

Back on the case!