Accelerated 2D APIs [was: Re: hw filled polygons & hw l

Let me explain. Let’s say I want to write a topdown scroller like ‘1942’. I
have this 3D model of the plane I want to display.

If I go the 2D way I render the plane in various positions (tilting to the
left, tilting to the right, multiple steps of a short loop (in 1942 you can
make a loop to dodge the bullets), multiple steps of the plane, burning &
tumbling down. After a while I have a few dozens of images and I can animate
my plane in all the various ways I want.

Now, if I go the 3D way, I can simply use openGL to draw my plane in any of
the above postions (with simple rotation & translation operations), any time
I want… I can even blend the animations. E.g., while my plane is tumbling
down, I can still tilt left/right etc… (bad example, why would I want to
do that :slight_smile: ). This is what I meant with ‘you don’t have to pre-render all
graphics’. Can you see this does simplify things?

While this may simplify things, what about the graphics quality? Is the
plane going to be as nice rendered in 3D compared to the pre-rendered plane?

Bryan

Tue, 05 Dec 2000 Bryan Pope wrote:

Let me explain. Let’s say I want to write a topdown scroller like ‘1942’. I
have this 3D model of the plane I want to display.

If I go the 2D way I render the plane in various positions (tilting to the
left, tilting to the right, multiple steps of a short loop (in 1942 you can
make a loop to dodge the bullets), multiple steps of the plane, burning &
tumbling down. After a while I have a few dozens of images and I can animate
my plane in all the various ways I want.

Now, if I go the 3D way, I can simply use openGL to draw my plane in any of
the above postions (with simple rotation & translation operations), any time
I want… I can even blend the animations. E.g., while my plane is tumbling
down, I can still tilt left/right etc… (bad example, why would I want to
do that :slight_smile: ). This is what I meant with ‘you don’t have to pre-render all
graphics’. Can you see this does simplify things?

While this may simplify things, what about the graphics quality? Is the
plane going to be as nice rendered in 3D compared to the pre-rendered plane?

That’s exactly what I was thinking. On a hot 3D card (ie one that’s suitable
for serious Quake III playing on big monitors), yes it can look almost as
good, at least in high resolutions, but you’ll have to work on that engine
code to get there…

OTOH, if really thinking about making modern arcade
class 2D games, who’d expect not to put almost as much work into it as one would
have to put into a decent 3D game? Once upon a time, 2D and 3D games weren’t
all that different when it came to development time or hardware requirements…

My guess is that some sort of “2D is easier than 3D” illusion has formed as a
result of 3D being State of the Art, while 2D games more or less stopped
evolving in the late Amiga days. (This is probably slightly less true for
game consoles! Until now, at least. The PS2, Dolphin, XBOX etc generation may
change this.)

Anyway, as to my idea of what to use OpneGL for: Initially, I didn’t intend to
use OpenGL for anything but fast blitting with alpha, anti-aliasing, and
sub-pixel accurate positioning. However, the cards that can do that can also
rotate and scale with high quality. (Interpolation is required.)

You still need to apply ligting in real time, after rotation, but I think that
can be done very nicely by raytracing a set of rotated lightmaps separately,
and then cross-fade between them, blending them over the rotated sprite. (Note
that if the lightmaps are sharp and detailed, you need to animate them together
with the object as well… You also need more lightmaps/rotation to deal with
sharper highlights.) Various hybrids between vertex lighting, per polygon
lightmaps (splitting the objects up) and “lighting sprites” seem more appealing
considering the huge amount of full-sprite lightmaps you’d need for rotation…

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

Back again to waste some more bandwidth! >:-)

Tue, 05 Dec 2000 Bryan Pope wrote:
[…]

While this may simplify things, what about the graphics quality? Is the
plane going to be as nice rendered in 3D compared to the pre-rendered plane?

Speaking of quality… I’m not going to accept 3D acceleration as a way to get
fast rendering at the expense of control and quality. In that case, I’m back to
software rendering. (Which seems to imply hacking drivers, as there’s no
sysRAM->VRAM DMA in Linux 2D drivers currently, and the bandwidth is useless
when using the CPU.)

A few things that still worry me:

* In past times, some 3D accelerators produced different
  results from others in some blending modes. Is this more
  standardized now? Can I ask the average OpenGL driver about
  that kind of stuff and/or do all (proper) OpenGL drivers
  comply with how the reference implementation does things?

* Is it guaranteed that the transformation factors are
  processed with full accuracy? If not, it's not going to be
  fun... (Sprites and tiles can be off by a pixer in size or
  texture alignment and that kind of things. Ouch.)

* Interpolation. Most current 3D cards do interpolation or
  similar when scaling and transforming textures. However,
  they're not using the same algorithms! Some use bilinear
  interpolation, while others use filters, and this produces
  slightly different results. It's common that texture
  rendering quality is compromized for cost and/or
  performance reasons, even on the top 3D cards... More
  importantly, this may affect the greater detal of 2D games
  more than it affects 3D games.

Not having experience with all that many 3D cards, I haven’t observed cases
where games look obviously different on different cards. (No bigger
differences than what different monitors and contrast/light settings make.)

Are these problems practically eliminated or at least possible to deal with, or
are we “Open2DGL” guys headed straight towards a massive wall…?

As to dealing with the problems, if it should be required:

* Differences in texture sharpness can be compensated for by
  preprocessing the textures or by tuning the texture/screen
  resolution ratio, at least for non-procedural textures.

* The same applies to blending, alpha channels and vertex
  lighting.

* Translation errors can probably be compensated for in our
  transformations.

Of course, this implies that we build a “correction database” over all cards
that don’t comply well enough with the reference rasterizer, and preferably
autodetect these cards when installing and/or running the games.

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’