Mail Archives: djgpp/1998/04/29/11:56:50
Eli Zaretskii writes:
> Personally, I think X emulation should *not* use Allegro as its
> underlying engine. IMHO, Allegro messes with the hardware too
> much, and this has some annoying implications in some cases.
> Programs which use Allegro will not work on some platforms
> supported by DJGPP; even on Windows 95 they sometimes are in
> conflict with the OS. This is IMHO a bad thing for a
> general-purpose library such as Xlib.
Without wishing to get into a GRX vs. Allegro debate, I don't think
you are being totally fair to Allegro here! Bearing in mind that
a) I'm not all that familiar with GRX, and b) I am naturally somewhat
biased here, there are a few things that I'd like to point out...
Sure, Allegro does a lot of direct hardware twiddling, but most of
this would not be needed for an Xlib implementation. In this context
the important bits are the graphics and mouse routines, and I don't
think that these are any less reliable than the GRX code.
You mentioned that it might be possible to simply call the int 0x33
polling functions to read mouse input, but most mouse drivers cannot
display a pointers in SVGA graphics modes: this means that a custom
handler is necessary if you want the pointer to be updated in the
background.
In terms of portability to different operating systems, Allegro
programs have been reported to run correctly under OS/2 and DOSEMU.
NT performance seems to be extremely variable: some people say that
it just crashes, others that it works fine. The usual situtation
seems to be that it only works in standard VGA modes, but this is
the case for all DOS programs and not just Allegro.
As far as win95 conflicts are concerned, the only things that I am
aware of are occassional problems with the video drivers not
correctly saving and restoring the screen state when you tab away
from the DOS session. Fortunately this trouble seems to be quite
rare, and in any case it is caused by the win95 drivers, so I would
be very surprised if other DOS code did not have the same problems.
By far the most common problem which can prevent Allegro from working
is the poor quality of many VESA implementations. I don't have any
detailed experience with the GRX VESA code, so I can't make a proper
comparison, but I've done everything I can think of to make the
Allegro routines as bulletproof as possible. Overall, I don't think
that Allegro does too bad a job of working around broken video
drivers, but it is a sad truth that some VESA drivers just don't
work properly. I have no idea what can be done about this: it seems
to be a fact of life where PC graphics coding is concerned...
IMHO there is very little to choose between the two libs in terms
of reliability. From my point of view, the more important factors
affecting suitability for such a project are:
- GRX supports 16 color resolutions, which Allegro does not.
Personally I find it very hard to care about this, but some people
might consider it to be important.
- GRX supports high level drawing primitives like dotted lines and
thick pen styles, which Allegro does not.
- Allegro is usually slightly faster than GRX.
- In the recent WIP versions, Allegro can use VBE/AF drivers to
access hardware accelerated drawing functions, giving big
performance boosts over any software drawing code.
> But since I'm not volunteering either, this is not my decision.
Of course. If/when someone decides to do some work on an Xlib wrapper
(and I agree with you that it would be a very useful thing to have),
this must be their decision to make.
Shawn Hargreaves.
- Raw text -