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

[Till Harbaum / Lists]

Hi,

there's definitely an improvement in that level. It now shows ~3-4fps most of 
the time, but it's still not solvable that way.

What about the double/float issue? Would it perhaps make sense to replace any 
occurence of doubles within the game with something typedef'd so we can 
easily change this to float if helpful. Or would you like us to test if 
floats actually give us a performance benefit before doing something like 
that?

Pipeline, the version currently in my repository is a) based on these latest 
patches and b) was made of the patch set i send around. So you're welcome to 
give it a try.

Till

Am Samstag 23 Februar 2008 schrieb Ronald Lamprecht:
> Hi,
>
> Pipeline schrieb:
> >> Another level that I would like to hear comments from Maemo users
> >> concerning the performance:
> >>
> >> Enigma VI#89 Magic Triangle
> >>
> >> How fast is this laser level - is it critical? I found some points
> >> that I could improve concerning laser calculations.
> >
> > This level is around 0-1 fps with --showfps on and rather unplayable.
> > After playing on desktop i see why you mention it.  Yes i suppose that
> > is alot of laser collision detections/hits which might benefit from any
> > improvements you might have in mind.
>
> With trunk r1046 I hopefully replaced all O(n^2) and O(n log n) laser
> algorithms by linear ones concerning the number of set laser beam items.
>   Could a Maemo user please check the influence on speed of this level?
>
> > Just to give you an idea of typical framerates had on maemo n800/810
> > devices, Tutorial #1 idles around 45fps (as do most nonanimated levels).
> > Enigma I #92 Security Guards now surprisingly hovers around 45-50 as
> > does E III #44 Rush Hour Traffic.
> >
> > Alot of physics intensive levels also remain playable in 6-40fps range
> > depending on collisions, triggers, bands, etc.  Let me know if there are
> > any other levels you want me to check (or recheck :) since the remainder
> > of examples i have found so far are 'combinations' of factors and/or are
> > still fairly playable.
>
> Any level showing a framerate of 6 fps and more will run realtime
> without any restrictions concerning the physical engine. When the load
> gets too high the display steps aside and all power is used for the
> physics simulation. The levels get unplayable because the shown display
> is out of date.
>
> > I'm sure you probably get all types of feature requests but I have to
> > wonder what level of difficulty would be involved in creating feature to
> > record gameplay for review/replay.  Could all the real time inputs be
> > captured and replicated, and if so do the actors use any randomizations
> > that would be difficult to replicate?   Might be interesting just for
> > the meta-simulation aspect, and useful for future multiplayer.
>
> That is one of the major features of the release that follows 1.10. I
> did a lot of the necessary preparations within the last year, e.g. I
> reengineered all random number usage to be able to feed back the same
> random numbers that fit to the recorded events. Sometimes I refer to the
> event recording as "journaling".
>
> Concerning the multiplayer game you find my basic concept described in
> http://lists.gnu.org/archive/html/enigma-devel/2006-03/msg00012.html .
>
> Greets,
>
> Ronald
>
>
> _______________________________________________
> Enigma-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/enigma-devel