666 replies to this topic

[toxie]

The max looptime actually works differently.. It just slows down the physics simulation in case the FPS drop heavily..

So if you set a 1 there, it will kick in as soon as FPS are <100, 2 if < 50, 3 if < 33, 4 if < 25, etcetc

 

I personally also use 4 now, seems to be a good compromise..

 

As for the flipper issue: This i absolutely don't understand, as the physics simulation should always be the same, no matter how high/low the FPS are.. :/

[jimmyfingers]

I thought you mentioned before though that the physics cycles and FPS are bound together with VP and not decoupled like FP and what seems unity3D does as well now. Also, that it would be desirable to split that in the future.

 

If that's the case I could understand why lower FPS results in physics behaviour being altered as 60 cycles per second may not be enough samples for reproducing physics accurately. In any case, the bug is definitely present and totally reproducible but you just need a table with the higher flipper speed type flipper physics settings. I can get the bug to appear after only a few flips / attempts on certain tables.  As usual, it's across the board on all the systems I have / have tested.

 

Have you not been able to reproduce it?  It's fairly easy and if you know where your shot should generally go - then seeing it wildly off to the side, you got it! I can toggle this on and off consistently on my MODs using the vsync option as they're typically set-up with high flipper speed flippers and I know the physics side well and what generally is expected from a resulting hit. However, I don't think anyone has to be a physics junkie to see the issue occur and I actually first noticed it on JP's 1st White Water table release a while ago as it was a heavy alpha ramp table and before some optimizations. The flip hits would occasionally go wildly off on that as the FPS was around or below 200 on my systems at the time (before alpha ramp optimizations) and didn't even need the vsync enabled as it was low on it's own.

 

You can reproduce it somewhat using the recently released Airborne table but it's very easy to see on my upcoming, but yet released, AFM GI8 BMPR MOD as it has a much more open lower and middle playfield.

Edited by jimmyfingers, 08 January 2014 - 07:19 AM.

[toxie]

They are bound together, but not in the sense that the physics slow down (that's only possible as said if you use this new max loop param) or loose precision heavily if the FPS drop, but that there are no separate threads for rendering&physics or something.

 

VP will simply "catch up" by iterating over the physics calls multiple times if the FPS drop below 100 (or more general somewhere below 200, as its not fully aligned).

 

There is one special case in the physics code though that will update the balls in potentially different stepsizes if the FPS are higher (otherwise there would of course be no visual difference at all if FPS exceed 100), but from my understanding it should not differ much in the end.

But as there obviously is a difference, maybe there is some bug still somewhere, but its not exactly super-trivial to understand without documentation.

[toxie]

Another random thing that comes to mind: Did anybody of you guys actually ever try modifying the light sources and/or shadow direction?

 

IMHO there is a lot of potential there to make a table look a bit less flat, but as it has implications on the way one designs a table and the gfx for it, one has to tune it from the very beginning.

 

One definite plus is that the lighting will not change when going from desktop to FS and vice versa, as the lights will be transformed, too.

But also the dynamic range of textures, etc can be improved this way, as the two default directional light sources that VP used historically are setup really really weird.

 

In case you are wondering what this all means and how to setup the lights, just take a look at the default table, where i did some changes to the default lightsource setup and shadow dir (coder art only, sorry )

 

 

If i'm really bored at some point i will also try to finally add some ambient occlusion baking or rough global illumination for the static parts, but i guess that's still far far away. So far the best, but very crude approximation to that is setting the shadow direction to both 0.

[jimmyfingers]

Another random thing that comes to mind: Did anybody of you guys actually ever try modifying the light sources and/or shadow direction?

 

IMHO there is a lot of potential there to make a table look a bit less flat, but as it has implications on the way one designs a table and the gfx for it, one has to tune it from the very beginning.

 

One definite plus is that the lighting will not change when going from desktop to FS and vice versa, as the lights will be transformed, too.

But also the dynamic range of textures, etc can be improved this way, as the two default directional light sources that VP used historically are setup really really weird.

 

In case you are wondering what this all means and how to setup the lights, just take a look at the default table, where i did some changes to the default lightsource setup and shadow dir (coder art only, sorry )

 

 

If i'm really bored at some point i will also try to finally add some ambient occlusion baking or rough global illumination for the static parts, but i guess that's still far far away. So far the best, but very crude approximation to that is setting the shadow direction to both 0.

I've been playing around with it here and there since you added the feature and recently came back to it, as you say, because after rotating a table a lot of the default lighting look changed which was / is a problem (even when disable lighting was used on a number of objects already).  It's still a bit tough to use if a table has dynamic GI (most above any EMs) as the light spots / brighter portions aren't dynamic and remain "lit" looking even if the GI is off and that comes across unnaturally / contrary to coding the dynamic GI aspects. 

 

Lately, I've been trying to use not as a lightsource / bright spot reason exactly but a quick way to get everything to look darker and moving the light sources for L0 and L1 way up and adjusting the ambient light colour / darkness to get an overall darker table, then using the newer options on light objects / lamps to disable the lighting so that they still shine properly.  However, one main problem is arising that I think is one of the last things that prevent me personally from using it (I have an EM mode that's 90% complete but stuck with this issue) and that is the ball gets way too dark and can not be lightened by image / PS work alone.  So, what we really need is an option similar to what we have now for walls and lights, where we can disable lighting on the ball itself.  Then even if it appears too bright with a darker table at least we can PS it to a desirable shade darker where as right now we can't make it any brighter as the dark lighting is over-riding even the brightest image we could use for the ball.   

 

