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...
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..
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?
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..
just to confirme that i effectively got the frame delay down to 2 frames AND the game running at normal speed.
if some of you where thinking about programming a Tetris clone on Iphone/Ipad... http://gamesfromwithin.com/lag-the-bane-of-touch-screens
- 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
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
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
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.
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.
The Enigmatic Form → SouthTown Arcade: good? Arcade Infinity → Denjin 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?
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...
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.
