OpenTomb
OpenTomb copied to clipboard
opentomb
Lara can't turn
Does anybody experience this bug? I'm sure everything worked less than one hour ago, but now Lara refuses to turn (although she leans properly).
Well... Something is wrong on my side then! :smile: Although it looks like engine wrongly identifies keyboard input as analog input - i. e. boolean value is treated as integer (degree of analog stick turn).
No, seems it was some issue with my compiler environment or conflicting commits...
This is very serious.
I believe, the bug is there because whole controls module was converted to boolean logic without taking move_logic and look_logic operations into account.
I actually was very careful when working at the controls; but move_logic and look_logic do the very same as before, as true and false are converted to 1 and 0 in arithmetic expressions (that's defined in the ISO standard of C++).
Then I completely don't understand what's happening. It is just very random, but is now much more frequent. Probably really memory corruption issue somewhere?
Funny thing that when I tried to record a video of it in Fraps, it suddenly vanished one more time.
Perhaps it depends on a frame rate? I can't reproduce bugs which require high frame rate for obvious reason :smile:
It seems that I can't reproduce this bug when I build with Release option set in CMake. Perhaps, it's something related to Bullet as well?
Not sure if we should close this or not... I think I will close it for now, until problem resurfaces with release build. There's already too much things to blame debug build for.
Is this a 32-bit or a 64-bit build? So far, the only debug/release builds I tested were 64-bit.
I'm using 64 builds on Linux and 32 bit builds on Windows (both Debug and Release builds), and cannot confirm this.
I'm compiling 32-bit, maybe it's related to certain self-built libraries (including Bullet)?
I am using MinGW-64 5.1.0+MSYS2 (latest version).
Are you compiling it using 64-bit compiler targeting 32-bit CPU or using an actual 32-bit compiler? Though, I don't know if it's even possible with gcc.
I have a self-built Bullet both on Linux and Windows (2.83.5). But from my knowledge 64-bit builds of MinGW were never really considered "stable", i.e. they may produce buggy code.
I am compiling using 32-bit compiler (I think so, because all my libs are 32-bit and placed in i686-w64-mingw32 folder).
Right now I have tested the game with my gamepad. It's been a while since I tested it with gamepad, and surprisingly I found another refactoring bug - for some reason, config parsing for movement axes of joypad was removed. But more interesting story is with gamepad and its analog sticks it produces same kind of error - Lara can't turn.
So it's not related to keyboard vs. analog input, as I thought.
Seems I have found a bug. For some reason, when FPS is not power of 60, engine_frame_time returns ridiculous values, like 0.01 or even just 0. I wonder why engine works, and works even at correct speed in such case at all.
So, since rotations are applied based on frame_time values, they are not applied correctly, because frame_time is zero most of the times. Which looks in game as not being able to turn.
I suspect this isn't always the case. Perhaps there is something special in your setup or maybe even MinGW. I never saw such time values and can't reproduce this bug as well.
What drives me mad is when I modify the source somehow and then recompile it, the bug goes away, but then reappears at some point. Currently I just copied delta * time_scale value into another static temp value and passed it as an argument for Engine_Frame, and bug is gone. But then I just rolled back all the changes and tried to compile it again, and guess what? No bug again!
There exist very tricky bugs with power management, especially CPU states. And sometimes clock values are wrong in such circumstances. That's platform and compiler dependent. I always turn off PM everywhere and that helps.
I had this happening to me a few days ago randomly. Stopped and started, not had it since though.
Yes, it's totally not related to a keyboard. As I said, the reason is frame_time contains wrong values all along, when FPS is not power of 60. It's either 0.001 or 0 all the time, and 0 is around four times frequent than 0.001. Because of this, rotations are not calculated properly.
I have no idea why it has no effect on animations, since animations should become stuttered as well, but they are not.
I thought it was my keyboard, but I found it works fine on other games when the issue was happening concurrently so definitely an OpenTomb bug.
I had this happen with vsync disabled during framestep testing - the higher the framerate, the slower the turning was. The reason in that case was that Game_ApplyControls() was called more often that the game logic (which it still has to for smooth mouse) and not adding up the total turn for each game logic step - so this may have been fixed by #269.
Actually, it become much worse in #269. I'm getting a very low frame rate and this bug occasionally.
In #269, the state handler dosn't properly handle slow-turn to fast-turn transition, which are based on the previous flawed frame stepping and animation sizes (like a couple of other state transitions). Have you tried enabling/disabling vsync in the connfig, and see if it makes a difference?