Are these timers in the table Script or the editor?
Edited by Outhere, 01 February 2016 - 08:30 PM.
Posted 02 February 2016 - 08:22 AM
..and changed again: the timer interval is kept like-is now, but the overall runtime of all scripts per frame is limited to 5 msecs, which means that (if the rest of the machine is up for it CPU- and GPU-wise) the scripts will never drag the machine below 200FPS..
hopefully this will solve the remaining micro-stutter issues..
of course there can still be some tables that can show bad physics behavior, but there you could try experimenting with the already existing 'Physics max. loops' parameter in the table backdrop settings.
start with something like 5 and decrease until the stutter shows up again. stutter will be replaced by 'slow/moon physics' instead though using this.
Posted 02 February 2016 - 08:52 AM
i have a i7 3770 3.4 ghz, 8gb ram, a gtx 970, overall almost all the tables are pretty smooth.
but as an example, AFM from JP, when i hit the saucer, all flashers lit and are flickering a bit, so at that time the ball goes down and it stutters, i'm running at 270 fps, it drops a little bit, to 250 at that time, but i wonder what is the cause of that, timers?

Posted 02 February 2016 - 09:20 AM
ok

Posted 02 February 2016 - 01:28 PM
rev2488 is up :
- add a "Raise Delay" setting to drop targets
- limit maximum amount of time spent in scripts per frame
- limit timer update interval to 200Hz (interval value = 5 (msec))
- add test if user folder already exists, otherwise create it (in controller.vbs)
Posted 02 February 2016 - 01:55 PM
Not that this is that important, but something that might want to be looked at. I recently showed a buddy VPX. He just wanted to see it in action without a fancy table, so I started a new table and just played that. Problem is the physics aren't that good. i think they should be finely tuned just to show off how great VPX can be.
Posted 02 February 2016 - 01:58 PM
I don't know if it's come up, but would it be possible to make it so I can actually have a white bumper base without having to replace it all with primitives and then animate it? Most materials that get applied are ok, muted but OK, but white is always grey. When I turn off base visible, then I have to place a skirt, a base, a ring, and then animate it. Maybe if the ring was a separate item so I could replace the base with a primitive but still use the built in ring and animation? This would be very time saving, and less timer animations (although slow ones, but they all add up).
Thanks.
Posted 02 February 2016 - 02:42 PM
rev2488 is up :
- add a "Raise Delay" setting to drop targets
- limit maximum amount of time spent in scripts per frame- limit timer update interval to 200Hz (interval value = 5 (msec))
- add test if user folder already exists, otherwise create it (in controller.vbs)
this one i disabled again.. so the responsibility to keep timer intervals sane is still up to the artists..
the core now only makes sure that not a whole bunch of costly scripts will fire within the same frame.. these are then spread out over multiple frames..
Posted 02 February 2016 - 04:15 PM
The BulbIntensityScale setting is great, just wondering what would be the code to use it with cvpm Ballstack ?
Found that I could add a line before kicker init and the first ball works, but not others...
and/or is there a way to change the default (1) for every ball in a table
Thanks
Posted 02 February 2016 - 06:01 PM
Not that this is that important, but something that might want to be looked at. I recently showed a buddy VPX. He just wanted to see it in action without a fancy table, so I started a new table and just played that. Problem is the physics aren't that good. i think they should be finely tuned just to show off how great VPX can be.
I think this is more of a community issue than a software issue. There's bound to be a learning curve and to get artists up to speed it would be really good to have folks who would be able to make objective suggestions for the sake of realism. I think the options to make it right is all there in the software, but the issue is that people need to learn (and be supported) to use it effectively.
Posted 02 February 2016 - 09:40 PM
The latest revision with the limit timer update interval to 200HZ seemed to really boost the performance of my boards I am wondering why you are now removing this toxie? Seems like a great addition
I admit I was excited to see this feature employed, as I was hoping it'd eliminate some stutter. I'm curious about it being disabled, too! I support your rationale, of course.
Posted 02 February 2016 - 10:47 PM
You can always manually limit the timers yourself so having it done in code is not desirable and can affect other operation. Plus I think people have the wrong impression and reported the latest revision as being better thinking the next one won't be by having this "feature" reverted, but this latest release already has the code reverted back to where it was (i.e. there was never a version released yet where it was at this hard coded 5ms / 200Hz level). Toxie was just correcting the release notes, as his reverting of this feature was done at rev 2487 before this 2488 release). So if you like / liked the way rev2488 runs, than it has nothing to do with forcing timers to no lower than 5 ms.
The timer stuff is not going to be the save all for stutter and certainly not the surging / tearing kind (as that is likely just going to happen if not using vsync in some way). I can still produce plenty of it depending on other aspects / settings (aero / desktop composition / dwm off and without using vsync) but also get it butter smooth as well. To isolate timers as ever a factor, simply using the default table for testing is the route, as it is not VPM based / integrate and has only one single timer for the ball rolling sounds plus also with that lone timer disabled, to test a timer-free experience, exclude all of this recent discussion / code changes from impact / being a factor and in that environment I can still produce stutter if I don't set things to the manner best to avoid it (and already discussed ad noxium). In fact most of my personal tests for screen / ball smoothness have typically used the default table as in general in limits a lot of other factors from being factors.
As Toxie says and I fully agree with, "responsibility to keep timer intervals sane is still up to the artists (authors)". I don't see why a feature should ever be hardcoded and forced on that an author or end user could still do on their own, just like in this case, if you want limiting to 5 ms or 200 Hz for timers, than check the timers on a table and any that are set below change to 5 - done.
Posted 03 February 2016 - 08:55 AM
The latest revision with the limit timer update interval to 200HZ seemed to really boost the performance of my boards I am wondering why you are now removing this toxie? Seems like a great addition
I admit I was excited to see this feature employed, as I was hoping it'd eliminate some stutter. I'm curious about it being disabled, too! I support your rationale, of course.
Don't get me wrong, everything is still in there, exactly like in the build you guys got, nothing changed since then.
Its just that this build already does not contain the striked out part anymore as the 'limit maximum amount of time spent in scripts per frame' part seems to be good enough to do the job.
But still, to all authors: Please keep timer intervals in the >= 5 range! (unless its really really necessary to go lower)
Edited by toxie, 03 February 2016 - 08:57 AM.