Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » bitmap structure

This thread is locked; no one can reply to it. rss feed Print
 1   2 
bitmap structure
Thomas Fjellstrom
Member #476
June 2000
avatar

int will probablyt be 64 bit on most standard complient compilers, long is <= int, so long should probably be 32bit (I hope).

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

ReyBrujo
Moderator
January 2001
avatar

Check the thread about Allegro 5 scrapped. Evert attached a document saying that long is 64 bits, int will stay at 32 bits.

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

A J
Member #3,025
December 2002
avatar

i have read that mostly
LONG will become 64bits.
INT will be 32bits.
size_t will be 64bits.
all pointers will be 64bits.

which means some (many) of the allegro structures will change size and or need padding.

___________________________
The more you talk, the more AJ is right. - ML

Tobias Dammers
Member #2,604
August 2002
avatar

...which is not really a problem, if sizeof() is used properly. There could be some problems with bitmaps and samples, though, but I'm pretty sure this can be solved with a few #defines once the conventions are clear about what will be what.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

A J
Member #3,025
December 2002
avatar

the allegro bmp file loader will break if re-compiled on 64bit (where LONG will be 64bits).

___________________________
The more you talk, the more AJ is right. - ML

Tobias Dammers
Member #2,604
August 2002
avatar

Maybe it will; it's a sorry mess anyway and needs to be cleaned up a bit. There are even divisions in it that should really be shifts, but that aside.
If the BITMAP* structure uses types like AL_INT32 and such, and the bmp loader uses the same (instead of relying on long being 32 bits), then there is little that needs to be changed.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Evert
Member #794
November 2000
avatar

Quote:

the allegro bmp file loader will break if re-compiled on 64bit (where LONG will be 64bits).

It should be using ints rather than longs...
The definitive fix for this (C99 types) won't make it into 4.2, but I can see what I can do about replacing spurious longs with ints.

A J
Member #3,025
December 2002
avatar

if you can write an "official" guide to which types need to be changed, i will do some code auditing.

___________________________
The more you talk, the more AJ is right. - ML

Bob
Free Market Evangelist
September 2000
avatar

Quote:

Evert attached a document saying that long is 64 bits, int will stay at 32 bits.

No, long may be 64-bits and int may be 32-bits.

A perfectly conforming C implementation may have char = short = int = long = 128-bits, and long long = 256 bits.

Different 64-bit platforms use different combinations of bit sizes for the standard types. For example, Alpha uses 64-bit ints and longs. GCC on AMD64 uses 32-bit ints and 64-bit longs. MSVC on AMD64 uses 32-bit ints and 32-bit longs, for backward compatibility.

--
- Bob
[ -- All my signature links are 404 -- ]

A J
Member #3,025
December 2002
avatar

this presents a bit of a problem for allegro, as it moves to 64bits.
i compile my code with gcc and msvc. and my main CPU for the next year(s) will most likely be AMD64.
most of the allegro funcs can morph to the platform recommended types, but im conerned about the data structures in allegro that are not bit size specific... such as the win bitmap header definitions.
more care needs to be taken with defining structures.

___________________________
The more you talk, the more AJ is right. - ML

Evert
Member #794
November 2000
avatar

Basically, what needs to happen, is to find each location where Allegro uses a long int but assumes it to be 32 bit.
For now (4.2), it will do to replace those with ints.

Tobias Dammers
Member #2,604
August 2002
avatar

Quote:

this presents a bit of a problem for allegro, as it moves to 64bits.
i compile my code with gcc and msvc. and my main CPU for the next year(s) will most likely be AMD64.
most of the allegro funcs can morph to the platform recommended types, but im conerned about the data structures in allegro that are not bit size specific... such as the win bitmap header definitions.
more care needs to be taken with defining structures.

In many cases, the actual size of a variable is not really important, provided it conforms to a given minimum size. For example, makecol() always returns an int, regardless of color format, and you can happily pass ints to the drawing functions even in 8bpp. You won't use more than 8 bits, but for that matter, you could pass the same value in 32, 64, or 2048 bits.
The exact size of int variables is only important when functions rely on them, which is the case for short and long in the BITMAP structure, which expects a short to be exactly 2 bytes and a long to be exactly 4 bytes. In these places, allegro needs to be fixed, either by using C99 types, or by defining types like ALLEGRO_INT32 according to platform (which I think should be done anyway). The file i/o part of the bmp loaders are actually not really such a problem, since they use the pack_XXX() routines, which afaik load the correct number of bytes (e.g. 4 for pack_igetl()).

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

 1   2 


Go to: