Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE301549F83@probe-2.acclaim-euro.net>
From: Shawn Hargreaves <ShawnH AT Probe DOT co DOT uk>
To: djgpp AT delorie DOT com
Subject: Re: OpenGL, DJGPP, and Allegro
Date: Tue, 3 Aug 1999 10:57:19 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Reply-To: djgpp AT delorie DOT com

RaniNmich writes:
> I have opengl95.exe

That's a Windows OpenGL implementation, so you need to be making a
Windows program if you want to use it. You can probably do this with
RSXNT.

If you want to use OpenGL in DOS, get the free MESA implementation
from www.mesa3d.org. This has at various points been usable with
djgpp, but I have a feeling that the current version has some
problems due to lack of anyone maintaining it. There are no particular
reasons why it would be difficult to fix, though, given somebody 
who was motivated to do this.

The DOS version of MESA won't give you any hardware acceleration,
but it does have support for some 3d chipsets on other platforms,
particular for 3Dfx cards using the Glide libs, so this is also
doable given someone with the time and motivation to work on it.

> And while I'm at it, can Allegro be used with OpenGL?  If so, how?

You can use MESA software rendering to draw onto Allegro bitmap
surfaces. There were some patches that did this a few years ago,
which have probably suffered from code rot by now, but it isn't
a particularly hard thing to do.

Using Allegro alongside a hardware accelerated OpenGL implementation
seems to be pretty much impossible, due to some very different
assumptions about how things should be set up, and conflicts over
who controls the hardware. I did quite a bit of work trying to
get this going using the recent Windows version of Allegro alongside
the Microsoft OpenGL implementation, and although it is possible
to get them both drawing in the same window, this isn't useful 
because OpenGL does double buffering with a hidden surface that
Allegro has no way to access, and the repeated switches between
2d and 3d rendering modes causes a complete flush of the 3d
pipeline, which is very harmful to the performance of your code. 
This is because the current generation of PC graphics hardware
is optimised for very deep queueing of 3d commands, with the
card often running as much as a frame behind the host processor,
while 2d commands are executed immediately, so when you try to
use both methods of drawing at the same time, you lose a whole
frame each time you switch. Better hardware doesn't have this
problem, but SGI machines tend to be quite expensive :-)


	Shawn Hargreaves.