80 replies to this topic

[jimmyfingers]

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.

Looking quickly at the table, it does not use the fading lights routine and therefore the lamptimer is not present. At quick inspection it appears to use alpha on / off images a fair number of bulbs and flashers and the default pinmame lamps handler. The stutter on that one is probably because of how many of the bulbs and lighting effects are actually alphas, even if only 2 stage.

Also, when using the built-in lamp controls I believe the timing is tied in with / handled by the pinmame timer, which is usually set at the lowest possible setting of 1 and wouldn't necessary be something to feasible or recommended to change. This may also explain this table being hard on systems as it's using the built-in lighting controls running very fast and updating the lights frequently.

[Aaron James]

ok, thanks for the reply.
What you said makes sense. I looked very carefully, and everything is intertwined with every thing else...very complex.
This version will just have to be as is.
Thx for the explanation

[jpsalas]

So, this means that I can just give up using fading lights?

[unclewilly]

The fading lights look too good to give up jp.

[wildman]

So, this means that I can just give up using fading lights?

NOT.. lol JP just keep um comin man no problems here

[settingsons]

So, this means that I can just give up using fading lights?

No please don't stop JP - they look too good . The reason I started this thread is there are a handful of tables that give me some stutter and one day I experimented with bits of the script (not really knowing what I was doing but a good way to learn ), and just by increasing the lamptimer interval by 5 to 10ms the stuttering went. I wondered if it was just good luck but it seems to help other people as well, but the increments vary from person to person. These are just adjustments individuals can try themselves. I mentioned this earlier in the thread but I feel that the stuttering is mostly a problem that arises when you have multiple screens. So please keep the fading lights

Cheers

[JAM0]

So, this means that I can just give up using fading lights?

NOT.. lol JP just keep um comin man no problems here

+ 1

JP, I just did that on the 3 or 4 tables that I had a lot of trouble with, none of which were yours

[Liteuser]

My XP SP3 PC with 3.4ghz can handle fading lights just fine. No need to edit or disable any lights here.

[rob046]

I agree. A few years back I didn't care about fading lights, nor was I even convinced that I could see fading on real pinballs. But it grew on me & it definitely looks nice. Just a simple 3 step system is fine. The 8 step stuff is fine as long as it doesn't kill my system of course.

& these days fading lights are sooooo much better because lamp objects can be used. But back in the day, when dropwalls needed to be used, that would bring tables to a crawl for some ppl. With that, I say authors go for the fading lights if they like them. & for those that don't, that is fine too. This is a preference that I'm OK with either way. I'm more concerned with the lamps just looking good whether they fade or not.

[jimmyfingers]

So, this means that I can just give up using fading lights?

Please no - do not change what you do JP! People here seem to just be talking about this approach mainly for a handful of tables that are more demanding and how, on less high end systems, they become a less fluid. I think anyone that can play a table half decently on their set-up would always enjoy the eye candy and realism of fading lights especially when done by some of the top authors and graphics people on this site.

With light objects mainly used now-a-days vs. walls for lights, I don't think the fading lights routines on their own is much of a hit at all, however, I think that it is the alpha ramp / lighting updates that, by using the fading lights timing, have affected the situation. The only reason improvement can be seen, IMHO, is that the higher timer setting / lower update speed is decreasing the load mainly from the alpha ramp aspects / redraws / transparencies - not the normal lights updates. And alphas for now in whatever use make the biggest impact on their own so no reason for lights / inserts to be not done the same awesome way you and others have been doing them in recent history.

[blur]

About this stuttering problems on fast machines - since speed of machine is usually not the problem - it could be that the problem is with synchronization between threads (every timer starts another thread that is executed in parallel with other threads and events)
For example two timers start both every 40 milisecs, but they both need info from the other - so in their command queue on top is command that waits for response from the other thread, and second one is a command that is received from the other thread that has to be done for the other thread to be able to continue. This is standard deadlock situation. No one can continue until deadlock is resolved.
This is just an example - maybe something like that happens in vp and causes stuttering.
You could see exactly what happens if there is an option to write every command executed to log file.

[MRZ999]

I never find this line in the script of Terminator 2 Chrome Edition. I got ball stutter in that one.

[bent98]

About this stuttering problems on fast machines - since speed of machine is usually not the problem - it could be that the problem is with synchronization between threads (every timer starts another thread that is executed in parallel with other threads and events)
For example two timers start both every 40 milisecs, but they both need info from the other - so in their command queue on top is command that waits for response from the other thread, and second one is a command that is received from the other thread that has to be done for the other thread to be able to continue. This is standard deadlock situation. No one can continue until deadlock is resolved.
This is just an example - maybe something like that happens in vp and causes stuttering.
You could see exactly what happens if there is an option to write every command executed to log file.

the real question blur is can it easily be fixed be the developers of VP?

[pinball2883]

I have 3 tables installed on my computer and all have terrible shutter. Tables are AFM ,MM and Cyclone. Cyclone has the least amount But it hard to play any with this. I have 2 monitors hooked up to the video card. I could add the GTX560 to run the backglass. I am planning on doing two monitors with the DMD controller when i get fully setup. I am not sure how to get rid of this terrible lag. It seems to go with the UVP lights. I originally had the GTX560 as my graphics card but thought the shutter/lag was caused by it.

Might be beacuse i get the shutter in VP. Yes i am a complete NOOB