If possible too, an option like on the walls to use the colour choice to shade the object would be great in addition to and when the "enable lighting" is unchecked as that would give us control over the ball shading without the need for an external program (if scriptable too we could use the colour shades in spots).  However, the absolute main thing is to get the ability to disable the lighting on the ball so that using a darker table via light sources doesn't leave the ball (too) dark as well.  Hope this can be an easy add like on the lights and walls.

[fuzzel]

Please try rev850. With this revision the flipper arms are dynamic objects like primitives, alpha-ramps or flashers or in other words a flipper is rendered with each frame now. With this update the potential issue on Intel based graphic cards is solved where the ball is drawn over the flipper.

[gtxjoe]

Should I be able to open a .vpt file in the VP editor by double clicking on it?  For me, double clicking a .vpt file just opens Visual Pinball editor, and then I still need to do File->Open

 

I did find this old post where apparently it works in XP.  I don't have XP to try      Can this be fixed easily for Windows 7 and beyond?

 

http://www.vpforums....?showtopic=4609

Edited by gtxjoe, 08 January 2014 - 09:49 PM.

[htamas]

rev 849 (finally) adds the per table adaptive vsync so many asked for a while back..

(-1 copies the global setting, 0 turns it off, 1 automatically detects refreshrate, anything else sets the refreshrate in Hz)

 

This is awesome, many thanks for it.

Actually I don't like to use adaptive vsync because sometimes it causes ball hiccups but it helps me getting rid of some weird whine in my speakers due to too high frame rates, so being able to turn this feature on on a table-by-table basis is great. I can have it only active for tables where the noise annoys me but turn it off in general

 

I think way back I was the one who suggested a similar controlled implementation of vsync, so finally getting this option is much appreciated

Edited by htamas, 08 January 2014 - 10:03 PM.

[toxie]

If possible too, an option like on the walls to use the colour choice to shade the object would be great in addition to and when the "enable lighting" is unchecked as that would give us control over the ball shading without the need for an external program (if scriptable too we could use the colour shades in spots).  However, the absolute main thing is to get the ability to disable the lighting on the ball so that using a darker table via light sources doesn't leave the ball (too) dark as well.  Hope this can be an easy add like on the lights and walls.

 

 

rev 851 adds the first step of this: it disables the lighting on balls, it was so far useless anyhow, especially as balls are pure 2D.

please let me know if there are problems caused by this on some tables (unlikely, but who knows).

[jimmyfingers]

Hey guys, can you make a version with the lighting on the ball disabled but the flipper changes reverted? The new flippers are causing some odd graphic effects with them going transparent during certain screen / refresh updates on some tables as well as graphical issues with alpha ramps for flipper logos. Also, the drop in FPS is reasonable and on a blank table / new from the editor the FPS has dropped by about 50 % with just that change alone (on my test rig from about 4000 to 2100 - 2200). On a couple other test tables I'm seeing about a 15 - 25% drop and experiencing some odd other physics that I need to test more before I can elaborate on here.

 

