Page 1 of 2
Practical engine limitations
Posted: Sat Nov 13, 2021 5:55 pm
by c3h8
Hi all! So the title kind of describes what I'm looking for -- I'm wondering if there are any practical limits to things like memory, number of sprites onscreen, music channels being played, etc. that are inherent to the engine? That is, I understand if a system has 8GB of RAM, my limit is something less than that by default, but I'm wondering if the engine itself has anything built-in that limits games, or whether anyone has run into system limits that effectively have become limits for anyone using the engine? For example, a Game Boy Color game can only have something like 8 or 16 moving sprite entities on screen at any given time, or there will be flickering. Thanks in advance!
Re: Practical engine limitations
Posted: Sat Nov 13, 2021 7:08 pm
by UnixRoot
I don't think there is a real limit. With sprite batches, texture atlases and clever coding, you can draw thousands of sprites in one drawcall.
But you can limit yourself, depending on the style you're aiming for. Restrictions are fun. I'm building a pseudo 3D racing game right now and make up my own restrictions. Only integer vertex positions, 256 color palette, 16 colors per sprite, etc.
Re: Practical engine limitations
Posted: Sat Nov 13, 2021 8:05 pm
by knorke
The physics engine (Box2D) has some limitations.
For example polygons for collisions have to be convex. Also
http://www.iforce2d.net/b2dtut/gotchas
But it is not nessecary to use that part of Love, you can use other physics libaries or make your own physics.
Re: Practical engine limitations
Posted: Sat Nov 13, 2021 8:37 pm
by BrotSagtMist
A couple of times ive hit the ram limit of my graphic card while drawing a ton of pixels in one frame. Oddly this caused no high cpu usage or frame drop. Simply said the card run out of ram and closed itself.
Further rendering several mb of text at once may cause your graphic card to completely lock itself up requiring a reboot.
But no there is no Löve specific limit that stops me from shooting myself in the foot here.
Re: Practical engine limitations
Posted: Sat Nov 13, 2021 9:46 pm
by zorg
Audio limits are related to OpenALSoft's limits, (64 active sources iirc - can be circumvented for some CPU-side software mixing with Queueable sources, if you need)
graphical limits are mostly tied to your GPU's VRAM and performance (including max texture size, and shader version support, etc.),
other "resource" limits tied to your main RAM (there is a 2GB limit for lua-owned memory, but that's mostly tables and strings; all löve objects are not part of that - also i'm assuming you're running löve on a 64bit system),
and all other performance limits tied to your CPU (one core, though you can do actual multi-threading as well, but it's not the simplest)
Re: Practical engine limitations
Posted: Sun Nov 14, 2021 12:12 am
by pgimeno
zorg wrote: ↑Sat Nov 13, 2021 9:46 pm(there is a 2GB limit for lua-owned memory, but that's mostly tables and strings; all löve objects are not part of that - also i'm assuming you're running löve on a 64bit system)
The limit is actually 1 GB on 64-bit Linux due to a nasty kernel bug. That limit will disappear in the next Löve version that uses LuaJIT-2.1; I'm not sure if 11.4 will use it but 12.0 for sure.
Some OpenGL limits can be queried from Löve itself, via
love.graphics.getSystemLimits (see also
love.graphics#System_Information for other info functions).
I believe that noise functions use single-precision floats internally, so you may run out of quality noise quickly if you use a lot.
Re: Practical engine limitations
Posted: Sun Nov 14, 2021 5:04 am
by Xii
zorg wrote: ↑Sat Nov 13, 2021 9:46 pm
there is a 2GB limit for lua-owned memory, but that's mostly tables and strings; all löve objects are not part of that
Does that include cdata?
Re: Practical engine limitations
Posted: Sun Nov 14, 2021 5:44 am
by grump
Xii wrote: ↑Sun Nov 14, 2021 5:04 am
zorg wrote: ↑Sat Nov 13, 2021 9:46 pm
there is a 2GB limit for lua-owned memory, but that's mostly tables and strings; all löve objects are not part of that
Does that include cdata?
Limited, if it's allocated through ffi.new or ctype constructors. There's no such limit on manually allocated memory, e.g. malloc or love.data.newByteData. The latter has the advantage that it can be shared among threads without relying on ugly tricks.
Edit to clarify:
Code: Select all
local mem = love.data.newByteData(2 ^ 31) -- 2 GB
local ptr = ffi.cast('whatever*', mem:getFFIPointer()) -- will become invalid as soon as mem is collected
Re: Practical engine limitations
Posted: Mon Nov 15, 2021 4:54 pm
by Xii
grump wrote: ↑Sun Nov 14, 2021 5:44 am
Code: Select all
local mem = love.data.newByteData(2 ^ 31) -- 2 GB
local ptr = ffi.cast('whatever*', mem:getFFIPointer()) -- will become invalid as soon as mem is collected
Can ptr be used like a table, same as with ffi.new? Also you used a 2GB allocation as an example, but this method can do more, right?
Re: Practical engine limitations
Posted: Mon Nov 15, 2021 6:55 pm
by grump
Xii wrote: ↑Mon Nov 15, 2021 4:54 pm
Can ptr be used like a table, same as with ffi.new? Also you used a 2GB allocation as an example, but this method can do more, right?
I think on most current 64-bit systems you can theoretically go up to 2^48.
Access is the same. ffi.sizeof(ptr) won't return the actual memory size, and you have to make sure to keep a reference to mem somewhere so it doesn't get collected. That's all the important differences I can think of right now.