1394 replies to this topic

[fuzzel]

flasher element, mesh primitive manager (something like the image manager), rubber element and overall improvements to VP to switch it to a new render API ( DX9 or OpenGL) someday. I can't say if all of these come in the next version (9.3), depending on my free time

[jpsalas]

Well, I must say that I like this rev 786. I have spent the whole week trying to get the ramps to work on my beta TOTAN table using rev 782 and 783 and there have always been some ramps that don't behave. I have had no problems with the ramps up to rev 780.

 

But now with rev 786 I can simply change the height of a ramp by +0,1 or -0,1 and they look nice again.

 

Now. I mean that before VP9.2 is released, a few things should be sorted out. Remember all the trouble people had when VP9 came out? People had trouble with the Hardware Device Rendering. Just one choice HDR on or HDR off, and I guess you all remember all the trouble people had with just one setting/option. And now there is not only the HDR, but RU and RO too.

 

When RU and RO came I found out that by turning off RU and turning on RO, the alpha ramps worked perfectly, and I didn't need to use any refresh light anymore. I have tried this setup on 3 computers, one with a Nvidia card, one Ati and one Intel Graphics (which I must run VP at 16bit). And this setup works fine on all them. I mean those options was nice to have in the beta testing phase, but to release VP9.2 with all those options will only lead to more frustation among the users. I mean it should be decided what should be the default settings, something we could test the tables before releasing them to be sure they worked fine at the default settings. So my idea is to decide what should be the default, and put a Default button selection in the video options. With this Default button selected all the other options are hidden or greyed out. If you deselect the default button, then all the options appear. All the tables should be tested to work with the default settings.

 

The problem should be to decide what should be the default settings. In my case I use just one monitor and no 3D, so my defaults could be

HDR ON (it should not even be an option, since nothing new works with it off)

RU OFF

RO ON

 

With these settings I don't need any extra refresh on the alpha ramps used as flashers or GI.

 

But I have no problem if it is decided the both RU and RO should be on or off, to make things more compatible with other hardware or with 3D settings. Then I know I'll need to add a refresh command to the alpha ramps. But that's ok. What I should like is to remove the confusion for the users who just want to play. And if a setting should be always on or always off then I mean it should not be an option at all.

 

Just my two cents. And I must say that I'm impressed with all you devs have added to the program.

Edited by jpsalas, 14 December 2013 - 06:19 AM.

[toxie]

I fully agree with you there JP..
With this release we added simply too much new stuff (which is obviously good, but also bad in some sense), thus we all still don't know about all the pitfalls waiting..

 

As for the default settings: I also agree on the RU off, RO on part from my tests.. I mean its also always an option to simply hardcode this into the table settings and then see what happens when more users use this table.. (there can always be still a new version or MOD afterwards)
Maybe we could even make it a new 'only' option over time?

 

But so far i would please ask you authors to work with refreshs as it is the only safe option to also work with 3D.

 

As for the sorting: I'll make this a table option (or even a per ramp option?) and also only use it for alpha ramps. I just wanted to get this to you guys yesterday for a quick test as i had to leave. Will implement the bells and whistles tomorrow, i guess, unless fuzzel beats me to it.. 

I would also vote to still include this into 9.2.0, as it will be completely optional and seems extremely useful for authors..

Edited by toxie, 14 December 2013 - 07:53 AM.

[toxie]

Further explanation with the issue... it seems that the the main ramp that goes from 0 to 130 is getting drawn above a flasher at a height of 51... Does it determine the sorting by the average of the top and bottom heights?

 

what would be better? bottom or top? (currently average)

[fuzzel]

@Toxie: if you want to add the sorting stuff, which is completely ok for me , do the sorting for primitives too. Because you can use an alpha texture on primitves too and if you add a toy on a ramp it could look odd... but that would mean to sort by the average value

[koadic]

Further explanation with the issue... it seems that the the main ramp that goes from 0 to 130 is getting drawn above a flasher at a height of 51... Does it determine the sorting by the average of the top and bottom heights?

 
what would be better? bottom or top? (currently average)

I would be a fan of bottom sort myself, and a per table option... maybe a separate box for primitives, as there is nothing I can do to make my overlapping primitives draw in the right order with the current method as far as adjusting either the z value or z size.

Also, if you were to enable this on a single ramp/primitve basis, how would the auto sorted ramps react with the manually sorted ones?

[koadic]

One other idea... maybe an actual height, and a draw/order height (to substitue for the current drawing order)? obviously if two alpha blended ramps are on the same actual height, regardless of order, there are gonna be a few issues, but when working with non flahsers (actual ramps) where the top/bottom/average covers such a wide range, it will throw a wrench into the works where forcing a drawing order via a definable 'draw height' would help, especially if all alpha ramps are autosorted.

