Exploding Balcony

[andwhyisit]

This bug only happens in the PAL build when you exit and enter the prefab building repeatedly.

Obligatory gif: http://andwhyisit.bugsiteguardian.com/csmd/explodingbalcony_zpsg5k6ifvs.gif

The NTSC build on the other hand settles on 102: http://andwhyisit.bugsiteguardian.com/csmd/102edbalcony_zpssawd7yf1.gif

[andwn]

andwn@gendev:~/cave-story-md$ /opt/toolchains/gen/m68k-elf/bin/m68k-elf-gcc -dumpversion
6.3.0

[andwn]

If the GCC version is different there could be differences in the way -O2 and -O3 optimization is handled.

Probably something to do with the various XGM_doVBlankProcess() I tossed into the stage load so you don't have to hear the music freeze during map load.

[andwhyisit]

Lets compile gcc 6.3 from source on centos then.

Hmm.. some 8gb of space is required before I can remove the source and build files? Better get economical with space.

3 hours later...

Not enough memory? A swap file it is.

Alright, lets start the build process.

Hmm.. this is taking a long time...

2 hours later (2am in the morning)...

Fuck this, I'm going to bed and hoping that the server hasn't run out of disk space by the morning.

5 hours later...

Cpu 99% Memory exhausted Swap 20% used Only half done

Why is this still going?

[andwn]

Gendev is great isn't it? I'll make a tarball of it you can just extract to /opt/toolchains/gen. 32 or 64 bit? I do have a 32 bit one in the fork's releases tab but maybe better to remake it just in case.

While I have been experimenting with a different toolchain for future projects (vbcc/vasm/vlink -- these compile in under a minute) there is likely a lot of stuff in CSMD that depends on features only in the GNU toolchain.

[andwn]

I checked and that 32 bit one is up to date for the parts I use. Building a 64 bit one now it'll be done in time for Christmas.

[andwhyisit]

Compiling gendev was blisteringly fast compared to compiling gcc from source (and compiling gendev took hours).

I'm talking about compiling gcc, not gendev mind you.

It is a 64-bit system last I checked.

Centos systems only officially support gcc versions up to 4.x. I couldn't use a software repository to install gcc 6.3.

[andwn]

OH. THAT. Sorry to put you on a wild goose chase there. The native GCC will take forever since it builds for almost every supported language like c++, java, ada, fortran etc. And that would just be to build tools like rescomp and xgmtool (...and Gendev too I guess). If you have to build the whole thing yourself don't worry about it. I can still send you a build of all the tools built with native 6.3 just in case, but if the Gendev GCC is already 6.3 then... what the hell? We've eliminated every other possible difference.

Watch it be because one of the tools is bugged on 64 bit. I'm gonna... try that now.

[andwn]

Well Balcony isn't exploding when I build it on 64 bit.

One day this mystery will be solved and I will feel more stupid than ever.

[andwhyisit]

Well gcc is now 6.3. My disk usage was 98% before I cleaned out the source and build directories, and after that it was 62%. That was waay too close.

Evidence: [root@cavestory ~]# gcc --version gcc (GCC) 6.3.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[root@cavestory ~]# g++ --version g++ (GCC) 6.3.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[root@cavestory ~]# which gcc /usr/local/bin/gcc [root@cavestory ~]# which g++ /usr/local/bin/g++ [root@cavestory ~]#

I force rebuilt the nightly and it still exhibits the issue.

Oh and: [root@cavestory /]# /opt/toolchains/gen/m68k-elf/bin/m68k-elf-gcc -dumpversion 6.3.0

And: [root@cavestory /]# arch x86_64

[andwhyisit]

Is it maybe my version of python or java?

[root@cavestory /]# python --version Python 2.6.6 [root@cavestory /]# java -version java version "1.7.0_121" OpenJDK Runtime Environment (rhel-2.6.8.1.el6_8-x86_64 u121-b00) OpenJDK 64-Bit Server VM (build 24.121-b00, mixed mode)

I tested in Fusion and it is happening there as well.

[andwhyisit]

Here's my output in animated gif form if it helps any: http://andwhyisit.bugsiteguardian.com/csmd/nightlybuild_zpszhrzu3ph.gif

This is from generating the nightly, so the second half of the output is "make pal".

Before both "make" and "make pal" my bash script does this: cd / /bin/rm -rf /cave-story-md 2>/dev/null git clone https://github.com/andwn/cave-story-md.git

..which means I start from a clean slate for both builds (2>/dev/null is just error suppression if the cave-story-md directory didn't exist at the time).

[andwhyisit]

And in case this is important: [root@cavestory /]# yum info texinfo (...) Installed Packages Name : texinfo Arch : x86_64 Version : 4.13a Release : 8.el6 Size : 2.0 M Repo : installed From repo : base (...)

[andwn]

Java is just for the lz4w compression. I'll disable it temporarily and see what happens tomorrow (unless it makes the ROM too big).

[andwn]

And even downgrading Java it isn't happening... though disabling the compression speeds up the build and the whole game still fits so I'll leave it that way for now.

Python is just to generate ai_gen.h so I didn't have to manage a header for all the AI functions manually. If nothing complains about that header there isn't any problem.

If it still happens tomorrow I'll comment all the audio code in stage load. That'll make the music freeze between rooms again but oh well.