What's wrong with GCC (sgdk)? Why it crashes 10% of runs?
Moderator: Stef
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
That is really weird.. just to be sure i tried to get back to your original C code but still that gave me the same error.
When i use the C versions of pcmtoraw i obtain a loss file of 468 004 bytes.
With the delphi version of pcmtoraw i obtain a loss file of 459 392 bytes.
So i have some differences here but i suspect my local MingW GCC (version 3.4.5) to produce wrong code here as the source is pretty simple and i can't find any valid reason for that overflow error.
When i use the C versions of pcmtoraw i obtain a loss file of 468 004 bytes.
With the delphi version of pcmtoraw i obtain a loss file of 459 392 bytes.
So i have some differences here but i suspect my local MingW GCC (version 3.4.5) to produce wrong code here as the source is pretty simple and i can't find any valid reason for that overflow error.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
I wonder if it's the filesystem... notice how it has the wrong size? I doStef wrote:That is really weird.. just to be sure i tried to get back to your original C code but still that gave me the same error.
When i use the C versions of pcmtoraw i obtain a loss file of 468 004 bytes.
With the delphi version of pcmtoraw i obtain a loss file of 459 392 bytes.
So i have some differences here but i suspect my local MingW GCC (version 3.4.5) to produce wrong code here as the source is pretty simple and i can't find any valid reason for that overflow error.
Code: Select all
fseek(FileInput, 0, SEEK_END);
size = ftell(FileInput);
fseek(FileInput, 0, SEEK_SET);
Code: Select all
if (feof(FileInput)) break;
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
When you listen the sample, the overflow error comes right after the first big cymbal sound... also it didn't make any sense, the raw file output size with C version is 229 704 where the delphi version gives 229 696 bytes (which is exactly original file size / 2). I do not understand how the loss out file and the raw out file can be have a size ratio different from 2 ??Chilly Willy wrote:I wonder if it's the filesystem... notice how it has the wrong size? I doStef wrote:That is really weird.. just to be sure i tried to get back to your original C code but still that gave me the same error.
When i use the C versions of pcmtoraw i obtain a loss file of 468 004 bytes.
With the delphi version of pcmtoraw i obtain a loss file of 459 392 bytes.
So i have some differences here but i suspect my local MingW GCC (version 3.4.5) to produce wrong code here as the source is pretty simple and i can't find any valid reason for that overflow error.
Is the overflow occurring where it tries to read past the end of the file? Maybe you can try adding a test for eof at the end of the while loop, and break if you find eof.Code: Select all
fseek(FileInput, 0, SEEK_END); size = ftell(FileInput); fseek(FileInput, 0, SEEK_SET);
Code: Select all
if (feof(FileInput)) break;
468 004 / 2 = 234 002 which is != 229 704
There is definitely something going weird with my version of GCC :-/
The only possibility is than fputc method does not always output a single char, i'll try to investigate...
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
I updated to GCC 4.7.0... still the same error...
When i examine the loss output file and play it i do not get the overflow problem i obtain with the DPCM but the play rate seems a bit slower (normal as the sample is longer) and the quality is really bad compared to the loss file generated by delphi version. It seems that some samples are randomly added here and there, i really do not understand what happen.
When i examine the loss output file and play it i do not get the overflow problem i obtain with the DPCM but the play rate seems a bit slower (normal as the sample is longer) and the quality is really bad compared to the loss file generated by delphi version. It seems that some samples are randomly added here and there, i really do not understand what happen.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Oooo - my fault. I thought I had those all as "wb"... but I see I missed both output files.Stef wrote:Err i finally found what the problem was... It turned out that when we write '0xA' char with mingw GCC (and so under windows) it automatically add a '0xD' char. I forgot the file was by default opened in text mode.
Using fopen("", "wb") fix the problem, too bad i didn't saw it before :p
See how easy it is for a bug to creep in from such a small thing? I didn't see the "w" issue because linux doesn't translate 0xA to 0xA/0xD.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Well i should have noticed it before :pChilly Willy wrote:Oooo - my fault. I thought I had those all as "wb"... but I see I missed both output files.Stef wrote:Err i finally found what the problem was... It turned out that when we write '0xA' char with mingw GCC (and so under windows) it automatically add a '0xD' char. I forgot the file was by default opened in text mode.
Using fopen("", "wb") fix the problem, too bad i didn't saw it before :p
See how easy it is for a bug to creep in from such a small thing? I didn't see the "w" issue because linux doesn't translate 0xA to 0xA/0xD.
But unfortunately it wasn't that easy to understand when we deal with binary file ! Ok now it's done and it work perfectly
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
To support all SGDK resources type we still need sources for these tools :
WAVTORAW= $(BIN)/wavtoraw
TFMCOM= $(BIN)/tfmcom
GENRES= $(BIN)/genres
MACCER= $(BIN)/mac68k
Wavtoraw : As far i remember it comes from Shiru, source not available.
TFMCom : Shiru's tool to compress tfm data.
Genres : Kaneda's tool (http://gendev.spritesmind.net/page-genres.html), source not available.
MaccerX : Kaneda's tool (http://gendev.spritesmind.net/page-macX.html) , we have the source for this one
Others tools for debug :
NM2WCH= $(BIN)/nm2wch
ADDR2LINE=$(BIN)/addr2line
OUT2GSRC=$(BIN)/out2gsrc
nm2wch : Kaneda's tool (http://gendev.spritesmind.net/page-nm2wch.html), source not available.
out2grsc : Medarin's tool, will probably change (only for the last Gens Kmod++)
Debug tools are not mandatory. The resource tools are more important, i think we can find/get sources by asking kindly their author :p
WAVTORAW= $(BIN)/wavtoraw
TFMCOM= $(BIN)/tfmcom
GENRES= $(BIN)/genres
MACCER= $(BIN)/mac68k
Wavtoraw : As far i remember it comes from Shiru, source not available.
TFMCom : Shiru's tool to compress tfm data.
Genres : Kaneda's tool (http://gendev.spritesmind.net/page-genres.html), source not available.
MaccerX : Kaneda's tool (http://gendev.spritesmind.net/page-macX.html) , we have the source for this one
Others tools for debug :
NM2WCH= $(BIN)/nm2wch
ADDR2LINE=$(BIN)/addr2line
OUT2GSRC=$(BIN)/out2gsrc
nm2wch : Kaneda's tool (http://gendev.spritesmind.net/page-nm2wch.html), source not available.
out2grsc : Medarin's tool, will probably change (only for the last Gens Kmod++)
Debug tools are not mandatory. The resource tools are more important, i think we can find/get sources by asking kindly their author :p
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Which ones are actually USED? Looking at genres, it's for supporting old tools. Maybe we should support something newer and cross platform, like tiled for maps. I'm sure there's also something for sprites, even if it's just a bmp/gif/anigif converter to use on files saved from GIMP. BMPs are easy, and I made an anigif player for the PSP, so I'm sure I could make an anigif converter.
If wavtoraw just converts a WAV to a 8-bit signed sample raw file, that's super easy to do from scratch. Do we need to compress TFMs? TFM is an obsolete format according to Shiru, so maybe that's another thing to consider moving away from. Perhaps something like Echo would be better to support.
The only ones from the list it looks like we NEED are MACCER, and that has source like you mention, and wavtoraw, which should be easy enough to do from scratch. Then toss in a BMP/ANIGIF converter and Bob's your uncle!
If wavtoraw just converts a WAV to a 8-bit signed sample raw file, that's super easy to do from scratch. Do we need to compress TFMs? TFM is an obsolete format according to Shiru, so maybe that's another thing to consider moving away from. Perhaps something like Echo would be better to support.
The only ones from the list it looks like we NEED are MACCER, and that has source like you mention, and wavtoraw, which should be easy enough to do from scratch. Then toss in a BMP/ANIGIF converter and Bob's your uncle!
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
To be honest myself i do not use them a lot, i already used genres though... Also i use a lot the bmp converter and sound tools for Z80 drivers.
But as djcouchycouch i am open to any new / better tools, i would love to have a complete toolbox which permit graphics / level /animation design as well as music / SFX composition For sound Echo is one of the most advanced sound library available for homebrew development (in the way it support both music and SFX play) but still the workflow seems a bit complex as djcouchycouch experienced it
But as djcouchycouch i am open to any new / better tools, i would love to have a complete toolbox which permit graphics / level /animation design as well as music / SFX composition For sound Echo is one of the most advanced sound library available for homebrew development (in the way it support both music and SFX play) but still the workflow seems a bit complex as djcouchycouch experienced it
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
It was a problem mainly because there was a bug in where it could play files from. That's been fixed. The music requires a couple steps to convert, but that's true about almost anything new. Otherwise, he just made a couple changes to the default make files.
Uh... the bintos tool already handles BMP format. It handles the resolution, palette, and bitmap. If more is needed, we could probably just add a switch to that. Or maybe, if you include more than one BMP filename, it could combine them into one output... maybe one palette if they're the same.
Uh... the bintos tool already handles BMP format. It handles the resolution, palette, and bitmap. If more is needed, we could probably just add a switch to that. Or maybe, if you include more than one BMP filename, it could combine them into one output... maybe one palette if they're the same.
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
It's not really the BMP support that I'm interested in, it's the fact that genres takes it and spits out the data into a handy dandy struct:Chilly Willy wrote:Uh... the bintos tool already handles BMP format. It handles the resolution, palette, and bitmap. If more is needed, we could probably just add a switch to that. Or maybe, if you include more than one BMP filename, it could combine them into one output... maybe one palette if they're the same.
Code: Select all
//SPRITES
struct genresSprites
{
u16 *pal; //pointer to pal data
u32 **sprites; //pointer to sprites data
u16 count; //nb sprites
u16 width; //width of each sprite in pixels
u16 height; //height of each sprite in pixels
u16 size; //since we use width/height in pixel, useful info on sprite size
//TODO : size is not SGDK compliant, you need to use size>>8
};
Image support can be whatever format. I just want it to be converted to easy-to-use types
If anybody updates genres to add support for converting VGM MM songs directly into echo compatible data then I will become their bestest best friend forever!Stef wrote: For sound Echo is one of the most advanced sound library available for homebrew development (in the way it support both music and SFX play) but still the workflow seems a bit complex as djcouchycouch experienced it
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
It outputs data arrays where the data is
It looks like the struct genres outputs is geared towards linked lists of sprites. bintos clearly just gives you the data you need for that particular bmp.
Code: Select all
bitmap_name:
dc.w width, height
dc.w <16 words that hold the palette>
dc.w <as many words as needed to hold the bitmap data>