1394 replies to this topic

[toxie]

747 has quiet some changes on how ramps and primitives are updated.. please test if i broke something..

 

but this could bring quiet some speed improvement for some tables (depends on how the script is programmed and how much stuff is animated in the script in a 'convenient' way )

also i would guess that now static primitives are really faster than dynamic primitives (at least in most cases)..

[koadic]

Alright, uploaded 747, just don't have time to test it at all before work , will try it out tomorrow morning

[jimmyfingers]

Sorry Toxie, downloaded as soon as possible to see about the potential performance gains you mentioned but before I got too far I got a bug using the test table I posted back on page 43 / post 860.  When the primitives are set to .TopDisable=0 it does not "undraw" them from the screen and the ball can go through and erase it.  On tables that have refresh lights going maybe this wouldn't be as noticeable as I have a feeling a refresh light update would update the primitives being off.  The 746 does not do this glitch and I've tried with and without forced (nVidia) AA and with combinations of RU / RO both on and off.

 

Here's a capture of when the test primitves are supposed to be off but not disappearing from the view:

 

 Capture of Primitive Performance Issue - Not disappearing after TopVisible set back to disabled with 747.png   444.8KB   12 downloads

Edited by jimmyfingers, 27 November 2013 - 05:06 AM.

[toxie]

ah, okay, now at least one section of the code i deleted makes sense..

but that's a minor correction, the improvements should still be valid after this change..

 

thanks for the quick test!

[toxie]

and fixed with rev 748.. as said, the other improvements should still be valid, especially noticeable when using stereo3D or the software FXAA..

 

so please retest..

[jpsalas]

I have just tried rev750, and it looks like the speed without the software FXAA is the same as before, but with software FXAA on it is much faster.

 

One thing I noticed: I use to play with the Region Updates off so I don't need all the extra refresh lights, but if I turn of software FXAA then to refresh the alpha ramps you need those extra lights.

[toxie]

Yes, because the ramps so far don't trigger region updates..

This should also be fixed at some point, as it's really stupid like that (everything else triggers updates, but not ramps)..

[Herweh]

FYI guys, at my development PC (nVidia card) Apollo 13 is running with more than 300 FPS at rev729 but with stutters and about 70 FPS at rev750.

 

Here are my settings of rev750:

 

Edit: rev743 is still running with more than 300 FPS.

 

Another edit: rev747 is still running fine with more than 300 FPS.

 

My last edit (it's getting late and I'm too tired): Looks like 746 was the last version with the FPS running at more than 300. With 747 it goes down to something between 70 and 100. And I've tested with the two check boxes "Region updates" and "Region optimization" on and/or off.

Edited by Herweh, 27 November 2013 - 10:32 PM.

[toxie]

could you PM me a link to the table so i could check what i screwed up, please?

[toxie]

Yes, because the ramps so far don't trigger region updates..

This should also be fixed at some point, as it's really stupid like that (everything else triggers updates, but not ramps)..

 

could some skilled table artist please provide me with a small test table that has all these unsupported cases in it?

then i could fix specifically what is missing..

[Herweh]

could you PM me a link to the table so i could check what i screwed up, please?

 

 PMed.

[toxie]

thanks, will look at it this evening (i guess)..

 

anybody else willing to create a small test table that demonstrates the problematic ramp cases that are currently not updated properly?

[jimmyfingers]

@Toxie - Could you explain the problematic ramp cases as I might be able to create a test table as with other cases, however, I'm not experiencing that situation to my knowledge or it's not happening with my settings (no RU / RO) and all tables I use still using a light refresh technique. I have the test table a ways back but that was for primitive TopVisiible on /off testing mainly. Is it something that's really happening only in VPM / more elaborate tables and would be tough to do in a simple VP template style test?

[jpsalas]

thanks, will look at it this evening (i guess)..

 

anybody else willing to create a small test table that demonstrates the problematic ramp cases that are currently not updated properly?

The two VP916 beta tables I uploaded, AFM and TOTAN, can be used as a test. I did not use any light to refresh the ramps, and I also use the light maps and several primitives.

 

The alpha ramps work very well with the RU disabled and the RO enabled. But if I turn on software FXAA then they do not refresh anymore. They did that before the latest changes, but the tables were unplayable.

 

So actually I think rev750 works quite well for me needs.

[toxie]

okay, thanks, because i think it would be a good idea to get rid of the light refresh hack (at least optionally), as it is really confusing..

 

but this light refresh hack is only needed for alpha ramps, right?

not for any other table element?

[jimmyfingers]

okay, thanks, because i think it would be a good idea to get rid of the light refresh hack (at least optionally), as it is really confusing..

Hey Toxie, if you could indeed please still keep it as an option to use the old light refresh technique this will be important for keeping some performance of some tables as using my global light refresh routine or as other's have derived their own version. It has essentially made them playable or much more smooth where as if we lost the ability to control that they would likely suffer greatly in ball stutter or even outright playability. The global refresh technique that I derived using a variable to keep track of a single table sized refresh light and update all items at once (only once per lamp timer cycle), has been a huge performance saver on my system - and other's from what I understand and to be expected - especially with forced AA. The technique alone has even saved the need to upgrade to a new video card (one I was able to return as the gains gong from a 580 to a 670 were less than using this technique instead). So yes, keeping this as an optional approach would be very important / desirable.

[toxie]

I understand that, but the problem with that technique is that the single "huge" update can lead to micro-stutter, as most of the time it will behave smoothly, but then one frame will take "forever" in comparison..

So at least there should be an additional "clean" option so that beginners, etc are not confused by this weird ramp behavior..

[jimmyfingers]

It's true that certain small areas would still be nice to update independantly as the pros are that we're getting only one update in total for all alpha ramps per lamptimer cycle but if only one little bulb is flashing (that has an AR composition) then it will trigger the same / general table sized light refresh.  I guess also or more of what you are saying is that when lot's of things have changed that that single update can be heavier in what is altered on screen but I'm not sure if that's worse than having all of those updates, that have been queued up, causing instead lot's of independant updates in the same time period / lamp cycle (a lot of them likely having pretty big refresh areas / light refresh objects of their own - i.e. flashers).

 

For the most part, I've still seen that the benefits far outweighs that drawback, again very noticeable in AA and with some stress test tables I have, but if certain elements could be done without the refresh at all (optionally on the item or the lamp routine used) that would be the best of both worlds I imagine. 

[jpsalas]

And, yes, the refresh light is only for the alpha ramps used mostly as flashers, but also as ramps that moves up/down, or animations.

[fuzzel]

rev752 should fix the performance issue started with 747.

Edited by fuzzel, 28 November 2013 - 08:25 PM.