From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Re: AllegroX project? Date: Tue, 15 Apr 1997 20:18:44 +0100 Organization: None Distribution: world Message-ID: References: <199704140838 DOT SAA22103 AT solwarra DOT gbrmpa DOT gov DOT au> NNTP-Posting-Host: talula.demon.co.uk MIME-Version: 1.0 Lines: 190 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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.