I know we have to eventually do some of these changes in the name of eventual porting to VP10 / DX9 or OpenGL, but for now can we keep these dynamic flipper alterations as a bit of a test version or something that becomes part of a separate stream for VP10 / DX or OpenGL support? I think in general that once we (you) start making some of these bigger changes in this regard the effects on existing table is likely going to be too much / high. Hence, splitting into separate streams would be very desirable as we start to take larger hits in the name of eventual DX9 or open GL support (i.e. a 9.2.1 and a VP 10 stream where things like the changes to pre-rendered to rendered every frame starts to take place as is the case with these latest flippers).

[fuzzel]

and another rev852 this one introduces a new video option 'Vertex Buffers in VRAM'. If you enable this VP will store all 3d model data on the memory of the graphics card. It can improve the performance on some tables/systems but that depends on your system, graphics card and driver of the graphics card. The default setting is disabled like in previous versions.

Hey guys, can you make a version with the lighting on the ball disabled but the flipper changes reverted? The new flippers are causing some odd graphic effects with them going transparent during certain screen / refresh updates on some tables as well as graphical issues with alpha ramps for flipper logos. Also, the drop in FPS is reasonable and on a blank table / new from the editor the FPS has dropped by about 50 % with just that change alone (on my test rig from about 4000 to 2100 - 2200). On a couple other test tables I'm seeing about a 15 - 25% drop and experiencing some odd other physics that I need to test more before I can elaborate on here.

 

I know we have to eventually do some of these changes in the name of eventual porting to VP10 / DX9 or OpenGL, but for now can we keep these dynamic flipper alterations as a bit of a test version or something that becomes part of a separate stream for VP10 / DX or OpenGL support? I think in general that once we (you) start making some of these bigger changes in this regard the effects on existing table is likely going to be too much / high. Hence, splitting into separate streams would be very desirable as we start to take larger hits in the name of eventual DX9 or open GL support (i.e. a 9.2.1 and a VP 10 stream where things like the changes to pre-rendered to rendered every frame starts to take place as is the case with these latest flippers).

Fully agree here...this change was a test balloon to see if this can be left in...But I'm really suprised that it has such an impact on your system. On my dev system here I don't notice any slowdowns. Did you test with rev850+ or with the test version? The test version is a bit outdated

[toxie]

yup, the new version should have almost zero impact compared to the test version.. same goes for the transparency..

Edited by toxie, 08 January 2014 - 11:05 PM.

[jimmyfingers]

Yah, just the test version and not the latest so that could have an aspect. Plus, my testing was very brief and mostly only enough to notice the graphic glitches which kinda ceased too much more work / testing on that version. Thanks, by the way, for adding that VRAM option. I think I got better performance using those custom builds before, however, it may have been something else that I've noticed where limiting the FPS (from whatever aspect) can actually at times seem to improve performance (periodic stutter) if your graphics card GPU is being pinned at or around 100%. I wrote in another topic about this phenomenon but as I use forced AA mainly (for playing) it often doubles the load on my GPU and I actually smoothed out a couple tables by either adding a couple random primitives or moving the slider up as dropping the FPS from over 1000 to around 800-1000 left my GPU more free and around the 70-80s in per cent utilized which seemed to help the occasional stutter / skip (not micro stutter) but when a lot of things happened at once and the load possibly tripped / tipped the scales at or on 100 % use.

 

Point of all that is my previous positive reports on the VRAM may have been simply because of the lower FPS that the option still yielded yet the smoothness perceived because of the above notes / GPU less (or optimally) taxed.

 

I'd say to anyone, keeping your GPU from not going above 90 % during any VP table game play is helpful in limiting stutter and GPU monitoring tools quite useful for further tuning your VP experience. Again, may only be an aspect more with the demands of forced AA, however, on less high performance graphic cards, the GPU utilized per cent will get up their on it's own without AA so all of the situation would then again apply. That's one of the reason I was pushing for a bit for the per table alpha ramp accuracy slider so that I could use it on already high FPS table to quickly bring the FPS actually down slightly and get the GPU load into an ideal range.  When you’re up and around 800-1200 you have FPS to spare and if it lowers the GPU from peak ranges of 90-100 I would recommend it at this point based on my tests / experience to date.

[jimmyfingers]

Hey guys, just tested rev 853 and get even less FPS simply using the New / Template table. See the attached files for the values and my video preferences settings. I go from over 4000 FPS in the official 920 build to around 1700 with the new flippers / rev 853 - all settings / system otherwise being equal. (see below)

 Capture of New Table FPS in Official 920.PNG   470.81KB   9 downloads  Capture of New Table FPS in rev 853.PNG   258.23KB   9 downloads  VP Video Preferences.PNG   62.4KB   9 downloads

 

