You are not logged in. Please login or register.
Another question before I start my Tuxracer trial: Many procedures like steering, braking, animations, speed, sliding sounds etc. depend on the ground texture. Ice for example is faster but needs a larger turning radius than snow or rock. Therefore you must be able to detect the kind of texture at all points of the scenery. Is that possible?
For the texture property I don't know, it maybe require to use a special bullet physics feature.
Also, in 3d hardware textures are loaded into the 3d card memory, trying to access texture pixel in software would require to also keep the texture loaded in normal memory. You could use vertex-color, using ray-tracing with a ray going down from the player is easier than reading a texture pixel.
But right now for sure you can use mesh-volumes and detect if you are inside to change the friction, speed etc.
You can also divide the collision mesh and define the correct friction value for each portion.
One way you can do it, if you want, is to create a "map" image of the racetrack and save it as a bitmap in memory. You can either create this dynamically from the level, or load it in as an image. You can then poke and prod the pixels to your heart's content.
I'm not saying this would be a good idea. Much better to mark the areas with collision volumes or some other tags. But hey, you could do it 
Last edited by Nistur (2012-03-06 22:27:30)
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.
I had this dilema at Christmas. I originally was intending to roll my own engine last year (got a good deal of the way through it too) but I realised I couldn't handle gameplay coding as well, on top of a full time programming job. This little brain can only take so much programming 
If it helps your decision at all, I can explain the research I did and reasons etc for me choosing Maratis over other more pedigree engines.
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
Ok, so, I guess first of all, the features I needed from my engine were quite simple, I wanted the highest flexibility in terms of platform as possible. There was one issue here, much as mobile gaming can now be quite lucrative and can get a decent amount of attention... I am not sure if I'm allowed to do mobile games, specifically iOS games, due to my contract at work. I don't think it would cause an issue unless I started making a lot of money out of the game, but because of this I was focusing on desktop OSs with posibility to branch into consoles at a later date if needed.
Secondly, I wanted some flexibility with the engine itself. I have no issue working with closed source proprietary software when it's needed however, previous experiences with such systems have made me prefer an open system where I could change things if I really need to (instead of getting the reply, "sorry, you can't do that with X" on forums/IRC)
Lastly, I needed a community. With my game being a personal project, I don't (currently) have other programmers to bounce ideas off, or help decypher source code and APIs. It doesn't matter so much that the code and APIs are clear and documented (although it's always nice) but more that if I am incredibly stumped with an issue, I could post and say "hey, how would you do Y, I've tried it in the following ways" and get an answer this decade. Again, had bad experiences with other projects.
So, next up is what engines I considered. Well, first up was UDK. A great all-round package. Has some very impressive results and it's relatively cheap for indie development. However it fell down on one point for me. I'm a Linux user. I've done various talks about playing games on Linux and developing games for Linux. Much as I know the linux gamer market share is pretty abysmal, I would feel wrong not contributing to the games available for Linux. Since Epic no longer support Linux, this was out.
Second was the open source id Tech 4 (iodoom3) Again, had great results, far more than I could possibly need. Also, it contains Carmack-code... which adds a certain something to it 
The issue with this was, mainly, the license. Now, I have nothing against GPL at all, in fact, I think it's a great thing, but it is a little constrictive for indie game development. I fully intend to release my game source at some point, but would be more difficult to get any compensation for the development (I'm currently out of pocket after commissioning artwork)
I didn't bother to look at OGRE again. I used it for a group project at university. OGRE itself is well documented. Has a thriving community. More than good enough for the job. The issue with OGRE is also something you could consider a strength... the plugins. There are plugins for anything and everything. They are all... hmmm... how to put this nicely... well... some of them are crap. We found that after trying to use 2 plugins (which were little more than wrappers for external libraries) we would have saved time to integrate the libraries directly. They're usually half written to solve a specific problem for one person and then released as a generic solution. By the time you've found the issues, you've wasted a lot of time.
I briefly considered Unity, but it has the same issue as UDK in that it doesn't support Linux. Also a few other pet dislikes with Unity, but largely irrelevant.
After coming to these conclusions, I spent a while looking at what other options were available (do I sound too picky yet?) I found Crystal Space and, like you, found it to be a bit of a headache to get anything working, so I decided it wasn't worth it. I had a look at the Sauerbraten engine but decided that repurposing a first person shooter engine for my third person adventure game would be more work than was worth it. XNA had the issue with Linux support.
Then I found Maratis. After sounding so overly critical about other engines, I don't want to make it seem like Maratis is the solution to all my problems, it has quite a few downfalls. However, the main thing that led me to say yes to Maratis is that, the first thing I did was email Anael to ask a couple of questions. He replied quickly in a friendly manner and was helpful and competant. After that I sat on the forums a bit, firstly just reading and seeing the frequency of posts, the content of them, and later, responses to my posts. Again, I found the forum, although not exactly busy, to be reasonably active and helpful. The issues with Maratis that I came up with are firstly the lack of proper publishing support, something I ended up contributing to and the lack of extensibility in the engine. Now, I don't want this to sound wrong at all (incidently "Anael's Wrath" sounds like a good title for a video game... ) Maratis hasn't got a lot of bells and whistles. It does a job and it does it pretty well, but there's nothing extra. Also, the design of Maratis is sort of geared towards a small, sleek engine. Bulking it out with the plethora of features that can be found in something like UDK would for one, probably reduce the average code quality, but also increase the complexity of Maratis. You could technically put any extension work you wanted into the game plugin DLL, or standalone game project executable if that's what you wanted but that doesn't lend toward generalised solutions and reusable code. Anael then mentioned that he actually had a plugin system, but it was removed from the release. Of course, if the plugins were enabled again, it might lead to a situation similar to what I found with OGRE, where there are many sub-par plugins. However I think it's the right path to attempt, and I think Anael does too (I'm not putting any words into his mouth here )
I think this deserves a tl;dr... so here it is:
tl;dr: UDK - no Linux support,
iodoom3 - GPL too constrictive,
Unity - no linux support,
OGRE - *shudder*
Maratis - not as "complete" but active, open and friendly
I've tried many engines, and Maratis has all the specs I didn't find in other engines:
1) Written in C++
2) Usable with C++
3) OGG support
4) PNG support
5) TTF support
6) OpenGL support
7) OpenCL support
8) Bullet
9) Scriptable with LuaJIT
10) Usable with Code::Blocks and MinGW (because it makes around 8% faster code than VS, and compiles 30 times faster, and has better ANSI C++ support, and more C++1x features, and makes 64-bit code, and has native Linux support too)
11) Expandable Game and Editor with C++ plugin DLLs
12) Free
13) Source code
14) Active development and support
15) 32-bit and 64-bit Windows and Linux support
16) Android support (hopefully soon, or I could try to make it myself after testing the Linux version)
17) Support for own shaders
18) Fixed pipeline renderer support
19) Blender 2.5x exporter
20) Extremely fast (especially if you have seen the MinGW version)
Last edited by Lumooja (2012-03-09 16:03:11)
As an aside...
10) Usable with Code::Blocks and MinGW (because it makes around 8% faster code than VS, and compiles 30 times faster, and has better ANSI C++ support, and more C++1x features, and makes 64-bit code, and has native Linux support too)
20) Extremely fast (especially if you have seen the MinGW version)
Would love to get your version of this
Yeah, no problem. I can upload it somewhere on google sites, and also the .cbp project files for Code::Blocks IDE, so you can compile it yourself (and maybe anael wants to copy them into the official source too).
Last edited by Lumooja (2012-03-09 16:16:45)
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.
Compiling Maratis from source with MinGW needs only one little update: The latest FreeType 2.4.8. Everything else compiles with the supplied 3rdparty libs in the SVN trunk.
Bullet has very advanced collision handling (I love how you can configure it how to behave when bodies overlap, and the CCD (Continous Collision Detection) collision demo is simply amazing - you can shoot at insane speed and objects always hit), and with Maratis there comes even a demo which shows how it works. I think it's done with Lua though, but it should be not a big deal to make in C++ either. I will need it too for the game I am doing.
Last edited by Lumooja (2012-03-09 18:23:54)
I can't remember anything particularly taxing in tuxracer you couldn't just do in lua, apart from the menu maybe. Great game though
If you are wanting to write the game in C++ anyway, there is nothing I can foresee that might cause too big a problem, unless you want multiplayer, there is no networking support yet.
I don't doubt that writing tuxracer from scratch would be a daunting task, but why exactly couldn't you? I'm not sure I totally understand, C++ has no built in explicit types for vectors etc, as you have mentioned, but they are trivial to crested, if you choose not to use those supplied in a library you're using, for example your physics library. Maybe I just misunderstood something.
Network support is relatively easy to include as another 3rdparty lib. I would use SDL_net with a MMO handler. I have the source code somewhere, and can find it again on the net. They said they tested it with 30000 players and it worked very fast.
Which would be a perfect target for a plugin, incidentally
I can't remember anything particularly taxing in tuxracer you couldn't just do in lua, apart from the menu maybe. Great game though
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.
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.