Windows arcade game programming
HAUGLAND, JAN STEINAR
I've been on vacation and can't actually quote the original posts,
but a resume could be that after some discussions about the slow
graphics processing in MS Windows I posted a note regarding the
multimedia extensions which is not at all slow. Somebody (forgot
your name, sorry) answered that what we DON'T want is simply some
premade clips of animation.
I agree. But please note that it is absolutely possible to create
these ANI/FLI files one the fly (no pun intended) and make this
animation really interactive.
Remember all that stuff about how good Amigas and STs were compared
to PC some years ago when the PC was claimed unusable for real good
arcade games? And look at the games scene now!
We should all know that the first person to write a really good and
impressive Windows game might well end up driving Porche...
And the game reviewers won't care if it requires a Pentium machine.
Strike Commander does sell, doesn't it???
For good examples of animation, see the "Grandma and Me" (for kids, but
in this group we're all kids at heart, eh?) from Broderbund and the
Where in the World is Carmen Sandiego game, both on CD-ROM bundled with the
Creative Pack Pro (SB Pro 16 + CD-ROM). These might not be real Windows progs
but they sure run perfectly with Windows, somehow.
Just my $.02
Regards, and good luck with games programming
Jan Steinar Haugland
Simon Lee
>Remember all that stuff about how good Amigas and STs were compared
>to PC some years ago when the PC was claimed unusable for real good
>arcade games? And look at the games scene now!
First of all, the Amiga and ST's didn't have games that ran with Intuition
(the windowing software on the Amiga) at the same time. The games ususally
took over the machine, like most of the PC's games.
>We should all know that the first person to write a really good and
^^^^
>impressive Windows game might well end up driving Porche...
^^^^^^^^^^^^^^^^^^^^^^^
I don't think this would happen, since using Windows takes way too much
resources just to function without crashing :) My point is, why? Why try to
run an action game in windows? You'd just be wasting the computer's resources
trying to run two processor intensive software at the same time which may
cause problems. Try running your important business software and a game at
the same time. OOPS! The game crashed! Now you've lost data. Bye bye job.
(worst cast scenerio). Anyways, I don't think a game is really necessary for
Windows. Even if there were Windows games, I don't think it'd be very
practical. Try running Strike Commander on Windows. Why???
--
* Simon Lee * Microscopy and Imaging Resource *
* si...@ivem.ucsd.edu * Intermediate Voltage Electron Microscopy *
* su...@ucsd.edu * UC San Diego, Dept. of Neuroscience *
-------------------------------------------------------------------------
Jeff Simon
>>We should all know that the first person to write a really good and ^^^^
>>impressive Windows game might well end up driving Porche...
> I don't think this would happen, since...
The first person to write a really good and impressive windows game will
probably end up driving the Porsche as his/her 'other' car...a million copies
per _month_? If someone can corner that market,they'll make a fortune!
> My point is, why? Why try to
> run an action game in windows? You'd just be wasting the computer's resources
> trying to run two processor intensive software at the same time which may
> cause problems. Try running your important business software and a game at
> the same time. OOPS! The game crashed! Now you've lost data. Bye bye job.
> (worst cast scenerio).
I don't see the difference between a game crashing and _any_ piece of
software crashing under Windows...You'll just feel more guilty if you lost it
because you were playing Civilization :)
You've targeted the wrong thing here; it's not a question of system stability
from running two programs at the same time (look in windows.advocacy for _that_
discussion :) ). Instead, the question that begs to be asked is whether it's
_feasible_ to run an action game in Windows. Put another way, would Strike
Commander benefit from being run under Windows with Excel and Word gobbling up
those precious resources?
Well, of _course_ not! This is the equivalent of asking whether S.C. would be
better off on a 386 or a 486. There will always be those games that demand
_every_thing from the hardware (and they'll probably all be from Origin, God
bless 'em :) ), and _any_ lesser availability of resources (Memory, CPU time,
etc) will be a problem.
To break it apart, there are (to simplify _enormously_) three basic types
of games:
(1) Not at all graphic intensive: Text games. Basic graphics
(2) Somewhat graphic intensive: Civilization. Any Sierra Game.
(3) Ridiculously, Wonderfully graphic intensive: anything from Origin :)
The benefits of writing a game in the first two categories should be immediately
obvious: Enormous market, standard APIs, not having to deal with device
dependancies (to be redundant redundant :)). Plus an enormous wealth of
Software Development Kits for the start up companies - everything from Audio
to reading CDs to playing Movies...everything that companies spend millions
on R & D on, only to find they don't support all platforms. I could go on...
A game like Civilization would benefit remarkably from Windows, both for the
programmer and the player: The programmer gets all the bene's listed above,
and the player gets the (relative) assurance that (a) the game will setup easily
and run on his/her platform, (b) he/she
can be running it while printing or reading or just doing something else on the
computer, since it is not processor-intensive enough to demand complete domination,
(c) a well-known, easier to use interface than available under DOS, and, most of all,
(d) a far more enjoyable game, since the majority of development time was spent
beefing up the originally pitiful AI routines and debugging code, rather than
writing that Mouse-interface code which takes 8 years under DOS.
That should be sufficient evidence to allow the chance that lesser graphic-intensive
games would benefit from Windows, from both the users and programmers points-o'-view.
As just one example: Battlechess for Windows. Need I say more? 'Wow' is the only
word for _that_ piece of software. I don't know if the programmers preferred Windows,
but I know the users did. (compared to the DOS version?)
So, examining the heavily graphic-intensive games: To continue with Strike Commander
as the ultimate resource-gobbling, accelerator-testing, texture-mapping beast of
gaming so far...
First of all, how many Strike Commanders are there out there? Granted, those are the
most enjoyable (at least, from a programmer's view: I still get giddy staring at
Underworld's texture mapped walls <"how did they _dooooo_ that?"> :) ), but they
are also a small majority of the gaming world.
But that sidesteps the point: why run SC under Windows?
From the programmers POV, there isn't much point in writing it under Windows, since
the odds are that they're going to be using their own proprietary graphics routines,
and tend to shy away from anything standardized. But on the other hand, they do
get the benefits of libraries upon libraries of pre-written code for user
interfaces, CD-management, Flat memory models, Virtual memory, and an enormous user base
(SC in Windows? _I'd_ buy it!). Which leaves us only with those portions of the
game which draw really fast.
Couple 'a points on this: (1) If you're zooming around space, blasting
Kilrathi while sweating and swearing, do you really _need_ that Excel document
sitting in the background? Put another way, would you rather run your game on a
386 or a 486? A 486, of course, and if the game requires that much blasted power,
then you're gonna give it to it (sorta like sacrificial offerings; "Oh mighty Origin:
I offer you this 16 Megs and Card of Acceleration" ;) ). So now you've got one
CPU-intensive program running. So the only thing that game programmers are giving up
is direct control of the video board, since their game now has the vast majority of
the CPU cycle. For this, I'd point the programmer in the direction of the Multimedia
Kit for Win 3.0 and up, which gives you a bunch of routines that tie directly to the
driver (AVI, etc), giving very fast (and standard) access to the video card.
There, unfortunately, I've got to stop, since I have to admit that some games will
still require more than the computer can offer. But this is only for the time being,
as graphics accerators and Local buses are quickly becoming the norm. Then the majority
of graphics-intensive games will be BitBlting as fast as from DOS, and those companies
that started writing games now will have the head start to capitalize on it.
Granted, it'd be nice to be able to run 16 Strike Commanders at the same time now, but
then it'd also be nice to be able to sit down and play it on a 286 under DOS. For those
games that require that much power, you've just got to give it to them.
> Anyways, I don't think a game is really necessary for
> Windows. Even if there were Windows games, I don't think it'd be very
> practical. Try running Strike Commander on Windows. Why???
I agree, a game is _not_ __really__ necessary for Windows. Or DOS. Or the
Amiga. etc etc etc. But with the amount of the Windows Entertainment
Packs that sold, I'd imagine that almost every company out there is at least
strongly considering making games for Windows...
I _definitely_ welcome any responses to this: But please, no flames - this is a
cool area for discussion, and I'd love to discuss (not duck and fling)
Finally, for those of you who have actually gotten this far, I'm looking into the
possiblity of creating some code for Sierra-esque games under Windows...Seems like
a cool type of game that has lots of graphics, but doesn't require all that much
computing power (just drawing one sprite every once in a while)...anyone wanna
help? The code'll just be thrown out onto the net when it's done, so anyone wanting
to join a discussion on it would be more than welcome; just email me! If there are
enough responses, we can have the discussion on rec.games.programmer...
Jeff Simon
jef...@microsoft.com (no, I'm not biased at all! Really! Well, maybe a little :) )
Windows Everywhere: Froasted-sugar-coated-Windows...Coming this fall!
Disclaimer: These opinions are mine - mine!mine!mine! and Microsoft can't
have 'em! (Nor, by the way, are they related to Microsoft in _any_ way other
than pride).
(PS notice how artfully I sidestepped the question? :) )
John Munsch
>My point is, why? Why try to
>run an action game in windows? You'd just be wasting the computer's resources
>trying to run two processor intensive software at the same time which may
>cause problems. Try running your important business software and a game at
>the same time. OOPS! The game crashed! Now you've lost data. Bye bye job.
>(worst cast scenerio). Anyways, I don't think a game is really necessary for
>Windows. Even if there were Windows games, I don't think it'd be very
>practical. Try running Strike Commander on Windows. Why???
I thought I had given a dozen good reasons "why" the other day but I'll try
to make my point again. Those of us who wish to do such a thing want to do it
because:
1) Portability to Windows NT opens the game up to a wider hardware
market. How many platform independent games are you familiar with
at the present time? Unix is one of the few operating systems with
a wide choice of boxes but there are very few or no commercial games
for it because it lacks the chrome that it needs (i.e. joystick,
sound, motion video, etc.).
2) I don't have to keep reinventing the wheel. If everybody decides
that 24 bit is the way they want to go, let them. My game doesn't
care about anything except that their hardware meet certain performance
minimums. If I go around worrying about the graphics hardware all of
the time then I'm going to spend much of my time writing code to deal
with Mode X, Y, or Z when I really need to be spending time on the
computer opponents (a frequent complaint in Computer Gaming World).
Obviously, similar statements can be made about digitized audio, MIDI
music, and memory management (a very difficult subject under DOS, just
ask Origin).
3) Why do I have to be running another "processor intensive" app at
the same time as my game? Why can't I just want to be alerted about
mail when it comes in or be able to free up some space on my disc when
I want to save a game and there is insufficient room?
4) "The game crashed" is not a valid concern for the future. Windows
continues to add more protection in each subsequent revision.
Eventually we will be running a protected version of it (probably
the Windows currently code named "Chicago") and one application will
be unable to take down the system.
5) As we progress into the future, I can offer my users a
standardized interface that they are already familiar with. Do you
know how to use the online help under Windows? Probably. Do you
know how to use the online help in Chris Crawford's _Patton Strikes
Back_? Probably not, and anyway, it usually crashes my system. It's
a shame it has bugs in it but that's the price you and your users
have to pay when every game house has to reinvent the wheel over and
over again.
6) If Windows is going to replace DOS and I certainly believe that
Microsoft intends for it to (as do I :-) then it will need games just
as much as it needs any other kind of software.
There's lots more reasons but these are just some of the more obvious ones.
If you don't want to write games under Windows, I'm not likely to convince you.
I want to and I believe that customers will ultimately want their games under
Windows. They've clearly already become convinced that they want all of
their business apps there. It's only a matter of time...
John Munsch
Chris Hecker
This has been a great thread, and people here have been following it.
Contrary to popular belief, we _are_ interested in enabling game-style
graphics under Windows.
With that in mind, what do you guys want from a graphics API standpoint?
The only things you can rule out are double buffering and direct access
to the hardware (for obvious reasons). Given those constraints, how
should GDI be extended for game graphics?
The number of posts to this thread proves people want to write games for
Windows; the same reasons it is a good idea to write a word processor
for Windows apply to games. Feel free to describe in detail what's
keeping you from doing it.
Chris
Philip Brown
>This has been a great thread, and people here have been following it.
>Contrary to popular belief, we _are_ interested in enabling game-style
>graphics under Windows.
Wow :-)
>With that in mind, what do you guys want from a graphics API standpoint?
Well, if you'll excuse an X programmer who has only dabbled with MS
Windows (But ported "MULE" to it as a class project)...
Better bitmap handling.
It was a bear to do what is convenient in X:
Writing to a memory-only pixmap, and updating that to the screen when
needed.
More Device Contexts, of course...
Possibly driver-level support for sprites?
--
--------------------------------------------------------------------
"Tea: a Noxious brew of various oriental leaves, containing toxic acids.
Personally, I rather like it." (paraprhased from Dr. Who: Peter Davidson)
ph...@cats.ucsc.edu ph...@soda.berkeley.edu
Jim Seidman
>With that in mind, what do you guys want from a graphics API standpoint?
>The only things you can rule out are double buffering and direct access
>to the hardware (for obvious reasons). Given those constraints, how
>should GDI be extended for game graphics?
This may sound silly, but I'd love to see error diffusion dithering built
into the GDI. That would allow me to greatly simplify some of my
color-depth dependent code.
Also, while it's not game-specific, it would *great* to have a message when
your window is about to be overlaid by another window so that you could
implement your own backing store.
If you're serious about making games feasible under Windows, get together
with Keith Laepple and Greg Levin there at Microsoft. They've spent enough
time talking to the guys who write Flight Simulator to know their beefs
about Windows graphics.
--
Jim Seidman, President
Cornfield Computing, Inc., 410 Hilltop Road, Champaign, IL 61821-7328
Ask me about our professional contracting services for MS Windows.
Paul H. Kahler
>
>This has been a great thread, and people here have been following it.
>Contrary to popular belief, we _are_ interested in enabling game-style
>graphics under Windows.
Way to go microsoft! Hopefully, the company will go under anyway :)
>
>With that in mind, what do you guys want from a graphics API standpoint?
>The only things you can rule out are double buffering and direct access
>to the hardware (for obvious reasons). Given those constraints, how
>should GDI be extended for game graphics?
Since double buffering isn't gonna happen, how about a method to do block
transfers (of arbitrary sized rectangles) to the screen. Later, when video
card makers get a clue, they can include some DMA hardware to do this. Then
we can keep our multiple buffers in system RAM and blast them out for the
same effect as double buffering. The transfers should allow you to copy an
arbitrary size rectangle from and arbitrary sized virtual screen to the
actual screen which of course can have different resolutions. TI has this
on the TMS340X0 graphics processors as an assembly instruction! You guys
would of course support it in software for a while.
Also, support line and Triangle generation which could later be pushed
off on hardware also. I would prefer texturemapping too, and larger polygons.
Face it, just look at a Silcon Graphics machine and see where graphics
hardware is going. If you can't support this kind of stuff, then you better
call the unemployment office real soon. Face it, windoze is too slow, and
there is an opportunity here to get REAL graphics standardization in the
PC world (which by the way is where windows belongs. Keep NT off my ALPHA!)
>The number of posts to this thread proves people want to write games for
>Windows; the same reasons it is a good idea to write a word processor
>for Windows apply to games. Feel free to describe in detail what's
>keeping you from doing it.
A friend & I have been doing our first Xwindows game... X is faster than
NT can ever hope to be, but yes, it isn't a true GUI
>
>Chris
Later,
Paul
ANETA COSTIN
Okay, we already have a very useful StretchBlt() call, which
lets you draw your graphics to any size and acheive resolution
idependance. The wonderful thing about this call is that hardware
acellorators do it _fast_, with the same source code. Of course, you
usually pre-stretch all you bitmaps fisrt anyways and use just plain
BitBlt() when actually drawing anyways...
But how about a MapBlt() call, that would map a bitmap to an
arbitrary quadrilateral - i.e. this, if done fast in hardware, would
enable you do fast texture mapping.
Needless to sday we need a 3D graphics API, but from what I hear
you guys are already looking into that (Open GL,perhaps?)
Also, we need to be able to read the vertical retrace,
preferably to get an interupt on it. There should be a high-resolution
timer callback, similar to the MDI timer API, but it should allow you to
do display I/O, not just sounds output and PostMessage(), as is allowed
now. This way, you don't have to worry about jerky animation becuase of
the iregularily of WM_TIMER messages (not a problem under NT, however).
It is already easy to size your window to grab the whole screen,
without title bars, etc, and even disable Alt-TAB if you want to, so that's not a problem.
How about control over which bitmaps are chached, for hardware
accelerators that cache images. We could tell it what we use often
rather than have it try to figure it out.
What we REALLY need, the limiting factor, is a FAST BitBlt()
call! This is where it bogs down! Perhaps you could make a
RestrictedBitBlt() function that only handles images that are an even
number of bytes wide, and bitblts only to a byte boundry (i.e. you would
pre-shift all of your sprites, and pick the right one every time you
drew it.) How about a fixed mode that allows masked copies, rather than
hvaing to do an AND bitblt and an OR bitblt as you do now, such as
MaskedBitBlt(HBITMAP hb, HBMASK hm, int x, int y, .. etc).
Yeah, basically, some retrace stuff and MaskedBitBlt() and
RestrictedBitBlt(), or, better yet, RestrciedtMaskedBitBlt()!
And a MapBlt() function, to enable hardware texture mapping.
cs931003 aka Jonathan Shekter, from sunny Toronto, Canada
Chris Magagna
>The only things you can rule out are double buffering and direct access
>to the hardware (for obvious reasons). Given those constraints, how
>should GDI be extended for game graphics?
>
>The number of posts to this thread proves people want to write games for
>Windows; the same reasons it is a good idea to write a word processor
>for Windows apply to games. Feel free to describe in detail what's
>keeping you from doing it.
Well, right now the thing that's keeping me from doing it is lack of time,
and lack of money to buy a Pentium/66. If you could fix either of these
I'd be grateful :>
Better bitmap manipulations: Provisions for doing rotations, skews, and
other standard transformations.
Better 256 color mode support. One of the most common questions on
comp.sys.os.windows.programmer is 'how do I display a 256 color bitmap?'
Right now you have to use LoadResource() and mungy code to get them in
memory. Making LoadBitmap() load a 256 color bitmap directly, without
dithering to the system colors, would be great.
Better access to the underlying video subsystem. I know you can't give me
direct access to the video, and I wouldn't want it given the number of
different systems out there, but it would be great to have Windows send me a
message or call a function at the start of the vertical retrace, so I could
know when it's okay to do a big BitBlt or ScrollDC without causing flicker.
Another nicety would be an extension of GetDevCaps to include data on how
fast the machine's video is. I'm not exactly sure how I would do
this, but something along the lines of 'this machine can display 15 frames
of 320x200 video per second, at the resolution and color depth it's in,' so
I don't have to determine this myself every time someone runs my game.
That's all I can think of right now. I actually _am_ writing a game for
Windows, but saying it's in its infancy stages would be too kind. It's more
in its can-almost-sit-up-but-mostly-just-drools stage. More will surely
follow...
Chris
Brian W. Hook
> Contrary to popular belief, we _are_ interested in enabling game-style
> graphics under Windows.
> With that in mind, what do you guys want from a graphics API standpoint?
> The only things you can rule out are double buffering and direct access
> to the hardware (for obvious reasons). Given those constraints, how
> should GDI be extended for game graphics?
Well now, quote #2 kind of invalidates quote #1 doesn't it? I liken it to
"We at Volkswagen would really like to enter the world of competitive Grand
Prix racing and would like your suggestions on car design. The only things
you can rule out is an aerodynamic body and powerful engine. Given those
constraints, how should it be designed to win races?"
Well, that Volkswagen's change of winning a race is only possibly by
killing all its competitors so it can limp to the finish line. Which seems
like Microsoft's attitude also.
Honestly and seriously, how in the world can you expect a good interactive
arcade game that doesn't support double buffering and direct access to the
hardware? Hell, the last one could almost be lived with, but you take a
performance hit. For many many years to come I think games will be using
good old DOS+extender. People will just have to have a FAT partition and a
boot disk to play their games.
And don't tell me it's impossible to allow access to the hardware. Look at
Linux and SGI's Irix -- they both allow limited access to hardware. Hell,
SGI can double-buffer in stereo per window.
> The number of posts to this thread proves people want to write games for
> Windows; the same reasons it is a good idea to write a word processor
> for Windows apply to games. Feel free to describe in detail what's
> keeping you from doing it.
The reasons to write a word processor for Windows:
1. Large market
2. Device independence for output
3. If you don't no one will buy your word processor
Well, that sort of applies to games also? So, the reason I should write a
game for Windows is because I would hope to A.) sell a lot B.) get device
independence for output and C.) everyone will be running Windows and you
won't even have the chance to boot vanilla DOS.
*sigh*
I guess those are compelling reasons to write games for Windows -- not
because you want to write a good game, not because you want to write the
best game, not because you want to stress the hardware to the max and get
cool graphics -- no, the reason you write for Windows is because it will be
Microsoft(r) Approved(tm) and won't be eradicated in Microsoft's New World
Order(tm).
Brian
--
//----------------------------------------------------------------------------
// Brian W.K. Hook "Stop! Stop in the name of all that
// ( b...@beach.cis.ufl.edu ) which does not suck!" - Butthead
//
// finger b...@beach.cis.ufl.edu
//----------------------------------------------------------------------------
Brian W. Hook
> NT can ever hope to be, but yes, it isn't a true GUI
Neither is Windows.
Robert J.C. Kyanko
>The only things you can rule out are double buffering and direct access
>to the hardware (for obvious reasons). Given those constraints, how
>should GDI be extended for game graphics?
Why are you ruling out double buffering? Great workstations have double
buffered windows. Granted this requires some hardware support. But
if Windows/Chicago/Windows NT doesn't support it, it'll never get done.
The game could query the hardware capabilities via API to see if it's there.
I think you need to look where graphics is going -> faster, better, faster,
better, more features, low-cost texture mapping in hardware, etc. Texture
mapping should eventually be supported as well. In just a couple of years
there are going to be $300-$600 real time texture mapping video cards. The
industry leaders in real-time simulation are headed this way with some
really impressive stuff (like GE/Martin). Have you seen/heard about this
new SEGA real-time texture mapping hardware for ~2k? It's coming very soon.
It's expensive this year, maybe next, but not the year after. Why not plan
ahead? Just my IMHO.
--
Yes, of course everything I say is my personal opinion!
Robert J.C. Kyanko (r...@rjck.oau.org or r...@rjck.UUCP)
Jerry Shekhel
:
: Well, if you'll excuse an X programmer who has only dabbled with MS
: Windows (But ported "MULE" to it as a class project)...
:
: Better bitmap handling.
:
: It was a bear to do what is convenient in X:
: Writing to a memory-only pixmap, and updating that to the screen when
: needed.
When I ported my game Chomp from X to Windows, I found it very easy to do
just what you say. In fact, I found it easier and more flexible with Windows
than with X.
About possible GDI enhancements for game programming, I really don't see
much at all that's necessary. BitBlt() is essentially all Chomp ever calls
once the window and device contexts are set up. If I understand correctly,
BitBlt() should take advantage of local buses and coprocessors if available,
so it should be possible to use it for moving larger areas (like backgrounds)
on the fancier video cards. The only thing I can think of which would be
very helpful for fast games is some sort of video beam synchronization
capability. Something like a BitBlt() which guarantees that it'll wait until
the beam is out of the window before doing its thing.
--
+-------------------+----------------------------+---------------------------+
| JERRY J. SHEKHEL | Molecular Simulations Inc. | Time just fades the pages |
| Drummers do it... | Burlington, MA USA | in my book of memories. |
| ... In rhythm! | je...@msi.com | -- Guns N' Roses |
+-------------------+----------------------------+---------------------------+
Jerry Shekhel
:
: Why are you ruling out double buffering? Great workstations have double
: buffered windows.
:
The thing is, with a local bus and a decent blitter, you can do effective
double buffering (with BitBlt()) without all the extra bitplanes and video
RAM. The only problem is video beam sync.
One thing I don't understand is why people are asking for things like
a 3D API and texturing/shading in the OS. It's not like these things
are available when you program games in "normal" environments (DOS, consoles).
The challenge is always to come up with your own routines that are optimized
for your particular needs and execute a lot faster than any generic library
could.
: Robert J.C. Kyanko (r...@rjck.oau.org or r...@rjck.UUCP)
Brian Goble
environment...for some developers it's worth it, for some it's not.
The same is true for game players...some like and want Windows games
and some don't.
I wanted to develope games for Windows so I created WAP (Windows Animation
Package). I created my first Windows shareware game with it (MicroMan -
Adventure 1: Crazy Computers) and have gotten a fair amount of feedback
on it from players and developers.
Now that this thread has gotten interesting, I'd really like to get some
feedback from everyone on what I have done. I really feel that I have
created the closest thing to a DOS-style arcade action game for the
Windows environment using WAP. I have seen a few other games that do
have some decent animation...but it's not true sprite animation (ie,
no masking over the background for "see-through" areas, no overlapping,
etc.). There have also been some decent vector-style games like
Hyperoids which was very nicely done as well.
When creating WAP, I didn't sit around and try to think of how to get
around all the video hardware limtiations that Window imposes...and I
didn't get mad at Microsoft or hope that they would improve things
in the future (since that wouldn't help me do something now).
I just used what there was. Heck, people used to write games for CGA
as the main platform...no page flipping there either :)
Anyways I invite all of you reading and/or participating in this thread
to check out WAP/MicroMan-Adventure1 and tell me (or this thread?) what
you think.
Now, I do fully realize that no arcade action style game under Windows
will ever compete with a DOS based arcade-action game. I'm just trying
to show that it is possible to create something...I think it's pretty
decent...what do you think? Is it "good" enough?
I would be happy to hear comments/criticims on game play, graphics, sounds,
etc. but I'm really more intersted on the subject of the sprite animation
used by the game. Is the sprite engine implemented by WAP good enough
(powerful ? enough) for games under Windows? Sure there's a gap between
this and DOS-based arcade-action games but is the gap so big that people
won't be satisfied with Windows games are does WAP help close the gap so
that people would enjoy a game like this?
I should probably also mention that I don't think it will ever be possible
to do a large-aread scrolling game under Windows.
Anyways, email or post anything...I'm really interested in the topic of
games under Windows.
Oh yeah, for those of you who are still with me way down hear, here's where
you can find MicroMan - Adventure 1. The file to get is MICRO1.ZIP:
ftp.cica.indiana.edu in pub/pc.win3/games
ftp.wustl.edu in usenet/comp.binaries.ms-windows/v3
gatekeeper.dec.com in .2/micro/msdos/win3/games
jum.kaist.ac.kr in pub/pc/win3/games
monu6.cc.monash.edu.au in pub/win3/games
For those interested in more info about WAP, check out the file, MICRO1.TXT
(contained in the micro1.zip archive). The first half talks about the game
but the second half of the text file talks about WAP. Don't hesistate to
send me email (go...@u.washington.edu) if you have any specific questions...
Thanx,
-Brian Goble
--
==)------------
Brian Goble | go...@hardy.u.washington.edu
"Finishing a close second means you didn't win."
------------(==
Brian W. Hook
Your asking Microsoft to plan ahead? Sh-yeah, right!
Mike Copley
16-bit API on top of a 16-bit DOS Kernel, does not allow
direct access to the screen, offers no efficient double-
buffering support (only limited support through memory and
device-context handlers), supports no page-flipping, fills a
meager 100 or so polygons a second (depending on the video
driver), has no real sprite support, does not support screen
scrolling (only limited window shifting functions through
the use of scroll bars), requires amjor application overhead,
Windows is a GREAT platform for games...
Mike C.
Jeff Simon
> With that in mind, what do you guys want from a graphics API standpoint?
> The only things you can rule out are double buffering and direct access
> to the hardware (for obvious reasons). Given those constraints, how
> should GDI be extended for game graphics?
How about a refresh bit? (yeah, I know...just wishful thinking :) )
Texture mapping? Map a bitmap (whatever format) to an arbitrary shape?
Is it possible to write simplified dirty-bitmap Blitting code? ie let the
driver deal with overlaps, etc?
How about a function which returns the relative performance of the video
card, who's return value can be used to set the level of detail in the game?
Jeff
Disclaimer: The above opinions are a result of my begin a product of the
system, and unrelated to Microsoft in any way. Blame the government!
> Chris
Brian W. Hook
>One thing I don't understand is why people are asking for things like
>a 3D API and texturing/shading in the OS. It's not like these things
>are available when you program games in "normal" environments (DOS, consoles).
>The challenge is always to come up with your own routines that are optimized
>for your particular needs and execute a lot faster than any generic library
>could.
Well, if that logic held true then SGI's wouldn't have GL distributed with
them. The reason a 3d API is necessary AND desirable is that, to a certain
extent device independence is built in, so whatever the video card has
built in can be used. If someone has a video board capable of doing Z
buffering or 3d transforms in hardware, why not let the API handle it and
you not have to worry about it? Also, what if you want to write, gasp, a
GAME and not a 3d library? Why should you start from scratch? Yes, you
may eke out a bit more performance with your optimized routines, but then
again, maybe you are doing something completely wrong because you're new at
it and maybe the 3d api knows how to do somethings better than you?
Brian W. Hook
> as the main platform...no page flipping there either :)
Rather a significant point -- arcade games under Windows are roughly at the
same state arcade games were in 1983 for the PC. This is what some would
term a Step Back.
> Now, I do fully realize that no arcade action style game under Windows
> will ever compete with a DOS based arcade-action game. I'm just trying
> to show that it is possible to create something...I think it's pretty
> decent...what do you think? Is it "good" enough?
And therein is the problem -- since when is "good" enough enough?
Jerry Shekhel
:
: >You can. Most of Windows exists in the form of DLLs, parts of which can be
: >discarded whenever necessary. Assuming the user desn't keep switching
: >between your game and some other big application, Windows' resident
: >overhead will remain pretty small.
:
: This is true, but if the user WON'T be switching between my game and some
: other big application why are they running Windows -- just for my game?
: I'd rather have them run DOS. Also, Windows memory management sucks.
: Supposedly Win32 will alleviate some problems with this, but I'd rather DOS
: extended 32-bit ptrs than Windows' HANDLEs.
:
The thing is that more and more people are doing lots of their work in these
graphical environments -- Windows, OS/2, NT, NextSTEP, whatever, and they don't
want to have to exit out to DOS (and possibly switch machines) to play a
game. Programming for these environments has many advantages, not the least
of which are device independence and portability to other platforms.
:
: > Of course not, but think for a minute. Complexity is irrelevant. The
: > point is that Windows does *not* "steal" CPU cycles, as Windows bashers
: > love to say. Under DOS, you have the CPU 100% of the time. Under
: > Windows you have it *at least* 99% of the time. What's the difference?
:
: I question the 99% rule....Windows is a lot of code maintaing a lot of
: stuff, and I just can't see how it can possibly be using up that little of
: CPU time. But then again, unless I have some verified stats one way or the
: other I won't discount your claim.
:
Windows doesn't have preemptive multitasking. A Windows application cannot
be interrupted; it can have 100% of the CPU if it wants, but then it ceases
to be well-behaved. All it takes to be well-behaved is a call to PeekEvent()
once in a while. In my game, where the main loop is very small and takes
very little time to execute, the overhead of calling PeekEvent() every time
through the loop is 1%. In a more complex game, where the cycle takes longer,
this PeekEvent() would represent an even smaller percentage of the CPU time.
:
: > Cheap SGI-like hardware is still a long way away. And it's not like the
: > Windows API is set in stone. In 3.1 there are hundreds of API functions
: > which weren't in 3.0 (mostly dealing with multimedia). It's an extensible
: > system.
:
: On the first point, it has nothing to do with hardware. Whether your
: underlying window system supports double buffering is a design issue.
:
The Windows API could be extended to support double buffering. Easily.
:
: As for the second point, how many WindowsFuncExEx() calls can we have before
: someone says "maybe this needs a redesign".
:
Come on. The 3.1 API contains hundreds of new functions. Some are extensions
of old functions as you describe, but most are brand new.
:
: Technically, that's what OS/2
: was supposed to do -- Ray Duncan, Charles Petzold, etc. have all stated
: that the OS/2 GPI was far better designed than the Windows API.
:
Yes, I think so too -- the OS/2 GPI is much more complete than the GDI. I
don't know what benefit that holds for game programmers, however. For
example, OS/2's transformation matrices are nice, but they're way too slow to
be useful in arcade-style games.
:
: And Microsoft is not ready to throw compatibility to the wind in the name of
: advancement of technology. Witness NT's stock Win 3.1 interface, probably
: the worst interface short of DRI GEM I've seen on a machine in quite a
: while.
:
Microsoft doesn't have to throw compatibility to the wind in order to extend
the API.
: >
: > Windows allows access to the underlying hardware through the API. What's
: > real-time 3D, anyway? As far as I know there are two steps. First you
: > generate an image. This is usually a computation-intensive task that is
: > not affected by the OS. Then, you blast it to the screen. Windows can
: > do that just fine (with VLB and a blitter).
:
: Well, the steps are true, except that you may not blast from main memory
: direct to screen....say you were ( gasp ) double buffering. You would be
: rendering directly to video hardware to a second page, but can't have that,
: that wouldn't be compatible ( you can see that their dogmatic approach to
: maintaining compatibility makes business sense, but I'm arguing technical
: merits here ). Also, a main memory->screen burst does NOT involve the
: blitter. This is why coprocessesd video cards are frowned upon for
: use with NextStep/486 -- the video transfers are main memory->display
: memory, and blitters simply blit from video memory to video memory.
:
You're right about all this, but there is nothing in Windows that says
that this capability (double-buffering) cannot be implemented in the
future. I don't see why you're singling out Windows here -- none of the
other PC window systems support this either. This makes sense, because
double buffering in window systems is something that *must* have hardware
support, and there's currently none.
: >
: > Ridiculous. How is UNIX better designed for real-time 3D than Windows?
:
: UNIX as an entity doesn't exist. Various versions of Unix are better
: designed because they were designed as real time operating systems. Irix
: and OSF/1 both come to mind.
:
Irix?! It's an absolute dog! SGI's graphics hardware is great, but Irix?
Honestly, have you used it much? I use it every day (I'm typing this on a
4D/35), and I think it sucks! You can't even run X effectively on this thing
without 32MB RAM.
:
: Irix is designed as a real-time operating system that,
: for example, can support an extra CPU for interrupt management. It lets
: the programmer do what he needs to do. It works with GL and GLX which
: support double buffering per window. Windows NT is not oriented towards
: engineering, period.
:
I still don't understand what makes you think that double buffering support
cannot be added to Windows. As for GL, yes, it's powerful, but it has to
be the worst API design I've ever seen bar none. Have you ever used it? It's
truly archaic.
:
: But finally,
: fundamentally you cannot write a simple POSIX app under Windows and do good
: 3d support....it's all or nothing. You have a WinMain() or you don't. A
: programmer needs to know GL and maybe a tiny bit of Unix to write a good 3d
: program under Irix/GL, however you MUST be a good WINDOWS programmer to
: write a WINDOWS program, once again, Microsoft dragging programmers into
: its camp by brute force.
:
Yes, you can write a 3D app using a few GL calls, and it will have great
3D graphics, but no user interface. If you want a user interface, you have
to use some other API in conjunction with GL. And yes, you have to write a
lot of code just to get started in a Windows application. In the end,
however, if you want your application to be marketable (to have good graphics
*and* a good UI), you'll end up writing about the same amount of code on
any system.
But hey, let's get off these window system wars and get back to discussing
game programming.
: Brian
Mark Berry
: either a) set your palette to all black [if running in 256 color mode,
: i.e. a mode that SUPPORTS palettes] or b)draw everything in black (i.e.
: just a black pen, a black brush, SetBkColor(RGB(0,0,0)), etc. Like, DUH.
Be aware that many device drivers special case drawing in black (and
white for that matter), so that you may end up with a frame rate that is
unobtainable in normal, ie mixed color, use. A better choice may be to have
a blue opening screen for example, and draw everything in blue whilst trying
to determine the frame rate.
____ . ______.
| \ / \ | / \ Mark Berry
| | /---| | /---| Data Connection Ltd,
|___// | |/ | m...@datcon.co.uk
C O N N E C T I O N
Jeff Simon
> Well, when we talk games I'm referring to games that people want to see now
> instead of regressing to CGA and 1982. Why the hell have a 486/66 running
> Windows 3.1 when the most advanced game you will have is going to be
> Asteroids for Windows? I don't care what Windows excuse is, the fact
> remains the same that GIVEN THE SAME HARDWARE that a game under DOS is
> going to be able to do a lot more than under Windows. Those
> "top-of-the-line simulations" are things like UW II, X-Wing, Strike
> Commander, etc. -- the best selling games out there in the PC market.
I agree with all of the above ; but my point was that, instead of attacking
Window's deficiencies _now_ as you've been doing, this thread could (and
should) be aimed at finding out what people want from Windows in the (near)
future. The majority of your posts were blasting at what Windows can't do now,
not what it _should_ be able to do.
This is a situation somewhat similar to the IBM 15 years ago: it was a horrible
game machine that really only existed for business applications. Back then
(in them olden times:) ) the Naysayers were shouting 'Why the hell have an IBM
running DOS when the most advanced game you will have is going to be Castle
Adventure?' Yes, at the time, an Apple was a far better machine for games, but
look at it now...
The gamers back then were ignored, and it remained a bad machine for games for
quite some time, while game companies slowly hacked their way through to good
games. Here, though, you've got a direct request for ways to improve Windows
as far as game programming goes...Wouldn't it be best to take full advantage
of that?
> I'm simply pointing out the flaws in Window's architecture. I'm sorry if
> "constructive criticism" implies criticizing something that can be
> improved, but I'm just telling it like it is.
Exactly! Criticize (sp?) what can be improved. But rolling your eyes at
the idea of games under Windows doesn't help us make it a better platform for
games!
> And I'm discussing why I don't believe Windows is a viable game platform
> for real-time 3d simulations.
Yeah, I agree that this thread can go several routes...Maybe break it into
a I-don't-like-Windows thread and a here's-what-I-Want-from-Windows thread?
> Bashing = pointing out floaws?
No, Bashing = Comparing Windows to Dog turds, while the thread focuses on
how to improve Window's game engine. It is a fine line, but if you want
Microsoft to listen to game programmers, then anything abusive is just
not going to get taken serously. Simple Pyschology! (Despite what people
say, a frosted dog turd _is_ more aesthetic than a non-frosted one :) ).
No, I don't mean sugar coat it, but then again, don't coat it in venom,
either!
>
> > Besides, Even you would have the agree that some games could benefit from
> > running under Windows...Civilization is a prime example; those games which don't
> > suck every resource your computer has dry could use everything that windows
> > has to offer!
>
> I think that games that use a windowing system would be optimal for running
> under Windows....this is obvious. I'm NOT dogmatic in my approach. I
> think Empire, Civilization, most strategy games, etc. would be ideal for
> the Windows platform. But I'm not arguing that. I'm arguing Underworld,
> Wolf3d, etc.
Cool, we agree on this part! Same as above - Shouting at someone about
what's wrong with something doesn't help, tho. Telling someone, 'Ya know,
this kinda sucks, and I want _this_...' could make Windows a far better
game engine in the future (I mean, realistically, who could have forseen UW
when we were all playing Zork...)
Jeff
jef...@Microsoft.com
Disclaimer: The above opinions were purchased for $2.95 at Costco (Aisle seven,
next to the Vegetables). They are _not_ related to Microsoft.
> Brian
Matt Saettler
>After reading through some of the other replies here, I had another thought
>for you Microsoft folks...
>
>In addition to the possibility of adding some capabilities to Windows to aid
>game developers, there's something else you could do that could help a lot.
>Create a document that explains all the best techniques and tricks for
>programming a game under plain old Windows 3.1, and make it widely available.
>'cause it seems to me that in addition to programmers wanting to do things
>under Windows that aren't practical, there's also some things that are quite
>doable but tricky to figure out.
>
I already wrote one a couple of years ago...
available for anon. FTP from ftp.uu.net in /vendor/microsoft/multimedia
look for graphx.zip.
It's also on the MSDN CD as well as many other places (CI$).
Matt Saettler/Microsoft
------------------------------------
I speak only for myself.
John Munsch
>to the hardware (for obvious reasons). Given those constraints, how
>should GDI be extended for game graphics?
So far I've been on the "Yes, I'd like to see games under Windows." side but
I'm afraid I've got to jump your case for this. Rule out double buffering?!?
"For obvious reasons"?!? I'm sorry, but that's just STUPID! Get a clue pal.
I realize that most of Microsoft (or at least the part that I've dealt with
over the years) is extremely introverted and very rarely looks at another
platform but take a moment to pull you head out of the sand and take a look
around. The Amiga has had double buffering for more than half a decade now
and guess what, it's a standard part of the operating system. Yes, that's
right, the windowing system supports it, just like Microsoft Windows could if
you bother to try. Sure, not every card has enough memory to do 1024x768x24bit
with two buffers. But many, if not most now feature enough memory to do
640x480x256 with two distinct buffers, but it does a fat lot of good...
Chris Hecker
SIGGRAPH this last week. (a couple items germane to this thread: Sense8
was showing the WTK running under Win31 at a respectable clip, and
two vendors (Intel and Pellucid) had OpenGL running under Win31 at a
less respectable clip:)
So far there have been a lot of good suggestions. People want a
vertical retrace interrupt, bilinear texture mapping (sometimes called
(incorrectly) affine texturing), a full 3D library, better palette
manipulation routines, sprites, video profiling APIs, and even
error diffusion dithering.
One request stands out above the rest, though, and that's a faster
DIB to screen blt. Game developers want to do their own drawing for a
number of reasons. Usually it's because they have certain special
optimizations available due to the restricted nature of their problem;
a general purpose graphics library simply couldn't take advantage of
these techniques and stay general. These developers will draw to an
offscreen DIB (Device Independent Bitmap - a fancy name for an
application managed bitmap) and then blt it to the screen. This
technique is used under DOS (Underworld 1 and 2, for example), and
can be used under Windows using the SetDIBitsToDevice and StretchDIBits
calls. These calls are notoriously slow, though (sometimes orders of
magnitude slower than BitBlt, which takes a DC as its source).
Hopefully we can address this problem in the near future in a backwardly
compatible way.
For now, it would be useful for me if people would rank the following
functions in order of importance for implementing games under Win31 (and
beyond):
1. fast DIB to screen blt
2. bilinear texture mapping - map a rectangle in the source to a quad
3. Gouraud shaded triangles
4. transparent blt
5. masked blt
6. built in halftoning - you assume an RGB device and we dither
7. a vertical retrace interrupt
8. a sprite library
9. video profiling APIs - we'll tell you how fast you can blt
10.faster metafile playback
11.convex polygons
12.OpenGL - a general immediate mode 3D graphics library
Thanks again for all of the responses.
Chris
Chris Hecker
> > The only things you can rule out are double buffering and direct access
> > to the hardware (for obvious reasons). Given those constraints, how
> > should GDI be extended for game graphics?
> hardware?
Perhaps you aren't aware that Ultima Underworld (one of the high
performance games you listed) draws to a bitmap, then copies it to the
screen. Besides the blt (which is not rocket science in mode 13h) and
the original palette allocation there is no direct access to the video
hardware. No page flipping, no double buffering (they may wait for
retrace, but I doubt it considering the size of their window). I'd call
Underworld a "good interactive arcade game."
Do you have any well-thought-out and constructive comments or suggestions?
Chris
Brian Hook
> For now, it would be useful for me if people would rank the following
> functions in order of importance for implementing games under Win31 (and
> beyond):
> 1. fast DIB to screen blt
Duh.
> 2. bilinear texture mapping - map a rectangle in the source to a quad
Nice, but can be done by the programmer if necessary.
> 3. Gouraud shaded triangles
Hmmmm, how high level? Are we talking:
void WinGShadeTriangle( float a[3], float b[3], float c[3],
float v1[3], float v2[3], float v3[3],
float light_source[3],
float r, float g, float b );
?
Or are we talking:
void WingGShadeTriangle( int a[2], int b[2], int c[2],
UCHAR rgb1[3], UCHAR rgb2[3], UCHAR rgb[3] );
The latter seems feasible ( interpolation ) but the former seems like a
waste of time.
> 7. a vertical retrace interrupt
Useless maybe? I don't know, it would seem that having to write an ISR for
Windows is kind of asinine. Maybe a callback procedure guaranteed to
execute in N amount of useconds after VRT? Could Windows support this type
of "real-time" extension? Also, why would it be needed if you were using
Windows supported blit routines -- wouldn't they check?
> 8. a sprite library
Overkill.
> 9. video profiling APIs - we'll tell you how fast you can blt
Reasonable.
> 10.faster metafile playback
> 11.convex polygons
Yeah, and an optimized triangle routine, but really, these aren't necessary
since people are going to render themselves to their own bitmap.
> 12.OpenGL - a general immediate mode 3D graphics library
Perfect. How about an OPENGL.DLL? Make it an option ( like MM Windows was
an option ) then integrate it with the core system so those who need/want
it get it automatically.
Brian
--
//----------------------------------------------------------------------------
// Brian W.K. Hook "Stop! Stop in the name of all that
// ( b...@beach.cis.ufl.edu ) which does not suck!" - Butthead
// ( 72144,3662 CI$ )
//
// "Oooooooo-la-tec! Ooooooo-la-tec!"
//
// finger b...@beach.cis.ufl.edu for more info on my 3d graphic project
//----------------------------------------------------------------------------
Jerry Shekhel
:
: So far I've been on the "Yes, I'd like to see games under Windows." side but
: I'm afraid I've got to jump your case for this. Rule out double buffering?!?
: "For obvious reasons"?!? I'm sorry, but that's just STUPID! Get a clue pal.
: I realize that most of Microsoft (or at least the part that I've dealt with
: over the years) is extremely introverted and very rarely looks at another
: platform but take a moment to pull you head out of the sand and take a look
: around. The Amiga has had double buffering for more than half a decade now
: and guess what, it's a standard part of the operating system. Yes, that's
: right, the windowing system supports it, just like Microsoft Windows could if
: you bother to try. Sure, not every card has enough memory to do
: 1024x768x24bit with two buffers. But many, if not most now feature enough
: memory to do 640x480x256 with two distinct buffers, but it does a fat lot
: of good...
Unless I'm missing something really big, there's NO WAY the Amiga supports
true double buffering in a window. For an Amiga app to do double buffering,
it has to take over the entire screen, and that's not what I'd call "window
system support for double buffering". Silicon Graphics machines support
double buffering in a window, but the hardware for that kind of stuff is far
from cheap.
Jim Seidman
>For now, it would be useful for me if people would rank the following
>functions in order of importance for implementing games under Win31 (and
>beyond):
>
>1. fast DIB to screen blt
>2. bilinear texture mapping - map a rectangle in the source to a quad
>3. Gouraud shaded triangles
>4. transparent blt
>5. masked blt
>6. built in halftoning - you assume an RGB device and we dither
>7. a vertical retrace interrupt
>8. a sprite library
>9. video profiling APIs - we'll tell you how fast you can blt
>10.faster metafile playback
>11.convex polygons
>12.OpenGL - a general immediate mode 3D graphics library
The fast DIB to screen blt is probably the most important of these as
regards speed. (And if you do this, please make sure that it's implemented
so that the blt goes from top to bottom, to minimize the tearing effect.)
As far as programming ease, a transparent blt would be *very* useful.
really wonderful.
Faster metafile playback, built in halftoning, etc. would be nice too. Some
of the other things on the list would probably (let's be honest here) be
derided as being "too general purpose... not well enough optimized for
games... etc..." even if you did implement them.
One thing I didn't think of before that I'd like to see is improved timer
functions. timeSetEvent is all nice and dandy, but since the callback
is called at interrupt time, it's of limited use. Sure, you can use
PostMessage() in the callback, but then you're still dealing with a fairly
unpredictable delay.
Stig A. Olsen
In article <1993Aug08.0...@microsoft.com>, che...@microsoft.com (Chris Hecker) writes:
>
> For now, it would be useful for me if people would rank the following
> functions in order of importance for implementing games under Win31 (and
> beyond):
>
> 1. fast DIB to screen blt
> 2. bilinear texture mapping - map a rectangle in the source to a quad
> 3. Gouraud shaded triangles
> 4. transparent blt
> 5. masked blt
> 6. built in halftoning - you assume an RGB device and we dither
> 7. a vertical retrace interrupt
> 8. a sprite library
> 9. video profiling APIs - we'll tell you how fast you can blt
> 10.faster metafile playback
> 11.convex polygons
> 12.OpenGL - a general immediate mode 3D graphics library
>
> Thanks again for all of the responses.
> Chris
I would put the vertical retrace interrupt higher on the list. Making
smooth animations would be so much easier. If one could call the DIB-to-
screen-blit routine from the VR-interrupt we could be guaranteed smooth
updates. And make sure there is support for several DIBs, not just one, that
way one could implement double-buffering without special support.
Whatever you do - make the routines fast!
--
| Stig A. Olsen | st...@ifi.uio.no | "Ja til EF" |
| Never hit a man with glasses. Hit him with a baseball bat. |
John Munsch
>Unless I'm missing something really big, there's NO WAY the Amiga supports
>true double buffering in a window. For an Amiga app to do double buffering,
>it has to take over the entire screen, and that's not what I'd call "window
>system support for double buffering". Silicon Graphics machines support
>double buffering in a window, but the hardware for that kind of stuff is far
>from cheap.
No, you haven't missed anything, you are quite correct. On the Amiga you can
only double buffer an application that has its own screen (or at least that
is the way it was under AmigaDos 1.3, which is the last time I programmed it).
I don't believe that I claimed that AmigaDos had "window system support for
double buffering". I believe that I said that it had "support in the operating
system". However, even if I did, that doesn't change what I think about this.
Try this on for size and see how it fits. Most accelerators these days are up
in the 10 WinMark area these days, many are much higher and have recently
gotten a big boost from VL bus on most of the new machines. If you could turn
on double buffering then this scenario might play out:
1) Double buffering turned on by an application.
2) All of the screen area is copied to a second memory area that
will be our second buffer.
3) When an application that doesn't have double buffering turned on
paints, the GDI calls are duplicated for both memory buffers. This
will effectively cut the speed of the card in half but lots of the
current generation cards and many future ones would still be very fast.
4) The application indicates that it wishes to draw to the non-visible
screen. All GDI calls go only to that screen when issued from the
application in question.
5) The app requests a buffer switch.
6) Etc.
Obviously, this restricts you to only one double buffered application at a time
and there are probably a dozen other holes to be dealt with but its something
that should at least be seriously considered rather than blown off. I can't
count the number of times that I've had to tell users or testers that that
tearing effect was "just something Windows does and I can't fix it". Even when
Microsoft has obvious opportunities to do double buffering they don't take
them.
Let me give you a "for instance": I asked why they didn't at least do double
buffering when they switch an AVI to full screen using DisplayDib. Especially,
since they were making changes to DisplayDib at the time anyway for AVI
support. They reply was, "Nobody suggested it." NOBODY SUGGESTED IT! It
bloody suggests itself when you run an AVI with a lot of screen update and
looks like its being wiped onto the screen as some kind of special effect!
John Munsch
P.S. Please note that I am not yelling at you , I'm just venting a little