The main logic also contains the rendering part of the program. But this rendering part needs to be done in the same thread that all OpenGL operations (like textures loading).
EDIT (for your second comment) : The rendering part and the “logic” part may interfere, causing bad bugs. This can be solved by heavily complex tools that would bring more complexity than performance gains to the engine. Besides, the rendering part would still be stopped, causing the freeze. And you misunderstood something, the force and the logic are not paused, the “lost” time is counted and the force/logic will be applied correctly.
Can’t you just load textures into memory in the separate thread not as a part of OpenGL, but in the way it accepts them? And never call OpenGL to do loading, only using what’s already there and unloading.
Yes, I understand that, but what if instead of making OpenGL do the loading into RAM which causes freeze since OpenGl loop is getting stuck on that almost all of the time, you prepare it in the separate thread, and when it returns back to you that loading is done, you call OpenGL for the update, it checks that texture is already there, and uploads them to GPU memory. Or is the bottleneck there? Because it really should not be, both RAM and VRAM are really fast.
First of all, even halving the time would be great. But second - no way, HDD’s are way, way slower, even SSD’s aren’t good enough, or RAM would just have no purpose - why not load everything from HDD then if it takes the same time? And third (second.b I guess), it’s compressed, which means it would have to use some processing power to convert it into bitmap transferring from HDD to RAM.
I’d even go as far as to say that in the current version you are not only not using RAM to your advantage, but in fact using it to slow the whole thing down! Not by much, but still. Because in this scheme it’s merely an unnecessary middle step, since VRAM is mirroring it completely - you keep assets that are offscreen in it anyway, even though just RAM would be enough for pixel perfect collisions. And any time you need a new asset, OpenGL calls RAM, and RAM calls HDD which needs to spin up and find the right place first to do anything, it’s not even about the speed at that point, it’s the lag of hard drive, that’s why even 8MB raw textures freeze it.
As I’ve told - when “create object” event occurs, main loop checks if textures are in the ram, if they are, it proceeds as usual.
If they are not, it sends a call to uploading library, telling it what to load, and probably the object to create so save on checks. Because after that “create object” event should be dismissed completely from the main loop. Instead, whenever is ready, uploading library should call back to the main loop and make it create that object that was dismissed, so the game would work as normal without that object for the time needed for the hard drive to spin up, decompression of the files be done, and bitmap data stored in ram.
It would act like a buffer between the fastest part of your computer which is GPU and slowest one that is HDD, which is the point of RAM.
And yeah, clearing VRAM from unused textures is always a good idea, if it’s all possible within OpenGL.
I could even suggest uploading textures to the RAM based on proximity to the camera - closest ones first till the limit is reached and rest is kept on hold within the uploading library which would not cause the game to freeze forever since it’s separated. But it maybe too much to ask. Would make making huge games easy and possible though!
I think many users won’t be happy of that behavior. Think of an event that creates an explosion sprite and then destroys the missile. If you add an extra delay to do the object creation and the next actions (destroy the missile), the missile can cause more damages to other objects meanwhile. You see, this choice is not as easy as you think and is counter-intuitive for many users.
You count “create object” event as complete, so missile will disappear, but explosion will lag for the time that would freeze the whole game in the current state of the engine. Which is worse, freezing the game, or making a small visual glitch? And you just put a note somewhere in the wiki that it takes time for assets to load (which is 100% honest truth) so if you want it to be frame perfect, you have to keep that particular asset in ram, which you’d have to do in any engine, including high-profile ones like unreal, with its infamous texture pop-in.
There is no dilemma, there is just right way and wrong one.
Then, your contribution is welcome. Don’t have time (nor 4ian the main dev of GDevelop) to GDevelop a feature not useful for many people (as many would accept to just keep the asset in memory).
By the way, I’ve just checked, there’re no disk opérations when loading an asset as the data file is fully loaded in memory. There’s only the picture uncompression.
Huh, that changes everything actually… Because I’ve tested it with 0 compression pngs to make sure it’s not some inefficient decompression algorithm, so in theory it should be as easy as to read it from one sector of ram and write in another. Yet it didn’t help, it kind of made it worse a bit actually. Sooo what’s the bottleneck then?
Keeping resources twice in the ram is a silly idea btw when you only have 4GB to work with.
There are actually multiple results in google concerning OpenGL texture loading being so slow. I’m not a coder so I can’t evaluate them, but this one in particular promises streaming textures and OpenGL multithreading opengl.org/wiki/OpenGL_and_multithreading
Ough, my brain hurts >.< I understand logic, not syntax…
Wouldn’t OpenGL multithreading be what it needs? It would still be able to render frames while assets will be loading in VRAM in another thread? Since VRAM is two-directional by design - it allows reading and writing at the same time D=
Doesn’t it bother you that something as simple and small as 8MB of textures completely brake your engine, making it unusable?
No, it doesn’t. Just keep the texture loaded in memory.
Not exactly, the rendering will still be blocked during the loading. The only solution is to produce smaller versions of the texture in the RAM and then load them first. Then, when it has some times, load the normal ones. However, it would still require extra processing when loading the texture into the RAM. Besides, the library we use doesn’t support this feature (texture streaming is not supported by SFML).
But that’s like programming 101 - never keep all resources loaded at all times. Especially not twice. Only what you need at the time. Because you can consider your hard drive to be an “endless” storage space in comparison. What can you even do with like 2GB left for uncompressed textures that need to be loaded all at once? (~2GB is for gam.egd, sounds playing, OpenGL, engine, script and whatever else) Pixelart and that’s it. I can do pixelart, but there is just too much of it already.
RAM is not for storing, it’s for the quick access. And even that is not working because OpenGL is used in some slow and inefficient way - there is a huge bottleneck between RAM and VRAM on the software level - it’s present on all systems we tested it on.
I figured that, but you also use RAM to store compressed textures, which is really bizarre to me, but should have solved singlethreaded nature of OpenGL implementation in a workaround fasion, yet it doesn’t. You should at least stop doing that since it’s not helping anybody, and raise the space for raw textures.