Equilibrium369 wrote:I've been trying to fix some bug for the last few days with no hope
It has something to do with drawing about 3 or more objects that have a size greater than 0 (repeated images) to the screen at once. Basically the whole game just slows down when I draw certain images with a large size.
Chilly Willy: I'm under the impression that blitting images to the screen which are outside the bounds of the screen are just ignored, is this true? It seems that if I have an object with a large size (several repeated images) and its drawn somewhere off the screen it still has the same bad affect as when I draw it inside the screen bounds. To me that just makes it seem like it must be my code but I just can't see a problem. I could be completely wrong, but maybe swizzling would help. I might upload the source code if it's ok?
Edit: I think I might have fixed it now, although everytime I think that it keeps coming back to bite me lol
I changed the image display system to use a similar one to the collision engine. There is an array of image boxes (a structure with coordinates and index of the Image data) and it gets added to each time a new object is placed when the level is loaded. Then I made it loop through the image boxes array and only blit the ones which have at least some part inside the screen bounds. I still think it might be best to add texture swizzling support though, if it makes that much of a difference.
The rendering on the PSP uses a local coordinate system of 2048 by 2048. As part of the initialization, you generally set some scissors so that only the screen (which is set at the center) actually gets written to the display ram. That's what these lines do:
Code: Select all
sceGuOffset(2048 - (SCREEN_WIDTH / 2), 2048 - (SCREEN_HEIGHT / 2));
sceGuViewport(2048, 2048, SCREEN_WIDTH, SCREEN_HEIGHT);
sceGuScissor(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT);
sceGuEnable(GU_SCISSOR_TEST);
Note that objects are always fully processed, even if outside the scissors, just not written to ram. Therefore, you don't want to render objects completely outside the screen as that's wasting time, however, a BIG object that is partially rendered and partially clipped could waste time if it's mostly outside the screen as well. Because of that and the small texture cache, people generally use "slices" to do blits to the display. The texture cache can only hold a certain width and height of the texture data, which depends on the number of colors in the texture. Most people settle for what fits using 32 bit or 16 bit textures, but if you use 8 bit, or 4 bit textures, you can increase the width of the slices to take better advantage of the texture cache. The cache is 8KB, and is organized as 64x32 with 32 bit textures, 64x64 for 16 bit, 128x64 for 8 bit, and 128x128 for 4 bit. Note that the nibbles for 4 bit textures are swapped from the normal convention! That is, bits 0-3 are the leftmost pixel, and bits 4-7 are the rightmost pixel. So if you use 4 bit textures, you need to swap the nibbles when you copy the texture to ram.
Anywho, because the cache only holds a certain width, attempting to use more than that width causes the cache to be reloaded. Because the PSP GE renders a line at a time, you'll reload the texture cache SEVERAL TIMES for EVERY SINGLE LINE if you exceed that width. That's why blitting lots of "big" textures gets slow. Slicing the texture into widths that fit in the cache is a tremendous speed boost. A typical blit with splicing looks like this:
Code: Select all
int j = 0;
while (j < width) {
Vertex* vertices = (Vertex*) sceGuGetMemory(2 * sizeof(Vertex));
int sliceWidth = 64;
if (j + sliceWidth > width) sliceWidth = width - j;
vertices[0].u = sx + j;
vertices[0].v = sy;
vertices[0].x = dx + j;
vertices[0].y = dy;
vertices[0].z = 0;
vertices[1].u = sx + j + sliceWidth;
vertices[1].v = sy + height;
vertices[1].x = dx + j + sliceWidth;
vertices[1].y = dy + height;
vertices[1].z = 0;
sceGuDrawArray(GU_SPRITES, GU_TEXTURE_16BIT | GU_VERTEX_16BIT | GU_TRANSFORM_2D, 2, 0, vertices);
j += sliceWidth;
}
Notice how the slice width is set to 64, which is the most a 32 bit texture can be. You step across the texture being blitted, doing 64 pixels (wide) at a time. Note that you could slice vertically as well, but there's usually no need. The texture cache holds 32 lines at 32 bits - if you blit more than 32 lines, it will reload the cache after 32 lines have been blitted. So the entire cache is used as long as you slice the horizontal dimension. Notice that slicing also stops when you reach the edge of the display. By slicing an object, you limit the amount of the object that gets processed outside the display for no reason.
it was a great post. However, you're saying that porting it to PC won't be any trouble at all? it'll be rather easy for you?
.