Path: chuka.playstation.co.uk!news
From: Developer Support <dev_support@interactive.sony.com>
Newsgroups: scee.yaroze.programming.2d_graphics
Subject: Re: interlace sprites
Date: Mon, 16 Jun 1997 09:32:16 +0100
Organization: Sony Computer Entertainment Europe
Lines: 114
Message-ID: <33A4FA10.5730@interactive.sony.com>
References: <33a411a4.265293876@news.scea.sony.com>
Reply-To: N/A-Use-Newsgroup
NNTP-Posting-Host: 194.203.13.10
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01 (Win95; I)

Jamin Frederick wrote:
> 
>         The message below was previously posted in SCEA.
> I'm about to design a 2-d demo but I'd like to get some questions
> answered before I decide on a resolution, especially the interlace
> issue.  I guess I'd like to see someone's viewpoint on the pros and
> cons of choosing a particular resolution and some of the preliminary
> decisions made about number of sprites, which ones to display, and OT
> organization -- from someone who's made a few of these, or developer
> support.  If this is too general, maybe some discussion can be made
> in context of a side-scrolling shooter, which is my first project.  If
> anyone can help, I'll expand a little more on my ideas...thanks.
> 
> Jamin Frederick
> 
> >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.

If your screen flickers, this is not due to a 50 or 60 fps update rate,
it's due to failure of the double buffering mechanism, whether
using two areas of VRAM as buffers or using one area with interlace.

Print out hsync count to see if your program runs at maximum frame rate.

> >
> >First of all, what interlace demos are we talking about? Are they
> >available to download and look at?
> >

The recently posted SCEE demo <scrn_res> shows a simple way to
flip high/low res during runtime.
I'm sure some of the other demos use hi-res interlace mode as well.

> >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.

It is usually easy to display many more than 30 sprites per second
without the slightest drop in frame rate.


> 
> >
> >>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?

Haven't tried this, I suspect that it may flicker.
Use FntPrint to display the hsync of your program

hsync = VSync(1);
FntPrint("hsync %d\n", hsync);

and see how it varies with sprite drawing.
On the SCEI 'balls' demo, over 900 sprites are drawn per frame before 
frame rate falls below maximum.

Lewis

> >
> >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