A Comprehensive List of BYOND's Known Limitations

ID:1516478
 
Mar 12 2014, 11:24 am (Edited by moderator on Jan 30 2020, 2:06 pm)
Have you ever been worried about BYOND's limits or need an idea of what you can push BYOND to do before executing that neat idea? Worry no more! This is a reference list of BYOND's currently known limitations (Thank Ter13 for the info!) as of BYOND 504.1234 (Stable) for developers. As far as I am aware, these are not listed in the DM reference.

[Last edit: by Lummox JR as of BYOND 513.1510. My edits in brackets.]

Caches support 4-byte indexes.

Procs are limited to 64k instructions each at runtime.

For icons, the total number of frames available to Dream Seeker is above 64k. [The value type DSIconId, representing an individual frame, is a 4-byte index.]

While maps do not have a set limitation, there is a crash with sizes around 1000x1000x200. [Maps actually get squirrely well before this point. The webclient strictly supports only map sizes up to 16M turfs, or 3 bytes.]

Pop limit (unique tiles in DMB) is 4 bytes.

[Individual map files have a limit of only 64K symbols. If a map with lots of Z levels nears this limit, split the file.]

[There is a unique map cell limit of 2 bytes, which has been expanded to 4 bytes in 508.1292. A unique map cell is each unique combination of turf prototype, turf appearance, and area ID that exists on the map at runtime. Typically this number is low, but some games with huge maps have been known to stress it, especially if they use area-based lighting systems.]

The number of Interface Elements are limited to the same amount as of Windows.

View size is limited to a total area of 5,000 tiles.

The highest number supported is a signed 32-bit floating point number. Integers beyond the 24 bit range are represented as single-precision floating points, and thus will lose accuracy beyond the range of +/- 16777216. (Thanks for the correction, Ter13)

Numbers in BYOND also allow binary access to the lower 16 bits only. [This was changed in BYOND 512 to allow access to 24 bits.]

Strings in BYOND are zero-terminated, and can support characters 1 through 255. [As of BYOND 513, strings use UTF-8 formatting for Unicode.]

The following are limited to 16,777,216 instances at runtime:
  • /obj
  • /mob
  • /area
  • /image
  • Appearances (this is something internal with BYOND)
  • Unique overlay and underlay lists [This is an internal type called an ID array.]
  • User defined datums
  • [Consider turfs unofficially on this list.]

If there are any limitations not listed or have been removed, please shoot me a PM or a reply and I'll add it as soon as I can! Also with each new version, if a limit is removed or added I'll post it here. Please note that the list is only for stable versions; if a limit is to be removed in a Beta version I will have a note beside a limit that reads "To be removed in version xxx.xxxx" if I am aware of it.

(I'd like to make a sticky request for this, if possible)
Mar 12 2014, 4:56 pm
Good job. Also include big numbers as a limitation.
Mar 12 2014, 5:07 pm
Can this be sticky please?
Mar 12 2014, 6:13 pm (Edited on Mar 12 2014, 6:24 pm)
In response to Ssj4justdale
Ssj4justdale wrote:
Good job. Also include big numbers as a limitation.

Big numbers? How big? I'm guessing as big as a 32 bit integer?
Mar 12 2014, 7:51 pm
http://technet.microsoft.com/en-us/library/ms187745.aspx

BYOND can handle int (integers) but not bigint (Which is useful to the DBZ fanbase)

Or people who create mathematical stuff with those intense numbers.
Mar 12 2014, 8:02 pm
In response to Ssj4justdale
That would make sense as I assumed long ago that BYOND was coded with 32-bit hardware in mind (due to its age) and not 64-bit hardware.

Will add it!
Mar 12 2014, 8:07 pm
Love it :)
Mar 13 2014, 4:38 am
I added some more accurate information to the discussion of number types, as well as included information regarding binary access to number types.

I also put in some information regarding the characters that strings support.
Mar 13 2014, 4:41 am
When it reads "64k instructions", what constitutes an instruction? It's kinda obscure. Is each line an instruction? Each operator? Is a call to another Proc within a Proc an instruction?
Mar 13 2014, 5:00 am
Ah, I can shed some light on that.
DM compiles information into bytecode. Not every line is equal to another in the number of instructions:

For instance, this line:

var/v = (x + 1) * 2


Compiles down roughly to something like this:

access x;
add 1 (pop, push);
mul 2 (pop, push);
define v;
assign v (pop);


That's roughly 5 instructions (ignore the pop/push, those are implicit instructions the VM does to manage the stack) for that one little line of code. Of course, the above isn't EXACTLY BYOND's bytecode, but it's pretty close.
Mar 13 2014, 5:39 am
In response to Wontoon
BYOND only maintains integer precision up to 24 bits, so +/- 16777216, after that it's represented as a single precision float.
Mar 13 2014, 6:02 am
Was my correction to wontoon's post not clear enough?
Mar 13 2014, 7:51 am
Well, 256^3 is definitely an odd way to express the 24 bit integer precision.
Jul 6 2015, 10:01 am
I made some edits to update the info. The map cell limit was specifically not listed, although in 508.1292 it's effectively removed.
Oct 25 2015, 9:09 am
I'm curious about current string limitations. Which characters is BYOND incapable of reading?

i.e., NUL (0x00) characters or other control characters
Oct 25 2015, 4:43 pm
In response to NullQuery
BYOND null-terminates all strings, so a null character can't be part of a string. The character 255 is used as a control character for a number of purposes.

I kinda think it'd be nice to support UTF-8 encoding, but I suspect that'd turn out to be super difficult. A lot of basic string tasks would suddenly be a great deal harder, like getting the length or copying a specific range, unless there were an internal raw format that used twice as much memory.
Oct 25 2015, 5:12 pm
twice as much memory.

Memory isn't really our bottleneck at all. CPU is our main issue.
Oct 25 2015, 10:21 pm
In response to Ter13
True, but I know some games do push the envelope when it comes to memory. It's not 100% out of consideration.

One of the changes that's been proposed regarding var access to increase speed might actually improve memory too, though: specifically, changing each datum's vars linked list into a sorted array. Ideally I'd like to do something similar with parent var lookups too; they're not linked lists but they're inefficient.