32-bit texture problem

[Valohtar]

Here a bit of background: I'm using the base code off of the spharm example, so most of the settings are set to whatever used to be there. I did change sceGuTexFunc from GU_TCC_RGB to GU_TCC_RGBA just so you know. I created a raw image with 4 channels RGBA in that order. I am also using that convertimage method (just changed the code for the alpha), although I'm not really sure why it's used. The image is 480x272, and when I use sceGuTexImage(0,256,145,256,logo_temp); as per the example, it doesn't appear to load the entire image. I've tried fiddling with the tbw, but I have no clue which number to use, and none of them turn out right. If you could give me some pointers, I would greatly appreciate it.



Also, is there any good reference sites that I could use to catch up on the basics of hardware rendering, such as what the texture buffer width and such. Google doesn't give the best results, but I also don't know what to search for.


Thanks.

[Shine]

You should read the documentation, see the pspsdk/sdk/gu/pspgu.h file:

/**
* Set current texturemap
*
* Textures may reside in main RAM, but it has a huge speed-penalty. Swizzle textures
* to get maximum speed.
*
* NOTE: Data must be aligned to 1 quad word (16 bytes)
*
* @param mipmap - Mipmap level
* @param width - Width of texture (must be a power of 2)
* @param height - Height of texture (must be a power of 2)
* @param tbw - Texture Buffer Width (block-aligned)
* @param tbp - Texture buffer pointer (16 byte aligned)
**/
void sceGuTexImage(int mipmap, int width, int height, int tbw, const void* tbp);

Your image is 480 pixels width, so using 256 is wrong. Use 512 (power of 2) for your image and change the parameters of the function call.

[Valohtar]

Figures I didn't know that you could click on the methods in the doxygen docs for more info =P. What I decided to do was to resize my 480x272 into 512x512 since the width and height said that it needed to be a power of 2. Once this was done, I changed the sceGuTexImage to (0,512,512,512,logo_temp) which I'm assuming is correct, but when it loads, one triangle of the quad shows nothing, while the second shows about the top third correctly then it seems to repeat itself, but a little bit smaller and a little more messed up each time it repeats. If that is hard to visualize, I can take a picture of the psp and post it.

Here a bit of the settings in case it helps:

Code: Select all

		logo_temp = convertimage(logo_start,512);
		sceGuEnable(GU_TEXTURE_2D);
		sceGuTexMode(GU_PSM_8888,0,0,0);
		sceGuTexImage(0,512,512,512,logo_temp);
		sceGuTexFunc(GU_TFX_REPLACE,GU_TCC_RGBA);
		sceGuTexFilter(GU_NEAREST,GU_NEAREST);
		sceGuTexScale(1.0f,1.0f);
		sceGuTexOffset(0.0f,0.0f);
		sceGuAmbientColor(0xff101010);
		sceGuTexSync();
		sceGuDrawArray(GU_TRIANGLES,GU_TEXTURE_32BITF|GU_COLOR_8888|GU_VERTEX_32BITF|GU_TRANSFORM_3D,6,0,vertices);

Thanks for the help.

[Shine]

Here a bit of the settings in case it helps:

No, it doesn't help, because your failure may be in setting up the u/v coordinates in the vertices array.

[Valohtar]

Thanks for the quick reply. These are all my vertices:

Code: Select all

struct Vertex __attribute__((aligned(16))) vertices[2*3] = {
	{0, 1, 0xFF000000, -1.7f, -1.05f, 1.0f}, // 0
	{0, 0, 0xFF000000, -1.7f, 8.10f, 1.0f}, // 1
	{1, 0, 0xFF000000, 14.7f, 8.10f, 1.0f}, // 3

	{0, 1, 0xFF000000, -1.7f, -1.05f, 1.0f}, // 0
	{1, 1, 0xFF000000, 14.7f, -1.05f, 1.0f}, // 2
	{1, 0, 0xFF000000, 14.7f, 8.10f, 1.0f}, // 3
};

From my limited understanding, I figured that should be right since I used a smaller image that I think was 128x128 and that looked fine.

[Shine]

Displaying quads are easier with GU_SPRITES instead of GU_TRIANGLES, see for example the graphics module in my Lua Player and the function "blitAlphaImageToScreen".

