Re: [AD] updated todo list and more

[Angelo Mottola <a.mottola@xxxxxxxxxx>]

> > 1) A function to get a list of supported video modes (Emmanuel Anne
> > suggested this a while ago, and I find it a very useful addition) for the
> > driver. If driver is windowed, the function pointer in the gfx driver
> > structure could be NULL, telling Allegro the driver is infact windowed
> > and thus it handles any resolution.
>
> But it doesn't: let's say I have a 640x480 screen and the application
> requests a 800x600 presuming the windowed driver handles it. In fact, it
> will handle it, but I won't be happy with that screen size.

Of course having a list of supported video modes can't be applied to windowed 
drivers. What I am suggesting is that all the fullscreen drivers have a not 
null pointer to a function that returns the modes list, so that users can 
call it and get a reasonable list of supported video modes. If a windowed 
mode is queried for supported resolutions, it should at least return a list 
of common modes, such as 320x200, 320x240 up to 640x480 and xga resolutions. 
But this should be considered as a list of *suggested* video modes: as you're 
handling a windowed gfx driver, you should be aware that any resolution is 
available to it, also resolutions higher than the current desktop one. A 
possible wiser solution to the problem could be to make our enum_gfx_modes() 
function to get the current desktop size (if appliable) and if a windowed 
driver is queried, to return only common modes lower that the desktop 
resolution.

> IIRC the proposal about a "supported list of video modes" has not been
> done before because there are drivers which simply don't know the
> available video modes until you try to set them and fail, being DOS the
> most notorious example of this (or as somebody pointed out lately, his
> DirectX says 320x200 is available, but Allegro is unable to set that
> resolution, for some unknown reason).

Very true. But there are other environments in which such a function could be 
very useful: DGA under Linux is my first thought, but also Windows and BeOS 
could benefit from it.
I understand we can't make it 100% reliable, but we could still make it and 
warn users about the possibility to get modes listed that aren't actually 
supported by the hardware.

The first usage of the function that comes to my mind is inside 
gfx_mode_select()... Imagine it to update the list of available modes as you 
select a different gfx driver.

> Instead, I would like to propose another thing: the setup program could
> have a "try all possible resolutions" button which would generate a
> supported video modes list in the appropiate specific or global
> allegro.cfg file for the user. Even with this, you are still not getting
> all possible combinations (I know people requesting things like 700x500
> even when they know it's only possible in a windowed mode), but possibly
> quite close.

Humm, I don't think having a database is a good idea. Think about this: when 
a developer makes a game, he has two possibilities to enable the database to 
the user: to ship the db file with the game (but then it probably differs 
from the available modes on the client machine) or to ship setup with the 
game. Both solutions are forced, and I don't think they're the way to go.

> BTW, if this can be supported with the new unified graphic architecture
> planned on the todo file, just say how.

That has nothing to do with the available modes enumeration. The planned 
modification is only about windowed drivers, to make them use a common API 
interface which should enable window updating with automatic color 
conversion, using the same code under all the ports. This should include the 
Win32, X and BeOS windowed drivers, and possibly also a future Mac one; 
currently they all use private code to update windows and do color 
conversion, and it's a waste of space and time, as everytime the coder has to 
reinvent the wheel. What we talked about sometime ago was just to unify the 
underlying code shared by these drivers.

> > [window resizing]
>
> How could a game handle this? Usually most of them set their graphic
> routines to work with a fixed screen size. Would Allegro rescale the
> screen automatically? What practical use does this have?

As Laurence Winthers already pointed out, the window resizing hook should be 
NULL by default; I suggested it just for completeness, and also because 
nothing excludes it may be used in future Allegro releases.
What is really important for me is the window closing hook: it's a shame that 
Allegro programs still don't handle window closing! Under X when you close 
the window you get a broken pipe message, and under BeOS when you click on 
the window closing button it doesn't even work... Don't know about Windows, 
but I assume a similar behaviour.

-- 
Angelo Mottola
a.mottola@xxxxxxxxxx
ICQ UIN #66972680