Practical engine limitations

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
c3h8
Prole
Posts: 3
Joined: Wed Nov 10, 2021 2:09 am

Practical engine limitations

Post 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!
User avatar
UnixRoot
Citizen
Posts: 80
Joined: Mon Nov 08, 2021 8:10 am

Re: Practical engine limitations

Post 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.
User avatar
knorke
Party member
Posts: 237
Joined: Wed Jul 14, 2010 7:06 pm
Contact:

Re: Practical engine limitations

Post 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.
User avatar
BrotSagtMist
Party member
Posts: 604
Joined: Fri Aug 06, 2021 10:30 pm

Re: Practical engine limitations

Post 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.
obey
User avatar
zorg
Party member
Posts: 3435
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Practical engine limitations

Post 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)
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
User avatar
pgimeno
Party member
Posts: 3541
Joined: Sun Oct 18, 2015 2:58 pm

Re: Practical engine limitations

Post 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.
User avatar
Xii
Party member
Posts: 137
Joined: Thu Aug 13, 2020 9:09 pm
Contact:

Re: Practical engine limitations

Post 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?
grump
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: Practical engine limitations

Post 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
User avatar
Xii
Party member
Posts: 137
Joined: Thu Aug 13, 2020 9:09 pm
Contact:

Re: Practical engine limitations

Post 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?
grump
Party member
Posts: 947
Joined: Sat Jul 22, 2017 7:43 pm

Re: Practical engine limitations

Post 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.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 14 guests