search

rushabhshah10 / opennero

Automatically exported from code.google.com/p/opennero
Other
0 stars 0 forks source link

Increase frame rate and use resources better #145

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
OpenNERO is currently somewhat of a hog for CPU resources - it only uses one 
core, but it uses it fairly heavily. This can lead to low frame rate on some 
systems and for some tasks/mods.

One possible place where things could be improved is the main game loop from 
Irrlicht engine, another is the Python embedding framework. We should profile 
these components to determine where the inefficiencies are.

Original issue reported on code.google.com by ikarpov on 1 Sep 2013 at 6:43

GoogleCodeExporter commented 9 years ago

Original comment by ikarpov on 1 Sep 2013 at 6:58

GoogleCodeExporter commented 9 years ago 
Are there specific cases that cause low FPS? I'm asking because Irrlicht seems 
to be doing good on its own. I have a slow (by modern standards: i5 3570k with 
integrated HD 4000) GPU and I get 200+ FPS on maps before adding any agents. 
One thing that I've noticed from profiling is that mIrrDevice->yield() in 
ProcessTick() takes up 25% of the CPU time (without agents present). This is a 
complete waste of time on multi-core systems.

Original comment by Luc4sDre...@gmail.com on 10 Nov 2013 at 8:42

GoogleCodeExporter commented 9 years ago 
Good suggestion - I removed the yield from the main game loop on trunk.

Original comment by ikarpov on 10 Nov 2013 at 7:38

GoogleCodeExporter commented 9 years ago 
Great, do you see improvement? Is it good enough to add collisions into
the game? In any case, we need to make another build for the final
homework so that people will get this improvement.

opennero@googlecode.com writes:

  >Comment #3 on issue 145 by ikarpov: Increase frame rate and use resources  
  >better
  >http://code.google.com/p/opennero/issues/detail?id=145

  >Good suggestion - I removed the yield from the main game loop on trunk.

Original comment by ri...@cs.utexas.edu on 17 Nov 2013 at 9:38