Managing memory for a ton of pictures

[Andlac028]

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.

So maybe try this: make resources in more resolutions and you will choose one based on resolution of window (so you don’t have unnecesarry big resources that you will scale down). And if someone has big resolution, you can except to also have more high-spec computer and more memory

[darkfrei]

Load the image.
If ok, then load another one.
If ok, load another two.
If ok, load another four.
(Double amount of loaded images and write the amount to the file)
...
If not ok, restart the game and use last saved amount of loaded images.
Now the system is loaded more than 50%.

[zorg]

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.

You use external tools for that i believe, there's no built-in way to do it... i assumed your backgrounds weren't procedurally generated so i didn't think this would be an issue.

[ivan]

No, 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?

It does not matter as long as the user does not notice the loading.
You can even do it by blocking the main thread as long as there is nothing moving on the screen.

[RNavega]

Do you have a screenshot of a mockup of the game? Is there any chance to optimize textures by channel packing?

When games need a lot of unique texture content, they usually stream it:
https://www.gamedev.net/forums/topic/69 ... streaming/

[BrotSagtMist]

I am already preloading, i already have zero loading times, i got this part covered.
The problem purely lies in that i do not know HOW MUCH i can preload.

Mosts games out there lists a ram requirement, i do not want this. I want the game to match the hardware and scale as needed.
It should run on a 128mb potato. But at the same time uses a 128gb monster to its fullest.
And i do not see a way to distinguish if the game runs on a potato or a monster.
Without knowing how much ram there is to fill i can not decide how much i will fill with preloads.

It is really depressing that this testing till it fails, as darkfrei just wrote, is the only solution we can come up with.

[RNavega]

But at the same time uses a 128gb monster to its fullest.

Let's think about it: the user has a monitor, and that monitor has a fixed pixel density. You don't need to load more texture content than what can be displayed 1:1 on that monitor, plus some extra for buffering (pre-loading textures that the user is likely to see in the near future, so the game doesn't stutter).

So whatever is the zoom level on your game screen, you know what textures you need to load and at what resolution. You don't need to load everything.
Even if you can zoom out to display the entire game level, that level is not being shown 1:1 on screen, it's way minified. So the texture data that you read from disk can be downsized and only then loaded into VRAM.

In conclusion, in terms of memory budget, you probably only need the current user screen size, plus the surrounding 8 neighbor screens for buffering -- or as you said in a game of high speed, based on the player velocity and direction, pre-loading two screen steps in that direction in a background thread.

[darkfrei]

Is it possible to use the pcall to load images safe?

[RNavega]

Is it possible to use the pcall to load images safe?

I just checked the source code, whenever there's an exception during the loading and creation of a new Image object, a Lua error is emitted.
Using pcall you can catch those, and if you don't, the default Löve error handler will do that for you.

Edit: clarified text...

[ivan]

I am already preloading, i already have zero loading times, i got this part covered.
The problem purely lies in that i do not know HOW MUCH i can preload.

You should load as little as possible in order to keep the memory consumption low.
Also, do not load pictures that are larger than the user's desktop dimensions.
It is usually wasteful to scale down pictures in order to fit them on the screen.