love.graphics.newImage hanging

[slime]

On my system (Mac OS X, integrated Intel HD 3000) it takes about 0.2 seconds to load. Note that the os.clock function gets the CPU time rather than real time (they aren't the same) – it might be good to use [wiki]love.timer.getTime[/wiki] for that sort of timing information, instead.

It's weird that it's taking 5 seconds for you with those specs, but on the other hand 280 unique images at once is quite a lot to load at once. It's usually better to combine images into a larger texture atlas, when possible. Doing so will also let you improve performance a lot if you draw more than one of those images at the same time, by allowing SpriteBatches and Quads to be used.

Does it still take 5 seconds for you in LÖVE 0.9.2?

[BOT-Brad]

Oh well I feel like a fool now. I just noticed that for some reason my default project folder has gone from my C: drive back to my B: drive, which is a network drive on our intranet system, so loading all those images obviously has some overhead with accessing the data over the network.

I just copied everything over to my C: drive and yep, the whole thing loads in around 0.1 seconds now.



Just for clarity, unfortunately squashing all the images into a texture atlas is not really an option with the way I am using the images right now. Is it better to just love.graphics.newImage() them whenever I need to actually 'display' them (and not store them in memory for long), or should I cache them and load from the cache if not already loaded. Is storing many images in RAM (and VRAM possibly?) a good idea?

[Jasoco]

Heh. I was going to say I also got it loading in a fraction of a second. Glad you figured it out. It's always a really silly mistake that causes problems.

To answer the question about storing a lot of images in VRAM, I'd say it's fine. Images take up a lot less space in memory than they do on disk because they're converted to a specific format. Someone posted the specifics of it somewhere on the forum.