 |
forums.ps2dev.org Homebrew PS2, PSP & PS3 Development Discussions
|
| View previous topic :: View next topic |
| Author |
Message |
mplacona
Joined: 07 Aug 2007 Posts: 28
|
Posted: Mon Oct 29, 2007 7:34 pm Post subject: Advices on image loading |
|
|
Hi guys I'm using OSLIb to load some images to my app, but am finding it a bit slow to load the number of images I want. I know it's not a problem with OSLib, 'cause it's quite quick loading less images.
In my code, I have to load roughly 60 images with 1-4kb each
That's what I'm doing
| Code: | OSL_IMAGE *imgObj[DECK_SIZE];
char image_name[7];
int i;
for ( i=0; i<DECK_SIZE; i++ ) {
sprintf ( image_name, "./cards/%s.png",cards[i]);
imgObj[i] = oslLoadImageFile(image_name, OSL_IN_RAM, OSL_PF_8888);
} |
I know it wopuld be quicker if I was loading the images directly on the code without putting them in a buffer, but then my code would be a bit messed up.
Can anybody tell me about a better way to load a big number of images?
Cheers |
|
| Back to top |
|
 |
Cpasjuste
Joined: 29 May 2005 Posts: 214
|
Posted: Mon Oct 29, 2007 8:28 pm Post subject: |
|
|
| You could try to load them in vram (OSL_IN_VRAM), i'm not sure if its faster to load them in vram but you can take a look. |
|
| Back to top |
|
 |
mplacona
Joined: 07 Aug 2007 Posts: 28
|
Posted: Mon Oct 29, 2007 8:38 pm Post subject: |
|
|
Yes, I tried that, and I'm also not sure if it'[s faster for the loading, but I now it's much quicker for the displaying, but for some reason it was freezing my app.
I know the VRAM is just 2mb, and in this case I would be loading less than 1mb, so I got a bit confused in it.
Cheers |
|
| Back to top |
|
 |
Raphael

Joined: 17 Jan 2006 Posts: 646 Location: Germany
|
Posted: Mon Oct 29, 2007 9:32 pm Post subject: |
|
|
| mplacona wrote: |
I know the VRAM is just 2mb, and in this case I would be loading less than 1mb, so I got a bit confused in it.
|
Wrong. Though your images may only be < 2MB on disk, they may very well be much more than that in RAM. When loading the images, they will reside uncompressed in memory, so the size only depends on the image resolution and bit depth.
Regarding your loading speedup, you could:
- put all images into one and load only that one (which speeds up loading by using only one file access rather than 60 - which most likely is a big part of your bottleneck), then have your drawing routines adjusted so they can work with an image-sheet
- put all images into another container file (some kind of very basic virtual filesystem) for pretty much the same reason as above, but you'd still have to do 60 calls to all the png functions
- Use a less CPU intensive file format - maybe try using simple TGA with RLE compression or create your own format that just holds the zlibcompressed raw data
- Do the loading in parallel with other things (like splash screen, main menu, whatever) by threading it
However, in case you don't know how to even start about doing any of the above, you just shouldn't care about it. Try to get your game working without major bugs and make it look reasonable, then no one will think about a one or two seconds loading time. _________________ <Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
 |
Jim

Joined: 02 Jul 2005 Posts: 487 Location: Sydney
|
Posted: Mon Oct 29, 2007 10:23 pm Post subject: |
|
|
Your image_name[] array is far too small to hold the filename you are sprintf ing in to it. If the filenames are 00 to 51 it needs to be at least 15 wide.
Jim _________________ http://www.dbfinteractive.com |
|
| Back to top |
|
 |
mplacona
Joined: 07 Aug 2007 Posts: 28
|
Posted: Mon Oct 29, 2007 11:03 pm Post subject: |
|
|
| Raphael wrote: | | mplacona wrote: |
I know the VRAM is just 2mb, and in this case I would be loading less than 1mb, so I got a bit confused in it.
|
Wrong. Though your images may only be < 2MB on disk, they may very well be much more than that in RAM. When loading the images, they will reside uncompressed in memory, so the size only depends on the image resolution and bit depth.
Regarding your loading speedup, you could:
- put all images into one and load only that one (which speeds up loading by using only one file access rather than 60 - which most likely is a big part of your bottleneck), then have your drawing routines adjusted so they can work with an image-sheet
- put all images into another container file (some kind of very basic virtual filesystem) for pretty much the same reason as above, but you'd still have to do 60 calls to all the png functions
- Use a less CPU intensive file format - maybe try using simple TGA with RLE compression or create your own format that just holds the zlibcompressed raw data
- Do the loading in parallel with other things (like splash screen, main menu, whatever) by threading it
However, in case you don't know how to even start about doing any of the above, you just shouldn't care about it. Try to get your game working without major bugs and make it look reasonable, then no one will think about a one or two seconds loading time. |
Right, I like the idea of the image-sheet, and I shall be implementing this one. Though I'm not sure if this isn't gonna generate more internal processing. I can just have a function that takes a piece of this image, but then I'll be having to cann this function whenever I want to display a function. Or can I put this little pieces into a memory allocation?
And I think the TGA might be a good idea too. The images can be much smaller and will for sure use less processing
I shall try some of those tips.
Thanks again Rafael |
|
| Back to top |
|
 |
mplacona
Joined: 07 Aug 2007 Posts: 28
|
Posted: Mon Oct 29, 2007 11:06 pm Post subject: |
|
|
| Jim wrote: | Your image_name[] array is far too small to hold the filename you are sprintf ing in to it. If the filenames are 00 to 51 it needs to be at least 15 wide.
Jim |
But that isn't generating any error, and yes, my images are called 01,02,03...
Do you think the buffer size can decrease the performance? Should I change it to say... 128 then?
Cheers |
|
| Back to top |
|
 |
Raphael

Joined: 17 Jan 2006 Posts: 646 Location: Germany
|
Posted: Mon Oct 29, 2007 11:27 pm Post subject: |
|
|
| mplacona wrote: |
Do you think the buffer size can decrease the performance? Should I change it to say... 128 then?
|
It will only cause your program to crash or at least behave strange at later points. If you want to avoid that, then yes, increase the buffer size to something bigger. _________________ <Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
 |
mplacona
Joined: 07 Aug 2007 Posts: 28
|
Posted: Mon Oct 29, 2007 11:38 pm Post subject: |
|
|
| Raphael wrote: | | mplacona wrote: |
Do you think the buffer size can decrease the performance? Should I change it to say... 128 then?
|
It will only cause your program to crash or at least behave strange at later points. If you want to avoid that, then yes, increase the buffer size to something bigger. |
So it's more a preventive thing. That's cool, I shall be changing it then.... This game has been a great leaning tool.
I've been implementing lots of things I've never used before, and am now reallyfeeling like I'm doing always better in my apps.
It's very strange 'cause I'm a developer for 7 years already, but in a different field (web), and when it comes to games, I feel like I've just started yesterday lol
Cheers guys! |
|
| Back to top |
|
 |
Cpasjuste
Joined: 29 May 2005 Posts: 214
|
Posted: Tue Oct 30, 2007 3:57 am Post subject: |
|
|
| Also note that with oslib 1.0, if you load some image in vram then you must delete them in the order you loaded them. I did some testing and i'm not sure it make a lot of difference in term of speed. |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|