Code: Select all
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);
}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.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.
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?Raphael wrote: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.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.
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.
But that isn't generating any error, and yes, my images are called 01,02,03...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
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.mplacona wrote: Do you think the buffer size can decrease the performance? Should I change it to say... 128 then?
So it's more a preventive thing. That's cool, I shall be changing it then.... This game has been a great leaning tool.Raphael wrote: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.mplacona wrote: Do you think the buffer size can decrease the performance? Should I change it to say... 128 then?
