813 replies to this topic

[dark]

Alright with some time for the excitement to die down a bit, I have to address the elephant in the room..

 

Once in a while someone comes around show casing unity or ue4 and everyone gets all excited but then it fizzles out.  We all remember how promising the 'unity3d' pinball project looked until the devs abandoned it because I guess they found it to be too much work vs too little reward.

 

Although unity3d was abandoned it did reach playable status, though it still needed a lot of polishing it looked promising.  One of the major problems it faced was no one could figure out how to build a table for it 'out of the box' besides the devs and maybe two other people.

 

You propose this will have an editor that will be user friendly to vpx users - This has to be a top priority.

 

The other issue other emulations have had is physics, you propose that it will use vpx physics - This also needs to be a top priority.

 

If you can accomplish these two things I believe the rest will fall into place.  Honestly wishing you the best in this endeavor and I truly hope it all works out but for now I'll refrain from setting my hopes too high.

[freezy]

The difference is that the other project was closed-source.

 

I already have ported VP's physics once, doing it a second time is pretty trivial, really. So you don't need any hopes for that, that's a done deal. About the editor, there's some work ahead, but given everything's open source I'm sure things won't be abandoned.

 

Also, I've been around a few years now and I don't plan on leaving any time soon.

[DCrosby]

 

 

 we should be able to port to other systems/consoles.  

 

I doubt that as it's encoding what it has in Unity into a VPX, so unless you have something that can read the VPX for say Switch it won't happen... Because you're not using Unity to generate an excecutable, you're using it as an editor, which makes sense and is why anything you do in Unity won't go over into VPX unless it's supported... which means standard shaders, and standard primitives... Like Flippers walls etc.. but meshes and logic can now be done better in external content development platforms, and imported, and presented with lighting and textures applied Which is a huge leap (for me )

 

 

me thinks you may need to read the synopsis again and see posts 17 and 18. 

 

I think you misunderstand me, there is a difference between a game engine and a game platform.  Yes, in theory if you have a common way of generating VPX files, that's open-source, any engine can convert its assets to VPX format and the VPX.exe executable can run them. But unless you re-compile VPX, VPMame, and B2s for Switch, that .vpx file won't run on switch no matter what you do in Unity.

 

Unity can generate Executables for all kinds of platforms, but that's not what's being proposed with this change.

Edited by DCrosby, 14 February 2020 - 12:07 AM.

[LynnInDenver]

So, I do have a couple of "pie in the sky" requests.

 

First: Proper multiple screen support for cabinets. Set windows for playfield, (optional) backglass, (optional) DMD/PostDMD in the same way Zen's Pinball FX3 does.

 

Second: Be screen rotation agnostic. Basically, if there is a "screen rotation", it's a system wide setting, not by the table. Support people's desire to not change their old build cabs from the landscape configuration (1920x1080 at 270 degrees), but also support those of us who just want to be in portrait (1080x1920 at 0 degrees). FX3, Zaccaria, and I think Pinball Wicked support doing it this way.

 

Third: In-engine support for generating DMD/PostDMD video displays for original tables. I know Future Pinball has some support for DMD, and it might be worth looking at how table authors script to interact with it. At minimum, DMD support should probably be immediately easier and more flexible than trying to use UltraDMD.

 

I do agree that backwards compatibility with as much of the VPX ecosystem as possible is desirable to help this take hold, especially in the region of scripting. I recognize that does mean supporting the COM mess as it currently stands, including UltraDMD and DirectB2S. But it will help make a transition happen.

[DJRobX]

Alright with some time for the excitement to die down a bit, I have to address the elephant in the room..

 

Once in a while someone comes around show casing unity or ue4 and everyone gets all excited but then it fizzles out.  We all remember how promising the 'unity3d' pinball project looked until the devs abandoned it because I guess they found it to be too much work vs too little reward.

 

Although unity3d was abandoned it did reach playable status, though it still needed a lot of polishing it looked promising.  One of the major problems it faced was no one could figure out how to build a table for it 'out of the box' besides the devs and maybe two other people.

 

You propose this will have an editor that will be user friendly to vpx users - This has to be a top priority.

 

The other issue other emulations have had is physics, you propose that it will use vpx physics - This also needs to be a top priority.

 

If you can accomplish these two things I believe the rest will fall into place.  Honestly wishing you the best in this endeavor and I truly hope it all works out but for now I'll refrain from setting my hopes too high.

 

No one can ever guarantee that a project will be finished, especially when it's just a hobby.  But, the source for this project is right there on Github.  I built it myself and loaded my existing table in it in about 20 minutes.       As long as the source is out there, this project can always be pushed forward, unlike Unit3d pinball.    I refused to donate money towards that project unless the source was released for a reason, and unfortunately what I thought might happen, did.    

Being able to explore the table in true 3D and navigate through its properties in this manner is pretty glorious.      What you saw in the videos really works.    There's a LOT of potential for greatness in terms of user friendly editing here.   Unit3d pinball didn't have any of that, it piggybacked off of FP's editor. 

[TerryRed]

 

Alright with some time for the excitement to die down a bit, I have to address the elephant in the room..

 

Once in a while someone comes around show casing unity or ue4 and everyone gets all excited but then it fizzles out.  We all remember how promising the 'unity3d' pinball project looked until the devs abandoned it because I guess they found it to be too much work vs too little reward.

 

Although unity3d was abandoned it did reach playable status, though it still needed a lot of polishing it looked promising.  One of the major problems it faced was no one could figure out how to build a table for it 'out of the box' besides the devs and maybe two other people.

 

You propose this will have an editor that will be user friendly to vpx users - This has to be a top priority.

 

The other issue other emulations have had is physics, you propose that it will use vpx physics - This also needs to be a top priority.

 

If you can accomplish these two things I believe the rest will fall into place.  Honestly wishing you the best in this endeavor and I truly hope it all works out but for now I'll refrain from setting my hopes too high.

 

No one can ever guarantee that a project will be finished, especially when it's just a hobby.  But, the source for this project is right there on Github.  I built it myself and loaded my existing table in it in about 20 minutes.       As long as the source is out there, this project can always be pushed forward, unlike Unit3d pinball.    I refused to donate money towards that project unless the source was released for a reason, and unfortunately what I thought might happen, did.    

Being able to explore the table in true 3D and navigate through its properties in this manner is pretty glorious.      What you saw in the videos really works.    There's a LOT of potential for greatness in terms of user friendly editing here.   Unit3d pinball didn't have any of that, it piggybacked off of FP's editor. 

 

 

 

You know you gotta post a pic or better...a video, right? What table?

[tictox]

First: Proper multiple screen support for cabinets. Set windows for playfield, (optional) backglass, (optional) DMD/PostDMD in the same way Zen's Pinball FX3 does.

 

 

Unity has support for detecting screens on a system and you can set the output of any camera to any screen , even multiple cameras onto a same screen. I already achieved this in my previous Unity built tables outside of this development. You could choose to assign the backglass or dmd to which ever screen you liked and set the size and position , right in the game menu while you playing, the screen option selection list was populated by unity when the game was running. Basically If it is available to the OS , then Unity can detect it. I  stored these settings in a SQLite database at runtime. So knowing this is possible already I dont think this will be an issue. That said Unity does not control VPinMame DMD. VPinMame is Not VPX. Changing engines to Unity still requires VPinMame to emulate the ROMS and so the DMD you all know is still under the control of VPinMame, because it is VPinMame , not VPX. I Personally just hid it, then I would grab the pixels myself from VPinMame and recreate the DMD within Unity .. so I could control it. 

[gtxjoe]

VPX can already display VPinMame pixels in the existing Flasher Object. Couldnt that be use and moved anywhere desired within Unity

[LynnInDenver]

 

First: Proper multiple screen support for cabinets. Set windows for playfield, (optional) backglass, (optional) DMD/PostDMD in the same way Zen's Pinball FX3 does.

 

 

Unity has support for detecting screens on a system and you can set the output of any camera to any screen , even multiple cameras onto a same screen. I already achieved this in my previous Unity built tables outside of this development. You could choose to assign the backglass or dmd to which ever screen you liked and set the size and position , right in the game menu while you playing, the screen option selection list was populated by unity when the game was running. Basically If it is available to the OS , then Unity can detect it. I  stored these settings in a SQLite database at runtime. So knowing this is possible already I dont think this will be an issue. That said Unity does not control VPinMame DMD. VPinMame is Not VPX. Changing engines to Unity still requires VPinMame to emulate the ROMS and so the DMD you all know is still under the control of VPinMame, because it is VPinMame , not VPX. I Personally just hid it, then I would grab the pixels myself from VPinMame and recreate the DMD within Unity .. so I could control it. 

 

Most of my multiscreen concern is actually with doing original tables using an internally generated DMD/PostDMD instead of external via COM. I know PinMAME is an entirely different beast in that regard, but setting that using the Freezy DLL is fairly trivial.

[Rawd]

"When you compile the solution, grab the produced DLLs of this project (all
but the `Unity*` dependencies), and copy them to your Unity project's asset
folder. You can also point the `VPE_UNITY_SCRIPTS` environment variable to
your Unity asset folder, and building the project will do this automatically.

You'll then have a *Visual Pinball* menu in the Unity editor where you can
import `.vpx` files. You'll be also able to drag and drop `.vpx` files into
your asset folder and Unity will create the table model directly."

 

I am trying to build the DLLs with Visual Studio 2017, and I am running into errors...

 

 

 

 

Does anyone recognize what I am doing wrong?

[tictox]

could be the .net version? The IDE Version does not determine the .net version.. im sure freezy can help out here.

 

As said grabbing the dmd pixels is possible in unity , hiding the VPinMame DMD is also possible , sending the then Unity created DMD to any screen is then totally possible. Im not exactly sure about freezy color DMD. I dont know how it works at all. 

 

For creating your own DMD the sky is the limit .. Unity can do anything like that ..just be aware that because it is capable -  does not now make this a trivial or easy task. To create a full custom set of DMD animations for an original table is a mammoth task. I have built a full system like this before so I know. The various animations are baked to frame sheets. A code system them has a multilayered system with the animated frame sheets and various dynamic text objects. Together these are captured to a render texture ( a buffer ) and that is finally  blit to the screen. Besides the system to do it , im referring to creating quality frame sheets for the animations. It is not easy , we are all spoiled by the already awesome DMD work of ROM emulation tables. Im sure it took those table artists and programmers quite some time to build those as well

Edited by tictox, 14 February 2020 - 08:33 AM.

[toxie]

@freezy: How do you plan to convert lights so that they can cast shadows? And bulbs vs non-bulbs? Curious, as at some point i want to fool around with dynamic lights in VPX anyway, so that we're kinda aligned there.

[freezy]

@Rawd: TBH I've never seen that. Looks like some conflict with your build tools? I haven't tested compiling with VS2019, I'm using Rider and I've tested with V2017.

 

@toxie: Good question So far I ignore everything that doesn't have a light bulb, including flashers. The flasher test in the video was a manually placed light source, since flashers don't have enough positional data in VPX anyway. It was fully dynamic, although Unity allows baking light maps, but I'm not sure how that works exactly yet. Since Unity has a deferred renderer, I guess many light sources should be doable, although I don't think all lights need to be casting shadows in order to make it look realistic. Most bulbs probably don't.

 

In VPX-JS I detect inset lights by looking at their surface, but it's a best-guess algorithm. Those aren't real lights but emissive maps.

[toxie]

Good point with most likely making that part configurable.

My plan is to have importance light lists per pixel (the luxury of having a static view in VPX and so one can avoid baking and light leaks), or something along the lines of what Timeshock was doing (same static view opportunity), but not 100% precomputed and shipped with the table, so that it can change on every table start (i.e. if one changes the POV or the enduser moves stuff around in the editor). Should be doable, given nowadays ray tracing perf, and the simplicity of the VP lights/materials and would not have that large of an impact on performance.

Also, i was wondering, why would you need LLVM support for PinMAME? It already works on Linux, so Android?? Don't know if it's worth it to follow that route. Most emulation of modern DMD based machines needs quite some horsepower, otherwise one would need to fallback to what Pinball Arcade and Pinball FX is doing on mobile platforms (i.e. more simulation instead of emulation).

[mk47]

Also, i was wondering, why would you need LLVM support for PinMAME? It already works on Linux, so Android??

Just in case that you're wondering who runs PinMAME on Linux, it runs on a Raspberry Pi as an MPU replacement for real pinball machines:
https://lisy.dev/
 

[blindpeser]

