21 replies to this topic

[pilotniq]

I realize that making Visual Pinball portable (meaning that the code can be built for other operating systems such as Linux or OS X) is a huge undertaking. But I think it is a good long-term goal. If nothing else, it would save $100 per cabinet build in not having to buy a Windows license.

 

I watched an interesting talk on how Valve ported their games from being Microsoft dependent (http://www.tomshardw...port,21876.html). Basically the strategy was to move the window and some OS functionality to SDL (Simple DirectMedia Layer, https://www.libsdl.org/), and they built a library called 'ToGL' which is a DirectX 9 API implemented in OpenGL for the graphics. ToGl has been released on github (https://github.com/ValveSoftware/ToGL).

 

I know there's much more that would need to be done for Visual Pinball (table scripts, COM interfaces, Visual PinMAME, ...).

 

How would the developers (and the community) feel if someone were to start on this path, and for instance start moving the Windowing functions to SDL? Would you accept patches conveting VP to SDL?

 

 Is this the right forum for such a discussion?

 

 

 

[toxie]

IMHO this is only the easiest part of the problem.

If you wanna start with something then you should rather start with the hardest part first: figuring out what could be done for all the scripting (incl. communication with VPM), and all the windows-specific messaging and input handling going on during gameplay. Cause otherwise all the easy work upfront would have been wasted (incl. potentially more performance overhead that was introduced due to that).

 

On top of that there is also all the windows-hardcoded UI stuff, but there at least one could argue that the UI would not be that important, and its enough to have just a simple player for other platforms.

 

But no matter what, if you wanna try your luck, create a branch from the SVN/VP10 and fool around with things. But please try to keep the branch up-to-date and merge the changes from trunk frequently.

 

EDIT: Don't get me wrong, if you can pull of a 2nd Mukuste, i'm the first to cheer. 

Edited by toxie, 17 December 2014 - 04:46 PM.

[Slydog43]

great addition to the end of your response toxie, I was thinking the same thing as I read your post.  Please come back Mukuste

 

Not that I don't appreciate all the work Toxie and others do on VP, thanks always

Edited by Slydog43, 18 December 2014 - 03:15 AM.

[sleepy]

Getting off the VBA-Only Scripting by implimenting javascript in the code might help, especially with any potential for using HTML 5 and the Canvas Object for a Player.

But I am not sure about the overhead in using HTML 5.

[mukuste]

Bit late to this, but it's something I have thought about a lot.

 

*) Major obstacle is IMO scripting. You'd need to change the scripting language. My preference would be Lua since it's basically the industry standard for game scripting, as well as small, light and simple to embed. JS could also work, I guess. But the main problem here is that all tables would have to be redone, scripting-wise, as well as having to re-educate the community about scripting in a new language. So this issue is IMO more social than technical, which is always scary. If we could integrate a second scripting engine in parallel so that old tables still work while new ones can be developed in the new language, that would probably be the best way.

 

*) VPinMame integration. This uses COM objects now. Probably a simple (assuming) Lua extension which either has VPM compiled in or calls into VPM, for now, via the existing COM interface should do the trick to get rid of this dependency. Of course, at some point VPM itself needs to be ported to work outside of Windows and I don't know how much work that is, but pushing the COM dependency out of VP is more urgent, IMO.

 

*) File format. VP uses this Microsoft Structured Storage API which won't be portable. So a new format is needed. Here I would lean towards something like JSON or MessagePack for the table file itself, with binary resources stored as external files in the same folder. This would create a nice open file format. A lower-friction way would be to use POLE, which is an open source implementation of Structured Storage, but maybe it's a nice opportunity to open up the file format and do it the right way.

 

*) Rendering. OpenGL, obviously. I think this is relatively doable since the RenderDevice is already abstracted. One issue is that shaders use a different syntax in OpenGL, so these would have to be hand- or machine-translated. I think there are some software projects which attempt to handle portable shaders, but haven't looked into it much. EDIT: This looks interesting, used in Unity: https://github.com/a...p/hlsl2glslfork

 

*) Codewise, the player needs to be refactored so it is more standalone from the editor. The editor is beyond all saving from its Windows/COM dependencies, but the player alone would be quite doable if the above problems are fixed. It would take quite a bit of refactoring to really separate the player from the editor, but probably minor compared to the above issues.

 

That's pretty much all of it, I think. So, quite a lot of work. I think, however, that even attacking any single one of these would be worthwhile, since it removes one more obstacle from the path. For instance, if you could get OpenGL rendering working and coexisting along the DX9 renderer, I think that's something really valuable. If we think in the long term, we just need to make one step after the other, and the order isn't so important.

Edited by mukuste, 12 January 2015 - 10:26 AM.

[freezy]

Now that I went through all the trouble of pulling data out of .vpt files on my Node backend, you want to change the format? Noooo!

 

Just kidding, an open format would be awesome.

 

Welcome back, by the way!

Edited by freezy, 13 January 2015 - 10:31 PM.

