Path: chuka.playstation.co.uk!news From: Andrew Partington Newsgroups: scee.yaroze.freetalk.english Subject: Re: Performance Date: Wed, 25 Jun 2003 16:45:48 +0000 Organization: PlayStation Net Yaroze (SCEE) Lines: 77 Message-ID: References: NNTP-Posting-Host: public2-ward1-6-cust140.oldh.broadband.ntl.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en In-Reply-To: I tried some of those ideas: - making the BG handler clump the same sprite types together (read: making each non-null block into a square one - same effect) - making the tile sizes 32*32 (4bpp) - 32*32 tiles AND the square block hack In each case, I never saw any performance improvements - it could have been my imagination but sometimes it looked slightly worse even. I was drawing exactly the same number of sprites in each case - seemed pointless to draw more of the map to compensate for a smaller block size when the performance was the same or worse. Very odd... I've not tried giving it a random block each time, someone else on the ng was complaining that their BG handler choked when more than 5 of the same type of block was being sent, i'll check that next. Matt Verran wrote: >>Or multiple ordering tables maybe > > > Yes I think that would have the same effect, sorting all the same block > images at once. > > >>I'm guessing that the official BG handler only >>has to calculate the scale and rotation matrices once then apply them to >>each sprite, instead of effectively recalculating them each time you >>call GsSortSprite(), must be a fair bit of overhead under the covers? >>Is it any slower moving sprites via mx/my instead of just x/y? > > > Try and find out if its the GsSortSprite() call thats causing the big > slowdown, or if it's the GsDrawOT(). This should tell you if the maths or > the drawing respectively is the problem. GsSortSprite() definitely seems to be the performance hit - you can go around the caverns and average around 80-90 on the hSync scale - glad I have that scanner in place! That's why I thought that there is something going on underneath GsSortSprite() if the scale/rotation values aren't equal to 4096, course that's just idle speculation on my part. Commenting out GsDrawOT() and printf()ing the hSync value to siocons gave around the same performance from what I could see (not a lot, since nothing was being sent to the screen). > >>Do you mean build the entire world >>as one massive TMD? Or have a seperate TMD for each block type, and >>draw TMD type n instead of sprite type n in the map routine, but >>wouldn't that way be subjected to the same scaling problems you >>described earlier when you come to texture them? > > > Actually I meant building a dynamic TMD every frame (or at least as often as > you need one) that is subdivided as much as needed, textured with the blocks > to the desired zoom level and only as big as to fill the screen. Then you > would only need one rotation and transform to display the whole BG. Yes you > would have the same scaling problems tho, it wouldn't definately be faster. > Ah, good idea. Guess I don't have to texture it and call it retro - dodgy coding or clever marketing? :O) (nah, gotta put a texture on it, if I go down that route...) Anything else I can do before abandoning sprites? (which I don't really want to do unless I have to, its already been vapourware long enough as it is!) Cheers, Andy