Loading a file from SDL_RWops

Hello.

I’m having trouble with the SDL_RWops functions. My problem is that I’m trying
to load a file from another SDL_RWops structure.

My game uses an archive for all the game files. I have a function called
LoadTiles() that’ll load a tileset file contained in the archive. The tileset
file contains the number of tiles, the flags for each tile and the image for the
tiles. I’ll use the SDL_image library to load all the files, so I need to use
the function IMG_LoadPNG_RW() to load them.

So is there a function that’ll create a SDL_RWops structure from another one? If
not, how would I do this? That’s the best way I can explain it, I think.

Thanks to anybody who replies.

Why would you want to do that? If you are just storing the entire PNG
file data in another file… simply seek to that location and use
IMG_Load*. Otherwise… allocate the necessary space… SDL_RWFromMem
it… then copy to it. The RWops API is flawed, broken and buggy. I’d be
careful not to do anything too crazy with it.

Drahcir wrote:>

Hello.

I’m having trouble with the SDL_RWops functions. My problem is that I’m trying
to load a file from another SDL_RWops structure.

My game uses an archive for all the game files. I have a function called
LoadTiles() that’ll load a tileset file contained in the archive. The tileset
file contains the number of tiles, the flags for each tile and the image for the
tiles. I’ll use the SDL_image library to load all the files, so I need to use
the function IMG_LoadPNG_RW() to load them.

So is there a function that’ll create a SDL_RWops structure from another one? If
not, how would I do this? That’s the best way I can explain it, I think.

Thanks to anybody who replies.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL_RWops is not “flawed and broken”. You found one bug in it, which is
great, but the patch you submitted changes(and breaks binary linking with)
tons of things. Just fix the bug, leave the interface alone :)On June 19, 2005 09:14 am, Antonio SJ Musumeci wrote:

Why would you want to do that? If you are just storing the entire PNG
file data in another file… simply seek to that location and use
IMG_Load*. Otherwise… allocate the necessary space… SDL_RWFromMem
it… then copy to it. The RWops API is flawed, broken and buggy. I’d be
careful not to do anything too crazy with it.

It is broken… there is no way of finding out if an error occurred. Or
if the end of a buffer/file was reached. The results of core
functionality is ambitious. Cant support large files. I’d say that’s
flawed. There are several bugs or potential problems. I fixed the
bugs… and got rid of some of those core flaws. Not my problem nor
fault the fix breaks things. No one seems to care anyway… as no one
felt the need to further discuss the issue or incorporate my fixes. The
fixes would take 2 minutes to incorporate even if you had to manually
look into the patch and replace only the bug fixes. Nor did anyone ask
me to submit a patch with just the fixes. There should be a separate
list for “developers of the SDL library” so these things get addressed
and dont get lost in the shuffle.

Tyler Montbriand wrote:>

On June 19, 2005 09:14 am, Antonio SJ Musumeci wrote:

Why would you want to do that? If you are just storing the entire PNG
file data in another file… simply seek to that location and use
IMG_Load*. Otherwise… allocate the necessary space… SDL_RWFromMem
it… then copy to it. The RWops API is flawed, broken and buggy. I’d be
careful not to do anything too crazy with it.

SDL_RWops is not “flawed and broken”. You found one bug in it, which is
great, but the patch you submitted changes(and breaks binary linking with)
tons of things. Just fix the bug, leave the interface alone :slight_smile:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

First off I’d like to say this is not a flame, I think you deserve thanks for
finding and fixing a bug in SDL, but there are some good reasons why the API
isn’t going to change any time soon.

It is broken… there is no way of finding out if an error occurred. Or
if the end of a buffer/file was reached.
No way besides SDL_RWseek, you mean.

Cant support large files. I’d say that’s flawed.
Try this program:

#include <stdio.h>
int main()
{
printf(“sizeof(int)=%d\n”,sizeof(int));
printf(“sizeof(long)=%d\n”,sizeof(long));
printf(“sizeof(size_t)=%d\n”,sizeof(size_t));
return(0);
}

Under any 32-bit compiler I’ve ever seen, those are all 4 bytes – standard
integers. So, no long file support via stdio under a 32-bit OS. :frowning: SDL
would need proprietary backends for the various UNIX flavors, Windows 9x,
Windows NT, Windows CE, MacOS 9, MacOS X, etc, etc, etc. to support long
files properly – essentially reimplimenting stdio in 64-bit. Which is not a
bad idea, I’d love to have an SDL_rwscanf, but probably more work than you
envisioned :wink:

There are several bugs or potential problems. I fixed the
bugs… and got rid of some of those core flaws. Not my problem nor
fault the fix breaks things.
It’s the “…and got rid of some of those core flaws” thing that’s the
problem. That’s unfortunately not backwards compatible, anything that used
SDL_RWops would need a recompile. You might be able to convince the devs to
put it in SDL1.3.

No one seems to care anyway… as no one felt the need to further discuss
the issue or incorporate my fixes.
I was waiting for an official word from the devs, myself. Maybye they just
missed it. People aren’t biting on my suggestions of incoroporating my
audio-input support directly into SDL either, but I don’t really think that’s
malice anyone’s part, and it doesn’t make the existing audio support
"flawed".

The fixes would take 2 minutes to incorporate even if you had to manually
look into the patch and replace only the bug fixes.
Longer than 2 minutes. :slight_smile: That’s a big patch and a small bugfix, I haven’t
yet been able to untangle them.

Nor did anyone ask me to submit a patch with just the fixes.
Could you do so now, please? I think the devs would be a lot more likely to
use it if it fixed the bug without breaking the API, and I’d LOVE to see that
bug fixed.

