2087 replies to this topic

[ClarkKent]

Roadshow still has the distortions on the jaws of the heads and on some lamps.

[unclewilly]

So the new test will have all the changes from the just released dx7 final version?

Can't wait to get home and test this out

[mukuste]

Yes, it does.

[toxie]

 

1. Start the player
2. Hit Esc or Q
3. Click on Resume (or hit Enter)

VP then completely exits. This happens consistently in Test8 for me.

 

 

Ah, okay.. In Test8, yes, but for the fixes you merged after that, too?!

 

EDIT: Forget it, just saw your other message that it works now.. 

Edited by toxie, 05 March 2014 - 02:57 PM.

[naboodiver]

 

Still a couple of bugs.     I am not sure if others are seeing the same but on my table I am seeing the following:

 

Can anyone explain why the ball flickers on Rocky and Bullwinkle?    http://www.vpforums....s&showfile=8782

 

The boogie men on Elvira Party Monster are missing.    http://www.vpforums....s&showfile=9003

 

I reported both of these issues.   I think the problem with Rocky & Bullwinkle is that "Fake anti-aliasing" is turned on in the table options.   Try setting it to 0.   Champion Pub has the same issue. 

 

Not sure why the boogie men are missing.  

 

Thank DJ..

 

I will have a look at the fake anti-aliasing at the table level.    Thanks for pointing it out for me.    I have seen screen shots from others where the Boogie Men are showing up on DX9.   Maybe a fresh install or another version.   I will take a look tonight.   Thanks again.

[ClarkKent]

Found a solution for TSPP: Just set black as transparent color for Homers head. Ball movement totally smooth now!

 

Would be nice if someone could provide a primitive for the head...

[kiwi]

 

Me too, I have trouble capturing the screen, sometimes it works.
I have noticed that there are darker areas, the sides of the hole seems there are some oil stains,
something similar happens also on target.
When I can capture the right screen , every time that I start rendering the result changes, I will post some pictures.

 

Thanks

 

Max

The sides of the holes are made with walls, occasionally there are also spots in the three central target
At the top of the image, the plastics as seen in VP920, below lacks transparency between the plastic of the left and the middle.
The bulbs are made with the bumper, are off instead of being turned on.
The triangular shape, is often very visible.

XP and ATI HD 5770 with the latest drivers available for this card.

 

 

Thanks

 

Max

 

I forgot to say that unchecking the box "Enable Lighting" in the property of the walls, oil stains disappear.

 

Thank you very much.

 

Max

[jimmyfingers]

Thanks for the latest build Mukuste.  Unfortunately, I actually get more ball stutter with VP9_DX9_Test8a than with VP9_DX9_Test7 on at least a few tables (some maybe just more noticeable than others).  At first I thought it was just the way FXAA was working and a new flaw / problem with that (possibly from some merging aspects), however, I can get a distinct difference between the two versions, all other things being equal, even when FXAA is disabled (i.e. only change being the version).  It just seems at the moment that FXAA just helps bring it out / demonstrate it a bit more I suppose with the increases system demands.  It's not entirely reproducible to the same extent on all table but I have a few that it's very obvious.  I've tested / verified it on two different systems both Windows 7 32-bit one with a GTX 560ti and one with a GTX 760 driver versions 334.89 and 332.21 respectively).  Same VP settings for both

 

I'll send you a PM / link for the test table and describe a bit more in there but if you run the one I'm sending you the link for right out of the gate, you should see a difference between the two versions.  Even better if you configure FXAA in the main VP preferences, then set the table options to -1 to take those general preferences (that's all I've been testing with as currently the per table option is unclear as to which FXAA mode it will invoke - quality or fast). Maybe something has changed for the opposite in the rendering / ball optimization that you mention in the release notes.  In any case, this example / table can definitely demonstrate a regression in micro-stutter / ball smoothness.

[mukuste]

