Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: jamin1@psu.edu (Jamin Frederick) Newsgroups: scea.yaroze.programming.2d_graphics Subject: Re: interlace sprites Date: Tue, 10 Jun 1997 02:26:58 GMT Organization: SCEA Net Yaroze News Lines: 74 Message-ID: <339c890c.27268896@news.scea.sony.com> References: <3397bc2b.2867861@news.scea.sony.com> NNTP-Posting-Host: ivyland222.voicenet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent .99g/32.339 On Fri, 06 Jun 1997 15:40:24 GMT, mperdue@iquest.net (Mario Perdue) wrote: >On Fri, 06 Jun 1997 07:30:37 GMT, jamin1@psu.edu (Jamin Frederick) >wrote: > >>Even though I use ResetGraph() on my interlaced demos, I think the >>reason it flickers is because of the high number of sprites being >>inserted in the OT, or just the delay in the entire screen getting >>displayed every 60th of a second. I think this also holds true for >>the 16x16 pixel tiles...i haven't got them to work in interlace. > >First of all, what interlace demos are we talking about? Are they >available to download and look at? > >Until I see the code, I'll just say that personally, I never use >interlace mode (on any system) during actual game play, because I've >never been able to get acceptable results. If I use it at all, it's >only for title screens and such. > So do most console games not make use of interlace mode during gameplay? The reason I would like to use it is that it makes efficient use of video ram, but if there's no feasible way to run things in this mode, someone please tell me. >>If I keep the number of sprites down to about 30 or so, interlacing >>seems to be fine. Perhaps a good thing to do as well is >>keep only sprites that will be on the screen "alive", or being >>insertable in the OT, because there's no reason to insert sprites into >>the OT that will be ENTIRELY clipped. This will keep the sprite count >>low. There will always be extra logic for offscreen sprites though, >>and this will contribute to frame rate drop. > >It's always a good idea to keep the sprite count as low as possible. >Just make sure that your clip routine doesn't eat up mor time than it >take to actually draw the sprite. Right. My "active sprite routine", or the routine that decides whether the sprite needs to be submitted to the OT at all (I like to refer to "clipping" as the thing that gets done to OT sprites on the border of the screen by the built-in playstation routines) is just testing to see if the object's rectangle intersects the screen rectangle, and if so, its sprite needs to be inserted into the OT. If my total number of objects increase, obviously this will take longer. I think if I have a good deal of objects outside the screen that don't need to be displayed, though, this is a good thing to do. > >>I'd like to get a good measurement of how many sprites the playstation >>can handle before this happens. > >That's hard to pin down. It depends on the size and color depth of the >sprites as well as the amount of 'control' code that is being run. The >best way to measure it is to draw your sprites and print the amount of >time it takes to do it. Keep adding sprites until the frame rate >drops. > > VSync(1) returns the number of HSync units from the last VSync() > VSync(2) returns the number of VSync periods from the last VSync() > >Either will tell you if your frame rate is dropping. > >>In fact, would the interlace mode begin to flicker after the >>frame rate drops right below 60fps? What do you think? > >I'm not sure. As I've said, I try to stay away from Interlace mode >whenever possible. Perhaps someone else has more experience with this. > >Mario Jamin