Re: [AD] split_modex_screen

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Saturday 22 January 2005 05:11, Chris wrote:
> Not all Windows systems will have DirectX though, which would put 
> GFX_DIRECTX in the same boat as GFX_DGA if DGA isn't present. The 
> difference is, there's no way to do a configure check to disable 
> GFX_DIRECTX on Windows (so all Windows drivers are available to use on 
> Windows), so why shouldn't Unix behave the same?

Well, just because Windows is broken doesn't mean that we have to pretend 
UNIX is, does it? ;)
Besides, there's a difference: UNIX systems that don't have DGA don't have 
the runtime nor the linker libraries for it - that's a homogeneous whole. 
In Windows, you can have the DirectX development library  but not the 
runtime library. Even if DirectX is not installed on the target system, 
Allegro could still use it if it were present because Allegro's driver is 
present. The same is not true of a UNIX system, since the code for the 
driver isn't build there at all.

> Also, there's something else you need to consider, with Allegro 
> Unix/Linux binaries. If the person compiling the binary doesn't have 
> GFX_DGA capabilities, then that binary will never work with DGA, even if 
> the end-user's library can handle it.

I know, I mentioned this.

> I would say the opposite. If GFX_DGA is a Unix driver, it should always 
> be available in Unix..

Well, there are probably more UNICES out there that don't have the GFX_DGA 
extension than there are that do...

> and there was nothing mentioning it may not be 
> defined.

As I said, this seems somewhat the normal behavior to me. You don't expect 
GFX_DIRECTX to be defined on UNIX because it's not a driver that's 
available on the system. Ok, so that one never is, while GFX_DGA might be. 
The principle is still the same.
I also have the feeling that this is the normal behavior for a UNIX 
library, but here I could be way off.

> But again, this part of the API was never clarrified, so who's to say 
> which code is wrong?

Well, I'd say that Allegro's examples and the code in the library itself is 
right in a case like this.

> The docs never said drivers will always be, or may 
> not be, defined.. and with such an ambiguity, 

As I said, there's not much of an ambiguity in my opinion. And we could 
have opted to make the docs more clear in that case.

> we should follow what the 
> other platforms do (define the drivers even if they're not available).

Other platforms don't define the driver names for drivers that aren't 
compiled into the library. Mostly because you don't have the option to 
disable certain drivers at compile time easily.
What bugs me about always having the driver identifier is not that the 
driver will not work when it is tried, but that it isn't even there! The 
next logical step in this line of reasoning would be to always define 
GFX_DIRECTX too, since the docs aren't too clear on that being undefined 
either.

Anyway, I have a feeling that neither of us is going to convince the 
other... ;)
I think this sounded like a good idea at the time, but I really think it 
wasn't such a great thing to do afterall.

> Besides, AFAIK split_modex_screen is the only public function that'll 
> disappear if the platform doesn't support a specific GFX driver (which I 
> think was a bigger error to begin with). But my patch should've also 
> fixed that by defining a dummy function of that that does nothing if the 
> platform supports Mode-X, but is otherwise unavailable (so if GFX_MODEX 
> is defined, even if unuseable, split_modex_screen will still be present).

In that case, I think we should rename it to split_screen(), as it's 
effectively a driver neutral function in that case.

Evert