1394 replies to this topic

[oldskoolgamer]

Wow that was fast! Thank you very much!

[imagamejunky]

The dropbox link at the beginning of this thread has versions up to 626. Would one of you be willing to share the 627 revision? Or is it available somewhere that I am missing?
Thanks

[LoadedWeapon]

It will have to get compiled then uploaded.. It will be out soon

[jpsalas]

I was looking for a way to "redraw" an alpha ramp without using a light under, as we have been done for years now. Mostly because I felt it was redrawing other ramps too, and the table looks better without those black lights

 

And there is a way. You simply add the command rampname.alpha = 1 whenever you want to redraw the ramp.

 

This worked very well under VP915, but it doesn't work very well under VP916 if the region updates in on.

 

Here you have a small table with an animation made with a single ramp. If you turn on region updates then you will see it stops working. I guess this could be considered a "bug"

 

 

So now you know, all of you authors, stop using those black lights

 

PS: You may ask, why use alpha ramps when you can use primitives? Mostly because the alpha ramps can be used not only in small animations, but also they are used to make the flashers, and they look really nice under VP916

Edited by jpsalas, 30 July 2013 - 06:39 AM.

[oooPLAYER1ooo]

Yeah I agree with Jp about ramps.

I have done lots of experiments with them and they can pretty much do anything animation wise and can be angle independent.
but as primitives get better I think ramps will be used less and less.

Nice find with the alpha redraw Jp that will tidy tables up a great deal in future.

[toxie]

I was looking for a way to "redraw" an alpha ramp without using a light under, as we have been done for years now. Mostly because I felt it was redrawing other ramps too, and the table looks better without those black lights

 

And there is a way. You simply add the command rampname.alpha = 1 whenever you want to redraw the ramp.

 

This worked very well under VP915, but it doesn't work very well under VP916 if the region updates in on.

 

Here you have a small table with an animation made with a single ramp. If you turn on region updates then you will see it stops working. I guess this could be considered a "bug"

 

demo_animation.vpt

 

So now you know, all of you authors, stop using those black lights

 

PS: You may ask, why use alpha ramps when you can use primitives? Mostly because the alpha ramps can be used not only in small animations, but also they are used to make the flashers, and they look really nice under VP916

 

 

One more reason to kick out region updates once and for all..

 

I just wonder why this worked in VP9.1.5, as there the region update was basically always forced to enabled. Do you also use the region optimization?

 

EDIT: Sorry, forget about this.. VP9.1.4 always had it enabled.. But the other question still is valid..

Edited by toxie, 30 July 2013 - 09:51 AM.

[jpsalas]

Oops, my bad, region updates had to be disabled in VP15 for them to work, just like in VP916. (I was sure I had turned it on)

 

Ok, here you have another demo, this time a rubber ball, just to show how the alpha ramps can grow and shrink, and also move up and down. So for small animations they can also be used.

 

 

 

 

[toxie]

So hooray for getting rid of region updates then in 9.1.7? 

[jpsalas]

So hooray for getting rid of region updates then in 9.1.7? 

Yes! and just now I'm a little confused, since in my computer at work, the animations also work without the rampname.alpha = 1 (!?) I'll need to try it at home

 

Edit: if Region Optimization (NVIDIA (FX)AA fix) is ON, then you don't need the alpha=1 statement. But if it is off then you really need the light under the ramp, since alpha=1 is not enough to redraw the ramp.

Edited by jpsalas, 30 July 2013 - 12:36 PM.

[luvthatapex]

Hmm, I just tried this and if NVIDIA FX AA is ON you are correct, you don't need the blacklight to refresh the ramps. BUT performance drops in HALF with this one. WOw what a FPS killer. I can't use that for sure.

 

So with AA OFF, how would you modify your fading ramp logic? Do I need another case statement to refresh the ramp to turn it off?

With the blacklight removed and using this sub to do the fading flasher, the flasher stays on....

 

Sub FlashAR(nr, ramp, a, b, c, r)                                                        'used for reflections when there is no off ramp
    Select Case LampState(nr)
        Case 2:ramp.alpha = 0:r.State = ABS(r.state -1):LampState(nr) = 0                'Off
        Case 3:ramp.image = c:r.State = ABS(r.state -1):LampState(nr) = 2                'fading...
        Case 4:ramp.image = b:r.State = ABS(r.state -1):LampState(nr) = 3                'fading...
        Case 5:ramp.image = a:ramp.alpha = 1:r.State = ABS(r.state -1):LampState(nr) = 1 'ON
    End Select
