Path: chuka.playstation.co.uk!news From: "Matt Verran" Newsgroups: scee.yaroze.freetalk.english Subject: Re: Performance Date: Wed, 25 Jun 2003 11:44:47 +0100 Organization: PlayStation Net Yaroze (SCEE) Lines: 31 Message-ID: References: NNTP-Posting-Host: 213.219.49.222 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 > 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. > 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. -Matt