Lara can't turn

[Lwmte]

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).

[vvs-]

At least it works for me in 50275d479f93503dcd2c1d3e499ce25b32333e28.

[Lwmte]

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).

[stohrendorf]

Is this still valid?

[Lwmte]

No, seems it was some issue with my compiler environment or conflicting commits...

[Lwmte]

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.

[vvs-]

I still can't reproduce this.

[stohrendorf]

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++).

[Lwmte]

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?

[Lwmte]

Funny thing that when I tried to record a video of it in Fraps, it suddenly vanished one more time.

[vvs-]

Perhaps it depends on a frame rate? I can't reproduce bugs which require high frame rate for obvious reason :smile:

[Lwmte]

Good idea! Fraps forces engine to work at exactly 60 FPS.

[Lwmte]

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.

[Lwmte]

You're not going to believe me, but now I'm getting it with release build.

[stltomb]

Is this a 32-bit or a 64-bit build? So far, the only debug/release builds I tested were 64-bit.

[stohrendorf]

I'm using 64 builds on Linux and 32 bit builds on Windows (both Debug and Release builds), and cannot confirm this.

[Lwmte]

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).

[vvs-]

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.

[stohrendorf]

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.

[Lwmte]

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.

[Lwmte]

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.

[vvs-]

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.

[Lwmte]

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!

[vvs-]

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.

[Gh0stBlade]

I had this happening to me a few days ago randomly. Stopped and started, not had it since though.

[stohrendorf]

Maybe a stupid question, but is your keyboard working properly?

[Lwmte]

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.

[Gh0stBlade]

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.

[T4Larson]

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.

[vvs-]

Actually, it become much worse in #269. I'm getting a very low frame rate and this bug occasionally.

[T4Larson]

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?

[vvs-]

Yes, I have. I didn't notice any difference. But the frame rate is very low, about 7-15 fps. I suspect that there is something related to Bullet which caused such dramatic drop.

[T4Larson]

I can reproduce the turn issue now; the reason why this is getting worse with the framestep is that with low fps the entity-frame actions may happen more than once per screen-refresh-frame (to avoid skipping frame/anim transitions but keep gamespeed stable), while the control-updates happen once per screen-frame (to have smooth mouselook with slomo timescale or high fps) - that's still a todo, but as it's also closely tied to the state function, where the rotation is modified in numerous places...still have to wrap my head around this - as @Lwmte said above, the rotation control handling isn't digital, but still turning based on refresh-time...

Leaves the question why you get framerate drops. If you suspect bullet, you could try reducing GAME_LOGIC_REFRESH_INTERVAL (game.h) to 1/30, to reduce the physics interval by half...

[vvs-]

Bingo! That fixed the frame rate. But it's merely a workaround. I don't think it should be that sensitive.

Also, that long jump in Atlantis, mentioned in #38, isn't working again. That means that speeds are still not invariant and depend on some tuning parameters :disappointed:

[T4Larson]

At least we have an idea about the origin of the frame drops now. The speeds may not yet be correct, but they should give stable results. I.e. gravity is set to 5800 in the current config, while based on the original TR gravity of 6 units per tick^2 converts to 5220 units per sec^2 ( = 6 * tickrate^2, or more precise 6 * tickrate * (tickrate-1) to compensate TR's stepped acceleration vs. bullets continuous gravity calculation ). There's still a bit tweaking needed...

[vvs-]

At least we have an idea about the origin of the frame drops now.

We already have a dedicated issue #266 for that. It just needed a confirmation that it has the same reason.

The speeds may not yet be correct, but they should give stable results.

But the problem is that they are not. With a refresh interval of 60 Hz Lara can reach the opposite ledge, while with 30 Hz she can't.

[T4Larson]

But the problem is that they are not. With a refresh interval of 60 Hz Lara can reach the opposite ledge, while with 30 Hz she can't.

Those small deviations are not surprising if you change the timestep interval - stable means, that everyone get the same results on every machine, regardless of monitor rate, vsync or cpu power.

Ideally you should get the same also for different timestep settings once the movement is better synced to the frame/state changes. But it may also turn out that it makes not much sense to have the timestep faster than the TR frame rate (which dictates the movement and state timing), but I'm still digging though this, currently I'm thinking about how to best rework the statefunc code so that it's easier to maintain and expand...

[vvs-]

This looks like another manifestation of #261. Besides, could it be reproduced in current master? Should it be closed then?