End Sub
 

 

Edit: if Region Optimization (NVIDIA (FX)AA fix) is ON, then you don't need the alpha=1 statement. But if it is off then you really need the light under the ramp, since alpha=1 is not enough to redraw the ramp.

 

[unclewilly]

on my win 7 pro 64bit  the animation won't play at all no matter what options I have checked.

 

my NVidia options are fxaa on,  anisotropic filtering 16x, override app settings, 16xQ CSAA

 

 

so not sure what I am doing wrong

[jpsalas]

@unclewilly: It has nothing to do with the Nvidia's control panel, nor its 3D options. It is just the option on the VP15 and VP916:

 

 

as you can see it has only selected the Hardware rendering and the Region Optimization (Nvidia....). Nothing else. If I select the region Updates the frame rate goes up, but the animations don't work anymore (unless you use a light under). And if I de-select the Region Optimization then the flashers with the Additive alpha looks like sh*t

 

@luvthatapex: I'm sure you must have enabled the Software FXAA. That really kills the framerate on my computer too.

 

With those setting I can even drop the ramp.alpha = 1. So with that options you can remove of the refresh lights, and the ramps will refresh when its size or image change.

 

So set those VP options and take one of those demo tables and remove the ramp5.alpha=1 or the ramp6.alpha=1 and the animations still works.

 

JP

[unclewilly]

ok so now I can see the animation.

the problem is unless I have the region updates on I get this issue with the flippers


 flipperissue.png   146.38KB   18 downloads

[jpsalas]

ok so now I can see the animation.

the problem is unless I have the region updates on I get this issue with the flippers


flipperissue.png

Yes, all computers are different. If I set Region Updates I get very high frame rate, but the ball suffers from tearing and if the ball travels at high speed it completely disappears.

 

I have that flipper issue with my portable computer with an intel graphics. To fix that I run VP in 16 bits mode, and it works quite well.

[unclewilly]

Hopefully fuzzel and focus can find a common ground so the alpha animation works without the light and the other glitches don't happen.
The animation without the light is a big improvement

[LoadedWeapon]

