I've read that it's generally bad to use RTTI for performance-minded games. Particularly dynamic_cast because not only does it need to look up the object's real type, it needs to compare it against all possible downcasts to see if the requested type is valid. I don't know how possible it would be to try compiling with -fno-rtti at this juncture, though.scrawl wrote:On topic: Found out that most of the time in osg::computeLocalToWorld and osg::computeWorldToLocal (used a lot in our skinning and particle system code) is spent in dynamic_cast's.
OSG on steroids
Re: OSG on steroids
Re: OSG on steroids
This means that the Debian version won't get this patch, right?
- psi29a
- Posts: 5361
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: OSG on steroids
Only if we can convince them that the improvements are a good thing. However, they will likely not want to carry patches that aren't planned on going upstream, rejected by upstream or do not have anything to do with the stability of the software on Debian.ap0 wrote:This means that the Debian version won't get this patch, right?
Re: OSG on steroids
Maybe something that has to do with stability can be bundled w/ the other improvements … intrinsically tied of course.
-
- Posts: 47
- Joined: 09 Feb 2015, 13:31
- Gitlab profile: https://gitlab.com/mym34
Re: OSG on steroids
Hi scrawl,
I compiled your OSG repo (master) following your cmake options and when compiling openmw I get that:
I compiled your OSG repo (master) following your cmake options and when compiling openmw I get that:
- Spoiler: Show
Re: OSG on steroids
Most likely some OpenMW object files didn't get recompiled although they should. Do a clean rebuild (make clean).
Or the OSG header files used don't match the used library files. Open cmake-gui to check if headers and libs were found correctly. Check OpenMW and OSG are both built in release mode. (In RelWithDebInfo and Debug modes, osg library files get a "d" or "rd" suffix which may prevent the cmake script from finding the libs if OpenMW wasn't set to the same build type).
Or the OSG header files used don't match the used library files. Open cmake-gui to check if headers and libs were found correctly. Check OpenMW and OSG are both built in release mode. (In RelWithDebInfo and Debug modes, osg library files get a "d" or "rd" suffix which may prevent the cmake script from finding the libs if OpenMW wasn't set to the same build type).
-
- Posts: 47
- Joined: 09 Feb 2015, 13:31
- Gitlab profile: https://gitlab.com/mym34
Re: OSG on steroids
Oops, indeed you were right. A make clean did the thing. Thank you very much.
Re: OSG on steroids
Pushed two more osg commits, one of which has been proposed upstream. More frames \o/
I've started profiling the OpenMW game logic. Two resulting optimization commits are in master and three more as pull requests. In total with all patches applied, Balmora improved from 290 FPS to 310 FPS. I'm happy with that for an evening's work.
I've started profiling the OpenMW game logic. Two resulting optimization commits are in master and three more as pull requests. In total with all patches applied, Balmora improved from 290 FPS to 310 FPS. I'm happy with that for an evening's work.
Re: OSG on steroids
Wowow! Great job! Really happy that we are at the point where we can start optimizing, and really glad you're making some headway with it! Thanks for all of your hard work scrawl!
- sandstranger
- Posts: 438
- Joined: 19 May 2014, 19:53
- Location: Oblivion