JF: Can you give me the approximate framerates from Test7 and Test8a on the tables where you notice increased stutter? Please also check the new frame time and max frame time counters on F11.

[jimmyfingers]

Framerates from average of 3 launches of each version, game started, and ball left in plunger:  

Test7: 271

Test8a: 308

 

Very interesting to note though is that both versions start with a framerate almost identical (at around 308) but only the latest test8a build stays that high during game play.  In the past, every table I can think of / when doing performance assessment always had the FPS drop from the initial FPS once a ball was in play vs. just the table being loaded / running.  Maybe there is a bit of a key here in that it is not doing it now / with test8a yet the ball seems out of sync?

 

As far as the max frame time counters, without having the test7 to compare to, I guess it's not as useful for a comparison but for test8a running FXAA quality set in main preferences and table at -1 to take the main settings, I'm getting 3.3 AVG and 4.0 max for the test table in question.  

 

I've finished sending you the PM with more information and the link to the table to try.  I expect you should be able to reproduce the results as my two Windows 32-bit systems showed the same issues (hopefully you got a couple to also try if you can't as there's definitely something going on).  The slightly slower one helped to highlight the issues more and running at 1080p is best again to show the disparity. 

[mukuste]

JF,

 

Thanks, those are very good results.

 

First, the FPS increase shows that the optimization to ball rendering was successful. Before, every time a ball was rendered, it basically caused a mini-stall in the graphics pipeline. This is now eliminated, and I'm happy that this translates so clearly to the FPS numbers.

 

Second, the 4.0 max frame time (vs 3.3 avg) shows that there are no major unforeseen spikes in frame duration which would cause any stutter. Again, very good.

 

So what I suspect is that the added microstutter is simply an effect of the increased framerate. This sounds paradoxical, but if you recall my recent post in the flipper test thread, the current physics engine has variance depending on the framerate which is quite erratic. So it's possible that the changed framerate simply aligns worse with these internal quirks of the old physics engine.

 

The other suspicion I have is that, since the table you got these results on uses primitives heavily, primitives are to blame. They are not very well optimized yet. However, I did some important optimizations to primitive rendering tonight which should eliminate the mini-stalls, just as I did for the balls. Why eliminating the ball issue should bring this other issue more to the front is not entirely clear, but it's certainly not out of the question.

 

I might send you some separate test versions to eliminate or confirm these suspicions.

[jimmyfingers]

Ok, so I have some key information using that test versions that allows for the same statistics to be viewed as with the test8a version BUT also because the test with the ball in the launch lane and standing still skewed the results. My initial findings from my last post still roughly stand when the ball is still / in the plunger lane and looks similar al beit slightly higher for test7frametimer.exe (about 3.6 and 4.2), however, when the ball is in play, I'm getting a considerably different max time for test8a vs. test7.  With FXAA enabled as described above, test8a is yielding a max time essentially consistently at about 10.2ms where as the test7 version with the counter is showing about 4.2 both with about 3.3 and 3.5 for AVG ms respectively (i.e. the test7 is not varying nearly as much as the test8a as far as max and the test8a max is consistently showing in that range).  It changes briefly when the ball goes in a kicker but as long as the ball is moving they differ on their max values.

 

I imagine you should be able to see this too with my test table and the test7 version with the stats display.  

[Slydog43]

I had a lot of ball stutter last night after playing a few different tables with VP 9.2.1 r930 and test7.  Very strange as it didn't happen very often and not consistantly (I know this sucks).  Running straight without any front end.  At one point, playing Gottliebs Joker Poker  2.06 FS, game was almost unplayable.  i quit out of DX9 version and fired up VP 9.2.1 and loaded same table.  Seemed fine again so I played 2 games.  Went back to DX9 VP and loaded table, very little stutter if any for a while, then some more came back, but not nearly as bad as before.  

 

