# TGM3 Input/display LAG

Thread in 'Research & Development' started by K, 14 Jul 2011.

1. ### K

First of all, the trouble origin of the input lag wasn't where it was expected.
Actually there is no noticeable or significant input lag If you use an Arcade system + a JVS I/O converter (currently the SEGA I/O revision B.). It's not an hardware input LAG but more an Frame displaying LAG depending directly from the game itself and/or Windows XP.
i was wrong about the screen resolution but don't matter as long as your PC is powerful enough to handle other task (winXP is still mandatory). The solution actually work on my PC and i can't garantee it will work the same for other but i'm confident about muf confirming it by doing the same experimentation.
With game_windowed.exe with the exact same running session keeping the mouse outside the windows drop the delay to 5 frames, putting the mouse simply inside the window, lower the delay to 3 frames, and finally keeping the mouse moving (with the longest mouse trail enabled) inside the windows lower the delay to 2 frames only wich is as good as the original TAP PCB.
During this time is clearly noticeable that the animated background is slowing down (time based?) whereas the game keep running normally (vSync). More test might indicate that the mouse is a simple trick to hog the CPU...

2. ### K

gah,
I was wrong.
when the bg slow down the timer too, so the overall game. The measure are biased.
Since the input are updated through another thread i'll keep digging..

3. ### mat

aren't you counting the monitor refresh? surely the gamespeed isn't altering the refresh rate? do you mean to say that the input is polled separately from the game logic, and then called upon during each game frame? and does this mean that if you force the game to run at, say, half speed, your input lag would be 0 game frames?

4. ### K

Yes the input are polled on another thread, leading to some potential delay.. the slowing trick might be a dirty solution for altering this thread priority..

5. ### K

just to confirme that i effectively got the frame delay down to 2 frames AND the game running at normal speed.

6. ### mat

eep! care to elaborate on what you're doing? any chance of this working without an i/o board?

10. ### K

if some of you where thinking about programming a Tetris clone on Iphone/Ipad...
http://gamesfromwithin.com/lag-the-bane-of-touch-screens

11. ### K

- TAP shmupMame became enough reliable for high speed gaming so i doesn't make sense these days just trying to mimic TAP without extra features..
Despite it's a very good coding exercice for personnal project, it's a never ending correction/adjustment until motivation fade away..
There are enough examples in this forum showing "history repeat itself", but only the original goes on

Ironicaly we got lot of "delay", in the input/display hack. we'll soon get the source from sh8's initial project and try to finish it by ourselves.
I look forward this year to work out something for it and "extras" features for "evangelisation"..

ps : seeing the view number count on this topic

12. ### K

yup here is something for trying to remove input/display lag.
muf will probably better explain with technical information how or why it work but i'll keep it simple : the input lag is not noticeable anymore and feel like original TAP !
Remember i'm using a JAMMA input interface with a SEGA I/O Board.
Config :
-winXP (dedicated for Ti)
-CPU : intel Core2 duo E8500
-GPU : ATI radeon HD 4800

tweaking program :
-ATI tray tools (3D tweaking)
-AutoHotKey (mouse control)
-Fraps (video recording / FPS display)

I force my screen resolution to 640*480, and run the game windowed. The game internal graphic update is based on Vsync so you must have a refresh screen rate

of 60htz
since i have an ATI GPU i don't have the nVidia graphics bugs issues.
Depending of your configuration, without tweaking the input/frame delay is huge.
with "my hardware configuration" simply putting the mouse over the game window will "instantly" improve the input/frame lag
and after few test it appear that slowly moving the mouse with a trail over the window greatly improve things, but too fast can also unconsistently alter the

frameRate and drop it even down to 30fps. Keeping the mouse on the top part of the screen is better than bottom for windows mouse graphic routine update.
so finally i use pretty simple autohotkey script for handling automoving mouse :
Code:
;autohotkey auto moving mouse routine
^!z::
loop{
SetMouseDelay, 0
if GetKeyState("F4","P")
break

MouseMove, 300,25,0
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
MouseMove, 15,0,0,R
if GetKeyState("F4","P")
break
}


