1394 replies to this topic

[Aubrel]

Very nice progress: thanks!

I have seen a few bugs with CV using r644, the big ball has gone out (it was funny to play with lol, but it happened to me only one time) and I've noticed some problems when the ball goes on the playfield reflect area of the big one.

It's not a big problem, but it it can help

Edited by Aubrel, 08 September 2013 - 08:29 PM.

[Aaron James]

Man, I am really lovin' this new ball reflection upgrade!!!!

 

It's add soooo much to the overall experience, and it's so cool to see what it looks like on all the games I haven't played in a long time.

[85vett]

Agreed.  The refection really adds to the reality of the game.  Great move adding that.

 

I will +1 what was said before about the editor and adding a grouping feature.  Would be nice to have a way to find a wall that goes outside the window in the selector tool.  Half the time I know which one I want but don't know where it its and try using that to find it to see it falls off the window :-(

[Bob5453]

Agreed.  The refection really adds to the reality of the game.  Great move adding that.

 

I will +1 what was said before about the editor and adding a grouping feature.  Would be nice to have a way to find a wall that goes outside the window in the selector tool.  Half the time I know which one I want but don't know where it its and try using that to find it to see it falls off the window :-(

 

Open table script, click on Edit, Open the left drop down box, every table object is in that list, find the one you want, select/highlight it, it will then be highlighted on the table, this drop down box has been there forever.

[koadic]

I don't see rev 648 & 649 in the Dropbox folder!

That's what happens when he commits changes while I am asleep (or at work, or...) I usually try to at least get them compiled and uploaded within 12 hours barring any unexpected complications (example - before 646, I had my computer torn apart for 2 or 3 days)

[stereth]

 

Hi there! Are my posts invisible until I get a certain postcount or something? I know I'm new here, but I really do have a regression.

 

I created a new table with two prims. Lighting is enabled on the one on the right.

 

In 9.1.5 they look fine, except that the sides take on the color of the top:

 

In 9.1.6 they do not look fine:

This is rev 650, but revs 639 and later behave the same. If lighting is not enabled, the prim is all white -- I expected to see the behavior from 9.1.5. If lighting is enabled, the prim has a harsh gradient from yellow to black.

 

I don't know what possible lighting could cause that kind of gradient on a flat surface. Can you set the default light sources to be a reasonable starting place, like a couple of overhead lights in a room, or at least an approximation of the infinitely-far lighting source that 9.1.5 apparently had?

 

I have a vpt but I don't know how to upload it here. Anyway, it's dead simple to recreate.

[fuzzel]

stereth, check out rev 651 it should work now if you enable lighting. BUT I wouldn't use the simple primitives at all. The whole primitive thing is more specialized for 3d meshes or simple primitives with textures applied to them. Simple primitives look odd if shaded because they don't have enough polygons.
To get the best looking results you should use 3d meshes.

Edited by fuzzel, 09 September 2013 - 06:26 PM.

[jimmyfingers]

