Need help to handle raw ARGB bitmap greater than 512x512
-
- Posts: 203
- Joined: Sat Jul 05, 2008 8:03 am
Need help to handle raw ARGB bitmap greater than 512x512
I there i'm have ported the execelnt sumatrapdf library to the psp but i stick with a problem when rendering the pdf i've got a buffer ARGB greater than 512x512
In the documentation of oslib or Easy_Accelerated_Image_lib they say that
the image must not greater than 512x512.
Is there a way to handle bitmaps that are greater than 512x512 or must i do
all by myself dividing the buffer in shunks of 512x512.
Another question can malloc use the extra 32mega of a psp slim ?
many thx for the replies (sorry for my poor english)
In the documentation of oslib or Easy_Accelerated_Image_lib they say that
the image must not greater than 512x512.
Is there a way to handle bitmaps that are greater than 512x512 or must i do
all by myself dividing the buffer in shunks of 512x512.
Another question can malloc use the extra 32mega of a psp slim ?
many thx for the replies (sorry for my poor english)
Look at the graphics.c blit code - it shows how to handle >512 horizontally. If you go >512 vertically, you'll have to do something similar for that direction as well. Basically, you're splitting the image up ANYWAY because the texture cache only handles 32 to 128 wide (depending on the depth). So most blit routines slice the image into 32 pixel wide stripes. You use the stride to allow for the fact that the image width does not equal the width you are blitting.
If you look at my refresh code in Basilisk II, you'll see where I split the blit both horizontally and vertically. My refresh handles >512 wide and up to 1024 vertically.
To get the extra memory on the Slim, you need to add "PSP_LARGE_MEMORY = 1" to the makefile.
If you look at my refresh code in Basilisk II, you'll see where I split the blit both horizontally and vertically. My refresh handles >512 wide and up to 1024 vertically.
To get the extra memory on the Slim, you need to add "PSP_LARGE_MEMORY = 1" to the makefile.
-
- Posts: 203
- Joined: Sat Jul 05, 2008 8:03 am
OK so when i but PSP_LARGE_MEMORY = 1 in my makefile the malloc function
automaticly give me the extra 32 Mega right ?
and has no effect when my homebrew run on a fat psp (just less heap space availaible) for know i need +- 20Méga of ram to rendering pdfs but i can use
the extra 32 mega for bitmap page caching thx a lot for the tips
automaticly give me the extra 32 Mega right ?
and has no effect when my homebrew run on a fat psp (just less heap space availaible) for know i need +- 20Méga of ram to rendering pdfs but i can use
the extra 32 mega for bitmap page caching thx a lot for the tips
Yes. Specifying large memory only affects the Slim - the Phat ignores it. The memory is available to plain allocation commands as long as you set the heap size to max or a small negative value.
takes all available user memory to the app.
takes all available memory except for the number of KB specified. I generally use
in my stuff. That leaves 256KB for threads and stuff. The heap size goes in your main.c, not the makefile (in case you were wondering).
Using the negative value is great if you want something that works on both the Slim and the Phat with a single executable while still giving all the extra memory on the Slim.
Code: Select all
PSP_HEAP_SIZE_MAX();
Code: Select all
PSP_HEAP_SIZE_KB(-kilobytes);
Code: Select all
PSP_HEAP_SIZE_KB(-256);
Using the negative value is great if you want something that works on both the Slim and the Phat with a single executable while still giving all the extra memory on the Slim.
-
- Posts: 203
- Joined: Sat Jul 05, 2008 8:03 am
-
- Posts: 203
- Joined: Sat Jul 05, 2008 8:03 am
You can create any size image. To load any size image, you have to comment out this block of code from the loadImage function:
Note that graphics.c doesn't handle vertical sizes >512, only horizontal. You'll have to modify the blits in the file to handle vertical as well as horizontal for heights >512.
Code: Select all
if (width > 512 || height > 512) {
free(image);
fclose(fp);
png_destroy_read_struct(&png_ptr, png_infopp_NULL, png_infopp_NULL);
return NULL;
Look at openTri game engine it supports > 512x512 (as long as the image fits into memory openTri can handle it)
Code: Select all
.øOº'ºOø.
'ºOo.oOº'
-
- Posts: 203
- Joined: Sat Jul 05, 2008 8:03 am