Re: [AD] GGI patch for 3.9.21

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

Michael Bukin <M.A.Bukin@xxxxxxxxxx> writes:
> There is an idea for GFX_SAFE mode which is explained with pseudo-code:

That's an interesting proposal, but not very portable because at least on 
DOS, when I tried to do an automatic screen update with conversion using a 
timer handler, it was very unstable and kept locking the machine. I don't 
think that is quite safe enough to fit the name of the driver :-)

I suppose what we really need to decide is, exactly what should this driver 
be used for? The orignal idea was that it was just for times when your mode 
set call had failed and you wanted to pop up an error, or for times when you 
wanted to let the user choose a few options before you did the real 
initialisation. For that, I think it is ok for it to choose any color depth 
at all without emulation, because I can easily make sure that alert() and 
gfx_mode_sel() will work correctly in any depth, and as long as we are clear 
to document that this may happen, it isn't too hard to be sure you always 
use makecol() rather than fixed colors in that kind of code.

The confusing factor is that I then went off and used GFX_SAFE in lots of 
the example programs, for a slightly different meaning. Here, I was setting 
a mode that would then be used for some serious work rather than just a 
quick message, so it does cause nasty problems if I want a paletted mode but 
get truecolor. I was just using GFX_SAFE as a way to say that I didn't 
really care about the exact resolution, and that if the mode set failed, it 
should just abort the program rather than making me bother to display an 
error message.

Using zero parameters as a way to say "don't care" is appealing, but it 
loses the ability to give a hint at what mode you would like while still 
accepting other options. For example in the setup program, it is very handy 
to be able to requst a 320x200 mode as the nicest looking option, but still 
go on running if a DirectX driver is only able to provide 640x480.

As it stands, I can see two difference scenarios where you may need a fuzzy 
mode selection:

- things like the setup program, tests, etc, want to be able to hint at a 
resolution, but will still accept other options. Changing the color depth 
causes problems, though.

- things that just need to display simple errors or menu options don't 
usually care about either resolution or color depth.

We could use GFX_SAFE for both of these, with zero parameters representing 
things that you don't care at all about, but this would lose the ability to 
request a particular value while still accepting others. Or we could make 
two GFX_SAFE style drivers, with different degrees of fuzziness. Or we could 
implement a full fuzzy-select system, where you could specify prefered 
values, lists of alternatives, and range limits for all the parameters. I 
think that is overkill, though.

Personally, my vote is to make GFX_SAFE go on using the current algorithm 
when given numeric parameters, or accept anything at all when passed zeros.
I'd be tempted to use a 0,0 screen resolution as a hint that different color 
depths are acceptible, though, rather than setting a zero color depth 
directly, so that the GFX_SAFE special case processing will be handled 
entirely within a single function call.


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."