Hi Bill,
I'm replying via the devel-list so we have this archived automatically...
On Fri August 15 2008 01:55, you wrote:
> Mmmm... progress. :) What sort of images would you use for the "marbles"
> ... ? What that be a texture wrapped around a 3D sphere? Or would it be
> more like animated sprites with enough frames to make it appear as if
> they're rolling?
That's exactly what I was already thinking about... basically, the "marbles"
should have the look of colored / textured 3D spheres (with a kind of "snow
ball" look), yes. But the question is, if we should use real bump mapped 3D
spheres or just 2D projections / sprites (with enough frames to animate them
smoothly).
The "problem" with the first approach is that it will require real 3D
operations for the animation, which isn't ultra fast in the software case,
but "okay" for all modern processors (would have to use matrix
multiplications for 3D transformations (rotations), and normal
additions/substractions for movements (translations)). And we would need to
calculate the projections to the 2D plane for any marble item to display it
on the screen... that's probably the best method with regard to
correctness -- but also the most "expensive" one. The major problem here is
the bump / texture mapping and lighting in software. With HW accelerated
OpenGL support that would mean nearly no cost, but we wanted a game which
will also run fine on a SW only / non-OpenGL / unaccelerated systems, so it's
probably too much for that... well, I could do it dirrently for both cases,
and of course, we could also let the user decide which features to turn on
and off...
The latter case (2D sprites) would make it much easier and faster also for the
software case. We could calculate the bump-/texture-maps beforehand with an
image processor and wouldn't need to do that at runtime. But it would mean a
lot of static images to include in the project, and we couldn't use dynamic
lightings (only "pseudo dynamic lighting" by changing the brightness of parts
of an image and/or adding some "glass effects" / reflections to it at
runtime - which would demand some processing power, but it should be possible
to do it in a precalculation step). Again, we could let the user decide which
effects to turn on and off... the major problem with this approach is that it
wouldn't be possible/practical to precalculate _any_ possible angle in which
a marble could have to be displayed, so it would mean that the
marble-animations would look more "synthetic" than in the 3D case. But on the
other hand it's questionable if a user would recognize the difference while
playing... and we could agree on some assumptions to avoid this problem (see
below).
It's also possible to implement both approaches, of course -- deciding which
one to use either through the OPENGL build option or with a the UseOpenGL
setting (or an individual setting, because even with OpenGL turned on it also
depends on the availability of direct rendering, of course). But doing both
would mean a lot more work -- probably useless doubling of efforts, because
of the following...
I vote for 2D sprites! It should be fine to have "snow ball" like marble
sprites for ~180 degrees (assuming that the marbles/textures/bump-maps use
rotational symmetry, which would even avoid the problem with the rotation
angle!). A "frame skip" of 5 should be sufficient, meaning to require at
least 36 sprite images per marble. If we do all textures / bump-maps the same
and just use different colors, it would be sufficient to have those 36 images
in white; I could create the rest on-the-fly in a precalculation step --
colorization, plus pseudo dynamic lightning / reflections / other effects. It
should be possible to run smoothly this way, even on systems with a slower
graphics subsystem.
Have fun, René
--
René Reucher
Tel: +49 160 7115802
FAX: +49 6359 205423
ren...@ba...
http://www.batcom-it.net/
It is only the great men who are truly obscene. If they had not dared
to be obscene, they could never have dared to be great.
-- Havelock Ellis
|