1353 replies to this topic

[fuzzel]

rev2842 is up:

 

- fixes for the new delayed timer en/disables by DJRobX
- remove the weird mutex-like code (that did never work, but only introduced all kinds of timer issues on all kinds of VP versions), thanx to DJRobX
- avoid problems with timers en/disabling themselves by storing all (combined) changes, then updating all these before the next round of timer runs
 

[toxie]

thanks!

 

what this means: there was at least since the initial VP9 release a bug with the timers that can prevent some timers to work correctly (e.g. triggered too early/often or too late/missing some triggers) if timers were enabled/disabled within a timer (it could even happen that more and more timers 'of the same type' were created then). so this was fixed now, hopefully without any new bugs or preventing existing tables from working correctly.

[Drybonz]

Thanks guys... are there any particular timer related features we should be watching for when testing... in other words, table elements that might be strongly effected... or maybe tables that might be strongly effected?

[Pinball999]

Thanks Fuzzel.

I've just tried rev2842 and it looks like some ramps are now invisible.

I've seen this on ST LE and Tron.

[kiwi]

I have a bumper cap that is more transparent than it should be, rev 2842 to the left, and to the right VP10.1.
In full screen mode the problem is not there.

 

 

Thanks

[DJRobX]

Thanks guys... are there any particular timer related features we should be watching for when testing... in other words, table elements that might be strongly effected... or maybe tables that might be strongly effected?

 

It's mainly watching to see that timers enable and disable themselves correctly, and a fire at the right intervals.    There's one particular popular space themed table that's unmentionable here that was TOTALLY broken by this initially, because it creates a timer for every single switch hit.   Firing at the wrong intervals caused MAME to miss the switch events.   I think it made for an excellent test case, but it all seems to work fine now with the fixes I submitted (and appear to be included in the build Fuzzel posted) 

 

I think mainly you're looking for animations that don't complete correctly.   That's usually where the issues manifested themselves that I saw initially. 

[BorgDog]

 

Thanks guys... are there any particular timer related features we should be watching for when testing... in other words, table elements that might be strongly effected... or maybe tables that might be strongly effected?

 

It's mainly watching to see that timers enable and disable themselves correctly, and a fire at the right intervals.    There's one particular popular space themed table that's unmentionable here that was TOTALLY broken by this initially, because it creates a timer for every single switch hit.   Firing at the wrong intervals caused MAME to miss the switch events.   I think it made for an excellent test case, but it all seems to work fine now with the fixes I submitted (and appear to be included in the build Fuzzel posted) 

 

I think mainly you're looking for animations that don't complete correctly.   That's usually where the issues manifested themselves that I saw initially. 

 

 

So could this potentially take care of those pesky star rollovers that get stuck down frequently?  I'll test some of those tables out and see if that is improved.

 

edit:  so I played a few games of Vulcan and an original table I'm working on, both of which have several star rollovers.  It did not seem to happen nearly as often as it used to but I did have 1 that got stuck down once.

Edited by BorgDog, 06 November 2016 - 07:18 PM.

[DJRobX]

Attempt #2, cleaner!     Please, kill this mouse pointer in True Full Screen before it drives me crazy.  

 

In player.cpp, add the bolded lines.   

 

 m_hwnd = ::CreateWindowEx(windowflagsex, "VPPlayer", "Visual Pinball Player", windowflags, x, y, m_width, m_height, NULL, NULL, g_hinst, 0);

 

   if (m_fFullScreen)

   { // blocks processes from taking focus away from our exclusive fullscreen app

  ::LockSetForegroundWindow(LSFW_LOCK);

  ::ShowCursor(FALSE);

 

   }

 

And later, in WM_DESTROY case:

 

// modification to m_vedit of each table after playing them must be done here, otherwise VP will crash (WTF?!)

      playedTable->RestoreLayers();

  if (g_pplayer->m_fFullScreen)

  { // blocks processes from taking focus away from our exclusive fullscreen app

  ::LockSetForegroundWindow(LSFW_UNLOCK);

  ::ShowCursor(TRUE);

 

  }

[Drybonz]

Does that allow the cursor to re-appear with movement... for instance if you want to move a DMD or something and move the mouse?

[DJRobX]

It only disables the mouse pointer over the active window.   So if you move the pointer outside the active window, it will still appear.    If for some strange reason that didn't work, it's also conditional only to true fullscreen mode.   Regular window fullscreen is unaffected.  

 

I tried changing the place where VP tries to just slide the mouse out of the way and it doesn't work.  Windows always resets the pointer dead center of the fricking playfield!

[Drybonz]

Can it just be locked to the backglass monitor?

[toxie]

Attempt #2, cleaner!     Please, kill this mouse pointer in True Full Screen before it drives me crazy.  

 

Yeah, sorry. I was planning to do a more general solution that would do this in all modes (but with proper restore in the necessary special cases), etcetcetc.

Will add this then.

[fuzzel]

rev2846 is up:

 

- fix mouse cursor in fullscreen mode
- add additional F11/debug tweak for the flipper lag: amount of frames until input is actually happening/rendering
- new debug/F11 output to show internal delay from left flipper key press to start of rotation to EOS event, and revert rev 2819 and 2820 due to this (as it did not make a real difference in this real measurement)
 

[toxie]

Explanation: i reverted the "flipper-speed up" code again (rev 2819 and 2820), as it did not lead to any actual decrease in flipper delay, using the new statistics mentioned above. Plus JF was unsure if it actually had weird sideeffects instead.

 

Everybody can now measure themselves what delay one gets, by flipping (only) the left flipper. This will show only the internal delay though, e.g. the point where we first read out the key down event is the start, and then until we get the notification to make the flipper rotate and then again until the flipper reaches the EOS/end angle.

 

On top of that there is of course still the USB input delay, and until we first catch the key down, plus afterwards the gfx driver buffering and the TV/monitor latency.

[toxie]

one more thing: i experience some stuttery audio nowadays with the recent builds and some tables (like SFII), please let me know if you experience the same.

[Drybonz]

I noticed stutters in the audio on Kingpin.

[DJRobX]

Can it just be locked to the backglass monitor?

 

 

Not easily because B2SBackglassServer.exe is not the focused application.    Plus you want to be able to get to the VPM DMD to adjust it also, and it may be on a 3rd monitor.

 

One minor issue I noticed with the full screen mode is that the "Hold ESC to exit" thing doesn't work at all on my cab.    Once that message pops up, I am unable to proceed.    Neither holding ESC/Exit, nor pressing Enter (or any other button for that matter) does anything.   All I can do is ALT-F4 out of it.    Not really a big deal when playing since PinballX will force VP to quit, but it's more of a problem when trying to tweak tables on my cab.  

 

(This is not related to the mouse pointer thing at all, it started before that.   )

Edited by DJRobX, 08 November 2016 - 05:29 PM.

[Drybonz]

Yeah, the hold esc thing has never worked... there's actually a lot of questions about "how do I get out of fullscreen"... answer Q Q (not the sad kind).

[toxie]

i'll add that to the info-text, too, then..

[DJRobX]

Yeah, the hold esc thing has never worked... there's actually a lot of questions about "how do I get out of fullscreen"... answer Q Q (not the sad kind).

 

OK.  How do I cancel and return to the game?   The point of that was supposed to be that I can resume the game if I accidentally hit Q.   Otherwise we'd be better off just exiting as soon as I hit Q.