-
Notifications
You must be signed in to change notification settings - Fork 102
Differences Between OpenDream and BYOND
This is a work-in-progress guide describing the major differences between OpenDream and BYOND. Things are added/removed as development progresses, and this list is non-exhaustive.
Various things cannot or will not be reconciled between OpenDream and BYOND.
Note that all unsupported procs should throw a compile-time warning if you try to use them in your DM code.
Since OpenDream does not have an equivalent to the BYOND hub, no procs or vars related to the hub will be functional, such as GetMedal().
Since we are not affiliated with BYOND, all users are treated as if they are not members. Procs like IsByondMember() will always return false.
All DLLs made for BYOND games are compiled targeting 32-bit. OpenDream targets 64-bit and DLLs will need to be recompiled.
BYOND uses UTF-8, while C# uses UTF-16. As a result, length() and other text procs may return a different value for some strings.
The point of OpenDream is not just to provide an open-source implementation of Dream Maker, but to improve on it. These enhancements are currently a very low priority compared to improving BYOND compatibility.
There are two types of deletions in BYOND: hard and soft. Soft deletion occurs automatically when a datum's reference count is zero. Hard deletions occur when del() is explicitly called with a datum that has a non-zero ref count. BYOND's garbage collector has to spend a large chunk of time finding and clearing the remaining refs.
OpenDream implements instantaneous hard deletions with no time wasted doing ref searching. The only downsides are that the memory is not actually freed until the .NET garbage collector runs, and hard deletions have a small amount of memory overhead. A dedicated page with more information on our del() implementation is coming soon™.
All aspects of OpenDream natively support Linux including the client.
OpenDream ships with CEF, providing a more modern and feature-filled alternative to BYOND's Internet Explorer 11 (or IE8 on WINE).
OpenDream targets 64-bit operating systems, enabling developers to completely ignore memory efficiency on a level not seen since modded Minecraft.
BYOND wastes a significant percentage of each tick just sending map updates (see world.map_cpu). Robust Toolbox's PVS is multithreaded and largely won't have any detrimental effects on other game processing.
Update: As of BYOND 515, SendMaps() is now multi-threaded in BYOND as well.
BYOND is very slow to compile large codebases like SS13 by normal compiler standards. Your mileage will vary by hardware, but our compiler generally can bring times from a minute or so down to ~10s or less. Note that subsequent compiles are even faster than the first run.
OpenDream includes a debugger with support for features like breakpoints, pausing on runtimes, disassembly, and more. You can find more info here.
The #pragma directive is a tool found in other languages for configuring compiler behavior, typically to change whether certain non-fatal compiler emissions will be warnings, errors, or suppressed entirely. This incredibly useful feature allows us to simultaneously maintain BYOND parity while also enabling us to implement a variety of optional lints to detect invalid or unintentional code that BYOND silently ignores. A dedicated page with more info on pragmas is available here.
The compiler is currently capable of enforcing the types of vars and procs, though this is still under active development and not production-ready.
Using either the server command hotreloadresource <file path> or calling the DM function /world.ODHotReloadResource(file_path) a resource (DMI or sound files) can be reloaded from disk and sent to all clients who have the old version. This allows developers to try multiple sprites or sounds without needing to recompile every time.
Using either the server command hotreloadinterface or calling the DM function /world.ODHotReloadInterface() the main DMF interface file can be hot reloaded and an update sent to all connected clients. This enables developers to make changes to the interface and see the results without need to recompile every time.