Tonight I loaded up a non DOF version without DirectB2s and get a little messup once and a while with DX9 test8a, but not much. Will keep testing, very strange. 

 

PS.  I think you can see microstutter easier if you have v-sync turned on, as I think I see the ball "slide" instantly to a further along point in its trajectory than it should if v-sync is not turned on.

[BananaBoat]

If at all possible, i would want to be involved in testing this micro-stutter issue as well if there is an interim beta compiled.

I can replicate the stutter almost always when playing certain tables so would be in a good position to validate any improvements.

[LoadedWeapon]

I see a nice FPS boost with 8 while ball in play.. Great job!

I did notice if you use the NV FXAA the fps is lower and the and the ms jumps around more than if you use the editor one on Quality FXAA.

[mukuste]

For those who want to debug stutter, the first step would be to look at the new max frametime counter on the F11 display. Is it much higher than the average frametime? Always, or does it jump? Does it correlate to any table events? And so on. Usually, if you have stutter, this counter should be much higher than the average.

[jimmyfingers]

I see a nice FPS boost with 8 while ball in play.. Great job!

I did notice if you use the NV FXAA the fps is lower and the and the ms jumps around more than if you use the editor one on Quality FXAA.

I tried the latest (most current WHQL) nVidia drivers on my mini-cab and the NV / control panel based FXAA went down to almost half of what it was previously (334.89 vs 332.21 - reverted back after seeing that).  And yes, even when they were poor in the new nVidia driver the quality mode of VP still worked well / similar to before the driver update attempt.  What's interesting is it was since BETA 334.67 that they were now somewhat working with VP DX7 builds in Windows 7 and FXAA being forced on in the control panel.  Toxie had mentioned that the nVidia FXAA was very aggressive and now I'm wondering if that was based on 334.67 or 334.89 as, despite them working with DX7, they are not needed for VP DX9 builds FXAA functionality (332.21 works fine via control panel or within VP) so their apparently extra aggressiveness / inefficiency is something to look out for moving forward but ironically may have been what finally helped them push the DX7 revs of VP into submission.

 

For now, I recommend the 332.21 drivers for cards that require a newer driver (i.e. 700 series and up) and for ones that can take it, I always found that 306.97 were solid and smooth but was forced to go higher when I upgraded to a GTX 760.  However, I can't say at this point how far back the driver versions and compatibility with FXAA even for VP9_DX9 builds go, so maybe this would be another aspect to keep in mind regarding nVidia drivers and FXAA aspects.

[LoadedWeapon]

yea i am using 334.89... i might try an older one...

[DJRobX]

The F11 display with the max frame time is as interesting as I thought it'd be.   It demonstrates a clear issue with directB2S on my system.   The last table I looked at ("T"), for example, with the directB2S backglass going, shows a maximum frame time of around 40ms.    Take the directb2s away and it drops to just 4ms. 

 

DOF, by the way, is NOT the problem.   B2S server + DOF + no backglass has a minimal impact (from ~4 to ~6ms).  I also watched it while lights were going on and off, and there was little to no movement in the max frame time.   I also tried an older version of B2S Server per suggestion of another thread and it did not improve anything.     Changing from "standard" to "EXE" mode did not make a difference either.    I also tried the frame skip options without much change.  I confirmed I am in 32 bit color mode.   It's so great to have a way to measure the impact, thanks for including this Mukuste! 

 

Scared Stiff's directb2s thankfully doesn't cause nearly as much of a problem (good, because the spider is kind of important ).  The max render time on that only goes up to around 12ms, even with the lights flashing and things going on.   I don't think directb2s works as well on XP as it used to in Win7 on this system.    I had DX7 slowdown issues in Win7 (particularly on tables with primitives), but directb2s never seemed to be the culprit.  In XP I've seen more instances of directb2s having a visible impact on performance.   

[BananaBoat]

DJ can you try the same test with big bang bar?

Sent from my HTC_PN071 using Tapatalk