Mail Archives: djgpp/1997/04/15/19:53:54
I'm replying to several posts by different people in this message: I
hope that doesn't get too confusing (otherwise I would have ended up
repeating the same things in several posts).
Chris A. Triebel writes:
>> > Allegro to have "DirectX driver support." DirectX was made specifically for
>> > Windows95 to allow Windows95 programmers to have Direct access to the
>> > computer's hardware, without writing any hardware spcific code. There is no
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Wasn't that the point of SVGA? ( really is a question for my own
>clarification ).
Not quite :-) I'll have a go at some clarification on this: there seems
to be a lot of confusion about this!
An SVGA chip is one that support more resolutions than the standard IBM
VGA card, most frequently the 640x480, 800x600, and 1024x768 256 color
modes, plus in some cases also even higher resolutions or ones with more
than 256 colors. Lots of different graphics manufacturers built such
cards, and they all implemented them in different ways. They are all
based on the VGA chipset, so they have a lot in common, but the ways in
which you access the higher resolutions differ in every card. Hence the
Allegro drivers for some specific chipsets like Cirrus, S3, and Tseng.
In an attempt to standardise this mess, the VESA standard was designed.
This is a software interface (not _not_ hardware, people who say they
have VESA in hardware are wrong, and really just mean that it is built
into their ROM BIOS rather than being loaded as a TSR). VESA lets you do
all the basic things (setting video modes, scrolling, and accessing
video memory), in the same way on any card, which is pretty cool.
>My impression ( right or wrong ) of DirectX is that it an attempt to create
>an interface IN HARDWARE for doing complicated tasks like drawing boxes,
>circles, flood fills ... Thus taking the burden of calculation and
>generation off of the shoulders of the main processors and FP facilities.
Sort of, but again not quite true :-)
Such hardware acceleration (lines, boxes, etc), has been around for a
while. Until very recently it has only been usable by Windows programs,
because those are the only ones that had drivers for it (sure, you could
write custom code for every SVGA chipset, but life is too short, and
using hardware accelerators is complicated). Also, I've never been
convinced just how useful these features are: they'd be great for
speeding up GUI programs that draw lots of boxes and lines (which is
after all what they were designed for), but rather less use for
multimedia stuff and games. An accelerated fill would be great for
clearing the framebuffer, but a profile of most computer games will
reveal 99% of the time being spent copying images from system RAM onto
the screen, and that isn't accelerated by any current hardware that I
know of (ok, so you could store your sprites in offscreen video memory
and use a hardware blitter to copy them across from there, but you're
going to run out of space real quick).
But I digress. DirectX isn't anything to do with hardware, it's a
software graphics API that can use such hardware features if the chip
supports it (you tell it to draw a line, it will do it in software if
required, or with a hardware accelerator if that is possible). This
isn't a new ability to DirectX: the Windows Graphics Device Interface
has been doing that for years (just imagine how slow Word would run
_without_ such acceleration! :-) The reason for DirectX is that the GDI
interface was designed for writing GUI programs, and proved to be pretty
useless for game-type things. DirectX can be seen as an
extension/replacement for the standard Windows graphics functions, which
makes them more useful for multimedia coding.
My current feeling is that hardware acceleration in DOS is more trouble
than it is worth to implement individually for each chipset.
Fortunately, SciTech are working on VBE/AF, which is an extension to the
VESA standard that supports 2d acceleration. As soon as they finish it,
I will start supporting it in Allegro...
3d acceleration is another matter, though. My feeling is that this isn't
a useful thing for Allegro to support. Unlike 2d graphics, where a
rectangle is pretty much equivelant however it is drawn, 3d cards vary
hugely in how and what they accelerate, so in order for hardware support
to be useful they need a proper 3d API rather than the low-level
rendering functions provided by Allegro, My feeling is that anyone who
wants to code for accelerated 3d chipsets is best off working with a
high-level 3d API like Direct3d (for masochists) or OpenGL (for more
sensible people).
(switch message, I'm now responding to a different person!)
Calvin French writes:
>The line is blurred. Originally I had proposed just using the
>OEM-shipped DirectX driver, no windows at all. But someone else made
This is where I start getting worried :-) I'm extremely wary of saying
that something is impossible, but in this case I'm very tempted to! If
you can make DirectX work from a DOS program, I'll take my hat off to
you, but my advice would be not to waste time on it. I don't think it
will work...
Sure, with some effort you could load VXD's and call their functions
from a DOS prog. But what do you do when these drivers proceed to access
other Windows routines, eg. parts of the GDI, various internals of
kernel.dll and system.dll, etc? My understanding is that DirectX is very
closely tied into the GDI (quite apart from anything else, the two have
to cooperate to keep track of who owns the display at any given moment,
and also I have a feeling that you can use GDI functions to write onto a
DirectX surface, which implies they are pretty tightly woven together).
Anything is possible with enough effort, but I can't help thinking you'd
have to emulate most of Win95 before this would work. And then what do
you do if Microsoft changes some internal detail of the driver format a
month after you finish? :-)
>between Windows and DOS programming is already blurred. Remember that
>even Win95 is only a thin fabric covering hardware, only "stepping in"
>when it has to. It is not any kind of great interpreter, redirecting
>hardware ins and outs accordingly, or any such thing. There are API
I think you are underestimating how much work Win95 actually does! For
all it's faults, there's a lot of code in it, and it does quite a few
rather complicated things...
>blurs the line. I always see the joy of Allegro as being a possible
>multi-platform game development suite; DOS, linux, Win95... So if I
>write a game using Allegro (which is easier than coding for just
>Windows, let alone all3) suddenly it can take advantage of DOS, linux
>and Windows platforms. DOS, through the hand-crafted drivers Shawn
>(and others??) have supplied with Allegro. Linux, through whatever is
>planned for linux (I've never used it myself). And Win95, if we add
>DirectX support.
This is something I would love to see. But I think that you are barking
up the wrong tree by trying to add DirectX support to the DOS version of
Allegro. I can't help thinking it would be vastly simpler and more
sensible to port the entire library to a native Windows environment, and
use DirectX in the context it was designed for. Of course it would be
great to be able to get programs that run under DOS, Linux, and Windows,
simply by recompiling them for the new platform, but that doesn't mean
the library has to stay the same on each target system!
>Shawn, I would really be interested in your input on this. Can Allegro
>be made into a multi-platform game lib? People (who know more than I)
I hope so! I'm planning to start work on a Linux version at some point
after I get the truecolor stuff done, and someday (or someyear: these
things take time :-) after that I might well become interested in
working on a DirectX version myself. Such a port would be a _lot_ easier
with a decent Windows version of gcc, though. At present I think it
would have to be done with a native Windows compiler such as Visual C++
or Watcom, which would involve a lot of effort to rewrite all the asm
routines.
>originally slated as a separate lib, so you'd at least have to ship 2
>versions, but wouldn't it be kewlio to just have one, unified lib
>which takes advantage of whatever's there? Or would this require
Except that the executable formats are totally different between the
three platforms!
My approach (already started for the Linux version) would be to keep a
single source tree for the Allegro code, and a single allegro.h, but
recompile it for each target OS. Some code (in fact most of the graphics
routines, sample mixing, etc), can stay unchanged between the different
targets, or will just need small tweaks that can be achieved with the C
preprocessor. Other routines (the I/O functions and hardware drivers)
will need to be totally rewritten. At the moment all the code I consider
to be basically portable is in allegro/src, DOS specific routines are in
allegro/src/djgpp, and some dummy files waiting to be filled out are in
allegro/src/linux.
If I was going to port it to Windows, I'd start out by downloading RSXNT
and Caldera's Win32 port of gcc, and seeing if I could get either of
them to work with DirectX functions. Neither is ideal, for legal
reasons, but I'd be tempted to use those for now and hope that someone
adds Windows support to djgpp while I was working on the port (or hey,
if I had enough time I might work on that myself, but I don't have time
so this is all hypothetical :-) Then I'd create an allegro/src/windows
directory, put some placeholder files into it, and keep running make and
fixing everything that upsets it until I got the thing to compile. Then
I'd start running programs, going through fixing problems, until it all
ran, at which point I would start the real work of the port:
implementing a GFX_DRIVER, DIGI_DRIVER, and MIDI_DRIVER, that ran on top
of the DirectX API, and finding some way to make the timer, mouse,
keyboard, and joystick modules work under Windows. I'm not planning to
do that in the forseeable future, but if anyone feels like doing it for
me I would be delighted to help out in any way I can!
Of course, if you really think you can make the DirectX drivers work
under DOS, you should try it. I would be both impressed and very, very
happy to have such a thing, but I have to say that it isn't the approach
I would take myself...
--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
Beauty is a French phonetic corruption of a short cloth neck ornament.
- Raw text -