TGM3 Input/display LAG

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

  1. @Kevin: Thanks for reminding me of Arcade UFO, I had meant to list it.
     
  2. Hello, TGM (particularly TGM TI) fan here. First of all, thank you K for providing this information. Without it I would have never started playing TGM.

    Muf, how are you calling your InvalidateRect? Every second or more? Just like with mouse script, calling it too infrequently results in hilarious effects. I personally set it to 16.6 and it seemed alright without any special set up. I ran it straight from W7 with all the random c* running in the background. Normally I either run it on dedicated desktop PC with XP (and ATI card) or on laptop from embedded XP specifically set up for TGM TI. In general going embedded doesn't really seem to improve much beyond what has been achieved. With few extra programs and a simple AH script you can pretty much automate it fully and launch from your controller, but that's besides the point. Not worth it. :p Been there, done that.

    As far as improving the game I don't think that the problem is polling (I'm probably wrong though). The hack (original) uses simple detours and as far as I know Dinput either works or it doesn't. Sure, you can set up threaded input if it hasn't already been done and it might improve something, dunno. However, since I started practicing IIDX I ran into massive sync problems that pretty much f*ed up running HDD rip and that got me thinking that this minimal .05hz can and will screw you up. If TGM is synced up to some mysterious specific refresh rate then not hitting that will over time start "skipping" or "canceling" inputs, if it's polling/updating based on that.
    Why these "tricks" work I have few ideas, but none which are actually feasible. It's just magic.

    To actually understand if there's anything wrong with the code *cough* you need a lot more than just peeking in. From the looks of it there's nothing that pops out for any particular reason (possibly because of lack of knowledge) and since it looks so "normal" (kinda) we'd need at least reasonable C pseudo-code for any kind of fishy parts or the whole main loop. That unfortunately takes c* load of time.

    Also, has anyone by chance made it so that when you hit F5 it sets the desktop resolution to 640*460@60hz as well? It's like 5min work, but every time I do something I keep forgetting. The game calls ChangeDisplaySettings and I suppose it should be enough to change the DEVMODE struct so that it points to a few constant variables in memory (yours). I actually did make a lil' app that toggles resolution, but for some reason TGM doesn't like it at all. It does result in silly effects though (over-sized or undersized particle effects).
    Anyway, maybe someone has already done something like that.

    Oh and for those who begin venturing this road, monitor does (refresh rate mostly) affect the game quite a bit. It may or may not be noticeable if you play, but the time might vary widely.
    This is actually quite interesting (but not surprising). Running on a laptop that I know is on 59.95 hz results in +20s over 7min roughly. I'm no math wiz, but it does add up comparing your average overall time from a few plays. This was interesting, because when I switched over to another monitor (BenQ GW2750) the game felt much quicker and you felt like it was really intense (probably because of display lag), but as already said, magically you're now 20s faster. At first I thought it was because I was, you know, forcing myself really, really hard, but then I had several bad games that I was sure will be way slower than on laptop, but it still ended up being faster than some of my normal games. There was a lot of back and forth and many videos and logs to understand it. Again, not surprising, but once time becomes important (there's plenty of time for that) you definitely need either a CRT or any other "proper" monitor for this.
    I do not know how much slightly lower or higher refresh rate (literally ~.05 - .1) actually affects the game in terms of timers and obviously pieces falling, etc, but laptop feels more relaxed whereas desktop doesn't (but it's faster). Again, this feeling of rushed is mostly likely because of longer display lag of desktop screen more so than anything.

    Oh, just curious, how many of you are using AltInput.dll?

    So, yeah. I'd personally want to do something to improve this game further in unobtrusive and clean way, but the amount of work it takes to get anything done...I mean...it works okay enough with all the scripts and s* running in the background. :D
    Just a thought, has anyone tried playing with UpdateWindow or RedrawWindow from the main module (game.exe code injection)? Just pop your own thread and keep calling that shiz...?

    Anyway, hello and thank you for getting this far!


    Ah and my take on mouse script:

    Edit : Little update. So I wrote a DLL to inject into the game that creates a thread what calls UpdateWindow every 1000ms. Running at fullscreen with no other modification (InvalidateRect or mouse movement) I can't really tell the difference between them. So, that's another option to look at. (Edit2 : Confusing results. Still something to look at)
     
    Last edited: 4 May 2014
  3. some more info about touch screen lag...
    https://www.youtube.com/watch?v=vOvQCPLkPt4
    1ms o_O
    maybe we'll have to use highly specialized hardware to build our really responsive games?
    he says "we used our test setup"... (sorry i can't catch much of the words.. not native speaker), and as seen, it should be something capable to run simple programs and operate and show bitmap graphic...
    i wonder what that hardware is, announcing a precision of 1ms, from touchscreen to touch event to cpu to graphic memory to screen refresh. basically that means the screen refreshes at least 1000Hz and what if we can get that hardware QvQ
     
    Last edited: 3 May 2014
  4. Are any of these tools available? I don't really have any knowledge of creating batch files or whatever so is there a pre-made one available to reduce the lag in TGM3?
     
  5. Open Notepad, write text, save as filename.bat (make sure it's not filename.bat.txt) and you're done.

    Though most of the posts in this thread are scripts for software like AutoHotKey, that you just run.
     
  6. Thanks for the response!
    The only problem is, I have no idea what to write in notepad. The mousescript seems annoying if it has to run windowed whilst constantly causing artifacts on the screen.

    I was looking at muf's solution or this helloworlds, but they aren't clearly explained.
     
  7. Muf

    Muf

    All the solutions listed here involve running the game in windowed mode, and they all cause artefacts.
     
  8. Ok thanks, I'll try to get the Autohotkey going.
     
  9. I got my Taito Type X with TGM3 a few weeks ago and I'm using a Capcom I/O Converter with my supergun on the Sony PVM. But I'm not that satisfied with the Capcom I/O.
    So I'm just curious, do you mean the Namco System 246 I/O? I can get this one for 80€ and I would like to give it a try. The seller would make me a suitable USB cable as well.

    [​IMG]
     
    Last edited: 2 Aug 2015
  10. He is referencing that one however the 1 frame is more urban legend than proven fact. At least I've never seen proper tests done.

    The base system itself has lag, even if you're playing native JVS.
     
  11. could you please share the invalidaterect tool? thanks a lot!
     

Share This Page