Duke4.net Forums: player start looking up or down - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

player start looking up or down

User is offline   Mark 

#1

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

User is offline   TerminX 

  • el fundador

  #2

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

User is offline   Darkus 

#3

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

User is online   Danukem 

  • Duke Plus Developer

#4

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?
0

User is offline   Mark 

#5

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.

This post has been edited by Mark: 03 May 2020 - 01:30 PM

0

User is offline   LeoD 

  • Duke4.net topic/3513

#6

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

User is offline   Mark 

#7

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

User is offline   LeoD 

  • Duke4.net topic/3513

#8

View PostMark, 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.
0

User is offline   Mark 

#9

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.

This post has been edited by Mark: 29 June 2020 - 01:22 PM

0

User is offline   TerminX 

  • el fundador

  #10

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

User is offline   Mark 

#11

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

User is offline   LeoD 

  • Duke4.net topic/3513

#12

View PostTerminX, 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 : Attached File  eduke32-dev-debug-9185.7z (10.51MB)
Number of downloads: 201
32-bit seems OK, 64-bit is now looking up by some degrees, within a reproducible range.

View PostMark, 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...
1

User is offline   Mark 

#13

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.

This post has been edited by Mark: 30 June 2020 - 03:41 PM

0

User is offline   Mark 

#14

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.

This post has been edited by Mark: 27 July 2020 - 07:53 AM

0

User is online   Danukem 

  • Duke Plus Developer

#15

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

1

User is offline   Mark 

#16

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

User is offline   Mark 

#17

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

User is offline   ViDi 

#18

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

User is offline   Mark 

#19

No difference. It was a good idea though.
0

User is offline   ViDi 

#20

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

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options