[Mark]

I couldn't find where I originally mentioned this a couple of months ago so I'm posting again since the issue remains in the latest revision. Since I couldn't find the old post I don't know if I found and posted the offending revision.

Has anyone else besides me had the issue where the player is looking up or down instead of straight ahead at map start?
In one project its looking down, on another project its looking up. It looks fine in Mapster.

[TerminX]

I've seen this one but I'm not sure what causes it yet.

[Darkus]

Isn't something related with loading hi-res textures/skyboxes? It also happened to me, when a level is started, some textures are still loading, like skyboxes when you're outside, causing hiccups, and make player view looking down at start.

[Danukem]

I seem to remember this issue started when the new player angle/horiz code was implemented, which ties the player view more closely to mouse input instead of only being processed 30 times per second during gameplay. Is it possible that we are changing horiz with our mouse while textures are loading?

[Mark]

I thought about that and was careful to do menu selections and start with keyboard so as to minimize mouse movement. I'll test again with purposely moving mouse up or down and see results.

EDIT: Interesting. Without using the mouse at all I started up HHR. Like usual, the player view is looking down. Again with keyboard only I hit escape, chose new game and restarted. This time the view was looking up. I chose new game again and the view was straight ahead and stayed that way for the next 2 times I tested. Again, this was entirely without moving or using the mouse.

Next I started the game using the mouse. After making my selections I slowly kept the mouse moving up while textures loaded and the map starts. It was still looking down. So it doesn't seem to me to be a mouse issue during loading.

And to Dan's point. I remember that now. That update also caused the player view to spin continuously in another project. So it still needs to be addressed eventually.

[LeoD]

Bisect-compiled to r8544-d8a523e50 / svn8551 & r8545-16fc20a5d / svn8552

Added to issue tracker.

r8544: the player's view "slides" into the correct position.

32-bit builds appear unaffected as of r8545.

Test suite with some example builds: vp029-BuildGameTest.7z

The bug is "turned off" when a valid md3 model (frame+skin) or [highres]texture is defined for a (any?) sprite of the test map.

[Mark]

LeoD, by "32-bit builds appear unaffected as of r8545" do you mean the player look problem does not happen in 32 bit revisions above 8545? I ask because I just tried the latest 32 bit build and the issue persists.

[LeoD]

Mark, on 16 June 2020 - 01:36 PM, said:

LeoD, by "32-bit builds appear unaffected as of r8545" do you mean the player look problem does not happen in 32 bit revisions above 8545? I ask because I just tried the latest 32 bit build and the issue persists.

Those were my findings using the test suite linked above. Current 32-bit/r9158 executable seems a few pixels off, but nowhere near the 64-bit version. I wouldn't notice without looking for it.

[Mark]

Judging by the date on my post I probably tested with 9150. I guess I'll try with 9158.
Still looking almost straight up In Suburbs and almost straight down in HHR with 9158 32 bit non-debugging version
and player spinning in circles in a 3rd project.

All were fine with older revisions.

[TerminX]

Alright, calm your tits... I have a change in my dev branch that's supposed to fix this. Maybe LeoD can compile you a build to test and see if the problem is still happening.

[Mark]

After a good night's sleep my tits have calmed down. :) I'll be waiting.

[LeoD]

TerminX, on 29 June 2020 - 04:52 PM, said:

Alright, calm your tits... I have a change in my dev branch that's supposed to fix this. Maybe LeoD can compile you a build to test and see if the problem is still happening.

I hadn't planned on learning more about Git shit than absolutely necessary, but, OK :  eduke32-dev-debug-9185.7z (10.51MB)
Number of downloads: 153
32-bit seems OK, 64-bit is now looking up by some degrees, within a reproducible range.

Mark, on 30 June 2020 - 04:02 AM, said:

After a good night's sleep my tits have calmed down. :) I'll be waiting.

Shake it, baby...

[Mark]

Downloaded and I'll post my results shortly.

HHR. Previously both 32 and 64 looked down at start. They both look slightly up now. If I go back to main menu and reload the map, its looking straight ahead in both versions.

Suburbs. Looks slightly up in 32 bit. Looks straight ahead in 64 bit all but one time when it looked slightly up. If I go back to main menu and reload the map, its looking straight ahead.

I'll check more of my older projects even though they were designed to run best on those old versions.

In Project Blue Skies, yes it will get finished eventually, both 32 and 64 bit start the player looking down. Gamma is way darker and framerates take a huge hit. Also, without texture filtering I find the maps horrible looking. I guess we'll be staying with an older version for sure with that project.

Looked straight ahead in both versions in GraveyardTC.

Both were looking slightly up in Decay.

Different behavior between my mods and difference from Leod's testing. Odd. I'll check my 3rd mod next.

Player still spins around in 3rd mod.

TX: Mblackwell said he started a private discussion with you or 266 a while back concerning this 3rd mod. You'll have to consult with him to work it out.

Whew, thats all for now. It sure is a goofy problem. Easy to reproduce but tough to figure why it behaves differently in each mod.

[Mark]

Another update. The changelog on new revision mentioned fixing the player look issue "after loading a saved game". The issue I reported had nothing to do with saved games. It happens when you load eduke32 and run a map for the first time. That issue still remains. Looking up in some mods, looking down in other mods. Maybe somebody else reported the issue happening with saved games???

I see something affected the player spin in one project. The spin is still there but much slower now.

[Danukem]

I've noticed that too (the looking up/down), but I think if you add this line of code into the APLAYER actor, that will clear it up:

ifl player[].player_par 3 setp[].horiz 100

[Mark]

That worked for 3 of the 4 projects I tested with. I didn't think the 4th one would work because it already has similar lines in the aplayer code. When run, eduke just went into an unending loop of game.con error that I had to 3 finger salute out of.

I'll keep your temp fix handy but I suppose it should get addressed in the main code itself.

[Mark]

Just an update to the player spinning in newer Eduke32. Mblackwell commited a change to our project to work around it. Seems it was the only project affected so I guess devs can ignore that particular bug.

[ViDi]

I wonder if this has anything to do with a controller been enabled. Try to disable it.

[Mark]

No difference. It was a good idea though.

[ViDi]

I had some issues with my controller so I thought it might have been it.