On Tuesday, 26 December 2006 at 11:41, Dennis Schridde wrote:
> Am Dienstag, 26. Dezember 2006 02:53 schrieb Christian Ohm:
> > On Tuesday, 26 December 2006 at 2:37, Dennis Schridde wrote:
> > > I just profiled Warzone using gDEBugger.
> > >
> > > The logs are horrible and attached.
> > > (I monitored ~3 frames)
> > >
> > > Basically it looks like this:
> > > Lots of Matrix popping
> >
> > Which is bad, especially if uses any glGetWhatever functions, those just
> > kill performance (I think the shadow code uses that).
> Didn't look like it uses glGetX, only A LOT of glPopMatrix and glPushMatrix.
> ...
> Really a lot.
OK, OpenGL state changes generally are slow, that's why decent graphics
engines group similar operations.
> > > Lots of texture binding
> >
> > Shouldn't be too bad, just uses up memory.
> From what I've read in GL3 articles, it sounded like glBindTexture is VERY
> bad
> and takes a lot of time... But actually it shouldn't use any memory, because
> the texture is only bound, not loaded. (Loading it multiple times would be
> even worse, though.)
Duh, mixed up loading and binding. Yeah, binding takes time as well. I
think there are some BUCKET ifdefs somewhere in the graphics code that
try to group operations that use the same state together, don't know how
effective that is, though.
> And glBindTexture taking long would also explain why the (callgrind) profiler
> reports that WZ spends a lot of time in the terrain rendering functions.
> I think if we would load the tertile texpage entirely (without spliting it
> into 512x512 pieces) and just calculate the tile-id into a UV coordinate into
> the complete tertile texpage, it should remove the need for 99% of the
> texture binds and thus improve the performance a lot.
An image is loaded and then split into several textures? Argh.
> I tried that a while ago (and still have the patches, if someone wants).
> It improved the performance a lot, but also didn't display any textures
> anymore (exercise: why? ;) ). That code looked a bit ugly and had lots of
> calculations with hardcoded values, so I found it difficult to understand...
> Maybe I'll sit down later this holidays, but I wouldn't rely on it.
Didn't look at that yet. Perhaps tomorrow.
> > > Lots of redundant enabling of various things
> >
> > Yeah, well, like I already said, the graphics engine is not really
> > suited for OpenGL. That's the one thing that really slows the game down,
> > and no changes to any other code can change anything about that.
> >
> > > When looking at the profiler output you'll see that Warzone loads all
> > > textures again and again, everytime I exit to mainmenu or start a new
> > > game. (Allways increases the number of loaded textures by 30.)
> This one sounds really bad and should be fixed, I think.
> Mainly a memleak on the graphics card... For users with cards with less than
> 512MB RAM it could become a problem if they run several games in a row...
Yes, that's what I meant earlier. Some proper texture unloading on exit
should do the trick.
> > > For easier understanding of the CSV: When about 50k GL calls are executed
> > > we are in the game, otherwise in the menu or somewhere in between.
--
I'll give you my opinion of the human race in a nutshell ... their heart's
in the right place, but their head is a thoroughly inefficient organ.
-- W. Somerset Maugham, "The Summing Up"
_______________________________________________
Warzone-dev mailing list
[email protected]
https://mail.gna.org/listinfo/warzone-dev