[s1500]

The big thing would be to go towards languages, file formats & standards that are not OS-specific. (okay, me being captain obvious here). Going all the way, imagine a lightweight Linux image custom tailored just for running a cabinet. Download a free image & go!

[pilotniq]

As far as I can tell, at least on ports of PinMAME ROM emulated games, the scripts are fairly short and simple, so porting them should not be very hard or time consuming.

[capnbleigh]

Bit late to this, but it's something I have thought about a lot.

 

*) Major obstacle is IMO scripting. You'd need to change the scripting language. My preference would be Lua since it's basically the industry standard for game scripting, as well as small, light and simple to embed. JS could also work, I guess. But the main problem here is that all tables would have to be redone, scripting-wise, as well as having to re-educate the community about scripting in a new language. So this issue is IMO more social than technical, which is always scary. If we could integrate a second scripting engine in parallel so that old tables still work while new ones can be developed in the new language, that would probably be the best way.

 

*) VPinMame integration. This uses COM objects now. Probably a simple (assuming) Lua extension which either has VPM compiled in or calls into VPM, for now, via the existing COM interface should do the trick to get rid of this dependency. Of course, at some point VPM itself needs to be ported to work outside of Windows and I don't know how much work that is, but pushing the COM dependency out of VP is more urgent, IMO.

 

*) File format. VP uses this Microsoft Structured Storage API which won't be portable. So a new format is needed. Here I would lean towards something like JSON or MessagePack for the table file itself, with binary resources stored as external files in the same folder. This would create a nice open file format. A lower-friction way would be to use POLE, which is an open source implementation of Structured Storage, but maybe it's a nice opportunity to open up the file format and do it the right way.

 

*) Rendering. OpenGL, obviously. I think this is relatively doable since the RenderDevice is already abstracted. One issue is that shaders use a different syntax in OpenGL, so these would have to be hand- or machine-translated. I think there are some software projects which attempt to handle portable shaders, but haven't looked into it much. EDIT: This looks interesting, used in Unity: https://github.com/a...p/hlsl2glslfork

 

*) Codewise, the player needs to be refactored so it is more standalone from the editor. The editor is beyond all saving from its Windows/COM dependencies, but the player alone would be quite doable if the above problems are fixed. It would take quite a bit of refactoring to really separate the player from the editor, but probably minor compared to the above issues.

 

That's pretty much all of it, I think. So, quite a lot of work. I think, however, that even attacking any single one of these would be worthwhile, since it removes one more obstacle from the path. For instance, if you could get OpenGL rendering working and coexisting along the DX9 renderer, I think that's something really valuable. If we think in the long term, we just need to make one step after the other, and the order isn't so important.

 

Hello. I'm even later to the party but is this still pretty much the state of things? An OGL renderer exists now so I can work on knocking out some of the other tasks if there's still work to be done.

[toxie]

I think its kinda useless, given the Visual Pinball Engine efforts nowadays.

[capnbleigh]

Fair enough, maybe I can help with the host application for VPE when it's closer to being ready.

[ciberfred]

Hello all i kind new in the world of virtual pinball and i discover vpx and pincabs.

 

tried vpx and as a point of view of dev i fill strange to see a such project only on windows (DirectX, COM/registry, VBscript, and so on). in my head why there is no port of vpx to linux to do like arcade games with simples frontend.

so i try to do a little test with vpx files to be render on linux.

 

i took a debian virtual and put some dev things in it. begin to download vpx source code from github and try to read and understand how things are done. i manage to extract code for the render part and adapt it to Ogre3D engine code. good get vpx file readed (thru libolecf) build class object (flippers, rubber, walls, etc...) and try to put vertex informations to ogre3D object to be render in a opengl window. it's showing :-)

try adding some keyboard interactions (thus Ogre3D part know as OIS). seems ok (still no balls and physics!) just a static table rendering (the default one given with vpx source code).

 

after it seems that pinmame get the knowledge and sounds and could be act as client/server with vpx. As there is no COM objects in unix world, we have DBUS. so try to get a minimal dbus server and add some dbus call to send events from my test apps. dbus server receive keyboard events (press and release). good but... where to put the receiver part in pinmame code ??? the base code is soo old and the unix part manage low level keyboard things and i don't understand where i could put the dbus function to replace keyboard press/release keys. also i wish put some dbus function that pinmame could send event to my apps that i could manage some light changes and so one...

 

Is anyone here could help me to find where i could put it ?

 

ps. you will find a screenshot here : http://fondriest.fre...x2021-05-28.png

 

hope someone could help and in future test it in a real pincab...(hope i could remove windows from a pincab !)

[wiesshund]

In linux?

I would probably compile pinmame as a stand alone executable
and then change vpx to use it rather than the com object

Seems easier?

[toxie]

actually there is the lib version of pinmame by now, that works on all common OSs: https://github.com/v.../src/libpinmame

this should fit your needs.

 

