Random Screenshots Thread

General Stuff about Armagetron, That doesn't belong anywhere else...
Post Reply
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

One more.
Attachments
abitoftraffic.png
ViTaL
On Lightcycle Grid
Posts: 10
Joined: Fri Sep 23, 2005 2:22 am
Location: USA
Contact:

Post by ViTaL »

How do you get all the maps on the bottom right, and the info on the bottom left? :o It's awesome!
Image
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

haxzszz
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

I posted the code, but it didn't get any further than explaining sane input values to Luke.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

TnA: that's just the new, different floor rendering code. The rip effect seems to be the same.
Jonathan: can you do a recording? The tricks that made it possible for dumbasses like myself to easily reproduce the old rip (huge rubber, high rubber speed, no mindistance) don't seem to work.
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

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:

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)
What's the first wall doing there?

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
Edit 4: Seems to happen in DrawLine, but I have no idea what it's doing.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Jonathan wrote:What's the first wall doing there?
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:Edit 2: Filtering it away fixed it.
Do I get this correct: you disabled the NULL wall drawing and the gap disappeared???
Jonathan wrote:Edit 3: A few more prints:
<snip>
Looks like a square to me.

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.
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

z-man wrote:
Jonathan wrote:Edit 2: Filtering it away fixed it.
Do I get this correct: you disabled the NULL wall drawing and the gap disappeared???
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:What is the arena size that causes this?
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: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.
Did DrawLine change after at most a week before beta1? If so, I'll have to try the new code first.

How would you compare everything in the giant function?
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Jonathan wrote:
z-man wrote:
Jonathan wrote:Edit 2: Filtering it away fixed it.
Do I get this correct: you disabled the NULL wall drawing and the gap disappeared???
I filled start's x and y with end's and returned, if the start and end were (-80, -36) and (0, 0), respectively.
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 bent :)
Jonathan wrote:
z-man wrote:What is the arena size that causes this?
See the settings of Shrunkland. It's scaled down from 500 to ~88, so the setting is -5 ~= log(sqrt(2), 88/500).
Thanks, I'll see what I can do with that.
Jonathan wrote:Did DrawLine change after at most a week before beta1? If so, I'll have to try the new code first.
No. The last relevant change to the file was the phasing bugfix on the tenth of August.
Jonathan wrote:How would you compare everything in the giant function?
Well, I'll step through it and see if any of the decisions the code makes are close ones.

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?
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

Added debug output to my map code as well. :) The final output:

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)
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.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

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.
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

z-man wrote:Can you find out where the destroy call comes from in eGrid::DrawLine?
I'll try.
Jonathan wrote:Edit: I just noticed I left some weird optimization setting on. I'm compiling with it off now.
That didn't fix it.
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

I haven't found it yet in DrawLine, but after completely turning off (what I thought was safe) optimization the missing piece appeared. I'll look into it.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

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.
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Post by Jonathan »

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.
Very likely. Even -O1 causes the problem. Would multiply-adds be enough to make a difference?
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.
OK.
Post Reply