Search options

libc6 2.13

Blender 2.62 runs on this machine without difficulty

I've compiled the sources from the svn trunk: the same error message

Ok, a nice game, especially for children. Simple rules and appealing ambience. But really great? I think, the program lacks some very important attributes. Here some more information.

- Except some kinds of rough trees, which are simply drawn with alpha textures, there are no objects in the scene. No buildings, no 3d trees, no stones and walls, no bridges, no obstacles, no other creatures etc. Such objects can be built with Blender, of course, but to use them in your own program you must convert the Blender output to an appropriate format. Doing this in C or C++ is much effort and you must have a lot of knowledge about 3d formats - too much for me.

- Even the character (Tux) is not a well-shaped object, it is completely built of spheres and ellipsoids. All parts of the body are icospheres with a lot of faces! That's not good. Shaping additional characters by using spheres is very intricate, much more than shaping them with Blender (see above).

- The physics engine comes from the first version of Tuxracer, written by Jasmin Patry 1999. It contains no collision code. There seems to be a collision with the ground but that's not right. In fact Tuxracer calculates the height at the current position and corrects the position when the character is diving into the ground. Height calculation is easily possible since the ground mesh is a regular (!) net of triangles.

For a better game we need collision with the ground, but most urgent is the collision with objects like bridges, ramps, rocks etc. Writing collision code is a great challenge, too great. Using bullet? Perhaps, I dont't know. Using a game engine with integrated collision? That's my question here.

- Finally the rendering. In Tuxracer there is a quadtree, but it is old and inefficient code. Each kind of texture is handled in a particular loop, and many different textures (e.g. > 8) slow down the race considerably. But it's faster than rendering the scene in a "brute force" way. Another disadvantage of the old algorithm: adjacent terrain tiles are blurred, the code lacks a nice blending.

You see, that's the situation. Sometimes I think, the best would be to give up the projekt. On the other hand, this classic game is too important to let it die. I'm going to start the last attempt.

Thank you for the posts. Finding out that other people have similar problems and experiences helps enormously. To speak about my own experiences: I don't know how many people have suggested to use Ogre. Some years ago I tried to install it, on Linux, of course.

Ogre needs lib A, B, C
A needs lib a, b, c
c needs lib aa, bb, cc
bb needs ...

After some days of downloading, compiling and installing libs the last dependencies:

xxx needs yyy, but in the latest version.
The latest version was not compatible with my glibc.
I asked the Ogre people: What to do ?
Answer: Your system is 2 years old, update it.

That time I used Debian, it was hard work to install and configurate the system to get it proper and expedient. Such a system grows over the months and I wasn't ready to put it at risk. Not for Ogre.

------------

Ok, there are a lot of reasons to use Maratis, though it is not complete yet. Now I could continue to ask: Is this possible? How does that work? And what about ...? Let me compress all the questions to a single question:

Your are familiar with Maratis, so do you believe that it will be possible to code Tuxracer with Maratis? Possibly you know Tuxracer, and if not, you can download the current Bunny-Hill version from my website:

http://www.txhome.de/tux/bunnyhill/down … nload.html

Why not going on coding the game with C++? Answer: There's no collision handling. The position, velocity and orientation of the character is merely corrected in each frame and it cannot collide with any object. The code has reached a limit.

No, not more than the reported error messages.

The computer is quite normal, with a x86 processer, a NVidia graphic card, with a running OpenGL etc. On this system I developed the C rewrite of Tuxracer. And OpenAL is installed, too (libopenal1). It's a 32bit system.

An my second computer I've Ubuntu 11.10 installed. I tried it on that machine, too. It runs !
A little problem with MaratisGame (starting without a game). I couldn't quit and had to stop the program with kill -9 xxxx.

Reinhard

Indeed, it might help. I'm tired of looking and asking around for the best lib or engine. What I really need is a good collision detection and a proper interface to react on collisions. And I need to link own C code.

Reinhard

At the moment I've to decide which libraries or engine to use - if any. So I'm evaluating the possibilities, but the size of the feature list ist not the most important criterion. Example: Crystal space is an extremely powerful engine and contains all (!) options I need (and more). But it's a monster. I had to install about 40 Linux packages and to compile 3 big libraries, und at last it doesn't work. A long list of error messages. The forum is as complicated as the code, and I found no way to register. After all I have to mind that the users of my game have to do the same install procedure. No, that's not practicable. Maratis seems to be clearer.

Oops, I think, something is wrong with me today. I tried to install the add-on that came along with the program package. Now, with the right add-on, it works.

Thank you and excuse me.