Good point with most likely making that part configurable.

My plan is to have importance light lists per pixel (the luxury of having a static view in VPX and so one can avoid baking and light leaks), or something along the lines of what Timeshock was doing (same static view opportunity), but not 100% precomputed and shipped with the table, so that it can change on every table start (i.e. if one changes the POV or the enduser moves stuff around in the editor). Should be doable, given nowadays ray tracing perf, and the simplicity of the VP lights/materials and would not have that large of an impact on performance.

Also, i was wondering, why would you need LLVM support for PinMAME? It already works on Linux, so Android?? Don't know if it's worth it to follow that route. Most emulation of modern DMD based machines needs quite some horsepower, otherwise one would need to fallback to what Pinball Arcade and Pinball FX is doing on mobile platforms (i.e. more simulation instead of emulation).

My hope was that we get rid of the static view thinking, no?

Edited by blindpeser, 14 February 2020 - 09:31 AM.

[freezy]

Also, i was wondering, why would you need LLVM support for PinMAME? It already works on Linux, so Android?? Don't know if it's worth it to follow that route. Most emulation of modern DMD based machines needs quite some horsepower, otherwise one would need to fallback to what Pinball Arcade and Pinball FX is doing on mobile platforms (i.e. more simulation instead of emulation).

Huh. I wasn't aware of that. I thought it was completely linked to Windows, also due to DX7 (I think?) still being used for the DMD. My bad if that's not the case. LLVM was still in my head because of WASM support, I guess (also, I replied while drinking at the bar, so I wasn't able to research it ).

 

So you're saying the only thing that prevents full cross platform is the VBS engine?

Edited by freezy, 14 February 2020 - 09:48 AM.

[Ben Logan]

Really fun to follow the discussion here. Just remembered tictox's versions of Elvis and Tommy. Had fun playing those! 

Edited by Ben Logan, 14 February 2020 - 02:15 PM.

[toxie]

>My hope was that we get rid of the static view thinking, no?

 

This depends. If we will go Unity anyway to support things like VR more easily (and much more performant), why then give up the perf and quality benefit of static views? After all this enables even windows-tablets to play VPX.

 

Also, i was wondering, why would you need LLVM support for PinMAME? It already works on Linux, so Android?? Don't know if it's worth it to follow that route. Most emulation of modern DMD based machines needs quite some horsepower, otherwise one would need to fallback to what Pinball Arcade and Pinball FX is doing on mobile platforms (i.e. more simulation instead of emulation).

Huh. I wasn't aware of that. I thought it was completely linked to Windows, also due to DX7 (I think?) still being used for the DMD. My bad if that's not the case. LLVM was still in my head because of WASM support, I guess (also, I replied while drinking at the bar, so I wasn't able to research it ).

 

So you're saying the only thing that prevents full cross platform is the VBS engine?

Visual PinMAME is still linked to all the windows madness. But the plain PinMAME core is free of all of that.

Sidenote: There is also still a branch open (https://sourceforge....e/branches/dll/) that implements most (basic) functionality of the VPM VBS interface as function calls. Maybe this would be worth it to finish up, clean it of all windows madness, and use that then?

Note that i never tested that, i just tried to keep it alive and compiling, as it was started (and used with UE or Unity???) by somebody else years ago.

Edited by toxie, 14 February 2020 - 10:05 AM.

[ravarcade]

"When you compile the solution, grab the produced DLLs of this project (all
but the `Unity*` dependencies), and copy them to your Unity project's asset
folder. You can also point the `VPE_UNITY_SCRIPTS` environment variable to
your Unity asset folder, and building the project will do this automatically.

You'll then have a *Visual Pinball* menu in the Unity editor where you can
import `.vpx` files. You'll be also able to drag and drop `.vpx` files into
your asset folder and Unity will create the table model directly."

 

I am trying to build the DLLs with Visual Studio 2017, and I am running into errors...

 

 

 

 

 

Does anyone recognize what I am doing wrong?

 

I was able to build all succesfully after i installed Developer Packs for .NET Framework 4.7.2 and .NET Framework 4.7.1 from there:

https://dotnet.micro...medium=referral

 

You may also need to restore solution and projects files from GitHub if you allow VS to downgrade target .NET Framework when you open solution first time.