Re: [xmoto-dev] overall performance improvements

["Rasmus Neckelmann" <neckelmann@xxxxxxxxx>]

On 12/10/06, Kees Jongenburger <kees.jongenburger@xxxxxxxxx> wrote:
> I ran a few profiler sessions on the current cvs xmoto.  I am manly interested
> to know what the slower parts are of xmoto. This because I need the
> processing time
> to do the graphics :)

Nice, always wanted to do that, but never figured out how to do it on Windows :)

> Things like text drawing should cost less , and perhaps large parts of
> the minimaps can be cached.

Yes, the minimap rendering is painfully slow. First of all because it
doesn't use vertex buffers like the primary rendering. Doing so would
probably divide the rendering time by two. Furthermore on levels with
no moving blocks, it would be nice to simply have a texture image of
the level instead. On levels with a lot of moving blocks it would
likely be slower to use such an approach... At least on computers
without fancy graphics hardware.

My suggestion for an ideal minimap system would be:
- If there's OpenGL with framebuffer object support: Have a texture
image of the minimap (the entire level), and render the minimap to the
texture whenever something is changed. (this can be done very quickly,
almost entirely without involving the CPU)
- If there's OpenGL but without framebuffer object support: Have a
texture image of the minimap initially, but the first time a block is
moved the game switches to simply rendering the minimap directly each
frame - just like now, but optimized with vertex buffers.
- If there's no OpenGL, just do some suitable caching, depending on
how you implement the software rendering.

> But nedless to say that I would like the
> game to spend less time in the UpdateGamePlaying dWorldQuickStep.
> Anything gained here will be a great improvement of the cpu
> requirements for the game.
> I would like to know if there are easy wins to recude the load on ODE.
> I played with
>  PHYS_QSTEP_ITERS by lowering it to 5 and this helped a lot, but I
> don't know if the game with these settings would still be considered
> to be xmoto

xmoto 0.1.0 was made from scratch in approximately one month. My guess
is that half the time was used to prevent the physics from exploding
:)
I can't say whether making the physics less accurate will make it
unstable... Maybe under most circumstances it will work fine with
lower accuracy, but on very rare occasions it might blow up. It's
quite hard to test and why physics stink :)

Lowering PHYS_QSTEP_ITERS maybe has no negative consequences, so maybe
it's a good idea to try it - and simply see whether people start
having problems.
If it's done I'd suggest that it's set to 5 regardless of which mode
the game is run in - in that way more people will try it out, and
unstability would be easier to track down.

--
Rasmus Neckelmann