walkawayy

Hm I thought maybe OG ended one frame early. But the frame timings are synced until this divergence. It's like TR1X is stuck for a frame and holds this frame...

@lahm86 I looked through 2.15 and hotfix patches and nothing stood out. Debug prints look fine. Idk. ``` ../../src/game/inventory/inventory.c 224 Inv_AnimateItem current_frame: 0; frames_total: 30; goal_frame: 14; open_frame: 14; anim_count:...

Just to clarify, is that from 2.15, or 2.15.3? So your chart is saying it's actually the first two frames that are displayed longer? And is this only a problem...

Ah ok. My post above was a test from the main menu. So maybe it's limited to something with quick load / quick save.

Hm quick load seems to look the same: 3.1: ``` ../../src/game/inventory/inventory.c 224 Inv_AnimateItem current_frame: 0; frames_total: 30; goal_frame: 14; open_frame: 14; anim_count: 0 ../../src/game/inventory/inventory.c 224 Inv_AnimateItem current_frame: 1; frames_total: 30;...

Idk what's causing this but I think I'm done hunting. `Inv_ConstructAndDisplay` seems fine, so the delay must be coming from somewhere else? ``` ../../src/game/inventory/inventory.c 759 Inv_ConstructAndDisplay current_frame: 0; frames_total: 30;...

@rr- I believe this is due to the phaser change adding a one frame delay. In `KeyHole_Collision`, this runs: ``` if (g_InvChosen == O_INVALID) { Inv_Display(INV_KEYS_MODE); } else { g_PickUpY...

I looked at this a bunch tonight, and I wanted to rework `g_InvChosen` and `Inv_Close` entirely. But, I keep coming across gotchas like the inventory is a phaser which delays...

FWIW I don't have this issue on OBS.

> Unfortunate that it would mean a bigger undertaking code wise. I understand then it may not be desirable. > > I could try it out by tailoring my gameflow...