Thanks fuzzel for fixing the decal bug (confirmed resolved in 650). I do have to agree with some of the others though that there seems to be at least a little ball micro-stutter introduced since rev628 and may be more noticeable with more demanding tables and while under heavy events or multi-ball. With all system and application parameters / configurations held constant, it does seem noticeable when comparing the game play of 628 and to the latest 650 revision with a couple tables I benchmark with as well as a modified test table I use that flashes all (alpha) flashers quite fast and while using forced AA (doing this as it puts a good demand on the table / VP application to help highlight any fluidity / ball stutter issues). It's tough to tell sometimes as I've seen even the same table from one launch to the next seem a little more fluid for unknown (VP's / pinmame oddities I suppose) reasons.

 

Even though it seems the FPS is close between the 628 and 650 revisions, there is still something that appears just a little less fluid in the ball motion. Is there any chance you can keep how you had some things from rev 628 while still adding these other recent items or that fix that you refer to regarding the materials handling? If you want to test / assess, I suggest you take a pretty demanding table and add a test timer that repeatedly turns all / most of the alpha flashers on / off quickly as well as possibly forcing AA for even more demands on the system and watch how the ball appears to be just not as fluid, have a little more micro stutter, or even just appears almost blurrier than with rev. 628 (all more easier assessed when the ball is at a slow to medium speed or in an apex). It's sometimes tough to test and subjective a bit as well as for the fact that FPS alone doesn't tell the whole story - I've definitely seen that FPS cannot be the sole relying measure / indicator of whether the ball motion is smooth and natural.

 

Again, I (we all I'm sure) very much appreciate all you are doing and where VP has got to currently largely because of the most recent work from you and Toxie.  Keeping ball motion fluid though I think is pretty important in one of the main aspects of the illusion of realism for virtual pinball - even over other enhancements. Hopefully you can work out a way to achieve what you need from the things that weren't right / broken with 628 to move forward from the problems but maintain as fluid and crisp ball motion / graphics as possible. 

[Slydog43]

Great point jimmyfingers.  I did a quick test with 650 vs 628 with latest South Park with full LedWiz including PWM (Using DOF) and get around 131 FPS with 650 with and without ball reflections.  I thought that the reflections was what was causing a slight slowdown, but seems same FPS on and off.  When I run same table with 628 I get 170FPS.  Love the new features, but FPS is king or at least needs to be at top of list.  Not complaining just my observations.

[fuzzel]

I fully agree here. Please try rev 652. I tried to optimized it a bit more and changed the material cache handling back like it was in rev628.
I couldn't test it on my cab but it seems it runs faster/smoother.

[LoadedWeapon]

I fully agree here. Please try rev 652. I tried to optimized it a bit more and changed the material cache handling back like it was in rev628.
I couldn't test it on my cab but it seems it runs faster/smoother.

Thanks fuzzel you are da man! I will do some testing tonight..

[jimmyfingers]

Thanks for the update and looking into this fuzzel. I had a chance to do some testing this afternoon and it still appears as if the rev628 is just more fluid some how. Even though the FPS levels seem quite close or even the same in some tests, I still see a bit of micro-stutter / smearing with the ball itself. Also, it seems that even if the FPS is quite high it can still be happening and I'm wondering if it's more just about the ball rendering than really how much FPS we're getting.

 

The one test table I'm using has a stress test timer that turns on and off all alpha flashers every 25 ms (uses a global refresh light / technique though) and the lamptimer at 10 ms to show the changes in the flashers quick enough for the stress timer. With this test table, I still get around 720 FPS with AA forced on while on my Windows 7 cabinet. I get about the same FPS between rev628 and 652 but it does appear 652 just doesn't draw the ball as clean under the same parameters. I've done most testing without any GPU over-clocking but when I boost to a standard OC to assess, I get a jump in FPS by about 15-20% yet it still seems to not affect the ball drawing or help smooth it out.

 

I'm finding that without forced AA enabled the difference is too slight to tell but the more demanding aspect of AA brings out the discrepancies between the versions. So I think, if you can test with AA forced on, it may help your own ability to assess and witness these issues. It does seem that even when lighting events are not happening, yet the table is somewhat demanding, by it’s build having lot's of static alphas as well as AA forced on, that it can be seen. I test with tables that have the flipper tap code so I can do a bunch of soft / lofty short shots and assess visually how the ball looks in the lower to mid-playfield and as it speeds up and slows down or travels through the apex.

 

I'm wondering if somehow the ball reflections option / code, even when disabled (globally or table wise), could have had some impact as it seems like around the same time it was introduced this slight ball drawing / stuttering arose. Also, is it possible things like the anti-stretch have a bearing, again even though the ball reflection option is disabled as I thought I saw some early bug reports when that option was chosen along with ball reflections? Would it be possible to make a test rev with everything held constant except remove the changes that were needed to give the ball reflection option? It doesn't have to be something official but I'd be happy to test out a custom build for at least diagnostic purposes.

 

Thanks for trying to nail this down.  By the way, while testing I have noticed that certain demanding sequences in some tables are now smoother than before these more recent 608+ versions likely because of your alpha optimization without rendering the sides when they're at a 0 height helping a lot of alpha flashers as they typically do not have any visible sides set (that was a great boost / help and I think helps cause less general stutter when dynamic alpha image changing events are occurring).

 

Lastly, I'm wondering if the other people noticing more differences in rev628 and 650 or 652 might also by chance be ones than have AA forced on as well?

[fuzzel]

wow Jimmy great test report, check your PM

 

Regarding the smoother feel on some sequences: I changed the way how ramps are updated. Before 652 alpha ramps were recalculated if you change textures and/or width/height. With 652 you can change the texture on an alpha ramp but that won't lead to a recalculation of the whole ramp just the texture will be changed. But if you change the width/height or use a texture with a different size than before the complete ramp has to be recalculated.

This behaviour can increase the speed on some tables...

[LoadedWeapon]

It would be great to nail this down and I really wish Nvidia would fix it so we could force AA. For me this one runs perfect but I don't force AA on windows 7 because it causes way to may problems.. JF might can get away with it because he knows how to maybe edit a table to reduce the problems but for me I get textures out of place, black lines all over the field, missing or half a ball, Missing or disappearing flippers and just weird glitches all over.

Any optimization is greatly appreciated tho Keep up the great work.. 

[Slydog43]

very strange, its seems that 652 is more fluid, ie less stutter, but my FPS according to F11 is only 107 on South park 1.3.  I was running south park 1.2 before so I'm not sure if I can compare.  thanks though for the work on this.

 

just tried 1.2 and I get 122 FPS.  

 

 

 

I don't care what the numbers says, Fuzzel you definitely have improved the smoothness of the latest VP build (652).  THANKS

Edited by Slydog43, 10 September 2013 - 11:24 PM.

[jimmyfingers]

Thanks fuzzel, gone through the PM, responded, and will be testing over the next day or two (going cross eyed at the moment from staring so hard at the screen trying to pick up any qualitative ball motion aspects while launching and re-launching VP versions and tables). 

 

That new ramp technique explains a bit and I'm curious though when you say same size for the texture, is there any concern when the texture is not a power of two for it still being recalculated due to VP's issues with non-power of two images? 

 

Thanks again for obliging on the test versions and I think the 2nd one so far is pretty close to 628 or getting so close it's tough to tell, however, the one without ball reflection at all still seems to be more consistent in behaving like 628.  But really, I think the variations in one launch to the next are hampering good comparisons.

 

From a couple of the other guys, it seems 652 has helped but your enhanced ramp redrawing optimization might still be masking some micro-stutter by helping in other areas.  Sounded like you did notice some differences in ball micro-stutter from 652 to 628 when cranking up the AA setting, which I think is a good way to draw out more stutter / potential variations from builds.

 

I'll PM you back in a day or so with my notes / observations to keep from flooding this topic with more of my verbosity

[Aaron James]

Veraciously verbose and valid, verifying victoriously!
Jimmyfingers has vowed to vanquish these venal and virulent vp vermin not in vain, but to vindicate the vigilant and virtuous visual pinball program and it's valor.
He is a true vicarious VP veteran.

[oooPLAYER1ooo]

very strange, its seems that 652 is more fluid, ie less stutter, but my FPS according to F11 is only 107 on South park 1.3.  I was running south park 1.2 before so I'm not sure if I can compare.  thanks though for the work on this.

 

just tried 1.2 and I get 122 FPS.  

 

 

 

I don't care what the numbers says, Fuzzel you definitely have improved the smoothness of the latest VP build (652).  THANKS

 

 

in version1.3 I included about 50 extra gi effects using alpha ramps.

you can notice on metal guides or the wire ramps that when the gi is off they darken too.

this will most definately run at a lower fps than 1.2 but from all reports it has been pretty smooth so far

Edited by oooPLAYER1ooo, 11 September 2013 - 06:38 AM.

[fuzzel]

Jimmy, you should change your nick name into Dr.Pinhead

[Tropi]

Guys, thanks a lot for your great work here and the great improvements you made. I love the new ball reflection very much.

I tried to follow the entrire thread, but I'm not a specialist and I appologize if I missed something in between.

 

The new flashers are a good improvement, but I was wondering if it is possible to adjust this effect.

I tried Safe Cracker and for me the area effected by the flashers is too large and looks somehow unrealistic. At 1920x1080 on 40'' PF it is around 15 cm.

The new flashers are very bright. When all 4 flashers in SC are on it's getting hard to concentrate on the ball.

 

Maybe somebody likes it that large, but others may like it smaller. Maybe somebody likes it bright, but others may prefer it less bright.

Is there any option already in or forseen to adjust diameter and brightness by a global or table based setting?

 

Just my 2 cent

CS