and as mentioned above: by now there is the VPE project https://github.com/f...lPinball.Engine that is/will be platform independent (at least as far as Unity support goes).

also, if this is 'just' about getting rid of windows: weren't there already ppl that succesfully ran VPX + VPM via Wine or something?

[Rawd]

also, if this is 'just' about getting rid of windows: weren't there already ppl that succesfully ran VPX + VPM via Wine or something?

 

https://www.vpforums...=44392&p=450874

[strikekat]

Also https://www.vpforums...topic=43650&hl=
I run it in Wine all the time (albeit 10.7 has some crashing/freezing issues, but it mostly works)

@ciberfred - that's.. interesting. Good work, but I think effort should definitely go into the VPE project at this point vs. wrangling the VPX codebase.

Current focus is on Unity integration, but I think VPE as a plugin into Godot gives you pretty much an end-to-end FOSS solution.
I would put your effort up on GitHub though if it was fairly substantial, either way.

 

I run Fedora full-time, let me know if you want help at least just running current VPX on Linux. I don't think it'd be quite stable enough for cab use but it's at least playable.

[ciberfred]

Also https://www.vpforums...topic=43650&hl=
I run it in Wine all the time (albeit 10.7 has some crashing/freezing issues, but it mostly works)

@ciberfred - that's.. interesting. Good work, but I think effort should definitely go into the VPE project at this point vs. wrangling the VPX codebase.

Current focus is on Unity integration, but I think VPE as a plugin into Godot gives you pretty much an end-to-end FOSS solution.
I would put your effort up on GitHub though if it was fairly substantial, either way.

 

I run Fedora full-time, let me know if you want help at least just running current VPX on Linux. I don't think it'd be quite stable enough for cab use but it's at least playable.

Hello,

ok i look at libpimame code maybe send you patch for pinmame about build pinmame as a lib on linux to be used by other progs.

edit: didn't see the cmake files... libbuild successufully with a little hack on CMakefiles.txt version on debian (3.13 instead of 3.16)
 

Edited by ciberfred, 31 May 2021 - 08:56 AM.

[toxie]

Great.. Note that libpinmame API is still a bit in flux though..

[freezy]

@ciberfred check out the CI scripts to see how it's built. And yes the API is still far from stable.

[ciberfred]

@freezy

so first test with libpinmame :

+ compile ok, test program run ok with a rom.

 

if i  try to add the test code in my program a really strange behavious appear. i setup the pinmameConfig struct with my functions like in the test prog, if i call the function from the member function of my object app it works (like p_config->fn_IsKeyPressed(MENU) but it crash in the pinmamesetconfig function. it seems that the pointer.

 const PinmameConfig pin_config =
 {
    44100,
    "",
    &OnStateUpdated,
    &OnDisplayAvailable,
    &OnDisplayUpdated,
    &OnAudioAvailable,
    &OnAudioUpdated,
    &OnSolenoidUpdated,
    &OnConsoleDataUpdated,
    &IsKeyPressed
 };
    snprintf((char*)pin_config.vpmPath, MAX_PATH, "%s", "/usr/local/share/pinmame/");
    printf("%d\n", &IsKeyPressed);
    pin_config.fn_IsKeyPressed(MENU);  <<--- here it's ok !
    PinmameSetConfig(&pin_config);
    
    PinmameSetHandleKeyboard(1);

valgrind return this :

==25290== Use of uninitialised value of size 8
==25290==    at 0x589E658: PinmameSetConfig (in /usr/local/lib/libpinmame.so.3.4)
==25290==    by 0x11A2ED: VPApp::test_pinmame() (main.cpp:1528)
==25290==    by 0x11A3E6: main (main.cpp:1552)
==25290==
==25290== Jump to the invalid address stated on the next line
==25290==    at 0x400000000: ???
==25290==    by 0x11A2ED: VPApp::test_pinmame() (main.cpp:1528)
==25290==    by 0x11A3E6: main (main.cpp:1552)
==25290==  Address 0x400000000 is not stack'd, malloc'd or (recently) free'd
==25290==

 

it's like the pointer function values are not correctly interpreted or set by the libpinmame library part but is ok in my code part... (i can call the function correctly from the struct) are function pointer differents between c and c++ ?!? the assignment of function need to be done specifically ?... hum.. by the way i can read correctly the sampleRate entry....

 

here where it crash : (in libpinmame.cpp)

LIBPINMAME_API void PinmameSetConfig(const PinmameConfig* const p_config) {
    if (_p_Config == nullptr) {
        _p_Config = (PinmameConfig*)malloc(sizeof(PinmameConfig));
    }
    memcpy(_p_Config, p_config, sizeof(PinmameConfig));
    printf("test\n");
    p_config->fn_IsKeyPressed(MENU);  <<<------ it's crashing here...
    printf("test\n");

maybe someone here will know what is wrong.... i dont' understand why i 'm loosing function pointer with the call to PinmameSetConfig as we give to function the pointer to the struct....