zdbsp compressed: supported in most ports?

Greetings,

I got some big maps laying around, ones that have >2^16 sidedefs and thus require compression during nodebuilding. Is it safe to assume that pretty much all modern ("boom-compatible") ports support this nowadays? If not I guess I'll start hacking away some of the excess detailing.

I know it'll work in latest prb+, (g)zdoom, here are the ones I'm less sure of:
- latest zdaemon
- latest zandronum
- eternity

Most of the info I found via googling or searching the forums was posted several years ago, so I imagined it would be easier to find out by just making a thread and asking.

Thanks!

Not supported in ZDaemon. :(

Of your list, I know Eternity and Zandronum support it, at least.

ZDBSP's compressed nodes format actually is just using zip compression, AFAIK. The real magic is in the fact that it's an extended format to begin with :)

Fortunately a few years ago ZDBSP was updated to allow building extended nodes without zip compression, and deprecate the compressed format, which paved the way for PrBoom-Plus and Eternity to support it. If you're on a version from the past few years, I think -X will force it to build extended-but-not-compressed nodes. (It'll automatically do so if the map is large enough to require it, but forcing it anyway means you get its benefits like reduced slimetrails even on smaller maps!)

edit: In case this was unclear, the newer extended-but-not-compressed format is crossport compatible, but the older extended-and-compressed format is not.

thanks for the info guys!

Memfis said:

Not supported in ZDaemon. :(

this is all I needed to hear. I want the maps to be compatible with zdaemon so I'm gonna go the route of stripping out some of the unnecessary detailing then.

if there's somewhere to suggest feature requests I'd definitely add this one to the list though :D

I am not sure what's being meant by compression here, but EE does *not* support deflate-compressed ZDoom nodes. And I am not aware of there ever being a technical requirement for the use of deflate-compressed nodes, either.

EE *could* support the deflate-compressed variety of the format now that it has zlib integrated, if and when I ever get back around to working on it. But it's a bit low priority considering there's no compelling reason in my sight for nodes to be compressed only to then be stored inside a ZIP which supports compression on its own. Why not use ZIP compression instead of individually compressing certain lumps; it makes no technological sense at this point.

my question was poorly phrased, my apologies. Basically it boiled down to: "If I have a map with ZDBSP nodes and >2^16 sidedefs (which induces an ambiguous compression step upon saving in db2 that as far as I understand hashes identical sidedefs together to work around the technical limit), which ports can run it?"

I think my error in phrasing was not realizing that this behavior is inherent to zdbsp, and that "zdbsp 'compressed'" is actually another beast that somehow works zip compression in there somewhere.

It's a common misconception, I think. I didn't realize the distinction until it was explained to me a few years ago when the compressed format was effectively deprecated.

Quasar said:

But it's a bit low priority considering there's no compelling reason in my sight for nodes to be compressed only to then be stored inside a ZIP which supports compression on its own. Why not use ZIP compression instead of individually compressing certain lumps; it makes no technological sense at this point.

Remember: The node format is older than Zip support in ZDoom. But ultimately you have to ask someone else (cough) why such things are important. Just this: I had to undo the odd 'space optimization' in ZDoom because it had some adverse effects that were not plainly obvious.