tuxor-devel

[tuxor-devel] 2D vs. 3D marbles (was: Re. blueballs)

[R. R. <ren...@ba...>]

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

Re: [tuxor-devel] 2D vs. 3D marbles (was: Re. blueballs)

[R. R. <ren...@ba...>]

On Fri August 15 2008 09:10, R. Reucher wrote:
> 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.
Thinking about it again, it should even be sufficient to render less than 
that... because if we use a rotational symmetric texture / bump map, a set of 
images for 90 degrees / a quarter of a full rotation should be enough, too.

But we should perhaps narrow the angle skip to 2 degrees, which means that we 
would need 45 images of the marble sprite to animate the rotation.

And... depending on the kind of texture / bump map, this could also be 
narrowed down to 45 degrees with a 1 degree "angle skip" (also 45 images). 
This should really be enough for a smooth animation of rotating "snow 
marbles" :)...

Have fun, René
-- 
René Reucher
Tel: +49 160 7115802
FAX: +49 6359 205423
ren...@ba...
http://www.batcom-it.net/

A truly wise man never plays leapfrog with a unicorn.