Results 1 to 6 of 6

Thread: About SDL_LoadBMP() ...

                  
   
  1. #1
    DCEmu Newbie
    Join Date
    Oct 2005
    Posts
    23
    Rep Power
    0

    Question About SDL_LoadBMP() ...

    Hi


    I have a question about SDL_LoadBMP() :

    when i load a file with this function where the data are stored ?
    in the main ram (16 mo) in the video ram (8 mo) ?

    i use this sequence to init SDL :


    screen=SDL_SetVideoMode(640,480,16,SDL_HWSURFACE|S DL_DOUBLEBUF|SDL_FULLSCREEN);

    ....


    thanks

  2. #2
    4ALLs coder chui's Avatar
    Join Date
    Aug 2004
    Location
    Madrid
    Posts
    414
    Rep Power
    74

    Default

    It is stored ALWAYS in RAM, no VRAM.

    VRAM transfers is very slow.

  3. #3
    DCEmu Newbie
    Join Date
    Oct 2005
    Posts
    23
    Rep Power
    0

    Exclamation Big memory Leak in SDL (dreamcast)?

    Well, if the SDL on Dreamcast use RAM to load surfaces like you said earlier, i found a very annoying bug in memory management

    i explain :

    Using:

    a coder's cable to link my DC to my PC
    DC serial to load elf produced by Gcc
    Kos 1.3
    SDL DC 1.2.9 (the latest from the web site) compiled with my version of Kos ...

    To test simply the accuracy of SDL_FreeSurface() i use a "big" bitmap file of about 6 mo, i place it on a romdisk with the elf.

    The code in the elf only process initialisations of Kos and SDL properly then load the surface with SDL_LoadBMP(). I have disabled Malloc statistics on kos flags (to test all il real condition).

    I use a simple for/next C routine wich load the surface, display it on screen, and free it. After only 1 iterations the system break down saying something like :

    Requested sbrk_base 0x8d0ab000, was 0x8cfe8000, diff XXXXX
    kernel panic: out of memory; about to run over kernel stack
    arch: aborting the system

    where XXXX is an amount of bytes ....

    I search some reasons why it crashes and i discover that in fact, all the surfaces loaded by SDL are not free'd when using SDL_FreeSurface().

    All seems to work like this :

    all the surfaces loaded are kept in main memory and never freed until the amount of main ram (16 mo) will be used, at this time the system crash and give the amount of memory needed to continue the execution of the program ... (the XXXXX bytes).

    For the example i said, 8 mo of BMP file loaded with the lenght of the elf and other ressources use all memory to perform a second loop ...

    If i reduce the size of the BMP file i increase the number of iterations, if i load the ressources from a CDR, it increase the number of iterations too, according to the fact that main memory have not to handle the Romdisk but it finally crash later ....

    If somebody have an idea, how to perform a "memory cleaning" ... or an advise to correct SDL source code ... it certainly appreciated by me of course but all persons using SDL ...

    Thanks

  4. #4
    DCEmu Coder
    Join Date
    Oct 2004
    Location
    Three rivers, ca
    Posts
    190
    Rep Power
    72

    Default

    Hum it could explain why our game morback crashes, but I don't get any memory error, so it may be something else.

    Anyway search in the sources for SDL_FreeSurface and look if there's some mistake somewhere.

  5. #5
    DCEmu Coder
    Join Date
    Oct 2004
    Location
    Three rivers, ca
    Posts
    190
    Rep Power
    72

    Default

    I see at the bottom of src/video/SDL_surface.c
    #ifdef CHECK_LEAKS
    --surfaces_allocated;
    #endif
    You could define CHECK_LEAKS and see if surfaces_allocated keeps growing after each load/free.

  6. #6
    DCEmu Newbie
    Join Date
    Oct 2005
    Posts
    23
    Rep Power
    0

    Default

    in src/video/SDL_surface.c we can see the SDL_FreeSurface function definition :


    /*
    * Free a surface created by the above function.
    */
    void SDL_FreeSurface (SDL_Surface *surface)
    {
    /* Free anything that's not NULL, and not the screen surface */
    if ((surface == NULL) ||
    (current_video &&
    ((surface == SDL_ShadowSurface)||(surface == SDL_VideoSurface)))) {
    return;
    }
    if ( --surface->refcount > 0 ) {
    return;
    }
    while ( surface->locked > 0 ) {
    SDL_UnlockSurface(surface);
    }
    if ( (surface->flags & SDL_RLEACCEL) == SDL_RLEACCEL ) {
    SDL_UnRLESurface(surface, 0);
    }
    if ( surface->format ) {
    SDL_FreeFormat(surface->format);
    surface->format = NULL;
    }
    if ( surface->map != NULL ) {
    SDL_FreeBlitMap(surface->map);
    surface->map = NULL;
    }
    if ( surface->hwdata ) {
    SDL_VideoDevice *video = current_video;
    SDL_VideoDevice *this = current_video;
    video->FreeHWSurface(this, surface);
    }
    if ( surface->pixels &&
    ((surface->flags & SDL_PREALLOC) != SDL_PREALLOC) ) {
    free(surface->pixels);
    }
    free(surface);
    #ifdef CHECK_LEAKS
    --surfaces_allocated;
    #endif
    }

    the CHECK_LEAKS macro could not bee usefull in this case of memory leaking
    It checks only the number of freeing opérations you make.

    For example, if you use 2 surfaces you be wise to use twice SDL_FreeSurface.
    I notice that the pointer is not set to NULL after freeing.

    The problem i talk about is in within the function (perhaps) because even with calling the function for each surface allocated, in any case it does not completly clean the memory.

    The problem is that i am not sure of what is not correctly clean.
    I think that the most important data in size are the pixel area of a surface :

    "surface->pixels" it's perhaps here where something's wrong. But i notice too that not calling SDL_FreeSurface at all will crash sooner the system.

    So the function make some memory cleaning but not all expected.

    I have seen in another function that the "pixels" pointer is allocated with malloc as "pitch*height" memory segment.

    I continue to search around ...

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •