Path: chuka.playstation.co.uk!news From: Mark Green Newsgroups: scee.yaroze.beginners Subject: Stuck with Sprites - Oddness` Date: Mon, 04 Aug 1997 21:35:48 +0100 Organization: No Lines: 33 Message-ID: <33E63D24.33F3@antelope.demon.co.uk> NNTP-Posting-Host: antelope.demon.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (Win95; I) Ok, after spending a while with this machine, I've finally gone from a completely blank screen to a completely blank screen with a slight tinge of red... Basically, I understand (I think!) how the graphics system works, but it seems to have inconsistencies in it that I don't understand. Perhaps some kind soul could explain a few things.. 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 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? 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...) 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 :) ) 5 - The drawing commands draw on the buffer that is *not* visible at the moment, right? Thanks for any help!! Mg