There should be a separate list for “developers of the SDL library” so these
things get addressed and dont get lost in the shuffle.
I agree with this completely. Maybye people could talk on the SDL-CVS list.

–TylerOn June 19, 2005 11:53 am, Antonio SJ Musumeci wrote:

Longer than 2 minutes. :slight_smile: That’s a big patch and a small bugfix, I haven’t
yet been able to untangle them.

Fwiw, neither was I, and didn’t have time to look at it for more than a
few minutes.

But it’s not a forgotten patch; it’s in my internal bugtracker with
about 20 other pending SDL patches that need to be poked, prodded,
tested on various platforms, and possibly veto’d by Sam (not necessarily
in that order!).

Could you do so now, please? I think the devs would be a lot more likely to
use it if it fixed the bug without breaking the API, and I’d LOVE to see that
bug fixed.

Actually, I’d appreciate that, too.

I agree with this completely. Maybye people could talk on the SDL-CVS list.

I don’t agree. It’s one more place to lose patches. :slight_smile:

–ryan.

It may not have been forgotten… but it would have been nice to know
that. I saw no indication it was being paid attention to. the main bug
was in mem_read… i’ll send in a new patch when i get home from work.
CVS list is not a good place… is there any reason we cant have a sdl
developers list made?

Ryan C. Gordon wrote:>

Longer than 2 minutes. :slight_smile: That’s a big patch and a small bugfix, I
haven’t yet been able to untangle them.

Fwiw, neither was I, and didn’t have time to look at it for more than a
few minutes.

But it’s not a forgotten patch; it’s in my internal bugtracker with
about 20 other pending SDL patches that need to be poked, prodded,
tested on various platforms, and possibly veto’d by Sam (not necessarily
in that order!).

Could you do so now, please? I think the devs would be a lot more
likely to use it if it fixed the bug without breaking the API, and I’d
LOVE to see that bug fixed.

Actually, I’d appreciate that, too.

I agree with this completely. Maybye people could talk on the SDL-CVS
list.

I don’t agree. It’s one more place to lose patches. :slight_smile:

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL_rwop.c mem_read patch

Antonio SJ Musumeci wrote:>

It may not have been forgotten… but it would have been nice to know
that. I saw no indication it was being paid attention to. the main bug
was in mem_read… i’ll send in a new patch when i get home from work.
CVS list is not a good place… is there any reason we cant have a sdl
developers list made?

Ryan C. Gordon wrote:

Longer than 2 minutes. :slight_smile: That’s a big patch and a small bugfix, I
haven’t yet been able to untangle them.

Fwiw, neither was I, and didn’t have time to look at it for more than
a few minutes.

But it’s not a forgotten patch; it’s in my internal bugtracker with
about 20 other pending SDL patches that need to be poked, prodded,
tested on various platforms, and possibly veto’d by Sam (not
necessarily in that order!).

Could you do so now, please? I think the devs would be a lot more
likely to use it if it fixed the bug without breaking the API, and
I’d LOVE to see that bug fixed.

Actually, I’d appreciate that, too.

I agree with this completely. Maybye people could talk on the
SDL-CVS list.

I don’t agree. It’s one more place to lose patches. :slight_smile:

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Antonio SJ Musumeci wrote:

SDL_rwop.c mem_read patch

If there was an attachment, it didn’t arrive; could you resend?

Thanks,
–ryan.

forgot to attach it… doh.

SDL_rwop.c mem_read patch

Antonio SJ Musumeci wrote:

It may not have been forgotten… but it would have been nice to know
that. I saw no indication it was being paid attention to. the main bug
was in mem_read… i’ll send in a new patch when i get home from work.
CVS list is not a good place… is there any reason we cant have a sdl
developers list made?

Ryan C. Gordon wrote:

Longer than 2 minutes. :slight_smile: That’s a big patch and a small bugfix, I
haven’t yet been able to untangle them.

Fwiw, neither was I, and didn’t have time to look at it for more than
a few minutes.

But it’s not a forgotten patch; it’s in my internal bugtracker with
about 20 other pending SDL patches that need to be poked, prodded,
tested on various platforms, and possibly veto’d by Sam (not
necessarily in that order!).

Could you do so now, please? I think the devs would be a lot more
likely to use it if it fixed the bug without breaking the API, and
I’d LOVE to see that bug fixed.

Actually, I’d appreciate that, too.

I agree with this completely. Maybye people could talk on the
SDL-CVS list.

I don’t agree. It’s one more place to lose patches. :slight_smile:

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: SDL_rwops.patch
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050623/4c82cc1f/attachment.asc

  • total_bytes = (maxnum * size);
  • if((maxnum == 0) ||
  • (size == 0) ||
  • ((total_bytes/maxnum) != size))
  • return 0;

Is there ever a time when (total_bytes/maxnum) wouldn’t equal (size),
since we create total_bytes from (maxnum*size) right beforehand?

I replaced this with:

if ((maxnum <= 0) || (size <= 0))
    return 0;

Which should catch all the bad cases. Is that acceptable, or am I
missing something?

Thanks,
–ryan.

in case of overflow…

Ryan C. Gordon wrote:>

  • total_bytes = (maxnum * size);
  • if((maxnum == 0) ||
  • (size   == 0) ||
    
  • ((total_bytes/maxnum) != size))
    
  • return 0;

Is there ever a time when (total_bytes/maxnum) wouldn’t equal (size),
since we create total_bytes from (maxnum*size) right beforehand?

I replaced this with:

if ((maxnum <= 0) || (size <= 0))
    return 0;

Which should catch all the bad cases. Is that acceptable, or am I
missing something?

Thanks,
–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Antonio SJ Musumeci wrote:

forgot to attach it… doh.

SDL_rwop.c mem_read patch

This is in CVS now, thanks!

–ryan.