1

I am learning to use the allegro library right now and when using the set_gfx_mode function if I use GFX_AUTODETECT_FULLSCREEN for the first argument the window will go fullscreen when running the compiled application, but after about the first second of running, all the colors change. Using any other graphics mode this doesn't happen, but on two separate machines the colors change just after changing to fullscreen mode. Has anybody else seen this happen before? I can't find any discussion on this problem at all.

I am using the pre-compiled allegro 4.4.2 library for visual studio 2010 and running windows 7.

Alex
  • 671
  • 3
  • 11
  • 25

1 Answers1

2

Allegro 4 is old and uses APIs that are no longer very well supported by modern operating systems. The full screen mode is going to be buggy, especially on 8-bit graphics. The best way to get a reliable full screen is to honor the user's current desktop settings:

int w, h;
get_desktop_resolution(&w, &h);

set_color_depth(desktop_color_depth());
set_gfx_mode(GFX_AUTODETECT_FULLSCREEN, w, h, 0, 0);

Then your application will need to center/scale the drawing. It's not really that difficult, just draw everything to an intermediate buffer that is the width/height of your native game, and then stretch blit it to the appropriate screen size.

All that said, you should really be learning Allegro 5 as it is designed to work on today's hardware and operating systems, including iOS and Android.

Matthew
  • 47,584
  • 11
  • 86
  • 98
  • I had a feeling it was probably a compatibility issue between windows 7 and the older versions of allegro, which is why I mentioned that in the original post. I did a test using set_color_depth as you suggested and the results are a little strange. I used makecol(255,0,0) as well as (0,255,0) and (0,0,255) to test plain red green and blue while trying to solve this issue earlier, and those colors seem to show up fine with a color depth of 32, but all the premade colors (i.e. colors 0-15) are turning pure black, to the point I can barely see them. Not sure what to make of that. – Alex Sep 19 '12 at 04:30
  • 1
    @Alex, not sure what you mean by "pre-made" colors. In 15/16/24/32 bit mode, you *must* use `makecol()` to get the proper constant for the current video card. This must be done after setting the graphics mode. The constants cannot be hard coded or preset, because it depends on the drivers and how it encodes pixel colors. (And 8-bit mode is known to not work very well except using the GFX_GDI windowed driver.) – Matthew Sep 19 '12 at 04:35
  • Okay, that makes sense. When I say premade color I mean the colors that you can use a constant for when you use pretty much any function that has an `int color` perameter, 0 being black and 15 being white, and various colors being assigned to 1-14. 8 bit colors do seem to be causing the issue, though. When I assign a windowed program to 32 bit, it looks exactly the same whether it is windowed or fullscreen, so this fixes my problem. I am just going to have to use makecol from now on. – Alex Sep 19 '12 at 04:47
  • Those colors (15=white, etc) only work in 8-bit modes because it uses an indexed palette. On Windows 7, the palette becomes corrupted in full screen, hence the loss of colors. – Matthew Sep 19 '12 at 13:57