813 replies to this topic

[freezy]

The idea is to make the backglass part of the scene, point a camera onto it, and output it to wherever the user configured it to output.

 

Not sure what you mean by spanning screens. VPE should be able to handle multiple monitors just fine. Also not sure what you mean with VPM data. We'll be getting solenoid/lamp/flasher events from the emu as we do now. If more fine-grained analysis (e.g. a bitmask on the DMD) is needed to trigger events, then that's another feature but AFAIK only Pup does this kind of stuff at the moment.

[wiesshund]

The idea is to make the backglass part of the scene, point a camera onto it, and output it to wherever the user configured it to output.

 

Not sure what you mean by spanning screens. VPE should be able to handle multiple monitors just fine. Also not sure what you mean with VPM data. We'll be getting solenoid/lamp/flasher events from the emu as we do now. If more fine-grained analysis (e.g. a bitmask on the DMD) is needed to trigger events, then that's another feature but AFAIK only Pup does this kind of stuff at the moment.

well, vp9 used to do a fullscreen with backglass by spanning screens

i dont have any of those tables any more to look at though

 

i mean the visual info from vpm
like how your dmd extensions read it and turn it into a software display

So that you could pull that inside VPE to be on your backglass?

[TerryRed]

The ideal would seem to gear towards more of what FP is doing. Having a complete room for the table, backglass, cabinet... everything is simply there...no special tricks, and a camera view can simply look at the backglass in all modes (desktop / cabinet / vr). It's highly recommended to take a look at how that works as it simply does many things you want to see / use really well....and additional extras like overlays for video DMDs etc.

 

Of course that can be done here. Integrating the "backglass" functions of b2s server for the backglass in terms of translating the vpinmame calls to whatever elements you want to display / change is what most want to see. Unity can allow for many cool things on top of that.

 

As for a playfield on the Backglass.... well again there are examples in FP-BAM of tables that create an entire separate playfield, and then use BAM's mini playfield tool to position that on the backglass. Works very well. Again... that should be very doable in Unity.... but one step at a time.

Edited by TerryRed, 07 January 2021 - 08:31 PM.

[htamas]

Getting a complete physics sim into the backglass for Banzai Run is going to be more challenging, but hey that's what we're here for!

 

What I was thinking of is the capability to somehow handle more than just one screen as the playfield. So instead of that overlay playfield like the VP9 Banzai Run does it, send that to the secondary screen instead.
Of course I have no idea about how complex this is or how to approach it

[freezy]

@wiesshund dmdext simply gets called by VPM and receives frame data. Then it spawns its own rendering window. VPE also receives DMD frame data (via a different API). If your question was about rendering, then yes, the plan is to render everything in the Unity engine and just use cameras to get the desired view, similar to what Terry described.

 

@htamas the tricky part is not the screen but the simulation. You basically need to somehow simulate multiple playfields with different gravities. I haven't looked into how VP9 BR does it, but out of the box, the VP engine only supports one playfield, so it probably patches the gravity via script when the ball moves to the backglass playfield.

[blindpeser]

Not sure if I miss something here. But why does another playfield need another gravity?

[hitman2304]

Maybe because its way smaller than actual playfield so obviously gravity is different,

[freezy]

Because in the simulation the playfield is parallel to the earth's surface and the gravity is skewed to make up for the slope angle, which makes it a whole lot easier to deal with geometry. So two different playfield angles mean two different gravities.

[blindpeser]

Because in the simulation the playfield is parallel to the earth's surface and the gravity is skewed to make up for the slope angle, which makes it a whole lot easier to deal with geometry. So two different playfield angles mean two different gravities.

Ok, sounds right somehow.

@Bret Hart: That doesnt sound right somehow.

[fripounet]

Because in the simulation the playfield is parallel to the earth's surface and the gravity is skewed to make up for the slope angle, which makes it a whole lot easier to deal with geometry. So two different playfield angles mean two different gravities.

 

?? gravity is a constant.

unless you have 1 part on earth and another part on the moon (for example), there is no reason to have 2 gravity values.

Edited by fripounet, 08 January 2021 - 02:00 PM.

[freezy]

Thank you fripounet, you never cease to amaze with your ingeniously sharp conclusions.

 

Can you maybe post them in another thread? That would be really awesome. Cheers!

[fripounet]

active bg (banzai run) ,  a single gravity is enough . work 100%.

just program the trajectory of the motorcycle

 

 

 

for vpx easily reproducible in fss or vr format

Edited by fripounet, 11 January 2021 - 11:50 AM.

[hitman2304]

I think it's time for a little update for those of us who don't follow github page daily :-)

[pitty]

Still watching and waiting with anticipation.

 

Looks amazing the work you guys are doing.

[freezy]

Apologies for the lack of updates. Was mainly focused on internal stuff and tooling, so not much to show off.

 

However I did some gameplay testing and figured a slow-motion feature would actually be quite useful. So here I'm trying to do a life catch.

 

[freezy]

This isn't merged yet, but it's exciting so I thought I'd share it.

 

VPE includes what we call the Gamelogic Engine - it's the part that gets switch changes and returns coil and lamp changes during gameplay. Most of you probably think about VPM, which is indeed a good example of a GLE. However when designing it, it was important for us to make it in a way that works with any type of game code. So I've been talking to Jan from the Mission Pinball Framework, and MPF now has an awesome gRPC API we can leverage in VPE. Check this out:

 

 

This spawns an MPF process when launching the game, connects to it and uses MPF to drive the game. In edit mode we can query the game's switches, coils and lights and connect them with the editor's wiring tools to the playfield items.

 

PinMAME will of course be another GLE implementation. And original games will also be exactly that, although they will also get a nice gameplay library so scripting authors don't need to re-invent the wheel all the time (or, they can also use MPF with hardly any coding at all!).

Edited by freezy, 10 March 2021 - 10:29 PM.

[TerryRed]

As someone who has spent the last 3 months on one original table (much of that being coding script and creating new features I needed)... any help is much appreciated for a newer modern editor. Realtime stats/monitoring for game events / switches would be very helpful.

 

 

Looks great.

[freezy]

Definitely. VPE already shows switch, coil and light states in realtime during gameplay. Here's the lamp matrix from MM driven by PinMAME for example:

 

 

MPF has its own status panel obviously.

[hlr53]

Wow! Awesome  

[blindpeser]

Yep, looks sweet! Please keep the amazing videos coming.