Page 1 of 2 12 LastLast
Results 1 to 20 of 22

Thread: Surface unloading and black screen

  1. #1

    Default Surface unloading and black screen

    Hi all,

    I'm developing using ClanLib versione 1.0 since I still don't have time to make a migration to 2.0. In my game I created a class managin resource for different game phases. This class have two main function for load and unload resource from XML file as follow:

    LoadResourcesFromXML(string XMLFile, string SurfaceSection)
    {
    ......
    CL_ResourceManager ResourceManager(XMLFile);

    ResourceManager.load_section(SurfaceSection);

    ResourceList = ResourceManager.get_resources_of_type(string("surf ace"), SurfaceSection);

    for(iter = ResourceList.begin(); iter != ResourceList.end(); iter++)
    {
    string SurfaceName;

    m_SurfaceList[SurfaceName] = new CL_Surface((*iter), &ResourceManager);
    }

    ResourceManager.unload_section(SurfaceSection);

    .....
    }

    UnloadResourceFromMemory()
    {
    .....
    if(m_SurfaceList.size() > 0)
    {
    hash_map<string, CL_Surface*>::iterator SurfaceIt;
    for(SurfaceIt = m_SurfaceList.begin(); SurfaceIt != m_SurfaceList.end(); SurfaceIt++) delete SurfaceIt->second;
    m_SurfaceList.clear();
    }
    .....
    }

    In my game there are three different sections and I allocate this class for every section loading the different resource connected to the right section. This mechanism work very well but the problem is that if I decide to call the UnloadResourceFromMemory() for only ONE of the three allocated class object (for free memory) also the other two sections doesnt work anymore and the draw surface function doesn't show any surface, I see only a black screen instead but, and this is the strage thing, the program continue to work like no problem exist. I'm checking the clanlib code but I can not find the reasons of this problem. Maybe I made a mistake in the way I unload the surfaces (delete SurfaceIt->second). Someone can help me?
    Thank you

  2. #2

    Default

    Nobody have a suggestion? This is a big problem for me since I can not free memory for load graphic set for the next game phase...

  3. #3
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Sorry, I can't personally help, because I do not know any of ClanLib 1.0

    Most active developers now use ClanLib 2.1

    Note, porting to 2.1 shouldn't be too difficult, see: http://www.clanlib.org/beta/index.ph...lanLib_1.0_API

    But it may be time consuming.

  4. #4

    Default

    Unfortunately the porting is no so easy as described in the article. A lot of things was changed. Log is changed, Mutex is changed, font is changed, Drawparams was removed and I still have to understand how to "substitute" them and these are only some examples. A complete porting of my project to 2.0 will need a very large quantity of time includign retesting for check that all the modifies was made well....
    Last edited by falsinfab; 03-26-2010 at 09:43 AM.

  5. #5

    Default

    Currently I don't have the time for make the porting but I absolutely must to resolve this problem. I'm the only game developer who need to free memory by disallocate some resources previously used?

  6. #6

    Default

    Maybe found the problem but currently no solution for find a workaround. In my game I have a main thread for initialize all the objects, resources and render the screen and a secondary thread for manage input events and magane the game phases. All the resources are loaded and intialized in the initialization phase called by the main thread and, currently, try to unload from the secondary thread managin the game. It seem this is the problem. The various ClanLib resources class during destructor phase call this piece of code:

    CL_OpenGLState state(CL_Display::get_current_window()->get_gc());
    state.set_active();

    that set as active screen an "unknown" screen (since, I suppose, get the gc from the secondary thread). From this point the game work but with a back screen I suppose because all the render functions are redirected to this "non existent" window....
    Someone have a solution?

  7. #7

    Default

    Hi,

    I'm still looking for a good solution to this problem. Some Clanlib developer can give me a suggestion for a workaround?

    Thank you

  8. #8
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    The problem is that the graphical resources are only be safe when used from the main thread. You therefore must create, draw and destroy your surface objects from that thread.

    Technically the windowing system resources (HDC and OpenGL handles) belong to the thread that created them and can only be safely used from there. It is not entirely clear on the WGL documentation whether an OpenGL handle can be safely used from a different thread, but even if it can I'm not sure if ClanLib 1.0's context tracking (the set_active thing) uses a thread local variable or a global static variable. If it uses a global static variable it could explain the behavior you are seeing.

    Hope that helps.

  9. #9

    Default

    Hi Magnus,

    Thank you for your explanation. You confirmed my tests. So there is no other way except to change the point where the resource are deallocated, from secondary thread to main thread.
    Well, I'll start to modify the code......

  10. #10

    Default

    Hi again,

    I would to ask you another suggestion. The problem of use the main thread to dynamically load and unload the graphic resources is that during load/unload the thread is "locked" waiting for the operation complete but, if this is the same thread drawing the screen, this mena that also the game will be stopped in consequence of this wait. Thi is a big problem and is the one of reasons I created a secondary thread for work with resources.
    Do you know some good triks for avoid this delay working with resources?

    Thank you again for your support

  11. #11

    Default

    Looking for a solution in Internet I found the following explanation:

    http://songho.ca/opengl/gl_pbo.html

    than using PBO is possible to load resources from a secondary thread and have them quicly available for the main thread.
    ClanLib does support this feature?

  12. #12
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    ClanLib 1.0 does not support this feature.

    However, in most cases its not the actual upload to the GPU that consumes most of the time: it's the loading and decompression of the image.

    You can therefore still load the image into a CL_PixelBuffer in a second thread, and then when it finished this task create the CL_Surface from the pixel buffer in the main thread.

  13. #13

    Default

    Thank you for your suggestion. This will be a very good starting point for find a solution to my problem.

    Why you specified regarding version 1.0? This mean new version 2.1.1 support this feature?

    Thank you again for your support

  14. #14
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    Only ClanLib 2.2 (SVN) supports pixel buffer objects - See http://www.rtsoft.com/forums/showthread.php?t=3244

  15. #15

    Default

    Hi,

    This could be a good news.
    What do you think (approximately) this new version will be released as stable?

    Thank you

  16. #16
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    It depends when http://clanlib.org/wiki/TODO have been completed

    Maybe at the end of the year, depending on how many patches we receive

  17. #17

    Default

    Unfortunately the end of the year is too late for my timeline.

    Than, currently, the only possible solution based to ClanLib 1.0 is to follow the suggestion of Magnus to load the image into CL_PixelBuffer from a secondary thread and use this object to create "quickly" a CL_Surface in the main thread.

    Based to your experience what is the difference, in performance time, from this solution compared to the pixel buffer objects way?

    Thank you and I'm sorry for all my questions

  18. #18
    ClanLib Developer
    Join Date
    May 2007
    Posts
    1,824

    Default

    They can be tricky to get the speed increase.

    Pixel Buffer Objects need to be double buffered to prevent the GPU waiting for a texture upload to complete before drawing the texture.


    i.e.
    Code:
    CL_PixelBuffer PB_A(gc, ....)
    CL_PixelBuffer PB_B(gc, ....)
    CL_Texture Tex_A(gc, ...)
    CL_Texture Tex_B(gc, ...)
    
    while(main_loop)
    {
        Tex_x.upload_data( PB_x, ...)
        Tex_y.draw(...)
        (swap, x and y pointers)
    }

  19. #19
    ClanLib Developer
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    554

    Default

    The actual upload takes virtually no time compared to the disk access and decompression part.

    I do not have any actual numbers, but as an illustration the software render target in 2.1 is able to render at about 60 frames per second on my computer at 2560x1600. This includes rendering the Pacman example in system memory and then copying the result to the video card every frame.

    In other words, even if your surface had the size of 2560x1600x32bpp it should still be able to maintain at least 60 frames per second while uploading one such image every frame.

    The PBO approach can still add additional performance. But that is mostly because that when the upload is done in the main thread, OpenGL blocks until the upload is complete. A worker thread using two PBO objects should be able to keep the pipelines going, but the benefits are most significant for continuous streaming data and not one time uploads.

    Personally I would not attempt to do the PBO swapping technique unless I had code already showing me the other method does not work fast enough. This is because the PBO approach requires far more work and is more fragile since the perfect sizes and amounts of PBO objects relate greatly to the speed of your GPU and system bus. Why write fragile code if the simpler approach works?

  20. #20

    Default

    Hi Magnus,

    than, from waht I can understand, you suggest the approact CL_PixelBuffer in secondary thread to CL_Surface in main thread can be a good solution for loading resource in background.

    About using this way I have an additional question. Currently I'm using the CL_ResourceManager for load and create CL_Surface and CL_Sprite objects from an xml file. Moving to the above solution loading CL_PixelBuffer it will be possible to use the same CL_ResourceManager "engine" or I'll have to write my own xml tags parser and load "manually" every images into a CL_PixelBuffer object?

    Thank you for your help as usual
    Last edited by falsinfab; 06-07-2010 at 02:57 PM.

Similar Threads

  1. Black screen in game
    By Boofo in forum Dungeon Scroll for PC and iPhone
    Replies: 3
    Last Post: 02-02-2013, 10:35 AM
  2. Unloading and Re-loading CL_ResourceManager
    By catch22 in forum Official ClanLib SDK Forums
    Replies: 10
    Last Post: 07-23-2009, 07:08 AM
  3. How can you draw a sprite or a surface onto another surface?
    By alexv1 in forum Official ClanLib SDK Forums
    Replies: 1
    Last Post: 02-26-2009, 03:36 PM
  4. draw surface onto another surface before drawing portion to the screen
    By alexv1 in forum Official ClanLib SDK Forums
    Replies: 2
    Last Post: 02-25-2009, 12:19 PM
  5. Black screen - no h/w acceleration
    By stodge in forum Official ClanLib SDK Forums
    Replies: 1
    Last Post: 12-11-2008, 04:34 PM

Bookmarks

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
  •