sceGuCopyImage() questions.

[sambro]

Hi guys,

This post might seem a little long winded, but I actually have a couple of questions about the way sceGuCopyImage() operates.

Basically, I'm in the process of porting an app over to the PSP. This particular app stores its pixel data in a u32* buffer.

The bizarre thing is, this app adds a black pixel at the end of each line, and also has a blank line at the top and bottom of the buffer. Apparently this is there to facilitate for image filters you can run on the buffer before displaying it (2xSaI, hq2x etc).

The sceGuCopyImage() documentation says your data needs to be aligned to a quad word (64 bytes right?). The app I'm porting over uses 160 pixel wide resolution, so obviously with the extra pixel tacked on the end of each line, I can't align the buffer on a 64byte boundary.

I tried modifying the internal workings of the app so it would pad the end of each line with two pixels inseatd of one. I also changed it so the app used memalign(64, width * height * 4); instead of malloc() to keep the buffer on the quad word memory boundary. I checked this at run time, the memory address with definetely on the 64 byte boundary.

So with that done, I tried this code.

Code: Select all

void pspGraphics::copyImageToBackbuffer(u32* src, int sx, int sy, int w, int h, int wa, int dx, int dy)
{
  if(!_initialized) return;

  sceKernelDcacheWritebackAll();

  sceGuStart(GU_DIRECT, _list);

  sceGuCopyImage(GU_PSM_8888, sx, sy, w, h, wa, src, dx, dy, 512, getBackbuffer());

  sceGuFinish();
}

... ....

(_width and _height are private members with width and height of app. *buffer is the u32 pointer to the app's pixel buffer)
for&#40;int y = 0; y < _height; y++&#41;
&#123;
  _graphics.copyImageToBackbuffer&#40;buffer, 0, 0, _width, 1, _width + 2, 0, y&#41;;
  buffer += _width + 2; // skips to next line &#40;skips over the last two bytes&#41;
&#125;

So as you can see, the code is copying buffer line by line. Bizarre thing is, those two pixels at the end of each line are showing up at the start of the next line. This obviously throws the whole buffer out of whack when it's displayed on screen (makes the image sort of slant)

This would lead me to believe that sceGuCopyImage() actually aligns to 128 bytes. The logic behind this statement is that if we look at the facts, the buffer I'm copying from:

• Is aligned on 64 byte boundary.
  Has 162 pixel line width (162 * 32 bytes / 64 bytes = 81) Evenly divisible on 64 byte boundary.

So that's my first question: does sceGuCopyImage in fact align to 128 bytes, or am I doing something incredibly wrong?

Second question is regarding the source buffer width parameter. As you can see from my above snippet, it's kind of strange that I'm doing image copies line by line. The reason I do this is because I don't want those two pixels on the end of each line showing up.

The app pixel buffer is 160x144. Obviously with the two pixels at the end, it's 162x144. Shouldn't I just be able to copy the buffer to the psp screen like this?

Code: Select all

  sceGuCopyImage(GU_PSM_8888, 0, 0, 160, 144, 162, sourceBuffer, 0, 0, 512, backbuffer);

By setting the source buffer width to 162, shouldn't sceGuCopyImage() skip over the last two pixels?

And also, when allocating the memory for the buffer, using memalign(64, width * height * 4); is correct is it not?

I checked at runtime, and it's definetely returning a memory address aligned to 64 byte boundary. It also seems to be sucking 15mb of my RAM at runtime :P[/code][/list]