So, can we get a build without the new flippers at least temporarily so that we can try the other new features without this FPS eater and testing of the new rendered flippers. The transparency issue seems resolved but the alpha flipper logo glitch still remains (see below)

 

 Capture of flipper alpha logo glitch in rev 853.PNG   423.96KB   8 downloads  Capture of flipper alpha logo glitch on other (left) flipper when GI off in rev 853.PNG   329.98KB   8 downloads

 

Seems Fuzzel agrees about a separate build thread / stream for significant changes like this in the direction of DirectX or OpenGL eventual porting.

[htamas]

_{rev.851 introduced a graphics glitch with flippers in Elvira and the Party Monsters.}

_{This was working OK with 849.}

 

 851_glitch.jpg   106.08KB   9 downloads

[LoadedWeapon]

well I just ran a few tests and everything past r849 i lose fps (f11) all test done with newest table updates..

 

Attack from Mars

r780  --  590fps

r849  --  625fps

r853  --  515fps

 

        CV

r780  --  775fps

r849  --  780fps

r853  --  645fps

 

     STTNG

r780  --  680fps

r849  --  685fps

r853  --  490fps

 

  Checkpoint

r780  --  280fps

r849  --  280fps

r853  --  260fps

 

     Apollo

r780  --  265fps

r849  --  267fps

r853  --  250fps

 

Starship Troopers

r780  --  405fps

r849  --  408fps

r853  --  340fps

 

  Indiana Jones

r780  --  370fps

r849  --  365fps

r853  --  325fps

 

 

 

 

 

[htamas]

 

rev 849 (finally) adds the per table adaptive vsync so many asked for a while back..

(-1 copies the global setting, 0 turns it off, 1 automatically detects refreshrate, anything else sets the refreshrate in Hz)

 

This is awesome, many thanks for it.

Actually I don't like to use adaptive vsync because sometimes it causes ball hiccups but it helps me getting rid of some weird whine in my speakers due to too high frame rates, so being able to turn this feature on on a table-by-table basis is great. I can have it only active for tables where the noise annoys me but turn it off in general

 

I tested this feature and while it works well for some tables, it causes severe sound stuttering and repetition with many others, especially the ones with a lot of ROM sounds. But even a table like Frontier (which only has some chirps and no constant soundtrack) stutters badly.

Is there a way to avoid sound stuttering while using adaptive vsync?

Edited by htamas, 09 January 2014 - 02:24 AM.

[sleepy]

 

If possible too, an option like on the walls to use the colour choice to shade the object would be great in addition to and when the "enable lighting" is unchecked as that would give us control over the ball shading without the need for an external program (if scriptable too we could use the colour shades in spots).  However, the absolute main thing is to get the ability to disable the lighting on the ball so that using a darker table via light sources doesn't leave the ball (too) dark as well.  Hope this can be an easy add like on the lights and walls.

 

 

rev 851 adds the first step of this: it disables the lighting on balls, it was so far useless anyhow, especially as balls are pure 2D.

please let me know if there are problems caused by this on some tables (unlikely, but who knows).

 

 

But doesn't that also disable the ActiveBall.Color method?

Dim ActiveBall
 
Sub Plunger_Init()
PlaySound "Plunger",0,0.5,0.5,0.25
Set ActiveBall = Plunger.CreateBall
ActiveBall.Color = RGB(255, 0, 0)
End Sub
 
Sub Trigger1_Hit()
ActiveBall.Color = RGB(0, 255, 0)
End Sub

The ActiveBall.Color method is not working in rev 851.

I'm not sure, but I think using a custom Ball.Image defeats the default lighting.

Edited by sleepy, 09 January 2014 - 04:07 AM.

[fuzzel]

ok rev 854 reverts the flipper rendering to the old pre-rendered version.

[vulbas]

hello ,

i have a probleme with VP 9.2.824 and better
indeed every release since this one disactivate the keys i use. i m' using GP wiz40 for my pincab keys 
http://groovygamegea...products_id=235

So when i use 9.2.824 or better my keys doesn't answer anymore. i tried to solve it test lot of things without success

do you have any idea ?

thx

 

i have the same problem with 853