834 replies to this topic

[mukuste]

When I worked on the ramps to adapt them to the new opacity model, I realized that there are two options on them which we probably don't need anymore now: additive alpha blending, as well as the Stereo 3D hack checkbox. Flashers should take care of handling this functionality in a more efficient way now. So would anyone object to removing these two checkboxes?

[mfuegemann]

Hi mukuste,

 

working with the two left ramps on BF I realized a strange behaviour. If the ramps are too close to each other (not crossing or overlapping), the ball movement on the inner ramp is blocked and the ramp seems to have invisible steps. As soon as the distance between the ramps is widened, the ramps work fine. Maybe You can investigate this behaviour for VP10.

 

Regards

Michael

[unclewilly]

That is fixed with the new physics I think.

Remove those checkboxes.
I just use ramps for ramps now

[unclewilly]

How far of is the merging of the physics mod with this branch

[mukuste]

Hi mukuste,

 

working with the two left ramps on BF I realized a strange behaviour. If the ramps are too close to each other (not crossing or overlapping), the ball movement on the inner ramp is blocked and the ramp seems to have invisible steps. As soon as the distance between the ramps is widened, the ramps work fine. Maybe You can investigate this behaviour for VP10.

 

Regards

Michael

 

Just to be clear -- you are talking about old VP9 physics, yes? That's not really relevant anymore since the new physics from the other thread will be merged into VP10 at some point. Not sure when, I still have a few tweaks to make to the physics.

[jpsalas]

When I worked on the ramps to adapt them to the new opacity model, I realized that there are two options on them which we probably don't need anymore now: additive alpha blending, as well as the Stereo 3D hack checkbox. Flashers should take care of handling this functionality in a more efficient way now. So would anyone object to removing these two checkboxes?

No problem for me, since as UW said, the flasher object can now be used instead of ramps.

[Pinbotfan]

The road to VP10 should include full documentation of each and every feature and function. touched or untouched. Explanation of settings, Value ranges, relationships. It would be much easier than writing a manual at the end

[mukuste]

The road to VP10 should include full documentation of each and every feature and function. touched or untouched. Explanation of settings, Value ranges, relationships. It would be much easier than writing a manual at the end

 

I fully agree -- do you volunteer to write it?

[Pinbotfan]

I don't know if you are earnest or not. I don't know what you are doing. I don't even fully understand the ranges of what can already be set. Documentation is a dev. duty.

 

I didn't say it has to be done. I said it should be done. 

 

The point was actually that if it is going to be done, that it would probably be much easier done during and not after.

Edited by Pinbotfan, 23 May 2014 - 07:48 PM.

[Shoopity]

Just my $0.02 (which unfortunately has a horrible exchange rate), and I'm sure this has be echoed by others so just count me in with that group:

Don't concern yourself too much with backwards compatibility.  VP9.9 is really good.  People are having to touch up their tables anyway just to take advantage of those new features.  And just like VP8 has remained available, just keep VP9.9 available and ALL those tables will forever be playable.

 

