Menu
▾
▴
tuxor-devel — Tuxor development mailing list
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: R. R. <ren...@ba...> - 2008-08-15 09:28:54
|
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. |
|
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 |
|
From: R. R. <ren...@ba...> - 2008-08-10 12:18:49
|
Hi, I've imported the initial development framework for Tuxor to the SVN repository. To checkout the SVN code, do the following: $ cd ~/src (or whereever you put your sources) $ svn co https://tuxor.svn.sourceforge.net/svnroot/tuxor tuxor As always, just use "cd ~/src/tuxor; svn update" later on... There's really nothing useful yet other than the development framework and some code which basically compiles :). The required Qt revision is 4.4.0+, though (it's checked on the call to qmake). The current code would also compile with Qt 4.3.5, but as we'll need the Phonon API for sound & music, I've restricted it to 4.4.0+ right from the start. The multi platform support features of the build system are taken from QMC2 and basically the same (so for example, using "make DISTCFG=1" will also work in case of Tuxor). At least I now have something I can use to develop on... Bill, if you or Michelle have any design input like images, logos etc. and would like to add those to the project yourself, I can explain to you how this is accomplished with SVN. Basically it's just a matter of adding the resources/files to your local working copy / tree, tell SVN to add it to the repo ("svn add ...") and then commit your changes ("svn commit ..."). If your're not familiar with SVN, I'd recommend you read the SVN book first: http://svnbook.red-bean.com/en/1.1/index.html :-) Have fun, René -- René Reucher Tel: +49 160 7115802 FAX: +49 6359 205423 ren...@ba... http://www.batcom-it.net/ Receiving a million dollars tax free will make you feel better than being flat broke and having a stomach ache. -- Dolph Sharp, "I'm O.K., You're Not So Hot" |
|
From: R. R. <ren...@ba...> - 2008-08-08 08:11:41
|
Hi there, this is just a test and welcome message to the tuxor-devel mailing list to see if it's working as expected :)... Have fun, René -- René Reucher Tel: +49 160 7115802 FAX: +49 6359 205423 ren...@ba... http://www.batcom-it.net/ "By necessity, by proclivity, and by delight, we all quote. In fact, it is as difficult to appropriate the thoughts of others as it is to invent. (R. Emerson)" -- Quoted from a fortune cookie program (whose author claims, "Actually, stealing IS easier.") [to which I reply, "You think it's easy for me to misconstrue all these misquotations?!?"] |
