User:Nev3r/UDMF
UDMF stands for Universal Doom Map Format. It is a map data specification which is text-based as opposed to a byte-specific, traditional binary map format. The main point of UDMF is to enhance the capability to store data in map elements.
Overview
UDMF compatibility for SRB2 has been suggested for quite some time. Currently a branch is being developed in the indev repository. It won't necessarily come out with 2.2, and if it does, it won't necessarily be the final implementation either.
The main consequence of using UDMF in SRB2, besides the data limit removal, is the lack of need to "hack in" parameters for special effects by using texture offsets, sector heights, linedef lengths etc. Instead, dedicated fields are provided for the required parameters, making it much easier and cleaner to configure special effects.
There is a detailed in-progress SRB2 specification being worked on in this page.
Pros
The main reasons to decide to make a UDMF implementation for SRB2 are:
- The binary map format has limits on the amount of data each map element can have on itself.
- UDMF-supporting editors such as SLADE and Doom Builder (and consequently GZDB and Zone Builder) provide a very high degree of interface customization (for example, linedef specials can have their own interfaces).
- It is highly compatible with different map format versions/variants; unknown fields in the map data are simply ignored.
Cons
Using UDMF to make a map has the following drawbacks when compared to traditional binary format:
- The filesize is going to be considerably bigger. This can be mitigated decently by using PK3 compression. The filesize can also be reduced by using compressed nodes.
- The level load time will inevitably be longer.
- There are no easy conversion methods between UDMF and binary format (or vice versa).
- Some really obscure scripting tricks using linedef executors, involving changing the sector heights, might stop working (for example, changing the height of a timed control sector with another control sector).