[Dev] how to collect performance data from users?

[Brian Fisher]

On Tue, Oct 28, 2008 at 8:39 AM, James Paige <Bob at hamsterrepublic.com>wrote:

> I had him post his benchmark results here in this thread:
> http://www.slimesalad.com/forum/viewtopic.php?t=554
>

Yeah, I think those results are fine for our needs.... you should have no
where near 44K triangles on the screen, we use Immediate Mode,  Display
lists, and no lights. So the relevant ones on that table should be those
that start IM Display List (L 0

and those lines are here:
IM Display List (L 0 F L I): 73.57 FPS, 3.28 MTS, 44k Tris (T96/288)
IM Display List (L 0 I S S): 69.72 FPS, 3.11 MTS, 44k Tris (T124/288)
IM Display List (L 0 F L S): 62.52 FPS, 2.79 MTS, 44k Tris (T112/288)
IM Display List (L 0 I L S): 61.56 FPS, 2.75 MTS, 44k Tris (T116/288)
IM Display List (L 0 I S I): 60.74 FPS, 2.71 MTS, 44k Tris (T108/288)
IM Display List (L 0 F S S): 57.73 FPS, 2.58 MTS, 44k Tris (T120/288)
IM Display List (L 0 I L I): 52.25 FPS, 2.33 MTS, 44k Tris (T100/288)
IM Display List (L 0 F S I): 37.62 FPS, 1.68 MTS, 44k Tris (T104/288)

again, which seem fine.

I would say to look at things holistically - Alt-F should show quick
performance meters, where the colors represent time spent in update, draw
and flip, and then overall (in that order going down). Longer bars mean
longer time which is bad. If update (red I think) is way longer than others,
it's not anything with drawing. If draw (green maybe?) is the longest, then
it either means we spend too long sending stuff to the card, or opengl is
too slow (SW opengl stacks cause that problem). if flip (blue maybe?) is the
longest, then it is definitively the card is taking too long to draw (which
may mean we are sending it bad instructions of course, but it does mean the
time is spent waiting for it to do what we told it.)

I would suggest making it so you can skip updates somehow (like with a key)
and then seeing what those meters are like when you just draw the same frame
over and over again.

If I had to guess here, I'd say stuff is for the most part slow all around -
and when the guy says "painfully slow" he may mean like 10fps. There is
probably a decent time spent in update, a decent time spent in sending draw
commands to the card, and the card maybe isn't the fastest.



> >    ...Does sidescroller try to draw every tile everywhere? is there any
> kind
> >    of quick rejection of large blocks of tiles going on? (like throwing
> out
> >    entire blocks in customer service robot)
>
> I haven't touched that particular code in a while, but if I remember
> correctly, it computes a corner block, then returns an iterator
> starting there, which iterates over the blocks on the screen until you
> get to the opposite corner
>

That approach is probably super great given what the features of our display
class are.


Breaking the map up into larger blocks like Customer Service Robot does
> would probably be a better idea, since I also want to have larger
> solid structures like rocks and roots embedded in the dirt. But it
> doesn't do that yet.
>
> well the big reason to do such things is so that you can create display
lists for sections of the map - the idea is that instead of making say 4800
calls for a screen of 80x60 tiles, if you break it up into 10x10 tile
blocks, then now you can get away with just 48 calls to draw the display
lists for those 8x6 blocks. When a tile changes within a 10x10 block, you do
have to recreate the display list for that block, but if you are only say
updating 3 or 4 blocks at once, you still get a considerable savings (like
440 draw calls instead of 4800). If all the tiles are changing, then it
degenerates to the case without that optimization, plus some small overhead
proportional to the number of blocks (so say 4896 draw calls now)

Anyways, if the problem is draw based, but not a card performance problem, I
think exposing display list tech to the game to be able to do some blocks of
tile based stuff is the right solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/dev-motherhamster.org/attachments/20081028/f55f767e/attachment-0001.htm>