Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: Clint Kelly <clint@erols.com>
Newsgroups: scee.yaroze.beginners
Subject: Re: Stuck with Sprites - Oddness`
Date: Mon, 04 Aug 1997 19:43:51 -0400
Organization: Cornell University
Lines: 48
Message-ID: <33E66937.2140@erols.com>
References: <33E63D24.33F3@antelope.demon.co.uk>
NNTP-Posting-Host: rkv-as1s30.erols.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01KIT (Win95; U)

I don't have very many answers, but I'll give this a shot...


Mark Green wrote:

>   1 - Ok, I have the frame buffer, which is basically a massive
> scratchpad except that part of it at any given moment will be onscreen.
> Things like GetTPage and LoadImage, etc. seem to refer to coordinates in
> this.  However, when it comes to actually _drawing_ things, it seems
> that the system compensates for the location of the current drawing
> buffer in the scratchpad.  (Evidence: The CHECK program, when it

When you have sprites on the screen, you're dealing with world coordinates (correct me if I'm 
wrong) and not frame buffer coordinates.  For example, you can move sprites to negative 
coordinates, even though no such coordinates exist in the framebuffer.

> recalculates the positions of the sprites, does not have an amount that
> it adds on in order to draw in the second frame buffer on every other
> frame).  Is this true?  What if I really do want to draw in the texture
> space, CLUT, or similar?

If you want to actually write somewhere off the screen in the frame buffer, I think you have to 
use LoadImage().

> 
>   2 - What colour does FntPrint() text come out in?  (I was trying to
> FntPrint() some text in the scratchpad, mark that area as TextureSpace
> then pick it up in a sprite, but it never shows up...)

I assume FntPrint() is in white, just cos I've used that function before and my text was white.  
If you want to have some text on a sprite, try writing the text using a paint program, saving the 
image with the text, converting it to a tim, and then mapping that tim to your sprite.
 
>   3 - Once you've drawn an Ot, you can do whatever you like to the Ot in
> memory, right?
>
>   4 - You don't actually *need* two sets of GpuPackets for two buffered
> frames if you're only drawing one at a time (which is a stupid thing to
> do, but is simple, so that's what I'm trying to do at the moment :) )

Can't help you with those, sorry.

>   5 - The drawing commands draw on the buffer that is *not* visible at
> the moment, right?

That's right.

CliNt