Not a real problem, but I was just wondering about the following when I was programming some stuff in Allegro: Let's say I want to define a 32-bit colour that can be used globally (say, red); I'd put the following code in some global header: and include it in the main source file. The weird thing is now, is when I want to use this colour to output some text on the screen using textprintf_ex: the text appears in blue! After trying some random RGB-values, I noticed that Allegro swaps the Red and Blue component: makecol32(0, 0, 100) would show up as dark red. However, the colours do appear right when the they're defined inside the main loop. Thinking this was some kind of odd bug, I browsed the Allegro manual and found that prior to using any makecol<colour depth>() routines, set_gfx_mode() must be called. Thus I was curious about the following: why does Allegro need to 'know' the current colour depth of the screen in order to generate appropriate colours, when you already specify what colour depth you are using by calling the appropriate function (e.g. makecol8, makecol24)? Just wondering...

Allegro's makecol differs in behaviour depending on the current (global) colour depth.

You have to use makecoln where n is your colour depth, if you're working with memory bitmaps of a different colour depth from your screen.

makecol might also be affected by palette in indexed modes (not truecolour though)

Just bear it in mind.

set_gfx_mode does NOT need to be called before calling makecol() I don't think. But you have to have initialised allegro. You can initialise allegro with SYSTEM_NONE (this is documented).

Using SYSTEM_NONE, all the Allegro graphics etc, functions should work, but you can only have memory bitmaps - it's intended for non-interactive programs like data packers, sprite manipulation etc.

Mark

Quote:

Original post by markr Allegro's makecol differs in behaviour depending on the current (global) colour depth. You have to use makecoln where n is your colour depth, if you're working with memory bitmaps of a different colour depth from your screen. makecol might also be affected by palette in indexed modes (not truecolour though) Just bear it in mind. set_gfx_mode does NOT need to be called before calling makecol() I don't think. But you have to have initialised allegro. You can initialise allegro with SYSTEM_NONE (this is documented). Using SYSTEM_NONE, all the Allegro graphics etc, functions should work, but you can only have memory bitmaps - it's intended for non-interactive programs like data packers, sprite manipulation etc. Mark

I am using the appropriate makecol<colour depth>() functions, so that can't be the problem. Also, using SYSTEM_NONE is not really an option, since my program is all BUT non-interactive. [grin]

I guess, as pointed out by the anonymous poster, it should've something to do with the way of storing RGB-values, for that's the only reason I can think of.

If your going to make a constant allegro color value, this is one of the few times I would suggest using #define. See, if you use const, it calls makecol before set_gfx_mode, so you can't declare it globally. However, if you use #define, it will call makecol everytime the constant color is referenced, therefore you can declare it globally with no problem.

Ah, thanks! #define it is, then.

Quote:

Original post by Harry de Man I guess, as pointed out by the anonymous poster, it should've something to do with the way of storing RGB-values, for that's the only reason I can think of.

Yup, that's it. I've had this cute little problem myself. [smile]