Code: Select all
// Color correction (aligned)
u32 *fbcc = (u32 *)PspFrameBuffer;
u32 *fbcce = (u32 *)(PspFrameBuffer + ((SCREEN_WIDTH * SCREEN_HEIGHT) >> 1));
while (fbcc < fbcce)
{
*fbcc = (*fbcc & 0x07e007e0) | ((*fbcc & 0xf800f800) >> 11) | ((*fbcc & 0x001f001f) << 11);
fbcc++;
}First question is whether you're using cached or uncached pointers here. Is this the real framebuffer, or something in system memory? Because uncached reads are going to be pretty slow.ChaosKnight wrote:Does anyone have code for quickly converting RGB to BGR on the fly. The best I've been able to make is this (and the color is still somewhat off):
Code: Select all
{
u32 pix = *fbcc;
*fbcc = (pix & 0x07e007e0) | ((pix & 0xf800f800) >> 11) | ((pix & 0x001f001f) << 11);
}This is not the real framebuffer, but rather in system memory.jsgf wrote:First question is whether you're using cached or uncached pointers here. Is this the real framebuffer, or something in system memory? Because uncached reads are going to be pretty slow.
SCREEN_WIDTH = 480, HEIGHT = 272.jsgf wrote:Also, its unclear what SCREEN_WIDTH is. If you're using the real framebuffer, which has a width of 512 pixels, then you'll end up converting quite a few invisible ones, since only 480 are visible.
actually the compiler does that allready (I've checked the generated asm code).jsgf wrote:The other thing you should do is read the value into a local before playing with it
Code: Select all
u32 pix0,pix1;
// Color correction (aligned)
u32 *fbcc = (u32 *)PspFrameBuffer;
u32 *fbcce = (u32 *)(PspFrameBuffer + ((SCREEN_WIDTH * SCREEN_HEIGHT) >> 1));
while (fbcc < fbcce)
{
pix0 = *fbcc;
pix1 = *(fbcc+1);
*fbcc = (pix0 & 0x07e007e0) | ((pix0 & 0xf800f800) >> 11) | ((pix0 & 0x001f001f) << 11);
*(fbcc+1) = (pix1 & 0x07e007e0) | ((pix1 & 0xf800f800) >> 11) | ((pix1 & 0x001f001f) << 11);
fbcc += 2;
}
are you sure the color format is really 565 for both, source and destination buffer?ChaosKnight wrote:To be honest, at this point my problem is not so much speed as it is the conversion itself does not result in the proper colors being generated
Code: Select all
// Video setup
#define FB_TYPE u16
#define PSP_MODE GU_PSM_5650
#define MAC_MODE FLAYOUT_HOST_565
#define PIXEL_SIZE 2
#define SCREEN_WIDTH 480
#define SCREEN_HEIGHT 272
#define PSP_LINE_SIZE 512
#define MAC_COLOR_MODE VMODE_16BIT
#define PSP_COLOR_MODE PSP_DISPLAY_PIXEL_FORMAT_565
#define FRAMEBUFFER_SIZE (PSP_LINE_SIZE * SCREEN_HEIGHT * PIXEL_SIZE)
FB_TYPE *g_vram_base = (FB_TYPE *)(0x40000000 | 0x04000000);
static unsigned int __attribute__((aligned(16))) list[256];
static int dispBufferNumber;
inline FB_TYPE *getVramDrawBuffer()
{
return ((!dispBufferNumber) ? g_vram_base + (FRAMEBUFFER_SIZE >> 1) : g_vram_base);
}
// Basilisk display configuration
static FB_TYPE __attribute__((aligned(16))) PspFrameBuffer[SCREEN_WIDTH * SCREEN_HEIGHT];
/*
* Initialization
*/
bool VideoInit(bool classic)
{
#if !DEBUG
// guInit - Taken from initGraphics() in graphics.c from LUAPlayer
sceDisplaySetMode(0, SCREEN_WIDTH, SCREEN_HEIGHT);
dispBufferNumber = 0;
sceDisplayWaitVblankStart();
sceDisplaySetFrameBuf((void*) g_vram_base, PSP_LINE_SIZE, PSP_COLOR_MODE, 1);
sceGuInit();
sceGuStart(GU_DIRECT, list);
sceGuDrawBuffer(PSP_MODE, (void*)FRAMEBUFFER_SIZE, PSP_LINE_SIZE);
sceGuDispBuffer(SCREEN_WIDTH, SCREEN_HEIGHT, (void*)0, PSP_LINE_SIZE);
sceGuClear(GU_COLOR_BUFFER_BIT | GU_DEPTH_BUFFER_BIT);
sceGuDepthBuffer((void*) 0x110000, PSP_LINE_SIZE);
sceGuOffset(2048 - (SCREEN_WIDTH / 2), 2048 - (SCREEN_HEIGHT / 2));
sceGuViewport(2048, 2048, SCREEN_WIDTH, SCREEN_HEIGHT);
sceGuDepthRange(0xc350, 0x2710);
sceGuScissor(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
sceGuEnable(GU_SCISSOR_TEST);
sceGuAlphaFunc(GU_GREATER, 0, 0xff);
sceGuEnable(GU_ALPHA_TEST);
sceGuDepthFunc(GU_GEQUAL);
sceGuEnable(GU_DEPTH_TEST);
sceGuFrontFace(GU_CW);
sceGuShadeModel(GU_SMOOTH);
sceGuEnable(GU_CULL_FACE);
sceGuEnable(GU_TEXTURE_2D);
sceGuTexMode(PSP_MODE, 0, 0, 0);
sceGuTexFunc(GU_TFX_REPLACE, GU_TCC_RGBA);
sceGuTexFilter(GU_NEAREST, GU_NEAREST);
sceGuAmbientColor(0xffffffff);
sceGuFinish();
sceGuSync(0, 0);
sceDisplayWaitVblankStart();
sceGuDisplay(1);
#endif
// Configure the Basilisk II framebuffer.
VideoMonitor.x = SCREEN_WIDTH;
VideoMonitor.y = SCREEN_HEIGHT;
VideoMonitor.mode = MAC_COLOR_MODE;
VideoMonitor.bytes_per_row = SCREEN_WIDTH * PIXEL_SIZE;
VideoMonitor.mac_frame_base = MacFrameBaseMac;
MacFrameBaseHost = (uint8 *)PspFrameBuffer;
MacFrameSize = VideoMonitor.bytes_per_row * VideoMonitor.y;
MacFrameLayout = MAC_MODE;
// Done.
D(bug("video "));
return true;
}
void video_set_palette(unsigned char *p)
{
D(bug("video_set_palette called\n"));
}
/*
* Deinitialization
*/
void VideoExit(void)
{
#if !DEBUG
sceGuTerm();
#endif
}
/*
* Video message handling
*/
void VideoInterrupt(void)
{
// Color correction (aligned)
u32 pix0,pix1;
u32 *fbcc = (u32 *)PspFrameBuffer;
u32 *fbcce = (u32 *)(PspFrameBuffer + ((SCREEN_WIDTH * SCREEN_HEIGHT) >> 1));
while (fbcc < fbcce)
{
pix0 = *fbcc;
pix1 = *(fbcc+1);
*fbcc = (pix0 & 0x07e007e0) | ((pix0 & 0xf800f800) >> 11) | ((pix0 & 0x001f001f) << 11);
*(fbcc+1) = (pix1 & 0x07e007e0) | ((pix1 & 0xf800f800) >> 11) | ((pix1 & 0x001f001f) << 11);
fbcc += 2;
}
#if !DEBUG
// blitImageToScreen(...) with some modifications.
FB_TYPE* vram = getVramDrawBuffer();
sceKernelDcacheWritebackInvalidateAll();
sceGuStart(GU_DIRECT,list);
sceGuCopyImage(PSP_MODE, 0, 0, SCREEN_WIDTH, SCREEN_HEIGHT,
SCREEN_WIDTH, PspFrameBuffer, 0, 0, PSP_LINE_SIZE, vram);
sceGuFinish();
sceGuSync(0,0);
// flipScreen()
sceGuSwapBuffers();
sceDisplaySetFrameBuf(vram, PSP_LINE_SIZE, PSP_COLOR_MODE, 1);
dispBufferNumber ^= 1;
#endif
}
It looks fine to me. I'm using the same shifts and masks to do it in PSPGL. How is it coming out wrong? Are blue and red obviously interchanged? Something else?ChaosKnight wrote:To be honest, at this point my problem is not so much speed as it is the conversion itself does not result in the proper colors being generated. It's close, but not exact. I have very little experiance with 565 comparitively speaking to my experiance with 8 bit or 24/32 bit modes. The 565 packing is still quite foriegn to me.
It's coming out purple. But now it's red again because I'm not sure how to apply the CLUT to the sceGuCopyImage()... I create the CLUT first thing off, then I do this after sceGuInit()jsgf wrote:It looks fine to me. I'm using the same shifts and masks to do it in PSPGL. How is it coming out wrong? Are blue and red obviously interchanged? Something else?
Are you sure its 565, and not 5551 or 4444?
Code: Select all
sceGuClutMode(PSP_MODE, 0, 0, 0);
sceGuClutLoad(8192, (void *)&PspCLUT);
Code: Select all
#define PSP_MODE GU_PSM_5650
#define MAC_MODE FLAYOUT_HOST_565
...
#define PSP_COLOR_MODE PSP_DISPLAY_PIXEL_FORMAT_565
I don't think you can; sceGuCopyImage is just a bit-for-bit copy. You need to set your image up as a texture, and then draw a textured sprite. See samples/gu/sprite/sprite.c for a guide. The main difference from what you're doing now is that you'll need to arrange your image to have a stride of 512 pixels wide, because the texture unit can only handle textures with power of 2 dimensions. You don't need to worry about making the texture 512 pixels high because you won't be drawing the parts below 272 rows.ChaosKnight wrote:It's coming out purple. But now it's red again because I'm not sure how to apply the CLUT to the sceGuCopyImage()...
Since it's already been proven that Mac OS is actually comfortable with any resolution, why not just make the option to double the screen size to twice that of the PSP (960x544)? Not sure if full screen games would work so well, but at least you can still preserve the aspect ratio. The Bochs port is ugly and harder to use partly due to it's destroying of the aspect ratio. Most applications would support this resolution without being cut off, as System 7 was designed to be compatable with the Macintosh SE, which I believe has a height of somewhere around 538. I'll check Apple docs and get back to you on that.Arwin wrote:While we're on this topic, I think we also need either a virtual screen of 640x480 or scaling of 640x480 to 480x272. Maybe efficient to combine the two routines, but it's no doubt something ChaosKnight wouldn't mind having some help with (I don't know anything about graphics myself, anyway).
This is my thinking as well. I will attempt to do the doubling and rescaling once I get it on a texture to start out with.sHARD>> wrote:Since it's already been proven that Mac OS is actually comfortable with any resolution, why not just make the option to double the screen size to twice that of the PSP (960x544)? Not sure if full screen games would work so well, but at least you can still preserve the aspect ratio. The Bochs port is ugly and harder to use partly due to it's destroying of the aspect ratio. Most applications would support this resolution without being cut off, as System 7 was designed to be compatable with the Macintosh SE, which I believe has a height of somewhere around 538. I'll check Apple docs and get back to you on that.Arwin wrote:While we're on this topic, I think we also need either a virtual screen of 640x480 or scaling of 640x480 to 480x272. Maybe efficient to combine the two routines, but it's no doubt something ChaosKnight wouldn't mind having some help with (I don't know anything about graphics myself, anyway).
Code: Select all
// Video setup
#define FB_TYPE u16
#define PSP_MODE GU_PSM_5650
#define MAC_MODE FLAYOUT_HOST_565
#define SLICE_SIZE 64
#define PIXEL_SIZE 2
#define SCREEN_WIDTH 480
#define SCREEN_HEIGHT 272
#define PSP_LINE_SIZE 512
#define BII_SCR_WIDTH 480
#define BII_SCR_HEIGHT 272
#define MAC_COLOR_MODE VMODE_16BIT
#define PSP_COLOR_MODE PSP_DISPLAY_PIXEL_FORMAT_565
#define PSP_COLOR_MODE2 GU_COLOR_5650
#define FRAMEBUFFER_SIZE (PSP_LINE_SIZE * SCREEN_HEIGHT * PIXEL_SIZE)
FB_TYPE *g_vram_base = (FB_TYPE *)(0x40000000 | 0x04000000);
static unsigned int __attribute__((aligned(16))) list[256];
static int dispBufferNumber;
inline FB_TYPE *getVramDrawBuffer()
{
return ((!dispBufferNumber) ? g_vram_base + (FRAMEBUFFER_SIZE >> 1) : g_vram_base);
}
struct Vertex
{
unsigned short u, v;
unsigned short color;
short x, y, z;
};
// Basilisk display configuration
static FB_TYPE __attribute__((aligned(16))) PspCLUT[65536];
static FB_TYPE __attribute__((aligned(16))) PspFrameBuffer[PSP_LINE_SIZE * SCREEN_HEIGHT];
/*
* Initialization
*/
bool VideoInit(bool classic)
{
#if !DEBUG
// Build color lookup table
for (int i = 0; i < 65536; i++)
PspCLUT[i] = (i & 0x07e0) | ((i & 0xf800) >> 11) | ((i & 0x001f) << 11);
sceGuInit();
// setup
sceGuStart(GU_DIRECT, list);
sceGuDrawBuffer(PSP_MODE, (void*)0, PSP_LINE_SIZE);
sceGuDispBuffer(SCREEN_WIDTH, SCREEN_HEIGHT, (void*)0x88000, PSP_LINE_SIZE);
sceGuDepthBuffer((void*)0x110000, PSP_LINE_SIZE);
sceGuOffset(2048 - (SCREEN_WIDTH / 2), 2048 - (SCREEN_HEIGHT / 2));
sceGuViewport(2048, 2048, SCREEN_WIDTH, SCREEN_HEIGHT);
sceGuDepthRange(0xc350, 0x2710);
sceGuScissor(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
sceGuEnable(GU_SCISSOR_TEST);
sceGuFrontFace(GU_CW);
sceGuEnable(GU_TEXTURE_2D);
sceGuClear(GU_COLOR_BUFFER_BIT | GU_DEPTH_BUFFER_BIT);
sceGuClutMode(PSP_MODE, 0, 0, 0);
sceGuClutLoad(8192, (void *)&PspCLUT);
sceGuFinish();
sceGuSync(0,0);
sceDisplayWaitVblankStart();
sceGuDisplay(1);
#endif
// Configure the Basilisk II framebuffer.
VideoMonitor.x = BII_SCR_WIDTH;
VideoMonitor.y = BII_SCR_HEIGHT;
VideoMonitor.mode = MAC_COLOR_MODE;
VideoMonitor.bytes_per_row = PSP_LINE_SIZE * PIXEL_SIZE;
VideoMonitor.mac_frame_base = MacFrameBaseMac;
MacFrameSize = VideoMonitor.bytes_per_row * VideoMonitor.y;
MacFrameLayout = MAC_MODE;
MacFrameBaseHost = (uint8 *)PspFrameBuffer;
// Done.
D(bug("video "));
return true;
}
void video_set_palette(unsigned char *p)
{
D(bug("video_set_palette called\n"));
}
/*
* Deinitialization
*/
void VideoExit(void)
{
#if !DEBUG
sceGuTerm();
#endif
}
/*
* Video message handling
*/
void VideoInterrupt(void)
{
unsigned int j;
struct Vertex* vertices;
sceGuStart(GU_DIRECT,list);
sceGuTexMode(PSP_MODE, 0, 0, 0);
sceGuTexImage(0, PSP_LINE_SIZE, PSP_LINE_SIZE, PSP_LINE_SIZE, PspFrameBuffer);
sceGuTexFunc(GU_TFX_REPLACE, GU_TCC_RGB);
sceGuTexFilter(GU_NEAREST, GU_NEAREST);
sceGuTexScale(1.0f / ((float)PSP_LINE_SIZE), 1.0f / ((float)PSP_LINE_SIZE));
sceGuTexOffset(0.0f, 0.0f);
sceGuAmbientColor(0xffffffff);
sceGuClutMode(PSP_MODE, 0, 0, 0);
// do a striped blit (takes the page-cache into account)
for (j = 0; j < BII_SCR_WIDTH; j = j + SLICE_SIZE)
{
vertices = (struct Vertex*)sceGuGetMemory(2 * sizeof(struct Vertex));
vertices[0].u = j; vertices[0].v = 0;
vertices[0].color = 0;
vertices[0].x = j; vertices[0].y = 0; vertices[0].z = 0;
vertices[1].u = j + SLICE_SIZE; vertices[1].v = BII_SCR_HEIGHT;
vertices[1].color = 0;
vertices[1].x = j + SLICE_SIZE; vertices[1].y = BII_SCR_HEIGHT; vertices[1].z = 0;
sceGuDrawArray(GU_SPRITES,
GU_TEXTURE_16BIT | PSP_COLOR_MODE2 | GU_VERTEX_16BIT | GU_TRANSFORM_2D,
2, 0, vertices);
}
sceGuFinish();
sceGuSync(0,0);
sceGuSwapBuffers();
}You need to set the texture mode to GU_PSM_T16 - 16 bit palette lookup.ChaosKnight wrote:Code: Select all
sceGuTexMode(PSP_MODE, 0, 0, 0); sceGuTexImage(0, PSP_LINE_SIZE, PSP_LINE_SIZE, PSP_LINE_SIZE, PspFrameBuffer);
Code: Select all
sceGuClutLoad(8192, (void *)&PspCLUT);
Code: Select all
sceGuClutLoad(8192, (void *)&PspCLUT[0]);
Code: Select all
sceGuClutLoad(8192, (void *)PspCLUT);
Good catch, I feel pretty foolish about now.holger wrote:should readCode: Select all
sceGuClutLoad(8192, (void *)&PspCLUT);orCode: Select all
sceGuClutLoad(8192, (void *)&PspCLUT[0]);Code: Select all
sceGuClutLoad(8192, (void *)PspCLUT);
Code: Select all
// Build color lookup table
for (int i = 0; i < 65536; i++)
PspCLUT[i] = (i & 0x07e0) | ((i & 0xf800) >> 11) | ((i & 0x001f) << 11);
Should be at least 1024, otherwise you wouldn't be able to have a 256x32bpp colour table. So does that mean the CLUT is uploaded when you execute command 196, rather than simply setting a pointer for later use?ector wrote:Your problem is that the CLUT memory on-chip is only 512 (or possibly 1024?) bytes as far as I can tell.
I wonder why the hardware (apparently) supports 16 and 32 bit index formats then?You can't use a 65536-color palette.
Yeah oops didn't think properly there... of course it's at least 1024b.jsgf wrote:Should be at least 1024, otherwise you wouldn't be able to have a 256x32bpp colour table. So does that mean the CLUT is uploaded when you execute command 196, rather than simply setting a pointer for later use?ector wrote:Your problem is that the CLUT memory on-chip is only 512 (or possibly 1024?) bytes as far as I can tell.I wonder why the hardware (apparently) supports 16 and 32 bit index formats then?You can't use a 65536-color palette.