Mode X a dead end?
Steve Hicks
a response to someone who posted that mode X seemed to be significantly
slower than mode 13h on a local bus graphics adapter. Any graphics
adapter/local bus savvy people out there know if this is accurate info?
> #: 17357 S3/DOS Games
> 29-Mar-95 18:33:04
> Sb: #17342-Mode-X _is_ slow?
> Fm: Tom Ryan [SciTech] 76531,1315
[snip]
> You are absolutely correct. Since Mode X utilizes the VGA compatible core
> of a graphics controller, it generally cannot access the additional band-
> width of today's local bus controllers. Most controller manufacturers have
> not touched their VGA compatible core in years. All the new developments,
> like local bus, have been put into the newer parts of the chips.
[snip]
> Anyway, the bottom line is that Mode X is really a dead end.
>
> Tom Ryan
> SciTech Software
--
Steven Hicks, ILX Systems
ste...@ilx.com, 212-720-3148
Thomas Bak
>I ran across this message in the game developers forum on CIS. It is
>a response to someone who posted that mode X seemed to be significantly
>slower than mode 13h on a local bus graphics adapter. Any graphics
>adapter/local bus savvy people out there know if this is accurate info?
>[snip]
>> Anyway, the bottom line is that Mode X is really a dead end.
Perhaps Mode X may be slower in various types of writes as compared to
mode 13h, but the Mode X has the ability to page flip which is quite
speedy. One doesn't need to redraw the screen every time you wish to
scroll. Also, I'm quite sure large fills are quicker. You can
essentially write 4 pixels to the screen by modifying one address.
Even if mode 13h is faster than ModeX with VLB, what would you do with
the poor ISA and EISA saps like me?
Why are we here?
Because we're here!
Roll the bones...
Roll the bones...
Kevin J. Butler
>Perhaps Mode X may be slower in various types of writes as compared to
>
>mode 13h, but the Mode X has the ability to page flip which is quite
>speedy. One doesn't need to redraw the screen every time you wish to
>scroll. Also, I'm quite sure large fills are quicker. You can
>essentially write 4 pixels to the screen by modifying one address.
Something I've been thinking about for a while: this is just large,
solid-color fills, right? I think most of what I'll be doing is more
complex than that...
>
>Even if mode 13h is faster than ModeX with VLB, what would you do with
>the poor ISA and EISA saps like me?
Sorry, the *only* decent answer to that is "Let you suffer till you upgrade."
(before you or anyone else jumps down my throat, I'm a poor ISA,
*unaccelerated* sap myself, and believe me, I'm suffering till I upgrade! But
the *only* decent way to do it is to design for the future. And while we're
at it, the future is PCI, not VLB, but I'm sure the issues are the same...)
kb
---
The above opinions may or may not be mine, Novell's, BYU's, or anyone else's.
kbu...@novell.com but...@byu.edu
P Moore906
like to add something.
Mode X is a 'tweaked' video mode, as I'm sure you all know. It's not
standardized, and most importantly is not guaranteed to work on anything
other than a true VGA card. Mode X has known problems on the newer
accelerated video cards. This is why most game makers (like Origin in
Ultima 6-8) use pure mode 13H. When you make the call:
mov ax, 0013h
int 10h
You're actually calling code that's built into the video card. That means
that it will DEFINATELY work with that card. But if you play with the
registers directly, you may run into a bug in the video card that wouldn't
otherwise show.
One advantage of Mode X is fast fills. However, the same thing can be
accomplished on a 386 or better processor, using the STOSD instruction.
Even on ISA busses, it's just as fast as the Mode X fast fill. Besides,
nearly every game today requires a 386, so it's not like you're making an
unreasonable requirement. And, with the 386, you can quickly draw image
blocks (non-transparent, of course) by copying 4-bytes at a time,
assuming, of course, DWORD alligned coordinates, like in Ultima 7 where
everything was aligned to 8 pixels.
Another advantage of Mode X is Page Flipping, allowing scrolling without
redrawing the screen. The standard VGA does have scroll registers, so
with a little devious code, you can make mode 13H scroll just as fast.
Or, you can simply redraw the screen. On faster machines (486 DX/33 and
up) this is no problem at all.
So, in my opinion, mode X really doesn't offer anything better than mode
13H. What it does offer is unnecessary incompatibility with newer
graphics cards.
Peter
America On-Line: P Moore906
Internet: pmoo...@aol.com OR pmo...@eagle.ibc.edu
AsmFiend
There's one thing I really have to disagree with and that is "just as
fast" fills in mode 013h as Mode X. In mode X you can set up to 16 pixels
with one STOSD write where as mode 013h is limited to four, max. On
today's video systems incorporating local bus, PCI, et al, you no longer
have the 8mhz ISA bus speed bottleneck so Mode X is definatly faster on
the new machines.
On an ISA, this makes no difference because the ISA is a lowly 8mhz. PCI
is hitting ten times that nowadays. Still if you want to play a digital
music soundtrack in the background (real-time music generation), then
every cycle counts. Using one STOSD in modeX verse four STOSD's means 1/4
of the time spend on doing video fills; for 3D polygon fills, mode X is
still #1.
As for compatibility, when you buy a video board you buy for speed or
compatibility. There's lots of high end "special" boards that offer great
speed, but are "mostly" VGA compatible. If it works on an IBM, but not on
some other piece of hardware, then you have a hardware compatibility
problem. Software vendors will not support all different hardware specs
so it has to standardize; in terms of VGA compatibility, if the card
doesn't do everything the IBM VGA does, then it can't claim 100% register
compatibility. The vendor needs to upgrade the board to do at least
everything the IBM VGA does.
Cheers,
AsmFiend
... This is not a flame. Really. Honest. Ok, its a bit warm, but only a
little.
Justin Johnson
> There's one thing I really have to disagree with and that is "just as
> fast" fills in mode 013h as Mode X. In mode X you can set up to 16 pixels
> with one STOSD write where as mode 013h is limited to four, max. On
> today's video systems incorporating local bus, PCI, et al, you no longer
> have the 8mhz ISA bus speed bottleneck so Mode X is definatly faster on
> the new machines.
>
> On an ISA, this makes no difference because the ISA is a lowly 8mhz. PCI
> is hitting ten times that nowadays. Still if you want to play a digital
> music soundtrack in the background (real-time music generation), then
> every cycle counts. Using one STOSD in modeX verse four STOSD's means 1/4
> of the time spend on doing video fills; for 3D polygon fills, mode X is
> still #1.
The polygon advantage of ModeX as far as i can see is diminishing rapidly.
The game players of the world want to see texture mapped and light sourced
polygons, mode 13 is faster for doing this kind of rendering.
Ok, Mode X can store multiple pages. But if your talking about a reasonable
486 with a VLB or PCI bus, the blitting a whole screen barely takes a few
inches of real raster time and is quite acceptable.
Personally, and this is only my opinion, Mode X will become less and less
used as time goes on. The only advantage i can see that it offers now, is
and extended resolution capability for standard VGA cards.
--
--------------------------------------------------------------------------------
Justin Johnson (jus...@jjavp.demon.co.uk) / / \ \ \ / / /-----/
/ / \ \ \ / / / /
'We are but silicon dreams in the minds / / ___ \ \ / / /---/
eye of a digital god...' / / / \ \ \ / / / AVP
================================================================================
P Moore906
justify the possibilities of bugs and incompatibilities. You can say all
you want about how video companies should fix their own problems, but the
fact of the matter is that perhaps millions of those boards are out there
already and most of them will stay out there for a while. We have to
consider that and the fact that we don't want a game to be incompatible
with so many video boards. Do we really want the Ultima 7 of Graphics
(remember how U7's incompatible w/ memory managers)?
P Moore906
rapidly.
>> The game players of the world want to see texture mapped and light
sourced
>> polygons, mode 13 is faster for doing this kind of rendering.
>>
>> Ok, Mode X can store multiple pages. But if your talking about a
reasonable
>> 486 with a VLB or PCI bus, the blitting a whole screen barely takes a
few
>> inches of real raster time and is quite acceptable.
>>
>> Personally, and this is only my opinion, Mode X will become less and
less
>> used as time goes on. The only advantage i can see that it offers now,
is
>> and extended resolution capability for standard VGA cards.
future. I know in my game, I wouldn't use any polygons. I use texture
bitmaps, exactly as you said. In Tie Fighter, for example, the polygons
were all textured. In that case, the fast fill is all but useless.
Kenneth Foo
[text deleted...]
>One advantage of Mode X is fast fills. However, the same thing can be
>accomplished on a 386 or better processor, using the STOSD instruction.
>Even on ISA busses, it's just as fast as the Mode X fast fill. Besides,
>nearly every game today requires a 386, so it's not like you're making an
>unreasonable requirement. And, with the 386, you can quickly draw image
>blocks (non-transparent, of course) by copying 4-bytes at a time,
>assuming, of course, DWORD alligned coordinates, like in Ultima 7 where
>everything was aligned to 8 pixels.
Uh oh...I don't think so.
Using ModeX and STOSD instruction, I'm able to plot 16 pixels at a time!
>So, in my opinion, mode X really doesn't offer anything better than mode
>13H. What it does offer is unnecessary incompatibility with newer
>graphics cards.
True...unless you're coding for speed in solid vector filling routines.
Joan E Krochko
syncronize sending my buffer to the screen and its square aspect ratio
makes sprite drawing so much easier. I switched to it because I got so fed up
with the non-square aspect ratio of mode 13h.
How do you normally handle the non-square aspect ratio of mode 13h. On
cards like my ISA can a buffer be successfully transmitted in the time it
takes for the vertical retrace. On one of the programs I wrote it runs
at 53 fps with almost no flicker without the vertical retrace.
thanx,
Andrew
Ed Goldman
: bitmaps, exactly as you said. In Tie Fighter, for example, the polygons
: were all textured. In that case, the fast fill is all but useless.
Except for clearing the screen...
Anyway, Tie Fighter uses absolutely no texture mapping (or, very little
if any). Mostly it's gouraud shading. Decals and other little details
were done with polygons. Bad example for texture mapping ... :-)
-edg-
Maxis
AsmFiend
If I understand the argument correctly, its that standard mode 013h is
fast enough for today's graphics without being incompatible with some
video cards. My original objection is that mode 013h is "fast enough."
Its impossible to have something "fast enough" since what we call fast
today will become slower than molasses tomorrow. Mode X is my preferred
mode because its faster on my system that mode 013h. Granted its
difficult to program efficiently, but if you can offload the work into the
VGA hardware, that's where the speed really comes from. Mode 013h is
simple, very painfully simple. The hardware provides no assistance for
bitblts or paging; you're relying on brute the force of the processor
(which is easy) instead of using smarter programming techniques (which is
hard).
As for compatibility, well, I can only say that any game with Mode X
graphics should have a label stating a 100% VGA compatible video card is
required. In any industry there are standards and the VGA is a long time
standard. If you or someone you know has an incompatible video board,
that doesn't mean developers worldwide should stop using something that
works on a real VGA and MOST compatibles but not a few incompatible ones.
There's no reason not to use mode X since it works on any 100% vga
compatible. Please read that sentence again. For the vast majority of
video systems out there, Mode X works great! If you've got a video card
that isn't in this majority, then you'll run into problems with some
games. Developers code for the majority, otherwise they'd still be
supporting the Sanyo 550, Tandy 2000, and all the other oddball partly
compatible machines that ever existed.
Arguments for Mode X includes the following:
Fastest poly fills and single color drawing
4X the bitblt speed when performing vram to
vram image copies.
320x240 resolution with a 1:1 aspect ration;
no scaling of images required during rotation
to maintain a proper looking images; also less
overhead drawing circles since aspect adjustment
isn't necessary.
Those are three that I can think of off the top of my head. I've already
mentioned that Mode X is the fastest mode for single color polygon fills.
Texture maps were mentioned and I propose that copying from video memory
to video memory will nearly double the speed of a straight copy from
system memory, again due to the use of latches to turn one byte
read/writes into four byte read/writes. In the standard Mode X (320x240)
resolution, you've got 1 1/2 video pages for storing animation bitmaps
assuming you use two pages for page flipping; you only need one copy of
each
When rotating objects, you need to scale for the aspect ratio otherwise
what was a tall object looks square when rotated sideways. Mode X is
320x240 with a 1:1 aspect ratio; each pixel is a square so no scaling is
necessary when rotating a bitmap. No adjustments for aspect ratios means
circles get drawn quicker too.
.Anyway, just my point of view.
AsmFiend
... "Oops!" Overhead at your local nuclear power plant
Tim TAL Lister
>I'm rather new here, but I have lots of experience with video and would
>like to add something.
>
>Mode X is a 'tweaked' video mode, as I'm sure you all know. It's not
>standardized, and most importantly is not guaranteed to work on anything
>other than a true VGA card. Mode X has known problems on the newer
>accelerated video cards. This is why most game makers (like Origin in
>Ultima 6-8) use pure mode 13H. When you make the call:
>
>mov ax, 0013h
>int 10h
>
>You're actually calling code that's built into the video card. That means
>that it will DEFINATELY work with that card. But if you play with the
>registers directly, you may run into a bug in the video card that wouldn't
>otherwise show.
>
>accomplished on a 386 or better processor, using the STOSD instruction.
>Even on ISA busses, it's just as fast as the Mode X fast fill. Besides,
>nearly every game today requires a 386, so it's not like you're making an
>unreasonable requirement. And, with the 386, you can quickly draw image
>blocks (non-transparent, of course) by copying 4-bytes at a time,
>assuming, of course, DWORD alligned coordinates, like in Ultima 7 where
>everything was aligned to 8 pixels.
>
>redrawing the screen. The standard VGA does have scroll registers, so
>with a little devious code, you can make mode 13H scroll just as fast.
>Or, you can simply redraw the screen. On faster machines (486 DX/33 and
>up) this is no problem at all.
>
>13H. What it does offer is unnecessary incompatibility with newer
>graphics cards.
Oh yeah? What about square pixels? _that_ is the main reason that i use
mode-X (set up as 320 x 240), because i can rotate images without losing
shape, as i would with mode 13h. And, of course, all the artwork software
available works with square pixels, so i don't have to ask the artists to
produce distorted images, and they happily use their Mac II's with
Photoshop to make artwork for me, and transmit PCX's to me. If you think
this is trivial, just try running a large game project that uses 320 x 200
artwork, and i hope you don't suffer too much.
Also, Page Flipping has nothing whatsoever to do with scrolling! Page
Flipping is used with double or triple buffering, which allows off-screen
updates, and thus eliminates flicker. Mode X has the advantage that all
2 (or 3) screens fit in the one 64K bank of memory that begins at A000:0000,
and so no bank switching or hairy register ops are necessary, just a set
of the screen start register. Since each screen is an exact multiple of
256 bytes (1 page), only the high byte of the screen start address needs
to be set, and there is no need to wait for a Vertical Blanking Interval,
as the value set into the Screen Start Register (high) is latched until
the start of the next VBI . This is _fast_.
regards,
tal
--
;----------------------------------------------------------------------
TIM (TAL) LISTER, max...@extro.ucc.su.oz.au
Maxtal Pty Ltd, 81a Glebe Pt.Rd, Glebe, NSW 2037, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Charley Lee
P Moore906 <pmoo...@aol.com> wrote:
>I suppose you're right about the fills. However, to me, it doesn't
>justify the possibilities of bugs and incompatibilities. You can say all
>you want about how video companies should fix their own problems, but the
>fact of the matter is that perhaps millions of those boards are out there
>already and most of them will stay out there for a while. We have to
>consider that and the fact that we don't want a game to be incompatible
>with so many video boards. Do we really want the Ultima 7 of Graphics
>(remember how U7's incompatible w/ memory managers)?
>
I think the fact that ID used Mode X (in 320x200 res) for Doom pretty much
supports the idea that Mode X is compatible for the majority of the computer
users out there. I mean, as far as I know, I've never heard of anyone who
had problems getting Doom to work on their system.
Also, Doom and Doom II were extremely successful, which supports the idea
that there is a large market of people who have 100% register compatible
VGA cards, or cards that are very close to that compatibility level.
I don't think that there is any problems with using Mode X at all. As long
as people are buying Mode 13h games, then there should be people still
willing to program Mode X games. When the market starts shifting toward
higher SVGA games, to the point where they are selling well, and that most
games are in these modes, then I think it's time to drop Mode X and Mode 13h
together.
Chuck
David Boeren
Just a note for everyone, you CAN have perfect square pixels in mode 13.
Just add the following one line to your mode setting code:
outp(0x3C2,0xE3);
This will change the vertical rate and give you square pixels in 320x200
linear addressed mode 13, how about that? Having only 200 vertical instead
of 240 makes your screen look like a letterbox edition, but personally I
don't think it looks unpleasant. Actually, it kind of simulates a wider
FOV, or at least LOOKS like it does.
I like the higher resolution of some X modes, I wish they were available in
a regular linear addressed organization too, but no chance of that.
Hans Insulander
s:
Someone told me one would have to perform a reset of the vga-card to make
that work with all monitors... But I'm not quite sure about that..
It works nice on all monitors/cards I've tested. (about five... :( )
Does someone know for sure?
---
Hans Insulander h...@algonet.se
Ayzer Meir-danie
: One advantage of Mode X is fast fills. However, the same thing can be
: accomplished on a 386 or better processor, using the STOSD instruction.
: Even on ISA busses, it's just as fast as the Mode X fast fill.
You can use STOSD on modex and paint 16 pixels at a time.
/Danny
Hans Insulander
>: It works nice on all monitors/cards I've tested. (about five... :( )
>
>that case, none of the X modes will work either. Thie technique should work
>on anything else, and I don't do any reset. I just do the outp() right after
>I call the interrupt to set mode 13, and it works fine. Also, almost nobody
>has a fixed rate monitor these days. Usually only school labs and other
>places that never upgrade old stuff.
Ok, thanks for that. Just a funny little piece of information... My new
17-inch monitor (borowed) has a little lcd on it. The lcd still says
I'm using 400 lines insted of 400 if I dont reset the vga. But the picture is
alright! (Sorry for my poor english... :( )
---
Hans Insulander h...@algonet.se
Dr. Cat
640*480, aren't they? I switched to 640*480 for all my work a while
back, you can get much more detailed artwork. And you can get decent
quality text on the screen, which 320*200 or 320*240 is just too coarse for.
***********************************************************************
Dr. Cat / Dragon's Eye Productions ** Come play DragonSpires!
******************************************** ftp.eden.com pub/dspire
Dragonspires is a graphic mud for PCs. ** has everything you need!
***********************************************************************
** http://www.realtime.net/~gauntlet/dspire.html for more info **
***********************************************************************
Rainer Deyke
: In article <3lfjis$e...@i-2000.com>, tb...@i-2000.com (Thomas Bak) wrote:
: >Perhaps Mode X may be slower in various types of writes as compared to
: >
: >mode 13h, but the Mode X has the ability to page flip which is quite
: >speedy. One doesn't need to redraw the screen every time you wish to
: >scroll. Also, I'm quite sure large fills are quicker. You can
: >essentially write 4 pixels to the screen by modifying one address.
: Something I've been thinking about for a while: this is just large,
: solid-color fills, right? I think most of what I'll be doing is more
: complex than that...
No, you can also use fast 32 bit writes copying from video memory to
video memory. This is useful if you place your (non-transparent) tiles
in video memory and thus requires less memory and is faster than mode
13h sprites.
: >Even if mode 13h is faster than ModeX with VLB, what would you do with
: >the poor ISA and EISA saps like me?
: Sorry, the *only* decent answer to that is "Let you suffer till you upgrade."
: (before you or anyone else jumps down my throat, I'm a poor ISA,
: *unaccelerated* sap myself, and believe me, I'm suffering till I upgrade! But
: the *only* decent way to do it is to design for the future. And while we're
: at it, the future is PCI, not VLB, but I'm sure the issues are the same...)
No, you should design for whatever equipment can run whatever you are
designing. For example, I am currently working on a tile based RPG and
I'm purposefully using mode X as opposed to mode 13h or SVGA. That's
because I really want square pixels and because a higher resolution
would not significantly add to the game but require a lot more memory
(to store larger bitmaps). This also increases my market because lots
of people still don't have SVGAs. I know, they're a small portion of
the market, but there is also less competition among low-end users
because most new games are made for better, faster computers with
higher resolution.
--
+-------------------------------------------------------+
| Rainer Deyke the Unemployed (rai...@mdddhd.fc.hp.com) |
| "A plague rages in all our hearts" - Napalm Death |
+-------------------------------------------------------+
Rainer Deyke
: One advantage of Mode X is fast fills. However, the same thing can be
: accomplished on a 386 or better processor, using the STOSD instruction.
: Even on ISA busses, it's just as fast as the Mode X fast fill. Besides,
: nearly every game today requires a 386, so it's not like you're making an
: unreasonable requirement. And, with the 386, you can quickly draw image
: blocks (non-transparent, of course) by copying 4-bytes at a time,
: assuming, of course, DWORD alligned coordinates, like in Ultima 7 where
: everything was aligned to 8 pixels.
Uh, what about 386SXs? They still exist, and run all 386 code, but
slow down to half speed when 32 bit instructions are used.
: Another advantage of Mode X is Page Flipping, allowing scrolling without
: redrawing the screen. The standard VGA does have scroll registers, so
: with a little devious code, you can make mode 13H scroll just as fast.
: Or, you can simply redraw the screen. On faster machines (486 DX/33 and
: up) this is no problem at all.
Many SVGAs don't support the wrap-around effect needed to use scrolling
registers in mode 13h but do support mode X scrolling. Thus, mode X is
actually more compatible. Besides, mode 13h still doesn't have
page-flipping. Redrawing the screen both slows down the game and takes
up more memory (assuming you are drawing to a virtual screen and
blasting it all to video memory using rep movsd).
Saulnier
: Geez, ya know, mode X and mode 13 are BOTH way lower resolution than
Tell me that there's a way to address ALL of your video ram linearly
and is relocatable anywhere in extended memory and that ALL SVGA cards
can do this in the same way and that they all work in the same way for
setting the screen-start address, the video-mode and I'll switch to 640x480
right this minute.
Yeah right!!! Sheeesh. I need speed more than resolution.
And 20 different SVGA cards doesn't help either.
Cleo Saulnier
Jong-Min Park
> Kevin J. Butler (kbu...@novell.com) wrote:
> : In article <3lfjis$e...@i-2000.com>, tb...@i-2000.com (Thomas Bak) wrote:
> : >Perhaps Mode X may be slower in various types of writes as compared to
> : >
> : >mode 13h, but the Mode X has the ability to page flip which is quite
> : >speedy. One doesn't need to redraw the screen every time you wish to
> : >scroll. Also, I'm quite sure large fills are quicker. You can
> : >essentially write 4 pixels to the screen by modifying one address.
> : Something I've been thinking about for a while: this is just large,
> : solid-color fills, right? I think most of what I'll be doing is more
> : complex than that...
> No, you can also use fast 32 bit writes copying from video memory to
> video memory. This is useful if you place your (non-transparent) tiles
> in video memory and thus requires less memory and is faster than mode
> 13h sprites.
I think there is a limitation on the pixel alignment. You may not
be able to vram-to-vram copy aligned by a single pixel; Both
addresses have to be aligned to the sample bitplane, i.e., aligned
by 4 pixels.
If I wanted smooth sprite movement, this could be a problem, unless
of course it is fast action and 4-pixel movement is not too distracting,
or I guess one could store all 4 possible alignments in vram if
they can fit.
+-------- Jong-Min Park -=?B?EUC-KR?udrBvrnO?=-박종민-----------
| E-mail: jong...@engr.wisc.edu
| Office: (608)-263-7784 266 ME Bldg
+-------- University of Wisconsin - Madison
John Robert Williams
> Dr. Cat (c...@eden.com) wrote:
> : Geez, ya know, mode X and mode 13 are BOTH way lower resolution than
> : 640*480, aren't they? I switched to 640*480 for all my work a while
> : back, you can get much more detailed artwork. And you can get decent
> : quality text on the screen, which 320*200 or 320*240 is just too coarse for.
> Tell me that there's a way to address ALL of your video ram linearly
> and is relocatable anywhere in extended memory and that ALL SVGA cards
> can do this in the same way and that they all work in the same way for
> setting the screen-start address, the video-mode and I'll switch to 640x480
> right this minute.
> Yeah right!!! Sheeesh. I need speed more than resolution.
> And 20 different SVGA cards doesn't help either.
You forgot to mention that all of you gfx functions are going to take
about 4x as long since there is so much data! Maybe when we all have
Pentiums and P6's...
--
John Williams <jo...@jove.acs.unt.edu>
Barach's Rule:
An alcoholic is a person who drinks more than his own
physician.
NOMIKOS ZOGRAFAKIS
: You forgot to mention that all of you gfx functions are going to take
: Pentiums and P6's...
my 0.02$:
i saw Wing Commander 3 on a pentium 90 with 16 megs ram and a vlb grafx
card (fast HD too)... and sadly it wasn't playable enouf/as much as in
320x240. hmmm...
--
Nomikos Zografakis
E-mail me @ N_Z...@VEGA.CONCORDIA.CA