I am considering writing a game for a project in school next quarter.
It will only be 2D but there are certain effects I want to include
(scrolling, bump mapping).
My algorithms for the effects are OK but not perfect. In 320x200 I get
81 FPS, which gives me some room for more effects. In 640x480 I only
get 22 FPS (the maximum FPS I can get for full-screen animation in
640x480 is 45 FPS, and that is a bit slow). Also, it only works fast
in 16 bit modes – Any other color depth would require SDL to translate
the color depth and that really slows it down.
Would I inconvience too many people if my program only runs acceptably
in 16 bit modes?
Yeah, is some cases, as there are targets that cannot switch between
different pixel formats. (That is, you need to change the system display
configuration to get 16 bit mode, unless that’s your default.)
Slightly less problematic in fullscreen modes, but the same restriction
applies there is some cases.
Are people turned off by 320x200 graphics?
Well, that depends on the quality… Keep in mind that most console games
are still using that sort of resolutions! Also keep in mind that the
average computer monitor is designed for at least 3 times that
resolution, and that that low resolutions are always line doubled on PC
monitors, so the old TV/video/arcade graphics tricks don’t work too
well… (No blurring; pixels become razor sharp and square, rather than
diffuse and round. Colors don’t “float” and mix horizontally.)
Anyway, for that low resolutions to look good, you have to be very
careful to use every single pixel to it’s full potential. One would
expect antialiazing and high quality, hand drawn or manually touched up
raytraced graphics. (Directly raytracing to that low resolution usually
results in either blurred details, or just no details at all - very
boring.) Alpha blending and various other effects at a reasonable frame
rate would help motivate the use of such low resolutions.
Finally, it might be a better idea better make it 320x240 instead of
320x200. It does mean that the chance of finding a real lowres mode
among the modelines of the average fbdev or XFree86 configuration is
slightly smaller - but then again, few distros come with a default
XFree86 config with <640x480 modes enabled anyway!
As to Win32, all cards I’ve used so far do have 320x240. Many also have
modes like 320x200, 400x300 and 512x384, but don’t count on those…
320x240 (50% of 640x480) is a standard vesa mode, at least as common as
the old VGA 320x200 these days, AFAIK.
Should I
try to get my algorighms running fast enough for 640x480… or should I
even bother since 45 FPS is the cap?
Well, fast code never hurts - there will always be users with less CPU
power than you, so it may be useful in lower resolutions as well.
Also, do note that the 45 fps limit does not reflect the power of your
CPU! It’s a result of things going wrong in the evolution of drivers and
hardware, which ultimately results in transferring data to VRAM being
very slow. Expect several times that frame rate when rendering into
system RAM.
Or; if your code kills another 23 fps while working in system RAM, you
might still have some work to do… (Reducing the frame rate by 50% means
that your code takes as long to run as the blit to VRAM - which means
that it takes as long as completely filling the screen with opaque blits
a few times over.)
This is on an Athlon 550, running Debian 2.2. I really would like
people with slower processors to be able to run it.
Depending on how much work you want to put into this;
1. Go for 320x240, and aim for super smooth animation and
high quality rendering, to make up for the low
resolution.
2. Go for the safe standard 640x480, optimize as much as
care to do, and accept the resulting frame rate. Keep
in mind that the "average PC" will be much faster by
the time your game is finished! ;-)
3. Hack an MMX version of your blitting code. Most people
have MMX (even pre-PII, and most non-intel x86 chips),
so it's a pretty safe bet these days. AltiVec would be
nice as well, but that's only supported by the later
PPCs - and PPCs aren't nearly as many as the x86es.
4. Support OpenGL, with procedural textures if required.
(But keep in mind that texture transfers are often
plagued by the same VRAM write bottleneck!) This
should take the insane load off the CPU, and should
provide decent frame rates on most 3D cards, even
including many of those that are already regarded as
collector's items. For the high end, OpenGL can give
2D engines *insane* performance!
My qualified guess would be that a combination of 1. and 4. would be the
best coding/result deal for fast action games, while 2. and 4. might be
better for slower games, where resolution and detail is more important.
3. is a hack to increase the potential range of players for a commercial
games - unless you just feel like hacking lots of MMX assembly. 
Quickest way to get a playable game up running would definitely be 1.
You already have the code, and it already seems to be fast enough for
reasonable machines.
Concentrate on gameplay, feel and nice, structured code first, and mess
with performance when you have a nice game with clean code. Doing it the
other way around usually results in Yet Another Dropped Project…
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 04 December 2001 00:27, Daniel W. Lemon wrote: