LÖVE

I am currently working on something that has a ton of big pictures, about a hundred ~10mpx to be precise.
These are loaded when needed and may be used anytime in the game.

I dont think they all fit in ram at once so now i have to come up with a clever strategy to decide if and when i unload them.
Ideally they should stay in ram as long as possible so i dont waste resources on reloading them, but i also cant fill it up to the brim.
Raises a few problems:
How do i get the amount of ram Löve is using for these pictures?
How do i get how much ram the system has and is available?
Can this even be done in Löve?
And what steps should be done to free ram?
Setting a picture to nil or Object:release() doesnt seem to do anything unless a manual garbage collect is called, this however is cpu heavy and causes stuttering.

What approach would you do for such problem?

You can hide the loading time by showing any pop-up message.

First question is, if you really can’t reduce number of images or resolution. If not, you can use Object:release() to clean up images, that are no longer needed (if I remember correctly, collectgarbage(“count”) only return size of memory used by Lua, not Love data itself on C++ side). To get textures memory size, use love.graphics.getStats().

As for total system RAM, I think, it can be done with FFI or some other way, but that can have some limitations.

Also if you target mobile, take a look at lowmemory call back.

Also on what basics are the images required (is it something predictable, as per level or per scene images? Or can you say, which images are more likely needed in the future?)

No, you are probably going to run out of memory if you try to load hundreds of 10mpx pictures at the same time.
Using popup messages, splash or loading screens breaks up the gameplay which is not ideal.
It is not easy to structure your game in a way where the images are requested, loaded and unloaded seamlessly.
collectgarbage("collect") will sweep up and unload any unreferenced images.

https://love2d.org/wiki/GraphicsLimit can get max texturesize.

Like Andlac028 my approach would also be to think if resolution or number of images can be reduced.
Then it depends on the game:
How much delay is acceptable?
How often do you need to switch between images?
When switching images, do you already know beforehand what will be the next image?
(or maybe at least have a list of possible next images, instead of "all"?)

You got me all wrong here, loading is covered.
I simply dont load them all at once and a single picture seems to fit within a frame so it doesnt cause stuttering.

It is really just the unloading that troubles me.

Andlac028 wrote: ↑Thu Feb 02, 2023 8:30 pm use love.graphics.getStats().

Oh yea that i was looking for. I also forgot thinking about, vram. I suspect having an onboard card and it sharing with normal system ram means that this functions result should somewhat match the normal ram usage of all pictures.

As for total system RAM, I think, it can be done with FFI or some other way, but that can have some limitations.

For limited support one can always just read the system files. It just doesnt taste right to make a game that runs around reading system files let alone i have no idea how to do that on every system.

Also if you target mobile, take a look at lowmemory call back.

That callback actually puzzles me, someone ever used it?
I mean when is it triggered? When 20% is left? When 2 mb are left? This thing could report anything.
But yea, i would actually really need such callback, that is exactly what i am looking for.
Its just that its neither documented nor works on desktops so in this form its as useful as a rockpet.

Also on what basics are the images required (is it something predictable, as per level or per scene images? Or can you say, which images are more likely needed in the future?)

Its one huge ass background made by photo stitching and then split apart again. So i can simply load the players surrounding and ignore all others.
Thing is that the player may move really fast and if i simply unload these tiles when they are passed i will cause a constant reading stream when the player runs left and right in sonic style.

ivan wrote: ↑Thu Feb 02, 2023 8:50 pmNo, you are probably going to run out of memory if you try to load hundreds of 10mpx pictures at the same time.

Yes but when exactly?

So ive been testing love.graphics.getStats(), the vram usage reported there is half the size of the used system ram.
Eg if it takes 500mb vram Löve uses 1gb in the system monitor.
Does that mean all data exists twice?

lowmemory is called when OS decides, it is low on memory, before it kills the app, so it’s something like ladt chance for program to minimize memory before forcefully killing (also collectgarbage is called 2 times automatically).

As for images, try to give some examples, so we can see, if the resolution or size can be reduced (like if you have repeating textures, you can have more smaller textures and draw that multiple times to reduce memory usage.

Löve supports reading specific (gpu-side) compressed formats and keeping them like that in memory; you could decrease the image sizes with that, although there's discrepancy between what desktop and mobile gpus support.

Andlac028 wrote: ↑Fri Feb 03, 2023 5:10 pmAs for images, try to give some examples, so we can see, if the resolution or size can be reduced (like if you have repeating textures, you can have more smaller textures and draw that multiple times to reduce memory usage.

Again, i specifically want this thing to be as big and resource eating as possible.
The problem simply is that i do not know how big it can be as there simply is no "you have now filled the ram to 50%" warning.

zorg wrote: ↑Fri Feb 03, 2023 7:47 pm Löve supports reading specific (gpu-side) compressed formats and keeping them like that in memory; you could decrease the image sizes with that, although there's discrepancy between what desktop and mobile gpus support.

Looking at it: I dont see a way to generate them.