228 replies to this topic

[melon]

 

Wire ramps really need to be updated. I don't think the solution is making it with Future pinball, exporting to blender and exporting to visual pinball.

 

What improvements do the wire ramps need?

 

 

The default wire ramps built in don't look good, so we are making it each wire aof each ramp with two flat ramps, one above other. For VUKs and ramp enders now I'm using the FP models.

[mukuste]

Ah, so it's only about the look. That should be relatively easy to fix then.

[freezy]

mukuste, check this out:

 

     

 

I only recently discovered this and specially the shadow map rendering via Blender I find pretty cool.

[melon]

The overall look of a wire ramp needs an update At present you can't apply a texture to a wire ramp. Applying a sphere map to a wire ramp would be nice and easy to add into the current version.

 

Yeah 

And for the future, it would be great to be able to add ring (for each point, we could specify if there's a ring, and what type of ring), and a ramp start and end model... 

[gtxjoe]

From physics perpective:  

Investigate flipper accuracy. Flipper precision was addressed recently but is the flipper accurate all the way across the flipper blade.  Here is Bob's old flipper test table http://www.vpforums....s&showfile=6191.  I was tinkering with this to automate shots across the entire flipper blade.    

 

For table authoring:

Add more standard objects as melon mentioned, including typicall used posts/standoffs, screw/bolt tops. lamp bulbs, light inserts that look like real playfield inserts. 

[kiwi]

I'm still not a big fan of Blender, but being able to export the table and import it into Blender to re-edit it, it would be cool.
Besides all the things already said on the ramps, height and width adjustable to any control point, I want to add that it would be useful to have two points at the beginning and at the end of the ramp, instead of one, to create ramps that start in diagonal and perfect connections between ramp and ramp.

 

Max

Edited by kiwi, 17 March 2014 - 04:23 PM.

[s1500]

Use the P-ROC sw architecture for modes, which would make programming deeper rulesets 100 times easier. 

[DJRobX]

It would be nice to have better performance settings management.   Right now we have a bunch of performance tuning settings in video options, some of which can be overridden by the table settings (in a UI that's completely different from the Video settings).    Which things can be overridden is inconsistent, and can be confusing if tables are overriding them without your knowledge.    As the DX9 feature set grows, I can see the number of adjustable settings increasing (like Unit3D Pinball), so it might be beneficial to come up with a better foundation for managing this early on. 

 

Being able to make performance tweaks specific to a table is great, but I don't think the performance tuning options should be stored in the VPT file.    It can be confusing if the table author has made some adjustment that doesn't work with everyone's system.   Settings may be getting overridden and it's not clear to the user when this happens.    For example, see this post, the author of Champion Pub forced FXAA on, which causes problems for both the current VP 9.2.1 and DX9 builds.     I think it would be better if Table/Setting overrides were kept with the VP installation. 

 

The Nvidia control panel has a nice example of a good UI that deals with program-specific overrides - one tab has the master list of things you can adjust, then there's another tab for specific settings to program that it either knows about or is currently running. 

[BANZAIDROP]

I'm still hoping for a more advanced video settings menu:

 

- screen option for multiple monitors

- full screen or fake full screen option

- orientation/rotation option for custom screen setups (90/270° etc.)

[ClarkKent]

I think the most important thing would be that it should be even more realistic. A more realistic ball moving over the playfield (e.g. the ball in Zen Pinball looks veeeery nice), more realistic light and shadow (like the fake lighting of the upcoming Pro Pinball), more realistic behavior of the different materials. But I think all of these things are in VP10 anyway...

[DJRobX]

[quote] screen option for multiple monitors

 

I'm still hoping for a more advanced video settings menu:

 

- screen option for multiple monitors

- full screen or fake full screen option

- orientation/rotation option for custom screen setups (90/270° etc.)

 

Regarding #1, Great idea - would be great if we had a nice easy to use UI to define what goes on each monitor, and where the DMD is.     Make VP the central authority for this, and it can write out the screenres.txt file for B2S to pick up so it only needs to be done once.    If VP knows where the DMD should go, it would allow the standard VPM startup scripts to position the DMD automatically.    This configuration is necessary anyway if VP becomes responsible for rendering the DMD the way Unit3D pinball does.

 

#2 is already in VPDX9.   

 

#3 agreed - goes with #1.  Also worth mentioning that the DMD positioning config needs the option to flip vertically for Pin2K style cabs.

[unclewilly]

It would be nice to have the back glass integrated into vp similar to fp. That way we could do all the back glass animation and lighting without an external program

[stuzza]

It would be nice to have the back glass integrated into vp similar to fp. That way we could do all the back glass animation and lighting without an external program

 

I agree.  It would be great to have a lot of the "add ons" that have appeared recently (db2s etc..) added to the core Visual Pinball.  Setting up visual pinball to work in a cabinet environment is quite complex and it would be great it this was simplified in one program.  Currently it is extremely hard to setup for new users.  I have helped a number of newbies out in the last few months and they are always so confused with all the separate files required just to get a table to launch full screen with an animated backglass and the DMD in the right location.

[DJRobX]

It would be nice to have the back glass integrated into vp similar to fp. That way we could do all the back glass animation and lighting without an external program

 

That's probably a necessity if we want one table file to be dynamically rendered in cab mode, desktop mode, or "hybrid view" mode.   On the negative side, having them separate has been good for collaboration.   Table authors can focus on the table while someone else provides a B2S without worry of getting permission to "mod" someone's table   Maybe we could have some sort of import feature that allows people to easily import a new backglass design into an existing table. 

 

The directb2s format itself and the B2S designer are fantastic.   As far as I know it's closed source, and written in C# (or some .NET variant), where VP is C++.   C# and C++ can talk to each other just fine, but it would be up to Herweh if he's interested in going open source with his project.  

 

We also would need a plugin architecture, for things like DOF, if the backglass gets built into VP. 

Edited by DJRobX, 20 March 2014 - 02:41 AM.

[mukuste]

 

It would be nice to have the back glass integrated into vp similar to fp. That way we could do all the back glass animation and lighting without an external program

 

That's probably a necessity if we want one table file to be dynamically rendered in cab mode, desktop mode, or "hybrid view" mode.   On the negative side, having them separate has been good for collaboration.   Table authors can focus on the table while someone else provides a B2S without worry of getting permission to "mod" someone's table   Maybe we could have some sort of import feature that allows people to easily import a new backglass design into an existing table.

 

I think the b2s file itself could still stay separate from the vpt file, even if the player gets integrated. I think the monolithic vpt files are getting a bit cumbersome anyway, now with more and more primitives and large textures getting integrated into them, they are really getting huge -- what about having the possibility to have external file resources? Would at least make saving tables much faster.

 

I haven't looked at the db2s format, so don't know how complicated it would be to port to C++. VP and B2S are already talking to each other via COM, just right now it's exclusively the script which does the talking. If Herweh would want to cooperate on something like this, I'm sure better integration could be achieved. It is a real shame that it's closed source.

[unclewilly]

Good point. It's actually kind of nice not to have to worry about the back glass after spending a few months in the editor building and coding the tables.

Plugin support for dis would be cool. Hopefully you and herweth can get together on that.
I'm sure arm grim will be more then willing to help out with dof.

A sound manager that worked with dof would be nice and save a lot of coding. Maybe something where you could go through and check sounds to not play in the sound manager

[boiydiego]

BAM in vp10 

[kiwi]

The plunger launch and nudge controlled by the mouse.

 

Max
 
 

[Swisslizard]

This is maybe just a small thing, but it has some annoying side effects:

VP should learn to properly shut down SBScript one the player exits the table. Today it seems the VP still holds some resources in that area and objects beening used by VP are still locked (e.g. DOF or B2S.Server).

[htamas]

Closer integration of dB2S would be good, it may even eliminate the rare weird issue with some tables when using a dB2S backglass messes up the playfield lights. I know of two affected tables: Alien Poker and Black Pyramid. There may be more of course...

The same issue is not present when UVP is used (which is VPinMAME-based), so there is something the dB2S server is doing differently than VPinMAME and causes the problem. I wonder what that may be...