SpritesMind.Net

Posted: **Sun Jul 22, 2012 10:10 pm**

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.

Posted: **Sun Jul 22, 2012 11:50 pm**

Stef 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.

I wonder if it's the filesystem... notice how it has the wrong size? I do

Code: Select all

    fseek(FileInput, 0, SEEK_END);
    size = ftell(FileInput);
    fseek(FileInput, 0, SEEK_SET);

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

    if (feof(FileInput)) break;

Posted: **Mon Jul 23, 2012 10:36 am**

Chilly Willy wrote:
Stef 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.
I wonder if it's the filesystem... notice how it has the wrong size? I do
Code: Select all
    fseek(FileInput, 0, SEEK_END);
    size = ftell(FileInput);
    fseek(FileInput, 0, SEEK_SET);
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
    if (feof(FileInput)) break;

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 ??
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...

Posted: **Mon Jul 23, 2012 11:56 am**

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.

Posted: **Mon Jul 23, 2012 1:24 pm**

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

Posted: **Mon Jul 23, 2012 3:29 pm**

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

Oooo - my fault. I thought I had those all as "wb"... but I see I missed both output files.

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.

Posted: **Mon Jul 23, 2012 5:06 pm**

Chilly Willy wrote:
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
Oooo - my fault. I thought I had those all as "wb"... but I see I missed both output files.

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.

Well i should have noticed it before :p
But unfortunately it wasn't that easy to understand when we deal with binary file ! Ok now it's done and it work perfectly

Posted: **Mon Jul 23, 2012 5:42 pm**

So what's next? We're getting close to having the ability to work on any platform, not just Windows.

Posted: **Mon Jul 23, 2012 6:31 pm**

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

Posted: **Mon Jul 23, 2012 8:18 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!

Posted: **Mon Jul 23, 2012 8:27 pm**

I basically just use genres for the SPRITES tag support. I export to .bmp using GraphicsGale. So if whatever new tool you guys create, that's all I'd need.

I never looked at the genres' animation support. Maybe I should.

Posted: **Mon Jul 23, 2012 9:04 pm**

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

Posted: **Mon Jul 23, 2012 9:40 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.

Posted: **Tue Jul 24, 2012 12:39 am**

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.

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:

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
};

(I don't know if bintos does the same kind of thing with bitmaps)

Image support can be whatever format. I just want it to be converted to easy-to-use types

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

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!

Posted: **Tue Jul 24, 2012 1:01 am**

It outputs data arrays where the data is

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>

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.

SpritesMind.Net

What's wrong with GCC (sgdk)? Why it crashes 10% of runs?