Re: [Enigma-devel] Maemo Port for Nokia Internet Tablets

[Ronald Lamprecht]

Hi,

Ronald Lamprecht wrote:
> > I thought I had eliminated all algorithms with quadratic behaviour on 
> > the number of actors :-(
>
> Gosh - it can even be done in O(1) with a constant that is less a 
> hundredth of the old algorithms constant!
>
> But first I am 
> interested on the performance reports for the Maemo.

Pipeline wrote:
> I tried your change, and it works wonders  :)   This does resolve hollows 
> performance issues i was having, and Enigma II-20 meditation was as smooth at 
> finish as it was at start (which was very smooth).

It is no wonder - for 10 meditation marbles it is a speedup by factor 
greater than 10000 on the ending condition tests. Please do not blame 
the authors of this code written for earlier releases - it is absolutly 
o.k. to make use of inefficient algorithms in the start phase of a 
project. The old code had the big advantage of keeping the logic locally 
what did make the code very stable to general changes.

> Maemo does have limitation on actors as it seems Enigma III : 60 bad flowers 
> and E-III:38 bright dots are (and always were) unplayable on maemo. 
> Interestingly bright dots on first load (without user input) the clock ticks in 
> 2-3 second lapses.  I suppose thats merely the cost for detection of 50 or so 
> 'potential' collisions.

"Bad Flowers" has several time consuming features:
- 26 actors with many collisions
- 40 rubberbands that need to updated every timestep
- 2 tops that get attracted by all other actors depending on the distance

The last feature should cause the biggest load on the system.

"Bright Dots" fits bad to the current collision detection algorithm. I 
did exchange the former quadratic algorithm, that checked every actor 
pair, by a linear sweep algorithm. For code and general efficiency 
reasons I did choose a vertical sweep line. Unfortunatly "Bright Dots" 
has a lot of "dots" vertically aligned :-( This inefficiency could be 
solved by choosing an odd aligned sweep line like "11x+3y" - but the 
code would get scambled and distance calculations would get worse.

BTW with the trunk version you can make use of the new option --showfps. 
Note that the engine will first slow down the display and use all 
computing power for the physical simulation. That is the reason that 
just a few additional actors can suddenly slow down the display nearly 
to zero.

Greets,

Ronald