Asynchronous fpg load method.

[Benjamin Hoffmann]

The asynchronous fpg load method doesn't works. The graphics are not displayed.

import "mod_say"
import "mod_proc"
import "mod_grproc"
import "mod_map"
import "mod_text"
import "mod_key"
import "mod_video"
import "mod_screen"
import "mod_draw"

process int main();
private
    int idFpg;
end
begin
    set_mode(800, 600);
    set_fps(60, 0);

    fpg_load("my_file.fpg", &idFpg);    
    while(idFpg == -2)
        say("Loading my_file.fpg file..");      
        frame;
    end
    if(idFpg==-1)
        say("Something went wrong!!");
        exit();
    end

    mouse.file = idFpg;
    mouse.graph = 1; // No graph displayed :'(

loop
    if(key(_esc))
        break;
    end
    frame;
    end
end

[Joseba Echevarria García]

I can reproduce the bug with the file examples/fpg/archive.fpg from the git repo.

I will have a look at it.

Thanks for reporting!

[Joseba Echevarria García]

I think this bug appears because SDL can not do any rendering operations from outside the main thread. That, apparently, includes creating textures.

So, textures created in the background thread are, basically, invalid. That is why they're not being drawn onscreen.

I need to think of a way of creating the textures from the main thread without breaking the current code structure.

See https://wiki.libsdl.org/CategoryRender and http://forums.libsdl.org/viewtopic.php?p=43305&sid=5ac640859c735d90af672204f55b45d2

[Joseba Echevarria García]

This has was fixed in a previous commit and should be working now. I've checked bot png_load and fpg_load, but it should be working for the rest of bitmap loading routines, too.

When loading GRAPHs, PixTudio now loads them into memory and then marks each GRAPH (even those contained within FPGs or loaded from FNT files) as requiring a texture update. Such update is performed on the main thread right before being drawn into screen, hence avoiding the limitation of only being able to update textures from the main thread.