Is it a good idea to load all resources at the beginning of my game ?

[inJuly]

I am working on a small puzzler to learn how this game framework works.
Currently, I am loading all the audio, images and fonts at the beginning of the game (c

Code: Select all

local Resources = require('game/Resources')

function love.load(arg)
  Resources.load() --loads all audio/images/fonts that are used in the game at any place
  -- other code
end

Currently I am using `collectgarbage('count')` to see how much RAM my game uses and apparently its 450.
I don't know if this number is too big or small since I am not that great with computer hardware.

Hence my question, was my decision of loading everything at once a good idea ?

[inJuly]

okay so I was wrong about the collectgarbage thing, it starts at 450 and keeps increasing from there

[zorg]

Hi and welcome to the forums!

Like most things, it depends; for a small game with not too many assets, i'd wager that it's fine just loading in everything at once at the start. For larger games, it probably would be smarter to load things in smaller batches, like per-level/per-world/whatever.

A bit more intermediate solution would be to use a coroutine to signal progress after each separate asset loaded, at least that way, one could include some graphical feedback that "hey! the game's not frozen, it's indeed loading stuff! ", although still with the occasional hiccup while the files are actually being loaded.

Even more advanced, since loading data from harddisks or even an ssd is relatively slow compared to memory access, and the fact that the main thread is blocked while doing that, for really large games/assets that take even longer, people did make solutions to load in files on a separate thread so that the main one wouldn't be blocked at all. (This may also fail certifications on some consoles, but that's usually not relevant for a Löve game...) And this kind of solution does exist for löve as well, but usually, most people don't have games where this would be necessary.

As for collectgarbage, that only shows an approximation of how much memory the lua side of things take up; Löve doesn't really have a function to tell you the C++ side of things, those being all *Data and Object types. Do take note that most images that aren't specific types that can remain compressed in your video card will be turned into more raw representations (rgba quadruplets; including jpg and png), the same with audio (except wav, that's already raw-ish data in most cases), that will take up more memory, so just calculating based on the file sizes won't be realistic either.

Then again, i wouldn't worry too much; do take care to heed the warnings on the wiki though, about not using any constructor (love.whatever.newWhatever) in love.update or love.draw each frame, that can tank both performance, but more importantly, waste memory.

[inJuly]

Hi and welcome to the forums!

Like most things, it depends; for a small game with not too many assets, i'd wager that it's fine just loading in everything at once at the start. For larger games, it probably would be smarter to load things in smaller batches, like per-level/per-world/whatever.

A bit more intermediate solution would be to use a coroutine to signal progress after each separate asset loaded, at least that way, one could include some graphical feedback that "hey! the game's not frozen, it's indeed loading stuff! ", although still with the occasional hiccup while the files are actually being loaded.

Even more advanced, since loading data from harddisks or even an ssd is relatively slow compared to memory access, and the fact that the main thread is blocked while doing that, for really large games/assets that take even longer, people did make solutions to load in files on a separate thread so that the main one wouldn't be blocked at all. (This may also fail certifications on some consoles, but that's usually not relevant for a Löve game...) And this kind of solution does exist for löve as well, but usually, most people don't have games where this would be necessary.

As for collectgarbage, that only shows an approximation of how much memory the lua side of things take up; Löve doesn't really have a function to tell you the C++ side of things, those being all *Data and Object types. Do take note that most images that aren't specific types that can remain compressed in your video card will be turned into more raw representations (rgba quadruplets; including jpg and png), the same with audio (except wav, that's already raw-ish data in most cases), that will take up more memory, so just calculating based on the file sizes won't be realistic either.

Then again, i wouldn't worry too much; do take care to heed the warnings on the wiki though, about not using any constructor (love.whatever.newWhatever) in love.update or love.draw each frame, that can tank both performance, but more importantly, waste memory.

That was very helpful ! Thanks a bunch
How do I know when my assets are too big to be loaded all at once ? what size does that usually happen at ? around 200+ Mbs or something ?

[zorg]

I'd say it's subjective; just try it out yourself; load in all assets at the press of a key at the start of the game (to not include löve's own initialization into it), and if the time between you pressing the key and everything getting loaded in is too long in your opinion, then start thinking about implementing either the visual feedback with a coroutine, which is simpler, or threaded loader, which is harder.

[inJuly]

I'd say it's subjective; just try it out yourself; load in all assets at the press of a key at the start of the game (to not include löve's own initialization into it), and if the time between you pressing the key and everything getting loaded in is too long in your opinion, then start thinking about implementing either the visual feedback with a coroutine, which is simpler, or threaded loader, which is harder.

Gotcha, thanks

[Tabaqui]

I don't know if it's a good or a bad practice (comments and suggestions are welcome!), but if i'm programming a small game with a limited amount of resources (5/10/20 images, 2/3 sound/music effects) i'd try to load them at the beginning (love.load).

If the game is bigger (a platform with a lot of different flavoured levels, an RPG, etc...) and it's very likely that in a play session the player will see only a small part of the sprites i'd use a different strategy with a sort of cache:

Code: Select all

ResourceManager = {}
ResourceManager.images = {}

function ResourceManager:getImage(name)
  if not self.images[name] then
    self.images[name] = love.graphics.newImage(name)
  end
  return self.images[name]
end

[pgimeno]

Keep in mind, a threaded loader can NOT use love.graphics at all, in particular love.graphics.newImage for example. These need to be loaded from the main thread.

[ivan]

I load the most "common" graphics at launch, then specific graphics per level.
Sound effects usually don't take much memory so they can be loaded all at once.

Tabaqui's method is on the right path, but it will never unload those images.
If you want to support dynamic loading/unloading then you need reference counting:

Code: Select all

local assets = {}
local images = {}
local refs = {}
function assets.request(n)
  refs[n] = (refs[n] or 0) + 1
  if refs[n] == 1 then
    images[n] = love.graphics.newImage(n)
  end
  return images[n]
end
function assets.unrequest(n)
  refs[n] = refs[n] - 1
  assert(refs[n] >= 0, "already released")
  if refs[n] == 0 then
    images[n] = nil
  end
end
return assets

This technique is very useful when your assets are loaded per level because when switching levels you can:
1. request all the images for the next level
2. unreference all the images from the previous level
3. call "collectgarbage" to cleanup
This way the assets that are shared between levels remain loaded.

[zorg]

Also, pgimeno's right in that you can't directly load in graphics onto the GPU, meaning any Texture types (Images and Canvases); a threaded loader would need to first load the asset into an ImageData (or FileData, but i'd say go for the former), and then on the main thread, do like a post-loading step of making Images out of the ImageData objects.

This will still be faster since you'll be moving data from main RAM to VRAM instead of HDD/SSD (to RAM, then RAM) to VRAM.

Kikito made a library for this, but that was for version 0.8.x, and to my knowledge was only updated for 0.9.x: https://github.com/kikito/love-loader