Re: [AD] dat2c ready for testing

[Laurence Withers <lwithers@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For those who don't want to read the whole message, please redownload 
and play with it. It is available at:
  http://www.lwithers.demon.co.uk/dat2c/
as dat2c.tar.gz and dat2c.tar.bz2 . Thanks.

Also, a quick request for help: what the hell are trigraphs, and why is 
gcc complaining about finding them in the middle of string constants?

On Friday 16 August 2002 22:04, Eric Botcazou wrote:
> This version is for the 4.0.x series. I've attached a patch for using
> with the current CVS code.

Thank you, patch applied. But I'm afraid I don't understand the changes:
1/. Why do we cast the color depth to (GFX_VTABLE*), rather than use
    a graphics vtable?
2/. Why do we write a color font flag, rather than a font vtable?

or are these changes related to your recent bugfix for dat2s?

> You must define ALLEGRO_USE_CONSOLE before including <allegro.h>

OK, done.

> It doesn't compile with Mingw32 because you declare:
>     extern int _compile_sprites;
> which is an Allegro internal symbol. You can't do that, because DLL
> symbols are prefixed. Include <allegro/internal/aintern.h> instead.

OK, done.

> The program rejects the '-U' option because of a pasto.

Sigh. Fixed.

> The default output on DOS/Windows uses '\r\r\n' as the line
> delimiter, making it unviewable with an editor. You must pass '-U' to
> get the correct '\r\n' delimiter. More generally, you don't have to
> handle the line delimiter at all: since the output is a text file,
> the libc takes care of it for you.

Doh! I forgot to open the text files in binary mode. The reasoning 
behind the options to output in other formats is simple: when I used 
DJGPP, DOS line endings annoyed me - the DJGPP tools (and fed :-) ) all 
handle Unix line endings fine, and of course the DOS line endings look 
messy on Unix systems. So I always made my programs handle Unix line 
endings. This is just a logical extension of that, although if you 
think it is too much then I can remove it.

[snip - fixup datafile]
> On platforms that support constructors, there is no need to call
> fixup_datafile() for 8-bit BITMAPS and 8-bit RLE sprites. But this is
> required for hi- and truecolor BITMAPs and RLE sprites. Moreover,
> since you don't support constructors at all, calling fixup_datafile()
> would be mandatory in the 4.1.x series.

OK, the issue here was that the demo crashed when drawing a BITMAP with 
blit (although not with scaled_blit) if I didn't call fixup_datafile(). 
The bitmap was 8-bit. This could have been a coding mistake on my part. 
Also, the patch you gave me changed some things in the bitmap 
structure, so I will test again.

Also: should we support constructors? I almost went ahead and did this, 
but given that portable code will have to call fixup_datafile() anyway, 
to handle non-constructor platforms, I decided not to. This way, nobody 
can 'forget' the call. What does everybody think?

> I think you should make it more compatible with dat2s, so that both
> are interchangeable for generating the compiled datafile of the setup
> program. This would involve:
> - getting rid of the '-d' option,
> - changing the '-c' option into '-o',

I think the letters are more logical and easy to remember the way they 
are, but if you feel strongly then I will change this.

> - making both '-o' and '-h' not required,

OK, done.

> - using 'data' as the default suffix,

Sorry, what do you mean? Do you mean the actual object names? (If dat2c 
currently outputs 'RLE_SPRITE obj_name' then should it output 
'RLE_SPRITE obj_name_data' instead?).

> - adding a constructor on platforms that support them.

See above point.

> Otherwise, great work! It works flawlessly for the setup program,
> both with DJGPP and Mingw32.

Great, thanks for testing. I'll work on it a little bit, tidying a few 
things up, and then hopefully it will be ready for merging with 
Allegro.

Quick note on my plans: I will merge the three source files into one, to 
better fit with Allegro. It is only in three parts because I like using 
small, multiple source files. (If I had written the grabber, it would 
be in at least 15 different files!). Also, I hope to be able to add a 
plugin to the grabber that uses the same code to allow exporting to .c 
and .h actually inside the grabber.

Bye for now,
- -- 
Laurence Withers,  lwithers@xxxxxxxxxx
(GnuPG 04A646EA) http://www.lwithers.demon.co.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9XaXlUdhclgSmRuoRAjymAJ4xZUZIXllfDtgPG673Et42eXvJDQCdFSjJ
YOqAOdXoP02azQkdSba5KhQ=
=0ulz
-----END PGP SIGNATURE-----