80 replies to this topic

[jimmyfingers]

I played around with this setting when Lethal Weapon 3 came out and noticed improvement in the stuttering as well. However, I saw the effects of these changes in the fading lights and especially blinking ones. I tried it on a couple other tables and you can definitely see the blinking lights get out of sync which for me took away from the simulation and at times even knowing what to shoot for. Some of them became random or even looking stuck on or off with simply not enough updates taking place. They could get in a void when the light status should be changing but is missing an event update from the "UpdateLamps" routine due to the timer length vs. the actual lampstate changes taking place at the real ROM emulation level.

This is hampered mainly because the fading light routines take 4 cycles to go from on to off or off to on in an effort to simulate the glow of a light which adds the need to be quicker for a lampstate change signal to be processed before it changes to something else again. Plus there are differences in some fading lights based on whether they are rom controlled or not that will yield further divergent results. Changing this setting too high on tables with alpha flashers will make the flashers likely look unrealistic as the "flash" will be stretched out or missed completely and strobing effects that would happen quickly and need lots of updates to "see" all 4 images of state quickly from on to off will become effectively random as to what image level of off, b, a, or on you get.

Working in depth on lighting aspects, I can say that increasing the value for the timer significantly will have definite effects on lighting and GI elements (even more so on the GI8 table MODs). Overall, if the timer is set too high (slow) you won't get nice transitions for GI and flashes for sure - insert lights may not be as critical or noticeable. I suppose if unplayability is the other choice then it can make sense, but, if it's just light stutter you're trading one kind of updating issue in for another. I could see that some people may choose inconsistency in the lighting vs. the inconsistency or stuttering with the ball image which IMHO is indeed one of the quickest ways to kill realism.

I am curious too as to what some more of the authors and senior VP guys have to say.

[Aaron James]

I played around with this setting when Lethal Weapon 3 came out and noticed improvement in the stuttering as well. However, I saw the effects of these changes in the fading lights and especially blinking ones. I tried it on a couple other tables and you can definitely see the blinking lights get out of sync which for me took away from the simulation and at times even knowing what to shoot for. Some of them became random or even looking stuck on or off with simply not enough updates taking place. They could get in a void when the light status should be changing but is missing an event update from the "UpdateLamps" routine due to the timer length vs. the actual lampstate changes taking place at the real ROM emulation level.

This is hampered mainly because the fading light routines take 4 cycles to go from on to off or off to on in an effort to simulate the glow of a light which adds the need to be quicker for a lampstate change signal to be processed before it changes to something else again. Plus there are differences in some fading lights based on whether they are rom controlled or not that will yield further divergent results. Changing this setting too high on tables with alpha flashers will make the flashers likely look unrealistic as the "flash" will be stretched out or missed completely and strobing effects that would happen quickly and need lots of updates to "see" all 4 images of state quickly from on to off will become effectively random as to what image level of off, b, a, or on you get.

Working in depth on lighting aspects, I can say that increasing the value for the timer significantly will have definite effects on lighting and GI elements (even more so on the GI8 table MODs). Overall, if the timer is set too high (slow) you won't get nice transitions for GI and flashes for sure - insert lights may not be as critical or noticeable. I suppose if unplayability is the other choice then it can make sense, but, if it's just light stutter you're trading one kind of updating issue in for another. I could see that some people may choose inconsistency in the lighting vs. the inconsistency or stuttering with the ball image which IMHO is indeed one of the quickest ways to kill realism.

I am curious too as to what some more of the authors and senior VP guys have to say.

Damn good explanation

[Noah Fentz]

You can also modify the fading lights script on problem tables to disable the fade altogether. You'd certainly see an improvement in performance without adversely affecting the light timing.

[Sabbat]

IMO, you really can't go higher than 50...because even i noticed the difference in the lights not blinking properly/as they should like the real thing.
200 may make the stutter go away, but the lighting patterns and blinking intervals are horrible and not realistic for a pro pinballer.

