Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: Ed Federmeyer <fedeedw@charlie.cns.iit.edu>
Newsgroups: scea.yaroze.programming.2d_graphics
Subject: More GsBG questions
Date: Thu, 24 Apr 1997 02:16:48 -0500
Organization: (no organization)
Lines: 317
Message-ID: <335F08E0.7758@charlie.cns.iit.edu>
Reply-To: fedeedw@charlie.cns.iit.edu
NNTP-Posting-Host: charlie.cns.iit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0C-GZone  (Win95; I)

Okay, I've done some more experimenting with the order that I call the
GsSort() routines, etc.  Its working a lot better now, thanks Mario!

BUT I've come across even more things I don't understand:

1) Why are 4-bit CLUT images reversed?  If you look at the image
definitions
for my tile1_image_data[] array, you'll see that I needed to do some
wierd
byteswapping to get the image to display the way I wanted it to.  I
started
experimenting with 15bit-direct images (with sprites), and they were
stored
intuitively, not requiring byteswapping.

2) Performance: Is there a general difference in the performance of
working with 4bit vs. 8bit CLUT vs 15bit vs 24bit direct images?
Just a generalization is all I'm after at this point.  I would assume
that the CLUT images are slower, since the routines or GPU must
translate
the CLUT info into real RGB values before the image is painted into the
display buffer.

3) You'll notice in the attached code, when I define the second cell,
which
LoadImage() puts his texture right next to the texture of the first
cell,
I need to define it's ".u" value as being 16, even though it is
physically
in VRAM 4 pixels to the right of the first cell.  Apparently the
routines/(GPU?) automatically adjust the ".u" member depending on if it
is
a 4bit/8bit CLUT or 15bit direct texture?  Is that right?

4) Why is GsSortClear() somehow different than the other GsSort()
functions?
All the GsSort functions do is add a command to the list of GPU commands
in the given OT, right?  They don't actually set the GPU into action,
right?
Then later you tell the GPU to start working on the complete list of
commands,
right?

Well, it's almost as if when preparing the commands, the GsSort() funcs
don't
need to know about the current display buffer (the GPU will figure out
where
exatally in VRAM the drawing commands should write to when the time
comes),
but GsSortClear() seems to peek at the current display buffer to figure
out
what VRAM area to create a clear command for.  I don't get it.

	Works:				Gives Black Screen:
	Clear OT			Clear OT
	Call GsSort() funcs		Call GsSort() funcs
	VSync/SwapBuffer		Call GsSortClear()
	Call GsSortClear()		VSync/SwapBuffer
	Draw OT				Draw OT

5) When I define the second of my double buffers via GsDefDispBuf() to
be
on the VRAM y-location of 256 (as is done in some examples), rather than
*immediatly* below the first buffer (at 240), the GsSortFixBg16()
routines
draws the BG 16 pixels lower on the odd frames!!!


Below is a more full-blown version of code I'm testing with.  It puts up
a tiled background, and a sprite in front of it.  The way it is now,
the image is "jumpy", because the BG jumps up and down 16 pixels every
frame, so tiles that are different are flickery.

See the comments for ways to "fix" the code.  Any ideas why the code
(GsSortFixBg16() in particular) behaves this way?

Thanks,
EdF

-------------------- Code for testing strange behavior
---------------------
#include <libps.h>
#include "pad.h"


#define PACKETMAX	(10000)
#define PACKETMAX2	(PACKETMAX*24)
#define OT_LENGTH	(14)	  

GsOT		WorldOrderingTable[2];
GsOT_TAG	zSortTable[2][1<<OT_LENGTH];   
PACKET		GpuOutputPacket[2][PACKETMAX2];


unsigned short tile1_image_data[4][16] = {
	0x1111, 0x1111, 0x1111, 0x1111,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x0001, 0x0000, 0x0000, 0x1000,
	0x1111, 0x1111, 0x1111, 0x1111,
};

unsigned short tile2_image_data[4][16] = {
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
	0x3333, 0x3333, 0x3333, 0x3333,
};


unsigned short clut[16] = {
	0x0000, 0x001F, 0x03E0, 0x7C00, 0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF,
	0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF, 0x7FFF,
};

GsSPRITE	sprite;

GsBG		bg;
GsMAP		map;
GsCELL		cell[2];
unsigned short	index[32][15] = {
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,1,1,1,0,1,1,0,0,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,1,0,0,0,1,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,1,1,0,0,1,0,1,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,1,0,0,0,1,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,1,1,1,0,1,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
};

unsigned long	bg_work_area[ (( (512/16+1) * (240/16+1+1) * 6+4) * 2+2 )
];