^{on my win 7 pro 64bit  the animation won't play at all no matter what options I have checked.}

 

^{my NVidia options are fxaa on,  anisotropic filtering 16x, override app settings, 16xQ CSAA}

 

 

^{so not sure what I am doing wrong}

 

Unclewilly in windows 7 64bit when you force settings to VP thats what gives the glitches.. I have ran many tests and if you set nvidia to default it wont glitch but then the tables that work good wont look as good.. I am using the newest Nvidia drivers on a gtx660 card

This is with all settings turned on in VP but nothing forced in NV

 on.png   1.28MB   7 downloads

 

This is everything on in VP and forced settings in NV

 VPinball 2013-07-30 16-34-06-40.png   1.25MB   7 downloads

 

ok but I did just test JP's animation and mine did the same thing.. With RU on it wouldent bounce but with it off it worked... Hmmm

Edited by LoadedWeapon, 30 July 2013 - 08:57 PM.

[fuzzel]

the render engine is really weired. I just want to explain some behaviours, well maybe I didn't understand everything myself so Toxie please jump in if I mix something here

You all know that 3/4 of every table is pre rendered, so basicly VP is a big sprite show if you play a table. Only alpha ramps and primitives are the only real dynamic elements. The majority of every table is static, no moving objects but the balls so to increase the performance only those areas are drawn again if something changed there. Because of that you normaly need the light under a ramp
just to tell VP to update that region. The sprites/animation is copied to the screen buffer if a region needs an update everything else
is untouched. Todays graphihc cards are optimized to render 3D stuff and not to move textures/sprites inside the buffers around.
I don't know how Nvidia and AMD have optimized their drivers but it's always a good idea render everything instead of copying it and I don't know how the backward compatibility with DX7 is done.

Now the 'bad' news: the whole render engine is optimized moving textures/sprites and not really rendering it for each frame.
I thought a lot about how to change this in a step by step way but unfortunatly I always end with a solution where I have to break the compatibility. This change of the engine is necessary to port VP from DX7 to DX9. So I fear that all these alpha ramp fixes are only possible if we rework the render engine once and for all.

Edited by fuzzel, 30 July 2013 - 09:37 PM.

[jimmyfingers]

Chiming in here with my experiences on this animation / the no light alpha approach / flasher graphical problems. On my rigs, this demo animation / no light approach will only work if region optimization is checked / enabled, however, that introduces the old forced AA (Nvidia control panel) that it originally fixed. I have also noticed the flashers with additive alpha can look terrible if either the region updates or optimization is indeed cleared (to help with AA bugs), however, that can be mitigated by selecting / enabling the checkbox on all alpha flasher ramp objects for "Normal 3D stereo" (knowing that this is counter-intuitive to the purpose of that option). That fixes the bad flashers and just takes some editing around the table to still keep bug free forced AA (except the long standing light black lines) by allowing the region optimization setting to be not selected. Of course that would be a problem if one was really using 3D stereo and the ramp “Normal 3D stereo” option desirable to not be on as expected for “halos / hacks” but in that case the 3D stereo has it's own AA (VP software) options that can be used and forced hardware AA can be turned off, region optimization left on, and the ramp objects left with the "Normal 3D stereo" option cleared for good 3D rendering.

 

On my rigs the performance also drops dramatically with region optimization enabled and AA forced and still somewhat even without AA and in both cases seems less fluid in game play. So, I've constantly got the best performance with just hardware rendering enabled and nothing else using the flasher graphic bug / additive alpha work around on the per ramp settings above.

 

As far as the black / refresh light, I created an updated alpha image based set of routines / refresh method that uses a single global refresh light that only gets updated once per lamptimer cycle and greatly saves performance as it updates all changed alphas in a single refresh. The routines for alphas were modified to simply set a flag that the light needs refreshing (if the alpha image has changed) and any other alphas that changed within that time period also get updated next lamptimer cycle with a single light refresh (no difference in timing either from the older / original routines but consolidated via scripting). It has allowed some huge performance savings, ability to add even more "eye candy", and yields very fluid game play on some not yet released MODs / tables I'm working on while also keeping the ball movement smooth even during heavy flasher / lighting activity. I believe the ramp.alpha=1 has it's benefits as well and might as well be an option but may take us back - performance wise - closer to as if the single light refresh / object refresh for each ramp as it is individually based again and, with lot's of them going on independently, be less optimized than using this newer script controllable method.

 

The BBB 2.0 update that I helped UW with has this newer global AR method and allowed for about a 250% increase before bringing it back down a bit with a number of primitive / graphic improvements for targets and flipper logos. Other soon to be released tables will demonstrate this as well and I personally would not change anything in how I'm able to achieve now some great FPS and smooth game play leveraging this technique (plus all the wicked performance improvements and options that have been gradually added to the VP builds). Again, I think getting the alpha.1 refresh with no light working is still important and great to have as a method to use but believe that the manually manipulated global / single refresh method will yield ultimately better performance - (i.e. both methods will have their merits). Which reminds me, a massive thanks to fuzzel for this latest build and it's great alpha / FPS increases! If you can't tell, I'm a stickler for performance

[unclewilly]

no biggie fuzzle.  I have no problems working with what we haqve now with the big render light.  we have that pretty optimized now.  I can certainly wait for you guys to gradually port over to dx9.

no rush and i'm more than happy with the advancements we already have.

 

the primitives are amazing and the animation we get with alpha ramps has been fairly optimized via the table script.

 

no worries and thank you guys for everything you've been doing

[toxie]

the render engine is really weired. I just want to explain some behaviours, well maybe I didn't understand everything myself so Toxie please jump in if I mix something here

 

You nailed it pretty much, so nothing from my side..

 

I just wonder how we should progress from now on.. Getting rid of all the stupid partial blits would be a start, to get rid of at least some of the rendering artifacts for now..

So no region updates anymore and maybe some other form of the evil region "optimization", i.e. blitting all stuff from scratch, each frame..

This will be slower in the beginning, but then at least we have a new, clean frame each cycle, and could then continue replacing the 2D blits by the original 3D render calls one by one??

 

And maybe releasing an official 9.1.6 before starting that?