Message-ID: From: Shawn Hargreaves To: djgpp AT delorie DOT com Cc: Eli Zaretskii Subject: Re: [Q] is xlib.h available to build GLUT for MESA with DJGPP und er DOS? Date: Wed, 29 Apr 1998 16:54:43 +0100 MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk 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.