My trial game i did this on was cirqus voltaire. (strike an arc multiball)

In the end, even if it takes ANY of the stutter away, it's a find, so thank you.

Dont you have a virtual pin? Why are you getting stutter?

[bladexdsl]

just tried this with bbb set to 100 than got multibrawl + tube dancer where the stutter goes crazy...holy shit what an improvement the stutter has vanished!

edit
60 also works even with uvp!

Edited by bladexdsl, 07 March 2012 - 08:35 AM.

[JAM0]

You can also modify the fading lights script on problem tables to disable the fade altogether. You'd certainly see an improvement in performance without adversely affecting the light timing.

How do you do that Noah?? I can wait to try that!

I set Freddy to to 300 and I am able to play it with virtually no stutter. Before it was literally unplayable, not because I didn't like what I was seeing, but because sometimes I couldn't see the ball or flippers at all. Yes the lights are way off but at least I can play it. I want to try Noah's solution on it.

I think a major clue as to whether this is the issue or not is if multiball increases the stutter or not. For most problem tables for me, the stutter level is the same whether I have 1 or 4 balls going -- no change, so I presume it is the lights.

If Noah's system works as well as I think it will, I will look at it this way: I just changed all my lights to LED's

[Eddie D'Orazio]

There are just a handful of tables that have ALWAYS given me stutter and/or micro-stutter with or without UVP. My PC is a Core i7 overclocked, GTX480, etc. I have thrown better RAM at it, a dedicated soundcard, only have 5 services running in XP and although most tables run like a dream on a 3-screen setup with UVP, there are just a few that don't.

The tables for me include Twilight Zone, Circus Voltaire (UVP version), Pinbot, Comet, Lethal Weapon, some microstutter on Freddie plus a few others. I really want Pinbot as it is a beautiful re-creation - therefore I spent a lot of time removing things from the script until I have stumbled upon a fix that sorts out my stuttering problem once and for all, for ALL tables.

The new pre-release version of UW superb BBB was also give me stuttering, but no more!

The following fix, fixes every table for me that I have had trouble with. I have absolutely no stutter anymore and I use UVP. I hope this might work for others.

Search for the line in the script where you see an interval setting for the Lamptimer.Interval, and increase the number by about 10ms to 15ms...

eg:
Lamptimer.Interval=35

and increase by 5, 10, or 15ms. I usually end up adding 10ms.

Lamptimer.Interval=45

Save and run the table. Not every table has this code in the script but it does appear in all the tables I have fixed.

From my understanding this simply means the interrupt to refresh the lamps will kick-in every 45ms instead of 35ms. I don't know if there are any consequences in doing this - someone else may know but I haven't had any issues so far.

My PC is super-fast so I am surprised this makes a difference. It will be interesting to hear if this makes a difference for anyone else, so please do try it on any tables you can't normally play smoothly.

Cheers

EDIT: It also FIXES Twilight Zone.

Made changes with UVP active with no success. Without UVP and no changes to lamptimer.interval, games work without studder. Not sure how it is working for you but I am interested to see if it does work with other members.

Cheers.

[Zablon]

I made the following changes:

LW3 from 35 to 45 - (no UVP) Stutter completely gone
Bride of Pinbot - 35 to 50 - (UVP) Stutter 95% gone. You can almost see some ball drag on occasion. I might play with this one some.

I notice people talking about issues with Freddy..oddly I have no issues with this one. I don't run with UVP though as it just doesn't seem necessary on this table. I also have no issues with the beta BBB.

Also, Checkpoint does not have that line in the script to change.

To Jam's point. Multiball does not give me stutters on any table that isn't already stuttering to begin with and even during multiball, the stuttering isn't any worse. Those 3 there represent the only ones I was still getting some on.

Edited by Zablon, 07 March 2012 - 01:25 PM.

[jimmyfingers]

I woke up this morning and realized something I had wrong from my previous post. The GI, if done through the WPC GICallback or GICallback2 (for 8 levels) does not tie-in with the fading lights / LampTimer / UpdateLamps routines so it's timing is independent of the changes that would be made and being discussed. However, other manual GI for tables that do no use this built-in funtion sitll would be affected if they use any of the fading lights / alpha routines as those do use the LampTimer and UpdateLamps at a core.

It was the extra alpha work and some other lighting components I enhanced when I had done on my GI8 mods that got me knee deep in fading light aspects and not the GI/GI8 for those tables - the different lighting elements all kinda blended in my recollection.

[JAM0]

I woke up this morning and realized something I had wrong from my previous post. The GI, if done through the WPC GICallback or GICallback2 (for 8 levels) does not tie-in with the fading lights / LampTimer / UpdateLamps routines so it's timing is independent of the changes that would be made and being discussed. However, other manual GI for tables that do no use this built-in funtion sitll would be affected if they use any of the fading lights / alpha routines as those do use the LampTimer and UpdateLamps at a core.

It was the extra alpha work and some other lighting components I enhanced when I had done on my GI8 mods that got me knee deep in fading light aspects and not the GI/GI8 for those tables - the different lighting elements all kinda blended in my recollection.

That's good to know because I increased the lamptimer.interval by 10 ms on both SS and Dracula, on both of which I was experiencing slight micro-stutter. It helped on both and I didn't notice any obvious degradation in the lighting effects, but after I read your first post, it was in the back of my mind that the degradation might be there. Nice to know it won't effect the primary GI effects

[gStAv]

Wow! This sounds great!! Gotta try!
Thanks for sharing!

[BitPirate]

Will also definately try this out. Thanks for sharing!

[settingsons]

Wow this thread has been busy!  Nice to hear it helps for others to and some very nice explanations.  Jimmyfingers - what you describe is interesting.  I have never had stutter with any if your mods.  Also what is interesting to know that some of us needed to go a lot higher in the increase in ms for the timer.  As I said for the handful of tables that had some stuttering I only increased the timer interval a min of 5ms and max of 15ms.  Having said that I to get the PC to the standard it performed before this timer tweak  I already did tons of other tweaking.  In case it helps here  is a summary:

• BG and DMD running in 16-bit mode
• Processor affinity settings to run VP and UVP on separate cores
• Most XP services disabled (5 or 6 only running)
• Overclocked processor from 2.8 to 3.8 ghz
• Turn off virtual mem completely
• Pinmame directdraw off tweak
• no firewall, no virus checker, no internet

It seems as soon as i introduced a 2nd and 3rd screen that us when the tweaking became necessary.

I was thinking at work today why this made such a difference  for my setup and i suspect the extra milliseconds where a timer is not running are just enough to prevent some kind if process bottleneck from occuring.  The lamp scripts in the tables  I had issues with are quite heavy.  Dozens of lamp updates which are executed by calling a subroutine dozens of times.  Not knowing how the VP timers work I was curious if a timer can be fired while the last instance is still running so did a test and used a boolean variable to only let the timer do stuff if not currently running... and only one instance can run so that isn't an issue.

If would be nice to hear some results from other cab owners.

[Aaron James]

IMO, you really can't go higher than 50...because even i noticed the difference in the lights not blinking properly/as they should like the real thing.
200 may make the stutter go away, but the lighting patterns and blinking intervals are horrible and not realistic for a pro pinballer.

My trial game i did this on was cirqus voltaire. (strike an arc multiball)

In the end, even if it takes ANY of the stutter away, it's a find, so thank you.

Dont you have a virtual pin? Why are you getting stutter?

Yeah..i get very little stutter though. I really can't complain. This game is so much like the real game, that all the flashers and lights to make it look good, sometimes cause a little stutter.
It's not a big deal. I'd rather have awesome quality in a HD emulation than not. 95% of all the games i play are perfect and stutter free.

[RipleYYY]

as others, trick works
tried with Freddy, its far better and playable now

[pixelmagic]

On the front: let me say that I am no expert in this, I just want to share my thoughts.

The approach that is being used at the moment on tables is that the vbs 'runs' the table and reacts on ROM events and send signals to the ROM. Most of that is driven by timer events, and the looks are that this gives us stutter in some situations. This could be (??) because there are too many timers running at the same time and being triggered.

Would it be an idea to look at some possible solution in replacing the currently used timers in some other mechanism, that would do the same trick but would be much less system heavy ? Something like a event manager that handles the timing devices ?

Again, I am no expert and I cannot create this, but maybe the pro's here can think about it ?

Edited by pixelmagic, 08 March 2012 - 07:57 PM.

[settingsons]

I added some code last night in the Lamptimer event to log to a text file the execution time for the timer and it was pretty instantaneous - virtually 0ms per call - unless I didn't use the Timer variable properly. When I get time I will try again.

What other thing I found interesting is for one table where I increased the interval from 40ms to 50ms to stop stuttering, I reverted back to the default interval of 40ms, and the stuttering consistency occurred and it seem to tie in with specific sounds from the Pinmame emulation (I went up and down several times). I then tried lowering to 30ms just for the hell of it, and surprisingly the table was fine although had the occasional microstutter but nowhere near as bad as the default setting. I went back to 40ms setting and stuttering again. I also don't know much about this at all but as you said PixelMagic it does make you think that maybe that interval is clashing with another timer maybe with the same or a similar interval. All pure guess work of course but certainly worth playing with these settings some more.

Edited by settingsons, 10 March 2012 - 12:03 AM.

[numiah]

Thank you for all these tips.
The lamptimer adjustment did nothing for me on BBB. With UW leaving that table it's a shame...

However on Dracula it sure did it's magic. I had some really really minor microstutter. That went away.
So thanks again.

[pixelmagic]

I added some code last night in the Lamptimer event to log to a text file the execution time for the timer and it was pretty instantaneous - virtually 0ms per call - unless I didn't use the Timer variable properly. When I get time I will try again.

I got some code from the internet to log live to a IE window, works very fine:

CODE

Sub Debug( myText )
' Output Debug to separate window
    If Not IsObject( objIEDebugWindow ) Then
        Set objIEDebugWindow = CreateObject( "InternetExplorer.Application" )
        objIEDebugWindow.Navigate "about:blank"
        objIEDebugWindow.Visible = True
        objIEDebugWindow.ToolBar = False
        objIEDebugWindow.Width   = 400
        objIEDebugWindow.Height  = 1000
        'objIEDebugWindow.Left    = -400
        objIEDebugWindow.Left    = 0
        objIEDebugWindow.Top     = 40
        Do While objIEDebugWindow.Busy
            WScript.Sleep 100
        Loop
        objIEDebugWindow.Document.Title = "Visual Pinball Debug Window"
        objIEDebugWindow.Document.Body.InnerHTML = "<b>" & Now & "</b></br>"
    End If
    objIEDebugWindow.Document.Body.InnerHTML = objIEDebugWindow.Document.Body.InnerHTML & myText & "<br>" & vbCrLf
End Sub

To be used in this way:

CODE

Debug("Text: " & variable)

I have started to look at some timings in core.vbs, specialy in Sub PinMAMETimer_Timer, made some lines to output totals every 10 seconds, and that routine get's called minimum around 1000 times every 10 seconds. Have not gotten to the part if that is good or bad, but 100 calls per second during normal gameplay seems a large number ?

Too bad none of the pinball makers/pro's get into this topic, it could be the way on making virtual pinball even better.

[Aaron James]

Where are you guys changing the line script in "checkpoint" ???
That game gives me the worst stutter unfortunetly.
The graphics are so high..beautiful game really, but its tough playing, at least for me, at this point. I'm running UVP as well.