Size/technical limits in Chocolate Hexen (and hexen mapping in general)

What are the limits for map size, number of linedefs, number of sectors, and other similar things in chocolate and/or vanilla Hexen? Map size being the most important issue (as well as how much you can make build within that size limit). There doesn't seem to be much information available about this, besides the fact that some values weren't changed from the doom engine, but do those limits still behave the same way in hexen?

As an experiment, I'm currently testing a very large empty map which consists of a square between the points -9400, -9400 and 9400, 9400, as described in this thread, and although it does run, I seem to get the "long wall error" on its outer walls, even when I split those linedefs into <1024 ones. Is this something that happens because of the distance I'm looking across in this case, rather than the linedefs? Or is it an error that would happen in any level with a bounding box this size, regardless of how it was then divided up and how far you could see at a time?

And also, on the subject of chocolate hexen behavior, why is it that some very simple maps just crash on opening in chocolate hexen, despite not being big or containing anything weird. It's almost like random behavior -- you start a map, make one sector and a player start, and it doesn't run. You change something minor and suddenly it does run. Is there any reason for this? Maybe hexen doesn't like running tiny maps ... although it runs MAP41: Maze perfectly well...

(As a final aside, is there a version of the visplane explorer plugin for doombuilder that works with hexen maps? Or maybe something like chocorenderlimits for hexen?)

Vanilla Doom engine has a problem that prevents it from running maps with only one sector.

Ah. Well that explains that.

Quasar said:

Vanilla Doom engine has a problem that prevents it from running maps with only one sector.

Was that problem introduced in 1.666 or 1.9? I remember running a 1-sector map in 1.2. First map I built with my brother in DEU was one unclosed sector. It ran and it looked like crap with HOMs.

Grain of Salt said:

What are the limits for map size, number of linedefs, number of sectors, and other similar things in chocolate and/or vanilla Hexen?

According to Crispy Doom: MAXVISPLANES is 160 and MAXVISSPRITES is 192. Not sure about anything else being changed. Certainly no changes to blockmap limits or max SSECTORS or anything else.

And also, on the subject of chocolate hexen behavior, why is it that some very simple maps just crash on opening in chocolate hexen, despite not being big or containing anything weird.

In addition to what Quasar said, I find Hexen maps with an empty or no BEHAVIOR lump to be oddly unstable. Even if you're not scripting at all, you should have a do-nothing script. In DB, go to View -> Scripts and add this in:

#include "common.acs"

script 1 (void)
{
}

(As a final aside, is there a version of the visplane explorer plugin for doombuilder that works with hexen maps? Or maybe something like chocorenderlimits for hexen?)

Andrewj just updated the standalone version of visplane explorer to include Hexen, you can find the thread in this forum. I believe MaxED has updated the GZDB plugin to reflect this but I haven't tried yet. GZDB doesn't have configs for vanilla Heretic or Hexen by default, I can post mine if you want.

Quasar said:

Vanilla Doom engine has a problem that prevents it from running maps with only one sector.

Only if that one sector is convex -- because such a map does not produce any NODES and the engine requires at least one node.

You can have a single sector map which is non-convex (contains angles > 180 degrees at vertices, e.g. a corner which sticks out).

Grain of Salt said:

What are the limits for map size, number of linedefs, number of sectors, and other similar things in chocolate and/or vanilla Hexen? Map size being the most important issue (as well as how much you can make build within that size limit). There doesn't seem to be much information available about this, besides the fact that some values weren't changed from the doom engine, but do those limits still behave the same way in hexen?

As shown on that link, the limits that were raised in Hexen are for players (up to 8 players instead of 4, so multiplayer-related values are doubled), visplanes (128->160), and vissprites (128->192). Increased visplane value allows greater map complexity; increased vissprite value was probably because of all the atmospheric effects (leaves, fog clouds, etc.).

Everything else is the same. Hexen also has its own limits, mostly for ACS-related stuff. It's all explained on that static limit page on the One True Doom Wiki. (I hope you're not using the wikia site.)

plums said:

According to Crispy Doom: MAXVISPLANES is 160 and MAXVISSPRITES is 192. Not sure about anything else being changed. Certainly no changes to blockmap limits or max SSECTORS or anything else.

You could have linked to the same page I linked to in the first post to reference those values, but I'm glad you didn't, because crispy doom actually looks quite interesting. A limit-removing hexen port with vanilla compatible behavior? Nice. I might actually move over to mapping for this port.

