[Fixed] [ARM] ZDBSP builds incorrect nodes on ARM

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

[ARM] ZDBSP builds incorrect nodes on ARM

Postby Csonicgo » Thu May 07, 2015 2:26 pm

This is a split from this thread , even though they are related.

ZDBSP was compiled using GCC 4.8, and E1M1 of DTWID was rebuilt using ZDBSP and exported to a separate WAD.

The link below is the ZDBSP-built E1M1 . If you walk to the right, the wall warps and stretches into a total mess. If anyone can rebuild E1M1 of this and compare the output, that would be greatly appreciated.

The reason for the 2 MB download is that ZDBSP has no options for exporting single maps (that I can find, anyway). Because of this, I obtained Esselfortium's permission to upload. I feel that this is fair use according to US law to diagnose a problem, and does not violate copyright.


http://speedy.sh/b3qYE/ZDBSP.WAD.zip
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Csonicgo » Tue May 12, 2015 10:40 pm

Also, wow, this apparently crashes ZDoom! Can anyone help test this?
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Gez » Sun May 17, 2015 9:46 am

To test that modified map on a non-ARM ZDoom, first, turn off textured automap before starting a new game.

I did not manage to get a crash, but there were plenty of visual glitches.
Gez
 
 
 
Joined: 06 Jul 2007

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Csonicgo » Mon May 18, 2015 1:58 pm

Thanks for confirming that it glitches out.
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Graf Zahl » Mon May 18, 2015 2:46 pm

Since nobody here owns affected hardware you'll have to find the cause yourself.

The best start would be to enable debug output by changing this:

Code: Select allExpand view
#if 0
#define D(x) x
#else
#define D(x) do{}while(0)
#endif


to #if 1

I suspect floating point math precision issues with the CPU.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Csonicgo » Mon May 18, 2015 3:20 pm

I just did that. Here is the output.
Attachments
stdout.txt.7z
debug output of E1M1 of DTWID.WAD
(83.57 KiB) Downloaded 52 times
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Graf Zahl » Mon May 18, 2015 3:34 pm

Hm, ok, that was useless, unfortunately that output truncates all fractional parts, making the output pretty worthless for checking precision issues.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Csonicgo » Mon May 18, 2015 3:58 pm

Graf Zahl wrote:Hm, ok, that was useless, unfortunately that output truncates all fractional parts, making the output pretty worthless for checking precision issues.


Quick question, are ANY casts being done through xs_Float.h ?
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Graf Zahl » Mon May 18, 2015 4:06 pm

That file is only used in the UDMF reader and was only added to avoid changing that code from how it appears in ZDoom.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Csonicgo » Tue May 19, 2015 1:24 pm

Here is a test file with five custom maps containing very simple structures. E1M1-E1M5. GLBSP found no warnings.

TEST1.WAD is the GLBSP version.
ZDBSP2.WAD is the ZDBSP version.
The debug output for ZDBSP is also included.
Attachments
ZDBSP2.7z
5 custom maps
(15.09 KiB) Downloaded 47 times
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby ibm5155 » Tue Jun 09, 2015 8:59 am

ehm, isn't better just to make a simple c program for detecting if there's some floaiting point iuse?
arms aren't that great with float, and some of them doesn't even have the float part (it's all fixed point), or it supports a low number of houses afert the ','/'.'
User avatar
ibm5155
Just Spooky
 
Joined: 20 Jul 2011

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Csonicgo » Wed Jun 10, 2015 10:27 am

ibm5155 wrote:ehm, isn't better just to make a simple c program for detecting if there's some floaiting point iuse?
arms aren't that great with float, and some of them doesn't even have the float part (it's all fixed point), or it supports a low number of houses afert the ','/'.'


I decided to do that just now and the ARMv6 and ARMv7 variants of the Raspberry Pi pass all tests. Whatever is going on, it's not floating point.
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Csonicgo » Mon Jul 13, 2015 11:03 am

A little update on a similar issue to this:

Quasar and I ran into an issue with Vela Pax concerning its ZDoom uncompressed nodes. Turns out, on ARMv7 devices, casting a double to a int (or int-like, like fixed_t) will give you undefined behaviour unless you specify precisely what signedness of said type you're casting to.

So for example, in R_PointToAngle2, the return function was originally:

Code: Select allExpand view
return angle_t(atan2(double(y), x) * (ANG180/M_PI));


instead of:

Code: Select allExpand view
return angle_t(int(atan2(double(y), x) * (ANG180/M_PI)));


When this was corrected, Vela Pax played properly.

Did you get that yet? Instead of giving the value of angle_t as expected, GCC and Clang both decide to punish the unclean casting code, and output 0. This resulted in all overflowing sections of the nodes (so basically facing the bottom angles of the map) to be drawn backwards or not at all, leaving large sections of the map invisible. This never pops up in x86 compiles because, for some reason, ints are always assumed to be signed there.


User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Graf Zahl » Mon Jul 13, 2015 12:22 pm

That sounds like a compiler bug to me. Even fixed_t and angle_t have defined signedness (i.e. fixed_t is signed and angle_t is unsigned)
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [ARM] ZDBSP builds incorrect nodes on ARM

Postby Blzut3 » Mon Jul 13, 2015 4:16 pm

Converting a double to fixed_t (aka int32_t) should be just as defined as converting a double to int. If that doesn't work I would indeed call it a compiler bug.

Converting a double to unsigned, like angle_t is a different issue. If it's giving negative floating point values then I suppose I can see how that would be undefined if the intermediate signed cast is not present (I think you shared a link with me in IRC before? It's in my history anyway). In this case ARM seems to be clamping values to be in the range of valid unsigned int values and x86 doesn't.
Blzut3
Pronounced: B-l-zut
 
 
 
Joined: 24 Nov 2004

Next

Return to Closed Bugs

Who is online

Users browsing this forum: DotBot and 0 guests