| Re: [AD] Small problem with driver removals |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Evert Glebbeek wrote:
I compiled the NES emulator that uses Allegro (it's on the depot, the name
doesn't spring to mind immedately).
FakeNES. That's what caused me to bring it up too.
> This failed to build because it was
using the GFX_DRIVER* constants explicitly to allow the user to select a
mode from the menu. I had to rip apart the code to get it to compile with
the latest version.
Same here.. which is why I consider it a bad API breakage.
However, I think this is really a design flaw in the emulator rather than
in Allegro. It also used the DGA variables as regular UNIX drivers, while
in fact they're not.
The emulator organizes the X drivers as Unix, and the Linux console
drivers as Linux. Could be done a bit better, buit that's an
orginization problem a program should be allowed to make if it wants.
If we go define all symbols of drivers that Allegro was not build with,
then shouldn't we define the DGA driver too on all flavours of UNIX?
That's pretty much what my patch does. All the X and Linux drivers are
defined in alunix.h regardless of which Unix flavor the header is being
used for.
In
fact, if we're going to do that, what's the rationale in not defining the
DIRECTX driver symbols too? They'll fail when requested, of course, but the
symbol will be there.
That's an interesting point. And honestly, one I wouldn't mind thinking
about. After all it's the preprocessor that's going to take the hit, and
the CPP is generally quite fast compared to the actual
compiling/optimizing. It won't have an impact on run-time performance or
code size.
Although the docs do say only the drivers for the target platform will
be available, don't they? I thought I read that.
For this latter reason, I've really always assumed that the driver symbols
are only defined when Allegro is build with the specific driver enabled.
Maybe we should rather document that the driver symbols are not defined if
Allegro is build without that driver than define them anyway.
I've thought about it.. but really, there's not much to think about.
4.1.15 still has the DGA1 driver, right? 4.0.3 does definitely. We
already know of one program that breaks even though it's following the
docs (in this regard, at least), so instead of asking "will programs
break?", it becomes a question of "how many programs will break?". And
it's not fair to go changing the rules after the fact because we caught
a mistake we've been making, because it's simpler to change/add a little
text to the docs than to fix the code. An API break is an API break. I
think it's reasonable to provide the defines, especially for an
environment that's so heavilly customizeable and source compilation is
the norm for distributing programs.
- Kitty Cat