note : the cursor is a simple custom 32*32 filled white (whatever color you use) Black is visually less disturbing and alpha pixel is less efficient.
Sorry for engrish

13. ### farter

sorry for bumping -m-
seems just if there's something interfering with its rendering area, it'l be forced to render a bit more in time...

on my laptop (win7 x64 / ATI gfx card) i'm feeling same as K mentioned, putting the mouse cursor on the window reduces the lag very much.

i recently tried to play it with live broadcasting. i'm using a function of a Chinese IM software (QQ, QQ Group video chat / screen sharing), which draws a rectangle on the edge of the area it's capturing when broadcasting. and it's somehow bad coded, you can see the rectangle flashing irregularly very fast.
though QQ itself and the video encoding inside causes random lag, i can feel that the "constant" lag become almost unnoticeable too. when i stop broadcasting it comes back instantly.

i think it's the flashing rectangle working... so i'm wondering which moves on the area of it's window makes it delay less..
why static mouse cursor works "a half"?
how does the framerate number rendered by fraps/BBSReader work?
or does graphic capturing work?
what if we make a small program to consistently draw something on it through windows GDI?
some idea in the way to implement graphic works which causes flashing?

orz

14. ### Muf

I have a small tool that calls InvalidateRect on a portion of the Ti window. While this by itself seems to have the intended effect, it's not a complete replacement of the mouse move script. Jago would be able to tell you more about it.

Personally I would prefer to profile Ti both with and without the mouse move script, and see which function(s) get called more often when the mouse is moved. It should be possible to work out the input polling function responsible and see if the executable can be patched/injected to call it more often by itself without resorting to mouse moving or calling InvalidateRect.

NB: I think this is very poor QA on Arika's part. If anyone remembers, an early beta of Ti written for NAOMI was cancelled quoting "input lag issues" on the NAOMI platform. The fact that we can accomplish so much in terms of improving responsiveness without any access to source code or knowledge about how the game engine is written, says a lot about the programming expertise (or lack thereof) at Arika. Mihara no doubt is a genius in game design and gets a lot done with limited resources, but issues like this combined with Taito's broken, trivial, and crippling DRM (shoutouts to Rockey), in my opinion make Ti a complete failure as a solid, lasting arcade game. 10 years from now, you will still be able to play TAP on original hardware with less input lag than Ti, the last "genuine" system of which will probably be on life support, if not either in a museum or in a garbage container somewhere. RIP arcade.

15. ### orz

how the fuck was minimal input lag not a primary goal of programming these games lol

16. ### colour_thief

Let's see:

colour_thief: good
muf: broken (overheating dongle)
kevinddr: broken (overheating dongle)
mike haggar: good
kitaru: broken (overheating dongle)

Am I missing anyone? 5 legit players, 60% failure rate. This is worse than RROD.

17. ### Kitaru

The Enigmatic Form → SouthTown Arcade: good?

These machines are missing in action, but were working when last seen as far as I can tell.

Wasn't there a machine floating around in Italy at one point? Also, the mysterious E-Spot machine that disappeared...

Arcade UFO: good welp no, bad, but I never got confirmation of whether it was the dongle or the whole Type X?

Last edited: 20 Aug 2014
18. ### K

Actually i think i described pretty much the trouble on previous post.. The invalideRect tool is far better than the mouse move script : it's consistant without all those annoying cursor artifact. pretty much of the work was done by muf.
this is a small application you load just before the game.exe loaded without border.. the game window position match the screen (640x480)..
basically it's just setting details but the effect is the same : 2 frames input/display lag wich is equal to TAP in term of reactivity.
Basically this setting become better than original, and it's even disturbing for people used to play on the original.. as muf said, it would become "not legit" to become GM on this hacked Ti setting since original player have to deal a "crap" but original version.. what a world...

19. ### KevinDDR

Pretty sure that AI's machine died at least once on them and they had to have it sent off for repairs. Also pretty sure that Arcade UFO had Ti and theirs died on them as well. Basically Ti is completely fucked, and there is no way around it sadly.

20. ### orz

luckily the arcade TGM games will become obsolete once GMO is released