plums said:

In addition to what Quasar said, I find Hexen maps with an empty or no BEHAVIOR lump to be oddly unstable. Even if you're not scripting at all, you should have a do-nothing script. In DB, go to View -> Scripts and add this in:

#include "common.acs"

script 1 (void)
{
}

I haven't been adding any kind of scripts to my maps so far, and most of my maps don't crash, so I guess this isn't a problem for me? SLADE shows these scriptless maps having BEHAVIOR lumps of 12 bytes in size, for the record.

By the way, do scripts not have to be compiled or anything before they work? When I open the original hexen maps, I apparently can't view any of the scripts, so I assumed they'd been compiled somehow. Is that just because their scripts are made in a different way or something?

plums said:

Andrewj just updated the standalone version of visplane explorer to include Hexen, you can find the thread in this forum. I believe MaxED has updated the GZDB plugin to reflect this but I haven't tried yet. GZDB doesn't have configs for vanilla Heretic or Hexen by default, I can post mine if you want.

I guess I could use the standalone version. Maybe moving to crispy hexen compatibility makes worrying about visplanes a moot point, though. You'd apparently need 1280 onscreen to crash that port.

andrewj said:

Only if that one sector is convex -- because such a map does not produce any NODES and the engine requires at least one node.

You can have a single sector map which is non-convex (contains angles > 180 degrees at vertices, e.g. a corner which sticks out).

Yeah, I don't know why I just agreed with the "one sector" thing above. I have several maps right now with only one sector that don't crash.

Gez said:

As shown on that link, the limits that were raised in Hexen are for players (up to 8 players instead of 4, so multiplayer-related values are doubled), visplanes (128->160), and vissprites (128->192). Increased visplane value allows greater map complexity; increased vissprite value was probably because of all the atmospheric effects (leaves, fog clouds, etc.).

Everything else is the same. Hexen also has its own limits, mostly for ACS-related stuff. It's all explained on that static limit page on the One True Doom Wiki. (I hope you're not using the wikia site.)

I wasn't asking about those values so much as more arcane behavior that might make large maps unfeasible in hexen. The "no two points further apart than 32767 units" limit isn't mentioned on that page, for example. That seems to work in hexen the same as in doom, though, at least so far.

I also recently got the following error message on my empty 18800x18800 map:

R_DrawPlanes: drawsegs overflow (-1430790832)

I think I solved that issue by deleting a few vertexes on the long lines, but I'm puzzled as to what caused it (and how to avoid it in future). This was on Crispy Doom, in a map with only three sectors.

Grain of Salt said:

A limit-removing hexen port with vanilla compatible behavior? Nice. I might actually move over to mapping for this port.

Be aware that the games other than Doom are not really "supported," i.e. those ports exist but no work is being done on them currently. I am kind of starting to port other features to them that are present in Crispy Doom, but I'm a pretty inexperienced coder and so it's going to take a long while. Any serious game-breaking bugs could probably get fixed though.

Also, it's limit-raising, not removing, to be in line with the limits of Hexen+. Definitely possible to break the limits still with extremely large/complex maps, especially vast outdoor ones. So, no Sunder-esque Hexen maps for Crispy Hexen. (yet?)

By the way, do scripts not have to be compiled or anything before they work? When I open the original hexen maps, I apparently can't view any of the scripts, so I assumed they'd been compiled somehow. Is that just because their scripts are made in a different way or something?

Scripts do need compiling. BEHAVIOR is the actual compiled lump that Hexen needs. SCRIPTS is the plain-text uncompiled version. You don't need this lump at all, but it's become common to just leave it in the wad both as a convenience while mapping, and because it's nice to do for anyone who wants to learn from your maps.

You can decompile scripts, there's DEACC, DESCRIPT, and ListACS, among others. Can't say if there's a best one, but ListACS seems to support ZDoom BEHAVIOR as well. Obviously you lose formatting etc. from the original script, but Hexen scripts are typically simple enough that it's not like reading assembly code or anything.

I wasn't asking about those values so much as more arcane behavior that might make large maps unfeasible in hexen.

Assume that stuff like the 32767 distance limit all applies to Hexen. In fact there might even be more arcane restrictions since Hexen derives from Doom 1.2, though I can't tell you what difference this would make off-hand.

I also recently got the following error message on my empty 18800x18800 map:

I'm guessing you had too many SEGS in view at once. Fewer linedefs = fewer segs.