In my game, I pre-load all frames. I use the function:
file_image = SDL_RWFromFile (“test.jpg”, “rw”);
With this function, I have many pointers to files loaded in memory.
Later in the game, I use the file in memory… so, I use:
the_image = IMG_LoadTyped_RW (file_image,0,“JPG”);
It works OK. But, if later, I want to display again the same jpg file, with the
same function:
the_image = IMG_LoadTyped_RW (file_image,0,“JPG”);
IMG_GetError return me: Unsupported image format.
It gives me the feeling that the file is closed, even if I passed the parameter
"0" to do not close the file…
In my game, I pre-load all frames. I use the function:
file_image = SDL_RWFromFile (“test.jpg”, “rw”);
With this function, I have many pointers to files loaded in memory.
The files are NOT loaded into memory. They’re still on disk. An SDL_RWops is
not necessarly a memory block, or even necessarily a file – it’s just an
abstraction that lets you read from lots of different things the same way.
Once you load an image IMG_Load or whatever, then they’re loaded into
memory.
Later in the game, I use the file in memory… so, I use:
the_image = IMG_LoadTyped_RW (file_image,0,“JPG”);
Any particular reason you need IMG_LoadTyped_RW? Nothing wrong with it, I
just tend to use IMG_Load_RW since it can detect and load many different file
formats, not just jpg.
It works OK. But, if later, I want to display again the same jpg file,
with the same function:
the_image = IMG_LoadTyped_RW (file_image,0,“JPG”);
Unless you freed the_image you loaded earlier with SDL_FreeSurface(the_image),
it’s still in memory! Your program will leak memory like a screen door in a
spaceship, waste massive amounts of CPU time, and thrash the hard disk by
repeatedly loading images. If all you’re doing is loading from files, I
think a better idea would be to just call IMG_Load(“test.jpg”) once, then
repeatedly use the surface pointers it gives you.
Incidentally, the image probably fails to load the second time because the
SDL_RWops stream was at the end of the file. an SDL_RWops stream doesn’t
necessarily hold anything – it’s just an abstraction on some sort of stream.On June 18, 2005 07:40 am, Talie wrote:
In my game, I pre-load all frames. I use the function:
file_image = SDL_RWFromFile (test.jpg, rw);
With this function, I have many pointers to files loaded in memory.
The files are NOT loaded into memory. They’re still on disk. An SDL_RWops is
not necessarly a memory block, or even necessarily a file – it’s just an
abstraction that lets you read from lots of different things the same way.
Once you load an image IMG_Load or whatever, then they’re loaded into
memory.
Later in the game, I use the file in memory… so, I use:
the_image = IMG_LoadTyped_RW (file_image,0,JPG);
Any particular reason you need IMG_LoadTyped_RW? Nothing wrong with it, I
just tend to use IMG_Load_RW since it can detect and load many different file
formats, not just jpg.
It works OK. But, if later, I want to display again the same jpg file,
with the same function:
the_image = IMG_LoadTyped_RW (file_image,0,JPG);
Unless you freed the_image you loaded earlier with SDL_FreeSurface(the_image),
it’s still in memory! Your program will leak memory like a screen door in a
spaceship, waste massive amounts of CPU time, and thrash the hard disk by
repeatedly loading images. If all you’re doing is loading from files, I
think a better idea would be to just call IMG_Load(test.jpg) once, then
repeatedly use the surface pointers it gives you.
Incidentally, the image probably fails to load the second time because the
SDL_RWops stream was at the end of the file. an SDL_RWops stream doesn’t
necessarily hold anything – it’s just an abstraction on some sort of stream.
I have more than 3000 frames to handle during the game. Loading them directly
with IMG_Load is too long, I want 30 fps. Also keeping these frames in memory
for the next use is also impossible.
The only way I found, is to preload in memory with either IMG_LoadTypeRW, or
IMG_LoadRW. These 2 functions gave me the same problem.
I do not think my game is special having 36 scenes of 3 seconds… so I am
really curious how commercial games handle this…> On June 18, 2005 07:40 am, Talie wrote: