Random Screenshots Thread
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
The gap is there all the time, no need to rip it. Again, on a client based on <beta1 CVS source. Maybe I can throw some debug messages in the wall code.
Edit: first result, printed at the start of eGrid::DrawLine:
What's the first wall doing there?
Edit 2: Filtering it away fixed it.
Edit 3: A few more prints:
Edit 4: Seems to happen in DrawLine, but I have no idea what it's doing.
Edit: first result, printed at the start of eGrid::DrawLine:
Code: Select all
Attempting to draw wall from (-80, -36) to (0, 0)
Attempting to draw wall from (0, 0) to (88.3884, 0)
Attempting to draw wall from (88.3884, 0) to (88.3884, 88.3884)
Attempting to draw wall from (88.3884, 88.3884) to (0, 88.3884)
Attempting to draw wall from (0, 88.3884) to (0, 0)
Edit 2: Filtering it away fixed it.
Edit 3: A few more prints:
Code: Select all
>> Wall [map code]
Inserting point at (0, 0) [map code]
Attempting to draw wall from (-80, -36) to (0, 0) [grid code]
Drawing line to (88.3884, 0) [map code]
Attempting to draw wall from (0, 0) to (88.3884, 0)
Drawing line to (88.3884, 88.3884)
Attempting to draw wall from (88.3884, 0) to (88.3884, 88.3884)
Drawing line to (0, 88.3884)
Attempting to draw wall from (88.3884, 88.3884) to (0, 88.3884)
Drawing line to (0, 0)
Attempting to draw wall from (0, 88.3884) to (0, 0)
<< Wall
That's not really a wall, it's a NULL wall used to insert the start point of the first real wall into the grid.Jonathan wrote:What's the first wall doing there?
Do I get this correct: you disabled the NULL wall drawing and the gap disappeared???Jonathan wrote:Edit 2: Filtering it away fixed it.
Looks like a square to me.Jonathan wrote:Edit 3: A few more prints:
<snip>
What is the arena size that causes this? There may be an error in some lesser used branch of the wall drawing code, that only gets triggered in certain configurations. I didn't happen for me though, probably because of floating point implementation differences, for all sizes from -8 to 0, so I'll probably have to step through the code and look for narrow misses.
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
I filled start's x and y with end's and returned, if the start and end were (-80, -36) and (0, 0), respectively.z-man wrote:Do I get this correct: you disabled the NULL wall drawing and the gap disappeared???Jonathan wrote:Edit 2: Filtering it away fixed it.
See the settings of Shrunkland. It's scaled down from 500 to ~88, so the setting is -5 ~= log(sqrt(2), 88/500).z-man wrote:What is the arena size that causes this?
Did DrawLine change after at most a week before beta1? If so, I'll have to try the new code first.z-man wrote:There may be an error in some lesser used branch of the wall drawing code, that only gets triggered in certain configurations. I didn't happen for me though, probably because of floating point implementation differences, for all sizes from -8 to 0, so I'll probably have to step through the code and look for narrow misses.
How would you compare everything in the giant function?
Ah. That modifies the grid and gives a different situation for the next walls that are drawn. And it only works for the very first wall, do the same for the players wall and watch the rim getting bentJonathan wrote:I filled start's x and y with end's and returned, if the start and end were (-80, -36) and (0, 0), respectively.z-man wrote:Do I get this correct: you disabled the NULL wall drawing and the gap disappeared???Jonathan wrote:Edit 2: Filtering it away fixed it.
Thanks, I'll see what I can do with that.Jonathan wrote:See the settings of Shrunkland. It's scaled down from 500 to ~88, so the setting is -5 ~= log(sqrt(2), 88/500).z-man wrote:What is the arena size that causes this?
No. The last relevant change to the file was the phasing bugfix on the tenth of August.Jonathan wrote:Did DrawLine change after at most a week before beta1? If so, I'll have to try the new code first.
Well, I'll step through it and see if any of the decisions the code makes are close ones.Jonathan wrote:How would you compare everything in the giant function?
If you want to do something, you can place debug output into the constructors and destructor of gWallRim and in gWallRim::Split. There is not much information available, just dump the raw this pointer of the constructed/destroyed/splitted wall.
I'm not good at plus/minus calculations; the missing segment is the one from (0, 0) to (0, 72)? The last one that should get drawn?
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
Added debug output to my map code as well. The final output:
It's about the last 3/4th of the last segment in the map file that's missing (below the 2nd from below above ... um, below the second wall counting from below in the output above).
Edit: I just noticed I left some weird optimization setting on. I'm compiling with it off now.
Code: Select all
gWallRim constructor 0x622ff30
gWallRim split 0x622ff30
gWallRim constructor 0x6233970
gWallRim constructor 0x6233860
gWallRim destructor 0x622ff30
gWallRim constructor 0x6233340
gWallRim split 0x6233340
gWallRim constructor 0x6233e20
gWallRim constructor 0x6233e90
gWallRim destructor 0x6233340
gWallRim constructor 0x62341d0
gWallRim split 0x62341d0
gWallRim constructor 0x62342a0
gWallRim constructor 0x6234310
gWallRim destructor 0x62341d0
gWallRim split 0x6234310
gWallRim constructor 0x62340e0
gWallRim constructor 0x6234150
gWallRim destructor 0x6234310
gWallRim split 0x6234150
gWallRim constructor 0x622aa80
gWallRim constructor 0x622aaf0
gWallRim destructor 0x6234150
gWallRim split 0x622aaf0
gWallRim constructor 0x6231170
gWallRim constructor 0x62311e0
gWallRim destructor 0x622aaf0
gWallRim constructor 0x62313b0
gWallRim split 0x62313b0
gWallRim constructor 0x6231640
gWallRim constructor 0x62318a0
gWallRim destructor 0x62313b0
gWallRim split 0x62318a0
gWallRim constructor 0x62317f0
gWallRim constructor 0x6231910
gWallRim destructor 0x62318a0
gWallRim destructor 0x6231910
----
rim wall 0x6233860 from (44.3902, 2.5034e-06) to (88.3884, 0)
rim wall 0x6233970 from (0, 0) to (44.3902, 2.5034e-06)
rim wall 0x6233e90 from (88.3884, 22.988) to (88.3884, 88.3884)
rim wall 0x6233e20 from (88.3884, 0) to (88.3884, 22.988)
rim wall 0x62311e0 from (11.462, 88.3884) to (0, 88.3884)
rim wall 0x62342a0 from (88.3884, 88.3884) to (30.3114, 88.3884)
rim wall 0x62340e0 from (30.3114, 88.3884) to (22.8321, 88.3884)
rim wall 0x622aa80 from (22.8321, 88.3884) to (17.6777, 88.3884)
rim wall 0x6231170 from (17.6777, 88.3884) to (11.462, 88.3884)
rim wall 0x62317f0 from (4.2839e-06, 72.8) to (6.16296e-06, 65.8766)
rim wall 0x6231640 from (0, 88.3884) to (4.2839e-06, 72.8)
Edit: I just noticed I left some weird optimization setting on. I'm compiling with it off now.
Aha, we're getting closer. Notice the pattern Split-Create-Create-Destroy (With the occasional Creation before that)? The last split deviates from that: the second wall that gets created in the split is destroyed as well. That's the missing piece. Can you find out where the destroy call comes from in eGrid::DrawLine? It surely is triggered by a smart pointer going out of scope.
Except for the last destructor, my own output looks identical.
Except for the last destructor, my own output looks identical.
Innocent optimization settings often result in subtle changes in floating point calculations; that's precisely what we're looking at here. It probably is not an optimization compiler bug.
Another something you can do with debug output: trace the exit points of DrawLine. The missing segment probably is deleted at one of them, and knowing which one would help.
Another something you can do with debug output: trace the exit points of DrawLine. The missing segment probably is deleted at one of them, and knowing which one would help.
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
Very likely. Even -O1 causes the problem. Would multiply-adds be enough to make a difference?z-man wrote:Innocent optimization settings often result in subtle changes in floating point calculations; that's precisely what we're looking at here. It probably is not an optimization compiler bug.
OK.z-man wrote:Another something you can do with debug output: trace the exit points of DrawLine. The missing segment probably is deleted at one of them, and knowing which one would help.