But it should work with 2 triangles, too. I think one triangle is not visible, because it has the wrong order (clockwise vs. counter-clockwise), if you have enabled backface culling. The u/v coordinates looks ok, so I don't know, why it looks wrong.

[Valohtar]

Thanks for the info. I'll check it out =).

[Valohtar]

I was messing around a bit with your functions and I decided to take the graphics.c/h and pretty much use that as pg.c/h that I was using before. Is there any problem with that? Also, I tried using the loadImage with blitAlphaToScreen and one of the two doesn't seem to be working for me. Whichever one it is, it's making the images turn out really messed up =/. I made a rainbow gradient png to test at 480x272 and it turned out to be about as big as a quarter of the screen. It also repeats twice and for whatever reason, there is only the red and green channels, or at least it appears that way.

I was going to take a screenshot(), but it came out black =/.

Have a look at the code if you want because it has me stumped:

Code: Select all

#include <pspkernel.h>
#include <pspdebug.h>
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <stdio.h>
#include "psputils.h"
#include "pspctrl.h"
#include "graphics.h"
#include <pspaudio.h>
#include <pspaudiolib.h>

#define printf	pspDebugScreenPrintf

/* Define the module info section */
PSP_MODULE_INFO&#40;"SDKTEST", 0, 1, 1&#41;;

/* Define the main thread's attribute value &#40;optional&#41; */
PSP_MAIN_THREAD_ATTR&#40;THREAD_ATTR_USER | THREAD_ATTR_VFPU&#41;;

//Callbacks were here...

int main&#40;&#41; &#123;
	SetupCallbacks&#40;&#41;;
	initGraphics&#40;&#41;;
	pspDebugScreenInit&#40;&#41;;
	Image* image = &#40;Image*&#41; malloc&#40;sizeof&#40;Image&#41;&#41;;
	image = loadImage&#40;"image.png"&#41;; 
	if &#40;!image&#41; &#123;printf&#40;"This isn't working"&#41;;&#125;

	while &#40;1&#41; &#123;
		blitAlphaImageToScreen&#40;0 ,0 ,480 , 272, image, 10, 50&#41;;
		sceDisplayWaitVblankStart&#40;&#41;;
	&#125;
	return 0;
&#125;

And my makefile:

Code: Select all

TARGET = pngtest
OBJS = pngtest.o graphics.o

INCDIR =
CFLAGS = -G0 -Wall -fno-exceptions
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
ASFLAGS = $(CFLAGS)

LIBDIR =
LDFLAGS =
LIBS= -lpng -lz -lpspgu -lm

EXTRA_TARGETS = EBOOT.PBP
PSP_EBOOT_TITLE = PNG Blit Test

PSPSDK=$(shell psp-config --pspsdk-path)
include $(PSPSDK)/lib/build.mak

This is the image I was using. It's non-interlaced if it matters.


Thanks.

[Shine]

I was messing around a bit with your functions and I decided to take the graphics.c/h and pretty much use that as pg.c/h that I was using before. Is there any problem with that?

this is ok, see the LICENSE file: you can use it for whatever you want, just include a little note somewhere from where you got it.

Image* image = (Image*) malloc(sizeof(Image));

you don't need this, because loadImage allocates the image structure.

blitAlphaImageToScreen(0 ,0 ,480 , 272, image, 10, 50);

This is not allowed and can result in undefined results, see the graphics.h documentation for the "@pre" line: dx + width <= SCREEN_WIDTH. All "@pre" statements are preconditions, for which the caller has the responsible (for speed reason I don't check it, because for my Lua Player for some functions I don't need to check all preconditions, for example when they can't be violated, because the positions are hardcoded).

I don't know why you see an image at all, because you don't call flipScreen and if you are using the original code, the drawing goes to the offscreen image all the time (and this is the reason why screenshot doesn't work, because it saves the currently visible screen). I think the problem is the call to pspDebugScreenInit after initGraphics, because this changes the graphics mode to 32 bit, and graphics.c uses 16 bit.

[Valohtar]

That's perfect! Finally I can get back to development. I've been stuck for a few days trying to figure out how the GU works when software rendering didn't provide enough speed. Thanks so much.