On Tue, Oct 28, 2008 at 8:39 AM, James Paige <span dir="ltr"><<a href="mailto:Bob@hamsterrepublic.com">Bob@hamsterrepublic.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I had him post his benchmark results here in this thread:<br>
<a href="http://www.slimesalad.com/forum/viewtopic.php?t=554" target="_blank">http://www.slimesalad.com/forum/viewtopic.php?t=554</a><br>
</blockquote><div><br>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<br>
<br>and those lines are here:<br>IM Display List (L 0 F L I): 73.57 FPS, 3.28 MTS, 44k Tris (T96/288)<br>IM Display List (L 0 I S S): 69.72 FPS, 3.11 MTS, 44k Tris (T124/288)<br>IM Display List (L 0 F L S): 62.52 FPS, 2.79 MTS, 44k Tris (T112/288)<br>
IM Display List (L 0 I L S): 61.56 FPS, 2.75 MTS, 44k Tris (T116/288)<br>IM Display List (L 0 I S I): 60.74 FPS, 2.71 MTS, 44k Tris (T108/288)<br>IM Display List (L 0 F S S): 57.73 FPS, 2.58 MTS, 44k Tris (T120/288)<br>IM Display List (L 0 I L I): 52.25 FPS, 2.33 MTS, 44k Tris (T100/288)<br>
IM Display List (L 0 F S I): 37.62 FPS, 1.68 MTS, 44k Tris (T104/288)<br><br>again, which seem fine.<br><br>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.)<br>
<br>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.<br><br>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.<br>
<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">>    ...Does sidescroller try to draw every tile everywhere? is there any kind<br>

>    of quick rejection of large blocks of tiles going on? (like throwing out<br>
>    entire blocks in customer service robot)<br>
<br>
</div>I haven't touched that particular code in a while, but if I remember<br>
correctly, it computes a corner block, then returns an iterator<br>
starting there, which iterates over the blocks on the screen until you<br>
get to the opposite corner<br>
</blockquote><div><br>That approach is probably super great given what the features of our display class are.<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Breaking the map up into larger blocks like Customer Service Robot does<br>
would probably be a better idea, since I also want to have larger<br>
solid structures like rocks and roots embedded in the dirt. But it<br>
doesn't do that yet.<br>
<br></blockquote></div>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)<br>
<br>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.<br>