|
From: R. R. <ren...@ba...> - 2008-08-15 07:12:39
|
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 |