hello, i was just wondering why if i load a PNG image of size 250250
and 4 bytes depth (RGBA) which should consume about 250^24 bytes of
memory (244KiB) but in practise it takes about 500KiB? is this normal or
i have some bug in my code? here are parts of my code which may be
related to this problem:======================================
if (SDL_Init(SDL_INIT_VIDEO) != 0) {
printf(“Unable to initialize SDL: %s\n”, SDL_GetError());
return 1;
}
// should I have 32 here instead? v
screen = SDL_SetVideoMode(1024, 768, 24, SDL_HWSURFACE | SDL_DOUBLEBUF
| SDL_ANYFORMAT );
hello, i was just wondering why if i load a PNG image of size 250250
and 4 bytes depth (RGBA) which should consume about 250^24 bytes of
memory (244KiB) but in practise it takes about 500KiB? is this normal or
i have some bug in my code? here are parts of my code which may be
related to this problem:
You have a memory leak:
*surf[i]=SDL_DisplayFormatAlpha(*surf[i]);
This creates a new surface and assigns it to surf[i]. The old surface is
never freed.
This should be:
SDL_Surface *image = load image;
*surf[i]=SDL_DisplayFormatAlpha(image);
SDL_FreeSurface(image);
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
hello, i was just wondering why if i load a PNG image of size 250250
and 4 bytes depth (RGBA) which should consume about 250^24 bytes of
memory (244KiB) but in practise it takes about 500KiB? is this normal or
i have some bug in my code? here are parts of my code which may be
related to this problem:
You have a memory leak:
*surf[i]=SDL_DisplayFormatAlpha(*surf[i]);
This creates a new surface and assigns it to surf[i]. The old surface is
never freed.
This should be:
SDL_Surface *image = load image;
*surf[i]=SDL_DisplayFormatAlpha(image);
SDL_FreeSurface(image);
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
thanx, how stupid of me :] it would take me long time to realize this,
i’m just not experienced with SDL
thanks again
515
This creates a new surface and assigns it to surf[i]. The old surface
is
never freed.
This has bitten me before, also. What reason is there for
SDL_DisplayFormatAlpha() not to free() the surface it is passed? I
can’t think of a case where someone would convert a surface to match
the screen format, then use both the old and the new surface
This has bitten me before, also. What reason is there for
SDL_DisplayFormatAlpha() not to free() the surface it is passed? I
can’t think of a case where someone would convert a surface to match
the screen format, then use both the old and the new surface
I can’t, either, but a general purpose library should be, well, general
purpose.
Right now, you can free() the old surface if you want. Maybe someone can
find a use for it.
OTOH, if SDL_DisplayFormatAlpha() did it automatically, the case we
can’t
think of would be impossible to do.
Sam should answer this question, but I guess the reason is something
like this.
This is how I would design an API, anyway.
Lic. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy
the beautiful power of C++ as opposed to other languages is its RAW POWER!
if you think it you can do it, thats what i love about C++.
SDL is awesome in that way too, and by not freeing it, it allows you to do
things you could otherwise not do (that we cant think of, but maybe someone
will make a great game that needs this functionality).
SDL rocks!> ----- Original Message -----
From: ggambett@artech.com.uy (Gabriel Gambetta)
To:
Sent: Wednesday, August 20, 2003 12:22 PM
Subject: RE: [SDL] SDL memory consuming
This has bitten me before, also. What reason is there for
SDL_DisplayFormatAlpha() not to free() the surface it is passed? I
can’t think of a case where someone would convert a surface to match
the screen format, then use both the old and the new surface
I can’t, either, but a general purpose library should be, well, general
purpose.
Right now, you can free() the old surface if you want. Maybe someone can
find a use for it.
OTOH, if SDL_DisplayFormatAlpha() did it automatically, the case we
can’t
think of would be impossible to do.
Sam should answer this question, but I guess the reason is something
like this.
This is how I would design an API, anyway.
Lic. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy
I can’t speak for the API designer, but IMHO consistency is a very
helpful thing in terms of library usability. If, when using a library,
the allocator is always also responsible for freeing, then you don’t
have to keep checking the API documentation to figure out whether or not
something will be freed.
If you allocate it, make sure you free it when you’re done.
Having implicit free()s just means that some other programmer is going
to get bitten by a double free bug instead of you getting bitten by a
memory leak. Pick your poison.
-Justin> ----- Original Message -----
From: “Gabriel Gambetta”
To:
Sent: Wednesday, August 20, 2003 12:22 PM
Subject: RE: [SDL] SDL memory consuming
This has bitten me before, also. What reason is there for
SDL_DisplayFormatAlpha() not to free() the surface it is passed? I
can’t think of a case where someone would convert a surface to match
the screen format, then use both the old and the new surface
I can’t, either, but a general purpose library should be, well, general
purpose.
Right now, you can free() the old surface if you want. Maybe someone can
find a use for it.
OTOH, if SDL_DisplayFormatAlpha() did it automatically, the case we
can’t
think of would be impossible to do.
Sam should answer this question, but I guess the reason is something
like this.
This is how I would design an API, anyway.
Lic. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy
I can’t speak for the API designer, but IMHO consistency is a very
helpful thing in terms of library usability. If, when using a library,
the allocator is always also responsible for freeing, then you don’t
have to keep checking the API documentation to figure out whether or not
something will be freed.
If you allocate it, make sure you free it when you’re done.
This is the rule of thumb used in the SDL design. Any allocation made
by the application needs to be freed by the application. If the API
were changed so that it did the conversion in-place, you would pass in
a pointer to a pointer to the surface, e.g.:
and then the conversion would free the old surface and assign the
new surface to the surface pointer. However, this is a little oblique,
so I decided to go with the more straightforward approach.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
I
can’t think of a case where someone would convert a surface to match
the screen format, then use both the old and the new surface
Actually there could be if you have an app where bpps can be switched
on the fly. An example could be the settings dialog of a game. In
that case you might wan’t to keep the old surface to be able to convert
it again if the color depth changes.
I can think of three uses for the current SDL_DisplayFormat behavior:
I can keep the original source surface around in case the format of the
display surface changes (in response to a user request) or the hardware
surfaces are lost (as can happen in DirectX).
I can create a copy of any surface in that has the correct pixel format
for the purpose of modifying the copy without affecting the original. This
is a pretty marginal use.
If SDL_DisplayFormat returns 0, I can keep using the original surface.–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com