I admit, I've only ever made one table and it wasn't popular (maybe because it's riddled with bugs), but I wouldn't mind making again.  I wonder what percentage of code is just getting stuff to look pretty (stuff that should be handled by the editor/player).  I mean, ideally speaking, coding a VPM table should be relatively easy; you just tie all the lights, buttons, motors, and solenoids of the table up to the ROM and let the ROM do all the control.  Right now it seems the vast majority of the code is just faking effects and making things move with timers.  Where as I don't expect that type of coding to completely disappear, I think it should be greatly minimized.

 

Take for example the lights; ideally I should just be able to say there's a light here, here's the color and the intensity, and the program handles the rest (proper shades, fading, etc.).  I shouldn't have to include a bazillion images that were done outside of the editor (thinking of the work Scapino did always makes my head spin) and program the swapping of those images.  The point is, you're not really "breaking" anything.  VP9 will always be available to work with tables designed for it.  Let's move on to the next great thing, even if that means re-making our favorite stuff which is only needed if someone feels like they want to include the new features (because the current tables look amazing as it is).

[mukuste]

I don't know if you are earnest or not. I don't know what you are doing. I don't even fully understand the ranges of what can already be set. Documentation is a dev. duty.

 

I can't say I agree with this fully. It might be true for a classical closed source/commercial development model; even then, it won't be the developers themselves writing the documentation, but a separate team of technical writers. VP is a community effort, there are programmers, table authors, artists, backglass designers... why can't there be people writing documentation, too?

 

Look at it this way: the VP community isn't that small, but there are only very few people who are able to contribute to the source code on a consistent basis, with a limited amount of time. If these people also have full documentation duties, they have even less time to work on the code. If another community member who doesn't have to be a coder writes documentation, that frees up a lot of dev time. Of course, it can't be expected that this person would know all the nitty-gritty details, but there are plenty of people who understand VP pretty well, and any questions can always be answered by the devs.

 

Actually that's one reason why I was pushing for a VP wiki in the past: it would allow the community as a whole to work on documenting VP, taking the responsibility off any single person. Sadly, nothing in that direction has materialized so far.

 

Have a look at this beautiful and comprehensive online documentation for FP: http://www.martin-br...uebersicht.html

That wasn't a developer, just someone passionate about the software who wanted to contribute.

[fuzzel]

Just my $0.02 (which unfortunately has a horrible exchange rate), and I'm sure this has be echoed by others so just count me in with that group:

Don't concern yourself too much with backwards compatibility.  VP9.9 is really good.  People are having to touch up their tables anyway just to take advantage of those new features.  And just like VP8 has remained available, just keep VP9.9 available and ALL those tables will forever be playable.

 

I admit, I've only ever made one table and it wasn't popular (maybe because it's riddled with bugs), but I wouldn't mind making again.  I wonder what percentage of code is just getting stuff to look pretty (stuff that should be handled by the editor/player).  I mean, ideally speaking, coding a VPM table should be relatively easy; you just tie all the lights, buttons, motors, and solenoids of the table up to the ROM and let the ROM do all the control.  Right now it seems the vast majority of the code is just faking effects and making things move with timers.  Where as I don't expect that type of coding to completely disappear, I think it should be greatly minimized.

 

Take for example the lights; ideally I should just be able to say there's a light here, here's the color and the intensity, and the program handles the rest (proper shades, fading, etc.).  I shouldn't have to include a bazillion images that were done outside of the editor (thinking of the work Scapino did always makes my head spin) and program the swapping of those images.  The point is, you're not really "breaking" anything.  VP9 will always be available to work with tables designed for it.  Let's move on to the next great thing, even if that means re-making our favorite stuff which is only needed if someone feels like they want to include the new features (because the current tables look amazing as it is).

Yes you nailed it. Building a VPM/EM or original VP table takes a lot of time if you want to make it "right". The problem with the old rendere was you can't do the fancy stuff you can do with todays graphics cards. Another problem was the backwards compatibility in VP9. Now we are more or less free to change things to achieve great effects without mind breaking the compatibility with older tables. There is one rule though: users should load VP9 tables into VP10 but they won't work well or give you errors. Now if you load a VP9 table in the early alpha version of VP10 you can see what I mean, the backdrop settings have changed, the light inserts have changed completely, ramps are missing some scripting commands because they are obsolete, the ball is different and there are multiple other things coming up...

[Slydog43]

the future is sure looking bright, long live pinball and vp!

[mukuste]

I'll just post another build here for those who want to test the latest features. As always, this is a prerelease and everything here is subject to change.

 

Changes:

• implemented transparent walls
• transparent ramps can now have their opacity set from the editor
• some bugfixes to ball drawing (no more squashing), and ball scaled to proper size
• Solid/Outline editor view is now remembered
• some script properties renamed for consistency (see the table upgrade guide), added Opacity property to ramps and walls
• fixed some bugs with light sources, custom light source positions may have to be adapted
• fixed bug in Select Element dialog box where selected items would get added to previous selection

Table Upgrade Guide: https://github.com/c...e-Upgrade-Guide

Attached Files

•  VPX_rev1081.zip   686.01KB   88 downloads

[BigBoss]

So the physmod isn't all merged into this?

[mukuste]

Not yet, no.

[unclewilly]

Thank you. Will test this out tonight.
Very much appreciated

[BigBoss]

Not yet, no.

Is there a reason not to just merge those branches since the physics updates are going to be in vp10 anyway?

[javier1515]

 

Not yet, no.

Is there a reason not to just merge those branches since the physics updates are going to be in vp10 anyway?

 

 

 

Ask the same question that Big Boss?

 

 

Thanks again for all work Makuste.

Edited by javier1515, 25 May 2014 - 04:31 PM.

[mukuste]

 

Not yet, no.

Is there a reason not to just merge those branches since the physics updates are going to be in vp10 anyway?

 

 

This VP10 pre-release isn't really compatible with any old tables, so it would make it very hard for people to test any changes I still want to make to the physics branch if it were merged into the VP10 branch.