void
main( void )
{
	u_long		pad_data;
	int		outputBufferIndex;
	RECT		rect;

	SetVideoMode( MODE_NTSC );
	GsInitGraph( 512 ,240, GsOFSGPU|GsNONINTER, 1, 0 );

	// CHOOSE ONE:  Using the 256 one will make the BG jump up
	// and down every other frame.  (See the IF around the
	// GsSortFixBg16() below!)
	GsDefDispBuff( 0, 0, 0, 256 );		/* jumpy picture */
	//GsDefDispBuff( 0, 0, 0, 240 );	/* nice picture */

	PadInit();

	WorldOrderingTable[0].length = OT_LENGTH;
	WorldOrderingTable[1].length = OT_LENGTH;
	WorldOrderingTable[0].org = zSortTable[0];
	WorldOrderingTable[1].org = zSortTable[1];

	rect.x = 960;
	rect.y = 0;
	rect.w = 4;
	rect.h = 16;
	LoadImage( &rect, (unsigned long *)&tile1_image_data );

	rect.x = 964;
	rect.y = 0;
	rect.w = 4;
	rect.h = 16;
	LoadImage( &rect, (unsigned long *)&tile2_image_data );

	rect.x = 960;
	rect.y = 256;
	rect.w = 16;
	rect.h = 1;
	LoadImage( &rect, (unsigned long *)&clut );

	sprite.attribute = 0x08000040;
	sprite.x = 300;
	sprite.y = 100;
	sprite.w = 16;
	sprite.h = 16;
	sprite.tpage = 15;
	sprite.u = 16;		/* SEE comment below about the .u member... */
	sprite.v = 0;
	sprite.cx = 960;
	sprite.cy = 256;
	sprite.r = 128;
	sprite.g = 128;
	sprite.b = 128;
	sprite.mx = 0;
	sprite.my = 0;
	sprite.scalex = 0;
	sprite.scaley = 0;
	sprite.rotate = 0;

	bg.attribute = 0x08000040;
	bg.x = 0;
	bg.y = 0;
	bg.w = 512;
	bg.h = 240;
	bg.scrollx = 0;
	bg.scrolly = 0;
	bg.r = 128;
	bg.g = 128;
	bg.b = 128;
	bg.map = &map;
	bg.mx = 0;
	bg.my = 0;
	bg.scalex = ONE;
	bg.scaley = ONE;
	bg.rotate = 0;

	map.cellw = 16;
	map.cellh = 16;
	map.ncellw = 32;
	map.ncellh = 15;
	map.base = &cell[0];
	map.index = &index[0][0];

	cell[0].u = 0;
	cell[0].v = 0;
	cell[0].cba = 16444;
	cell[0].flag = 0;
	cell[0].tpage = 15;

	// SINCE this cell texture is really stored right next to the other
	// cell texture, and each texture is 4 bytes wide, why to I need to
	// set the .u to 16?  I would have thought I should set it to
	// "4", indicating it is 4 pixels from the start of the tpage?
	cell[1].u = 16;
	cell[1].v = 0;
	cell[1].cba = 16444;
	cell[1].flag = 0;
	cell[1].tpage = 15;

	GsInitFixBg16( &bg, &bg_work_area[0] );

	do {
		outputBufferIndex = GsGetActiveBuff();
		GsSetWorkBase( (PACKET*)GpuOutputPacket[outputBufferIndex]);
		GsClearOt(0, 0, &WorldOrderingTable[outputBufferIndex]);


		// CHOOSE ONE:  If GsDefDisBuf() sets the second buffer
		// at y-offset 256, the BG image for every odd frame is
		// 16-pixels lower on the screen!  Test this by only
		// drawing the BG on either an even or odd frame and
		// comparing where the lines cross the edge of your TV!
		// Comment them both out to have the BG jump up and down
		// at 60Hz!
		// IF GsDefDispBuf() sets the second buffer at y-offset
		// 240, then the BG gets displayed correctly on both
		// odd and even frames.
		//if ( outputBufferIndex == 0 )
		//if ( outputBufferIndex == 1 )
						 {
			GsSortFixBg16( &bg, &bg_work_area[0], 
				&WorldOrderingTable[outputBufferIndex], 100 );
		}

		GsSortFastSprite( &sprite,
			&WorldOrderingTable[outputBufferIndex], 5 );

		DrawSync(0);
		VSync(0);
		pad_data = PadRead();

		// How come if I put the GsSortClear() here, I just get
		// a black screen?  Does it somehow use the "current"
		// buffer to know where to clear?  Why is this different
		// from the other GsSort() functions?
		//GsSortClear( 0x0, 0x0, 0x0,
		//	&WorldOrderingTable[outputBufferIndex] );

		GsSwapDispBuff();

		GsSortClear( 0x0, 0x0, 0x0,
			&WorldOrderingTable[outputBufferIndex] );

		GsDrawOt( &WorldOrderingTable[outputBufferIndex] );

	} while ( !(pad_data & PADselect) );

	ResetGraph(3);
}
---------------- End of Code for testing strange behavior
------------------