[AD] First try to change GFX_SAFE fb behaviour.

[Grzegorz Adam Hankiewicz <gradha@xxxxxxxxxx>]

Hi.

With this first post, I am willing to open a can of worms, as I already
announced the 12th of August on the AML: I want to change the GFX_SAFE
behaviour (at least under Linux for the framebuffer).

I will repeat my arguments:

- When you use a framebuffer device, you _are_ in a graphic mode.
  Therefore, it doesn't have much sense to switch it. It's better to use
  it. A good example of this behaviour can be watched with fbi, a quick
  image viewer: it's fantastic to launch it and have the image
  immediately at the same resolution you are working with (for the
  interested, try a search at http://freshmeat.net).

- No need to look out for resolution settings in configure files, which
  may (and already have) change format, requiring different parsers for
  different configuration file versions, if willing to support them.

- Really nice behaviour with vesafb. As you probably know, vesafb
  disallows resolution changes. Before, Allegro programs just failed at
  set_gfx_mode. With the new behaviour they fail at color depth, but that
  will be explained below.

- That last point can be applied to any new architecture (especially rare
  embedded systems, or pdas) which may have a fixed resolution display.

All in all, it's wonderfull to use vesa fb and have most Allegro programs
working (partially).

Contras:

- It renders _all_ written code unusable: most, if not all programs, 
  expect the screen to be at 8 bpp, which makes most programs show bad  
  colours, nothing at all (ie. everything shifted towards dark blue), etc.
  Allegro's GUI functions are first to bail out.

That's the only contra I've found, but there's a way to avoid it without
breaking old code (although I would _love_ to break it).

For the moment, I am attaching the small hack which allows fb_init detect
when there was a GFX_SAFE request and act in consecuence. It _is_ a hack:
I didn't know how to make set_gfx_mode and fb_init communicate, so I added
a global variable (which may be useful later). The code doesn't do
extensive checking for the actual resolution: it may not work on anything
else than i386, or weird graphic cards (like 37bpp, for example :-).

I found the fb_init code a little bit messy, so I will rewrite it in my
next trys to get it working on anything whith /dev/fb0. The idea is to
reforce it with more video mode conditions, and take out even more fb_init
code which won't be used with GFX_SAFE.

Now here comes a good question I would like everybody to answer, because I
am biased: before I was talking about this patch breaking most programs,
in that they get the resolution but in an unexpected color depth. This can
be fixed via that global variable, just like with the color conversion
variable: it can be a bitfield, with different options, one of them being
by default GFX_SAFE_DISALLOW_COLOR_DEPTH_CHANGE.

However, I would prefer that bit to be optional, and force end-users to
write their programs in such a way that if they use GFX_SAFE, they can
cope with any color depth resolutions. IMHO that's better, but that's what
I am asking for: your opinion.

Finally, I would like to suggest this same behaviour for windows. The last
time I checked it, Allegro would try a full screen mode with GFX_SAFE.
Couldn't GFX_SAFE be a synonim of GFX_GDI? It would make more 'well
behaved' windowed games, although the speed would be horrible if the game
didn't allow changing the driver...

Please, somebody tell me if you want/will reject this change, or let me
continue it. When I posted this question long ago, I didn't recieve any
feedback :(

 Grzegorz Adam Hankiewicz   gradha@xxxxxxxxxx - http://gradha.infierno.org
 Other web pages:  http://glub.ehu.es/  -  http://welcome.to/gogosoftware/

Attachment: allegro_gfx_first_try.gz
Description: Binary data