And an alternative, going back to full manual sorting, maybe a new 'drawing order' dialog that only includes alpha ramps/non-static primitives, but lists all of them on the table (and possible extra information like height?) so there are no surprises when one ramp is adjusted, throwing a bunch of other stuff out of whack. This should be fully compatible with older releases as it should populate with the current order anyway, effecting no change unless it is utilized to make changes. Alpha/Advanced Drawing Order Ctrl+Shift+A

Edited by koadic, 14 December 2013 - 10:56 AM.

[unclewilly]

I haven't messed with the ramp lighting yet.

For the default settings, I would vote for having ro and ru turned off. This way you can use nvidia aa. With no glitches.
I also get better fps with both off.
And using the single refresh command in the script should also eliminate the need for the refresh light

[PilzTom]

DELETED by me, sorry - I should had have a look at VP before.

Edited by PilzTom, 14 December 2013 - 01:27 PM.

[fuzzel]

One other idea... maybe an actual height, and a draw/order height (to substitue for the current drawing order)? obviously if two alpha blended ramps are on the same actual height, regardless of order, there are gonna be a few issues, but when working with non flahsers (actual ramps) where the top/bottom/average covers such a wide range, it will throw a wrench into the works where forcing a drawing order via a definable 'draw height' would help, especially if all alpha ramps are autosorted.

And an alternative, going back to full manual sorting, maybe a new 'drawing order' dialog that only includes alpha ramps/non-static primitives, but lists all of them on the table (and possible extra information like height?) so there are no surprises when one ramp is adjusted, throwing a bunch of other stuff out of whack. This should be fully compatible with older releases as it should populate with the current order anyway, effecting no change unless it is utilized to make changes. Alpha/Advanced Drawing Order Ctrl+Shift+A

I'm a fan of the alternative solution. Afaik changing the drawing order to automatic sorting would mean a longer testing phase but adding another drawing order dialog for ramps and primitives is much easier and can be easily tested.

[toxie]

I'm actually just working on this, just a few more minutes..

[fuzzel]

Yeah, on which one?

[toxie]

Okay, done with rev 787..

 

I actually went for a mixture: Instead of only having the drawing order for the place where you click, you can now also optionally have this list for all selected elements.

This way you can select whatever you want and tweak the order.

 

(unless i screwed something up, fuzzel, please review my checkin)

 

 

EDIT: oh, and i reverted the sorting of the alpha ramps, as it was just a test for you guys, which obviously didn't work out..

Edited by toxie, 14 December 2013 - 04:23 PM.

[fuzzel]

looks good but the context menu doesn't open the drawing order dialog. I only did a quick test but if I select multiple elements (primitives, ramps, walls) and open the context menu and click on 'Drawing Order (Select)' nothing happens. If I use the menu Edit it works...

[toxie]

phew.. if you find it could you please fix that, i've gotta go again.. :/

 

and at the authors: please test if this is feasible to work with, otherwise we have to figure something else out..

[fuzzel]

I haven't time yet, but I can have a look at it tomorrow

[jpsalas]

phew.. if you find it could you please fix that, i've gotta go again.. :/

 

and at the authors: please test if this is feasible to work with, otherwise we have to figure something else out..

Yes, it works fine for me. By selecting all the ramps and adjusting their redrawing order was easy. But all the ramps that are on top of each other should be at different heights, a 0,1 of difference in height is enough. I guess this will break the tables that has been released relying on older betas (like the latest night mods). But with the help of the layers and using this drawing order based on the selected items, they will be easy to fix. Using CTRL SHIFT S was the fastest way for me to get the menu

 

So I guess now it is a matter of fixing the right click to open this menu and VP9.2 is ready to go

 

About adding a default settings button, with HDR on, and RU and RO off (as UW suggested), I don't think it is needed since to keep it compatible with most hardware we need to add the refresh command to those alpha ramps used as GI or flash. And by using the refresh command it make the ramps refresh regardless if RU or RO is on or off. So maybe just leave RU and RO off as default, so it is more compatible with the Nvidia AA, and if someone need to turn them on to increase performance so they can do it.

Edited by jpsalas, 15 December 2013 - 03:42 AM.

[jpsalas]

I have updated my TOTAN and AFM beta tables so they work with this latest revision.

I have also updated the fading lights with the refresh command for the alpha ramps, so it should work on all the setups (with RU and RO on or off).

I have changed also the gi subs so they work a little better than before, making the gi fade quite nice (it uses the 8 vpm levels)

 

I'm still learning about how to make a mesh for the 3D primitives, so the pegs and screws aren't as good as I should like

 

So, test the tables and see if they work on your system.

[DreamTrap]

is it me or does the ball seem like it's FLOATING in rev787?

[toxie]

fuzzel just fixed the context menu and i added a tiny thing from my todo list (per table FXAA setting) with rev 789..

is it me or does the ball seem like it's FLOATING in rev787?

 

for me it looks/behaves exactly the same as before..