Computer stats
i5 3.30 Ghz
p67 Sabertooth motherboard
4 gig of ram
500 gig HD
GTX460 video card with driver 270.61
windows xp

Edited by pinball2883, 16 March 2012 - 02:54 PM.

[blur]

try to move dmd to playfield, and try to play that tables without uvp

if it runs faster - then solution is to run uvp only with non dmd tables - and move invisible dmd to first screen (make it visible, move, then hide it again, or just put dmdx=0, dmdy=0 in table script) cause even if dmd is invisible, its position influences performance

Edited by blur, 16 March 2012 - 02:57 PM.

[htamas]

I have 3 tables installed on my computer and all have terrible shutter. Tables are AFM ,MM and Cyclone. Cyclone has the least amount But it hard to play any with this. I have 2 monitors hooked up to the video card. I could add the GTX560 to run the backglass. I am planning on doing two monitors with the DMD controller when i get fully setup. I am not sure how to get rid of this terrible lag. It seems to go with the UVP lights. I originally had the GTX560 as my graphics card but thought the shutter/lag was caused by it.

Might be beacuse i get the shutter in VP. Yes i am a complete NOOB



Computer stats
i5 3.30 Ghz
p67 Sabertooth motherboard
4 gig of ram
500 gig HD
GTX460 video card with driver 270.61
windows xp

That's strange, and definitely not caused by the hardware being inadequate.
All those three tables run fine on my system, UVP and all... and it is just a slightly overclocked Athlon X2 Brisbane at ~2.45Ghz, 2 GB DDR2 RAM and a GT 440 video card driving both the playfield and backglass. I have an SSD but in this case this doesn't matter I think.
It has to be something software-related...

Edited by htamas, 09 April 2012 - 07:17 AM.

[htamas]

I have a question that's probably more for those who have good development knowledge with VP, knowing how it uses hardware resources.
What has more effect on eliminating stutter, a faster, more capable processor or a better video card? I know both have a role, but which one has more? I have the specs of my setup in my above post.

I pretty much only have some stutter if I use UVP with a handful of tables (and with some more demanding Future Pinball tables but that's another story).
As soon as I turn off UVP, these tables runs smooth. I figure it's probably the processor that holds back the system, and if I had a little faster, 4-core processor instead of the current dual core, then stutter would go away. Then I could set affinity of VP to two cores and UVP to the third core.
I tried to assign VP to one core and UVP to another, but it only made things worse, so having two cores for VP definitely helps things.

Am I on the right track with saying that processor upgrade is more worthy in this case?

Thanks for the advice.

[Itchigo]

From what I've heard the processor is more important. Also vp uses only 1 core. I'm running an I3 with a gt220 card and 16g ram with no problems. I don't have a cab set up yet, but I have had 2 screens running with no problems. I also don't have a front end yet either.

[unclewilly]

Just my 2 cents on the stuttering issue since i know people find issue in this regard with most of my tables.

I think the issues are very table dependent and there is no single solve all solution.

First off my system specs, which i'd say the os is a very important part of when talking about this issue..
Xp 32
4gb ram
i7 quad core 2.7-3 ghz
2 nvidia 250 gts 1gb
onboard sound
cab setup:
32 inch 1080p lcd playfield
19 inch 4:3 backglass
later added a 7 inch usb monitor for the dmd
and a 26 inch led lcd 1080p as my desktop sits outside my cabinet and also serves as my desktop pc

Keep in mind that this pc being my desktop is always connected to the internet and always has Microsoft security essentials virus software running.

I get no stuttering on any of my tables or even the system killing monopoly table.
No stuttering on the t2chrome.

The only stutter i ever saw was when using uvp on some tables.
I stopped using uvp as aside from the picture the lights on the backglass are not that important to me unless they are related to the game like the jackpot lights in bad cats.


So in my opinion you can't place the cause of stutter on any one issue.

1. Moving the dmd off the playfield monitor causes slowdown. This would be a pinmame issue, as i don't believe pinmame was designed for multiple displays. I could be wrong on this.
2. Uvp causes slowdown. Not sure why, my thought is that it replaces the pinmame controller and is also based on an older version of pinmame. So not only is it putting pinmame on another screen it is also processing all the graphics as well.
3. Alpha ramps with transparency. This causes slowdown due to vp having to redraw the table everytime the ball or a light object passes below or behind and alpha ramp. This would be vp rendering and i think is also related to the fact that vp uses dx7 and to change the dx would require a huge rewrite of the program.
4. On tables like freddy the gottleib emulation is not as fast as with other Rom systems so this causes slowdown. That would be a pinmame issue.

Also as discussed in other threads i believe that xp32 has the least amount of issues


so id say there is no quick fix and it can't be pinpoint as either a vp or pinmame or uvp issue it is any number of combinations of them all.

That is probably why this timer fix works for some people and not for others and works on some setups and not all of them.

I think people individually and on a per table basis need to play with the settings to find what works best for them.

That's all i have.

Thanks and have a nice day

-Scott

[settingsons]

I have to agree with you Scott - there are so many factors at work here that it is really up to each individual to play around with their config. Nothing is clear-cut on so what will work for people won't work for others.

I think we are at a stage where we have quite a few things/tweaks that people can try to improves performance. A more recent suggestion from Chriz recently yields positive results for me as well setting the Pinmame sound sample rate to 16K. For me I don't hear any reduction in quality, and it definitely helps with play smoothness.

Cheers

Vic