813 replies to this topic

[blindpeser]

>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.

If this doesnt affect us VR guys, to keep static view for other consumers is totally fine.

 

@ravarcade: Great to see you here!

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

[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.

If this doesnt affect us VR guys, to keep static view for other consumers is totally fine.

 

As said, it all depends. At the moment the vpvr fork seems to bitrot, while the unity port is starting/going forward. Only time will tell what happens.

 

I can only do so much and cannot influence what other devs are doing in their spare time. 

 

Also having a static view must not mean that the lighting is static! This was my whole point in the post above. It just enables a whole new class of algorithms to (ab)use.

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

[blindpeser]

OK, got it. Thanks

[freezy]

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 by somebody else years ago.

 

Ah, nice, I didn't know that the Windows stuff was only VPM. So we would need to wrap PinMAME into a cross-platform library, replace VBScript and we'd be full cross platform?

[toxie]

As said, maybe that branch could be exactly that? The functions should allow for handing everything needed over the lib fence in an efficient way, and then there could still be something like a VBS emulation or whatever on the other side.

And to grab that data and throw it over the fence i don't see why there should be any windows dependency, but who knows how this was implemented in the branch.

[freezy]

Thanks @toxie, great stuff.

[toxie]

Maybe i'll have a look at that branch over the weekend, let's see.

[freezy]

Looked at your branch. So a guy named syllebra created it and already used it in Unity at some point? That was mid 2017, then you guys maintained it for another two years?

[JLouLoulou]

Waahhh!! I have no word .. The future of visual pinball will be crazy..  

[toxie]

Looked at your branch. So a guy named syllebra created it and already used it in Unity at some point? That was mid 2017, then you guys maintained it for another two years?

 

That's how i roll..

Seemed to be useful for the future (and i was right ).. Other branches i usually re-integrate "quickly", but that one i was never sure what to do with it, as i could not really test it and only rely on the creator..

(same for that damn HW branch, btw, extremely useful but somehow unfinished)

Edited by toxie, 14 February 2020 - 11:12 AM.

[freezy]

Well, that's an unusual level of professionalism for a hobby project. Hats off!

 

Which one is the HW branch? UltimateIO?

[Rawd]

 

 

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.

 

Thank you, I installed those successfully and managed to get the toolset needed by using the package manager console and hitting restore... but no success   I am familiar with Unity, but I am not very familiar with compiling builds/dll's with Visual Studio.

 

I was hoping that even in its current state, it would be a tremendous help for designing VR rooms.  I'd like to give it a shot.

 

If anyone wants to try to help me out through PM or something, it would be greatly appreciated.. Thanks.

Edited by Rawd, 14 February 2020 - 12:03 PM.

[freezy]

Which version of Visual Studio are you running? This and this hints a version issue. Try updating Visual Studio 2017, usually just launching the installer and let it do its thing should get you there.

@toxie I've tried to compile the dll branch, fails with not being able to link to dinput.lib. That's DirectX stuff that shouldn't be there, right? I'm getting it twice for the PinMAME and PinMAME32 project.

[toxie]

 

Which one is the HW branch? UltimateIO?

 

yup
 

@toxie I've tried to compile the dll branch, fails with not being able to link to dinput.lib. That's DirectX stuff that shouldn't be there, right? I'm getting it twice for the PinMAME and PinMAME32 project.

Don't know.. As said, i never looked really into the details of the branch, just followed loosely the progress and that it does not break anything else..

 

DX can actually be used for PM and PM32, too, as it needs to output stuff and get user input, it just has a different counterpart for Linux, of course. BUT the dll should not need windows specific things in the end, so maybe we can hide some of these things better (=behind ifdefs like user input code, UI wire code, display code, etc.)

[Rawd]

Thanks Freezy..   I was able to update VS2017 using the VSInstaller, and I was finally able to get it to build with no errors.   However, I'm now getting all kinds of errors in Unity when I add the DLL's to the asset folder.   I'm not quite sure which DLL's to move?   I apologize for the newbie questions, but I'm really struggling to get past this.  Does it matter what version of Unity I'm using?  I'm on an older version..  2019 1.3.f1

[freezy]

Glad you got it to compile!

 

The best is to set your VPE_UNITY_SCRIPTS environment variable to point to your Unity project's asset folder (or any sub folder, I usually put them into Assets/Scripts). Like that, the right files are copied after every compilation.

 

The problem you have is that in order to compile, we need a reference to Unity's library. Since Unity is not installed on the same location on every machine (and there are different versions anyway), VPE ships with its own DLL, which will end up in the build folder as well. If you copy that, Unity is confused because a) it already has its own and b) it's probably a different version.

 

There is another subtlety, which is that we're using miniz to compress bitmaps, which is a native dependency, meaning there are two DLLs, one for 32 bits and a 64 bit version. If you copy the 32 bit version, Unity will complain.

 

All these issues can be avoided by setting the environment variable mentioned above (you'll need to restart Visual Studio, and probably Unity too if you've already copied the native DLLs).

[xantari]

I love that I already see ravarcade on here! BAM for VPE here we come!!! 

[Phazer51]

Freezy:

I am in awe.

[Rawd]

OK.. thanks for your help Freezy.  I got it!

 

This should make VR room development about 600x faster. 

 

[tictox]

getting rid of the static view is not so simple as just having a 3D engine. Transparency is the issue here. To anyone in the know transparency sorting in real time that works in every situation is an unsolved problem. So With that in mind at authoring time you have to make provision for problematic sorting concerns. ( separating meshes into smaller objects with unique origin ).

 

So already existing VPX tables are not authored with any movement in mind and so concern to creating objects that are transparency sorting aware does not go past the. ( one view perspective ) which is not a problem. 

 

For example when I built Fishtales in unity the Rod plastic on the left hand side was long and had sort issues with the "stretch the truth" plastic when you rotated the camera around in 3D. So I split that long plastic mesh into two separate mesh objects with their own origins. This solved the sorting issue. 

 

Freezy has gone around in circles with me about this lol. It not a train smash , im just pointing out that there are going to be transparency sorting issues if you expect a table authored without sorting in mind to be viewed in 3D from any angle.

 

hth