"Questions that don't deserve their own thread" thread

[Whatthefuck]

Let's try this. If you have a question, but don't think it deserves it's own thread, post it here and get help from fellow forum members.

I'll start. When using sprite batches, if I need to change all of it's sprites, which would be cheaper: clearing + readding or setting the sprite in the spritebatch? If the latter, how much cheaper is it?

[slime]

I'll start. When using sprite batches, if I need to change all of it's sprites, which would be cheaper: clearing + readding or setting the sprite in the spritebatch? If the latter, how much cheaper is it?

They'll both perform about the same in that case - be sure to use [wiki]SpriteBatch:bind[/wiki] before setting/adding the first sprite, and [wiki]SpriteBatch:unbind[/wiki] after setting/adding the last one, to get the best performance.

Something like this:

Code: Select all

function love.draw()
    spritebatch:clear()
    spritebatch:bind()

    for i,v in ipairs(sprites) do
        spritebatch:add(v.quad, v.x, v.y)
    end

    spritebatch:unbind()

    love.graphics.draw(spritebatch, 0, 0)
end

(SpriteBatch:bind/unbind will be made obsolete in the next LÖVE version, but only because SpriteBatches will essentially automatically do the same thing under the hood. Until then, use them!)

If you're going to be adding/changing the sprites every frame then you should also use the 'stream' SpriteBatch usage hint when creating the spritebatch (i.e. love.graphics.newSpriteBatch(image, maxsprites, "stream")). If you aren't modifying the spritebatch every frame, 'static' might be the best to use.

[Whatthefuck]

If you're going to be adding/changing the sprites every frame then you should also use the 'stream' SpriteBatch usage hint when creating the spritebatch (i.e. love.graphics.newSpriteBatch(image, maxsprites, "stream")). If you aren't modifying the spritebatch every frame, 'static' might be the best to use.

I'm using spritebatches for baking the lighting into canvases which I then draw over everything.
The problem is that if I need to update the lighting often (I have added a time of day system with day and night cycles), it creates a slight stutter, and considering that I have a i5 4670, I expect it to be even worse on lower end CPUs. I'm using a single sprite batch (which has a maximum of 256 sprites) which I clear + re-add everything to and then draw it to a canvas. The canvas is not a single one, but plenty of 16x16 canvases. (to avoid having to re-render unnecessary stuff)

Are there any better solutions to this?

The reason why I bake the lighting into canvases, is because when I upscale them to match the screen resolution, I get smooth lighting as a result of linear filtering kicking in.

Edit: just realized I had power options set to 'balanced' which increased CPU clocks gradually as CPU load increased. Setting it to high performance yields constant 60 fps with no fps drops. Ugh.

[Ranguna259]

I have a question:
Is there any way to make images smaller (memory wise) ?
I have loads of PNGs that I need to load but in the game they are going to be resized quite a lot (they'll be smaller) so I was thinking if there was a way to make resized images smaller in termes of memory.

Would canvas do the trick ?

[bartbes]

I have loads of PNGs that I need to load but in the game they are going to be resized quite a lot (they'll be smaller) so I was thinking if there was a way to make resized images smaller in termes of memory.

Actually make them smaller?

[Whatthefuck]

I have a question:
Is there any way to make images smaller (memory wise) ?
I have loads of PNGs that I need to load but in the game they are going to be resized quite a lot (they'll be smaller) so I was thinking if there was a way to make resized images smaller in termes of memory.

Would canvas do the trick ?

Search for 'optipng' on google. That thing removes unnecessary data, as told by my friend, and preserves the same quality.

Also, the threading system in love2d's wiki says that you can send flat tables to threads. What is a 'flat' table? Table with no indexes? Table with numeric indexes only?

[bartbes]

What is a 'flat' table? Table with no indexes? Table with numeric indexes only?

Tables that contain no other tables.

[Ranguna259]

Actually make them smaller?

Yeah, make the space they use in the memory smaller, I shrink them by scalling them down but that just changes it size while keeping it's space the same.
Imagine a hella huge image, arround 1MG that's 4096x4096, I load it by using love.graphics.newImage() and then scale it down by, say, 0.25 and it becomes 1024x1024, but in the RAM that image is still taking the same space as the 4096x4096 one, so I wanted a way to make the space that the 1024 image uses smaller in the memory. Is that even possible ?

Search for 'optipng' on google. That thing removes unnecessary data, as told by my friend, and preserves the same quality.

Also, the threading system in love2d's wiki says that you can send flat tables to threads. What is a 'flat' table? Table with no indexes? Table with numeric indexes only?

I'm not looking for an external program, I'm looking way to do this in LOVE (if possible)

Tables that contain no other tables.

Aren't flat tables, tables in strings, exemple:

Code: Select all

tbl = loadstring('return {1,2,3}')()

[Jasoco]

No, bartbes was actually saying to just make the image smaller. Is there a reason you'd want a 4096x4096 image if you're just going to shrink it? Just include a smaller 1024x1024 version and load that.

[slime]

I have a question:
Is there any way to make images smaller (memory wise) ?
I have loads of PNGs that I need to load but in the game they are going to be resized quite a lot (they'll be smaller) so I was thinking if there was a way to make resized images smaller in termes of memory.

Downscale the image files on your computer using an image editing tool (maybe combined with a script if you want to automate it). You could include all the images in the .love and only load the ones which have an appropriate size for the system the game is running on, if you want.

If you want to use LÖVE as your image processing tool, you could create a canvas at the final size you want, draw the image to the canvas, and use [wiki]Canvas:getImageData[/wiki] and [wiki]ImageData:encode[/wiki] to re-save the downscaled image to a new file.

For even more RAM/VRAM usage optimization, you could convert the textures to DXT1 or DXT5 (depending on if they're fully opaque or not). DXT-compressed textures stay compressed in RAM and in VRAM, unlike regular image formats. LÖVE can't save to DXT though, it can only load them.

Search for 'optipng' on google. That thing removes unnecessary data, as told by my friend, and preserves the same quality.

PNG/jpeg/etc. are always decompressed into raw pixel data when they're loaded into RAM, so that'll only help with filesizes rather than the amount of RAM/VRAM used.