(Edit: Read my last post again and I said K presses before the reaction, so I guess I was right before. And I found out you need to subtract the last K press to get the actual number of frames to set per game. I did some frame advance testing and I think the default 1 frame of run ahead is appropriate for the majority of games. sure with shorter frame times sound will just pop and visual artefacts will be subliminal but it's still not quite what i need. RESTORE PC-T2, apply press, skip first frame of result (bullet cancel), display second frame of resultĪrtifact of hearing your death, seing a hit, not seeing the immediate result of your bullet cancel, however sound continuity and pacing is maintained (no note 3 repetition) If you restore T2 + apply button+let go 2 frames X (YOU ARE DEAD Note 3) *BUTTON PRESS*Īrtifact of hearing your death when you press the button, seeing a hit and hearing the bullet being cancelled, repetition of sound note 3, pacing damaged It would mean you would experience on laggy TV, RESTORE PC-T2, apply press, display first frame of result Two hypothesis: restore + advance 1 frame of result and restore + advance 2 frames of result is my hit box and X is a bullet alive O is a bullet killed, (sound). Let's say we live in a world when a frame rate is 1 frame per second, I am not sure i get it, tell me if i am mistaken. "game over"ing for a frame and it then never having happened.Īny other sources of latency, like display latency, have nothing directly to do with any of this: the display will always just be tasked with showing one row (whichever one you select) of frames from this illustration. This could be any other more sever artifact or artifacts, like e.g. And now to finally answer your question: at 3 frames or more of compensation with only 2 frames of latency, there will be an artifact, in this case manifesting as the character abruptly moving twice the distance of what it is supposed to be moving per frame.At 2 frames latency compensation, the response is "perfect", happening right after the button press.Every row down is one more frame of "render ahead", and compensates for one frame of added latency.The first row of rectangles is the sequence of frames produced by the game without this "trick".Īs you can see, it takes two frames after the button press for its result (a jump) actually starting to happen.A blue player, and a red enemy moving towards them.I get that feeling of having weighted training clothes taken off when comparing run ahead off to on it's pretty nice. I only really noticed a little snapback in certain platformers when pausing mid jump. I realize I might get into trouble using 2 frames for everything, but it seemed to work well without noticeable rollback effects during gameplay for the games I tested. Picodrive was one I found odd that didn't work at all, but I only use that for Chaotix. Though maybe Dwedit can optimize the state code in PSX to make that feasible. I didn't try certain cores like Desmume, Beetle PSX or Saturn since I'm pretty sure they're too heavy. MGBA: Frame delay 8 and secondary instance enabled to fix audio. Mednafen NGP: Frame delay 6 and secondary instance enabled to fix audio. BootROM core option needs to be disabled or it causes freezes. Run ahead secondary instance needs to be enabled to fix CD audio in CD games. I'm using run ahead frames 2 with hard sync frames 0 for each of these: ![]() I played around with run ahead tonight and tuned the settings for my humble, OCed 4.4Ghz 2500k.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |