Does the gu on PSP have a scale function that will let me scale a texture and store the result in memory or even on the memory stick? I am playing around with PSP programming by writing a simple image viewer.
I want to be able to scale large images with some filtering so the results aren't garbage. I wrote a standard resize function using bilinear interpolation but it is slow as hell. I was wondering if PSP provided a hardware solution.
Please help this newbie out ;-)
Scaling image in hardware, storing result
Well, you don't need to resize a texture at all, because you will always map it on a poly....if you want to reduce texture dimensions once loaded before entring in critical loops, long elaboration time should not be an issue...if you still wish to do such a thing you should study the renderTarget demo in pspsdk....it shows how to render (a quad poly with your texture mapped upon, in your case) in another texture:it allows scaling filtering and blending features
No, obviously you cannot use this tecnique with image sizes that doesn't fit in hardware supported textures....somewere in this forum or in pspsdk sources you should find the maximum dimensions and formats of PSP GE textures...if you want to do image processing on large data blocks in a crytical loop and still -somehow- maintain performances, you should rely on ME processor, but this is definitely no newbie fiendly :)
Consider explaining in a clearer way what do you want to achieve as a final effect; in the beginning i was afraid to show off my ideas too, but if you don't, people has to do a far harder work to help you...
jean
Consider explaining in a clearer way what do you want to achieve as a final effect; in the beginning i was afraid to show off my ideas too, but if you don't, people has to do a far harder work to help you...
jean
You can accomplish what you want, you would have to be pretty crafty about it though. You would have to create an image loader that could load the texture up on pieces. In other words, your 2048x2048 would have to be loaded as four 512x512 images, 16 256x256, or 32 128x128 images. There's ways of doing it. After you have that accomplished, you would create as many quads (for 3D and rotation) or sprites (for 2D or 3D no-rotation) as you do have pieces of that huge texture (which as a bunch of smaller textures). Then, you would map each of the smaller textures to your quads, and align the quads to that it creates you giant image. That should do it.
This can be tedious for the PSP, but luckily, I have a few solutions:
-Break all giant textures such as this that you want to load into smaller pieces like 16x16 or 32x32. It is MUCH faster blit/draw smaller textures than it is to draw bigger ones.
-I'm guessing that you won't be able to see the whole texture on the PSP? In that case, nest your sceGuDrawArray() call with the sceGuBeginObject() and sceGuEndObject() functions. All objects that aren't in view are culled. For the bounding box parameter, supply the vertex array for your quad.
Note: You will need to be using the 3D transformation pipeline to cull objects like this as far as I know.
EDIT: Also, the largest supported textures that the PSP supports are 512x512. I think there isn't a limit to the height, but there is definitely a limit on the texture width. I am most certain this is a limit to the texture height though. It is very possible to do what you want, but it will take a little strategic programming to do the job. ;)
This can be tedious for the PSP, but luckily, I have a few solutions:
-Break all giant textures such as this that you want to load into smaller pieces like 16x16 or 32x32. It is MUCH faster blit/draw smaller textures than it is to draw bigger ones.
-I'm guessing that you won't be able to see the whole texture on the PSP? In that case, nest your sceGuDrawArray() call with the sceGuBeginObject() and sceGuEndObject() functions. All objects that aren't in view are culled. For the bounding box parameter, supply the vertex array for your quad.
Note: You will need to be using the 3D transformation pipeline to cull objects like this as far as I know.
EDIT: Also, the largest supported textures that the PSP supports are 512x512. I think there isn't a limit to the height, but there is definitely a limit on the texture width. I am most certain this is a limit to the texture height though. It is very possible to do what you want, but it will take a little strategic programming to do the job. ;)
I'm not sure doing this thing of breaking the texture into chunks would be that fine. First of all you still can't write in a texture bigger than the max size (512x512 you say...), second if you want it fast you have to setup a display list (complexity for such a simple task grows) and last but not least, processing small squares instead of the whole thing definitely throws in the trashcan FILTERING (even this can be fixed, but complexity keeps growing, or you can leave your result image with a grid-looking style). I'm sure that all the answers of the world can't answer a wrong question: let Shapyi explain what his plans are. So we can understand:
1) why can't you save your texture already resized?
2) why resize time is an issue for you? Aren't "Loading..." screens cool? :)
3) if you've to do this realtime, why don't make use of MIP mapping?
4) is filtering (and generally speaking quality) important to you?
jean
1) why can't you save your texture already resized?
2) why resize time is an issue for you? Aren't "Loading..." screens cool? :)
3) if you've to do this realtime, why don't make use of MIP mapping?
4) is filtering (and generally speaking quality) important to you?
jean
I'm just writing a simple image viewer.jean wrote:1) why can't you save your texture already resized?
2) why resize time is an issue for you? Aren't "Loading..." screens cool? :)
3) if you've to do this realtime, why don't make use of MIP mapping?
4) is filtering (and generally speaking quality) important to you?
jean
1) Because I want to throw any image at it, resizing it on the PC and putting it on the memory stick defeats the purpose
2) Resize time is not an issue, it could take a couple seconds, it does not need to be instant. More or less it should take the time PSP's XMB menu Photo channel resizes it.
3) That is a possiblity
4) Yes, the resized image should be smooth
I've been looking at something someone else wrote in SDL right now and it seems to be working. I was just wondering if there was a simple solution provided by PSP, if not I can live with the SDL implementation.
Ok, then i think I wouldn't bother doing this in hardware or using a whole media library like SDL...just optimize your load-and-resize algorythm. To do this you have to:
1) load the whole image in memory in big chunks...it's a common mistake to do unbuffered small reads: this slows down like hell
2) avoid "IF" and generally jump statements in tight loops if possible
3) use the VFPU or (better in this case) fixed point arithmetic in filtering algorithm
I think the whole thing should take less than 0.5s...the bottleneck is memory stick access.
1) load the whole image in memory in big chunks...it's a common mistake to do unbuffered small reads: this slows down like hell
2) avoid "IF" and generally jump statements in tight loops if possible
3) use the VFPU or (better in this case) fixed point arithmetic in filtering algorithm
I think the whole thing should take less than 0.5s...the bottleneck is memory stick access.