Tue, 05 Dec 2000 Dominique Biesmans 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.
Ok; not the way to go if you have a 3D accelerator around the corner of that
bus…
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…
Yep. That’s another one of the bonuses of using a 3D accelerator. 
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 ).
Because it would look cool!
Seriously, not needing to hardcode every single animation expands the game
design possibilities a great deal. Imagine a 2D platform fighting game (Double
Dragon style) where all characters are actually 3D or “semi 3D”, with skeleton
based or similar animation system… You could actually control every single
kick or blow with unlimited accuracy - and the silly "flip over and fly away"
style animations would be replaced with apparently physically correct animation.
This is what I meant with ‘you don’t have to pre-render all
graphics’. Can you see this does simplify things?
Yes, at least for games that would benefit in was like in the above examples.
However, do keep in mind that rendering 3D models with the same quality and/or
feel as pre-rendered (raytraced, GIMPed or pixeled) is very hard, even
disregarding that you have to keep the polygon count down. (You generally have
lots of models visible at the same time in a 2D game - and you have no LOD:
Allways rendering with full detail!)
And yes, if you use the 3D api for rotations, scaling, blending etc… you
can also shortcut some prerenderings, but you’d also have to deal with some
3D math in that case …
Well, this is basically a performance issue. If the 3D API is poorly optimized,
you can’t use it for heavy transformations, while if it’s hardware accelerated
(SIMD/array processor on the video card, separate card or as a CPU extension),
it would be a waste (and probably a slow-down) not to use it.
And then we have Direct3D Retained Mode… (Which is more similar to OpenGL
than Direct3D Direct Mode, but totally useless because of it’s total lack of
performance and control. Oh well, that’s what those who tried all three use to
say - I haven’t touched Direct3D at all myself, and probably never will.)
Basically people think very black-white about 2D versus 3D. Actually, 2D
games don’t really exist, they are just isometric views along a certain
axis, while movement is usually restricted to one plane (view axis often
perpendicular on that plane).
Yes. The main distinction (if any) IMHO is that true 3D requires texture
transformation (or just filled polygons…) instead of 1:1 blitting of
predrawn/rendered graphics. Of course, with this definition, many games cross
the boundaries slightly, which makes it even more obvious that there is no
strict distinction.
That’s why I think building on top of the same APIs and hardware that 3D games
use makes a great deal of sense.
Of course, I’m not saying either way is better than another, I’m just
thinking out loud here. I’m still trying to find out how I should tackle
this (2D-ish) game I’m planning to write right now
Well, for me, the choice is easy. (I’m also into doing some game coding - don’t
know if I’ll ever get the time to do anything playable, though.)
First, we have this frame rate deal. One could do some hacking to allow users
to try out a suitable modeline when installing the game, but that’s not really
solving anything, as it would limit both the quality of animation and the
display quality. Design for 60 Hz, and the user can choose "stroboscope mode"
or “ghost animation mode” (120 Hz, “double exponation”)… Design for 90 Hz,
and some won’t be able to play your game at all, at least if it’s using a
resolution that’s adequate for computer monitors.
Besides, if all of the above was solved, you can still only get certain
movement speeds to be absolutely smooth! (The scrolling background would be the
first priority.) Slow parallax scrolling levels will blur somewhat no matter
what.
Now, with sub-pixel accurate rendering, all of the above problems are gone.
Just make sure the refresh rate isn’t higher than the frame rate you can keep
up (if you can run full frame rate on the system in question at all - if not,
it just can’t be helped anyway), and then “sample” object and screen positions
(with interpolation or acurate calculations) from the physics engine at the
exact rendering frame rate. Everything will be perfectly smooth regardless of
refresh rate and speed, as long as the machine is fast enough.
As full screen sub-pixel accurate rendering is virtually impossible to do on
current CPUs in decent resolutions in full frame rate (ok, I have some ideas for
that too - interested?), the only alternative is to use 3D acceleration.
//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 -’
These characters are quite a bit
