again: performance

[erin]

Firstly, this is open source, the project doesn't end because a founder disappears. Ideally they'll be contactable or be able to maintain/transfer hosting resources (if this place isn't already hosted on Sourceforge).

That's right, usually an open source project doesn't end abruptly. So we can hope that someone will issue the next release. The code is ready.

Again:

the performance issues will come down to expensive loops and misunderstood rendering techniques.

I agree now. I've rewritten the particles code (almost). The new code is simpler and faster but the particles are at least as nice as before. Now I'm going to check the trackmarks code.

[FreeGamer]

A good point. I wonder how much of the speed has to do with texture resolution. ETR has some pretty high resolution textures, and loading/drawing those can be ugly.

Are all textures square / factor-of-2? i.e. 256x256, 1024x1024 etc. That makes a big difference.

[erin]

Are all textures square / factor-of-2? i.e. 256x256, 1024x1024 etc. That makes a big difference.

Of course. I don't think that it makes sense to use textures with other ratio.

I wonder how much of the speed has to do with texture resolution. ETR has some pretty high resolution textures, and loading/drawing those can be ugly.

There are many conjectures about the performance. I've compared on a blank course:

256 x 256: ~117 - 120 fps
1024 x 1024: ~ 115 fps

With the low precision of fps mesurement in mind the difference doesn't seem to be very significant though. More and more I think that the performance problems are the sum of many unfavorable loops and algorithms. With the limited features of Tuxracer 0.61 the program runs quickly enough but additional options require to revise most procedures. Particles and trackmarks are convincing examples.

Another example: The "collision" detection is realized in a loop with all trees and items. That shouldn't be a problem even if there are more than 1000 trees. But in the second view you detect that this loop is called several times by the ODE solver, for each small timestep.

etc.

[FreeGamer]

So we can hope that someone will issue the next release. The code is ready.

If it's ready, why don't you do it? Or ask (use email) for the permissions to do it? Or state explicitly, "persons needed to compile release" in an announcement.

the performance issues will come down to expensive loops and misunderstood rendering techniques.

I agree now. I've rewritten the particles code (almost). The new code is simpler and faster but the particles are at least as nice as before. Now I'm going to check the trackmarks code.

Glad to hear you are more optimistic that it can be improved without making it look worse.

[erin]

Glad to hear you are more optimistic that it can be improved without making it look worse.

Yes, there's a great potential of enhancements, not only the algorithms. Lot of OpenGL options are not used in Truxracer / ETR: multi texturing (terrain rendering), more display lists for the common tasks (e.g. drawing trees), stencil buffer (shadow), perhaps shaders.

[StevenB]

Has anyone used the GNU profiler (gprof) before? I don't know how much information it will be able to give us since a lot of time is spent in GL calls, but I'm sure it will have some useful information. Hopefully I'll be able to post some results soon.