Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
40oz

The "strong" points of Limit Removing

Recommended Posts

Limit Removing is a common "advanced source port" response found in text files for maps that haven't been tested in vanilla. Many of my past maps are either labeled limit removing or boom compatible because I didn't effectively bother to test it to check for VPO's or other errors, even though they probably would run fine in Vanilla anyway had I made the effort.

Since I don't have a lot of experience mapping or bugfixing for vanilla purposes, I'm curious what the goal would be for creating maps specifically designed for Limit Removing source ports. The evolution of Doom from Wolf3D was to use a lot of light contrast, lighting effects, various-angled walls, and height differences to really distinguish the differences between the two games. At the moment I'm drawing a blank for discerning the difference between vanilla and limit removing for anything other than extreme sector counts and detail. What can you expect to find in a map that clearly exhausts the potential of Limit Removing and screams "definitely not vanilla!" to the player?

Share this post


Link to post

You said it - extreme sector count and detailing, and no need to be bothered by constraining limits. Possibility of extreme and elaborate tricks like extensive 3D bridges and traps relying on hundreds of lines / sectors. Possibility of very large open areas with decent amount of detail. Generally a longer map which won't be simple as vanilla, but it's not a rule. That's about what to expect.

Share this post


Link to post

It's not necessarily about potential either, a lot of it is just down to workflow and productivity; I find it much easier to map when you don't have to worry about vanilla limits.

Share this post


Link to post

Doesn't have to be extreme detail; even just large open areas can VPO in Vanilla easily. Check out mouldy's MAP28 in NOVA if you haven't already, such a thing would have to be seriously compromised to work in Vanilla.

Share this post


Link to post

40oz said:
Since I don't have a lot of experience mapping or bugfixing for vanilla purposes, I'm curious what the goal would be for creating maps specifically designed for Limit Removing source ports.

It really depends on what that means, concretely. To me it's so that you can play it under vanilla mechanics, either Doom+ or compatibility level 2 in PrBoom+. In the end, "limit removing" just ends up meaning whatever it was tested with. As far as I'm concerned, "limit removing" tested on default PrBoom or ZDoom, or some other popular port, is sloppy mapping, more so if there aren't any "tested with" and "does not work with" warnings.

Using vanilla compatible behavior during testing offers a good deal of long term reliability for any port because most ports remove limits but are made to be able to run vanilla levels. The other historically persistent option, as you know, is Boom, or "limit removing Boom"; somewhat less universal but adds features.

Other than that, I don't think there's any design difference stemming from limit removing that isn't being forced by vanilla's limits. Or, I mean, "just edit freely within the limits of limit removing without worrying whether it isn't vanilla-styled any more".

Share this post


Link to post

I think LR is a very bad term because it's so unclear what exactly different people mean by it. I don't recommend using it.

Share this post


Link to post
Memfis said:

I think LR is a very bad term because it's so unclear what exactly different people mean by it. I don't recommend using it.


I kind of agree with this, if you're going to say Limit-Removing you should specify what port you're targeting or what non-vanilla features you're using.

Share this post


Link to post

"Limit-removing" means that the map shouldn't rely on any non-vanilla feature. Just that it can have more visplanes/sidedefs/whatever than a vanilla map.

Share this post


Link to post

^ This definition seems pretty straightforward to me, and I always got the impression it's a widely accepted one.

Share this post


Link to post

The term "limit-removing" is good, it means a purely vanilla-format map where you don't have to bother with VISPLANEs, DRAWSEGS, maximum of 64 scrolling lines, and other limits.

Share this post


Link to post
Gez said:

"Limit-removing" means that the map shouldn't rely on any non-vanilla feature. Just that it can have more visplanes/sidedefs/whatever than a vanilla map.


But tons of limit-removing maps have vertically-tiling textures that aren't 128px tall, or midtextures on 2s linedefs made from multiple patches, or sprite replacements without Dehacked (or instructions to use DeuSF etc.), etc. And for a lot of ports that isn't a problem. And then there are large maps that require extended nodes or blockmap support.

I don't think these kinds of things should be prohibited in a limit-removing map, but I also don't think that an assumption should be made that any limit-removing port can handle them.

Share this post


Link to post

The points i see ;
- room for a better manifestation of the mappers thoughts and fantasy.
- No need to constantly do or think ; 'am i going over a limit', 'better test it', 'testing it after one edit', etc...
- Large spaces can be used instead of tightly controlled viual areas to avoid Visplane problems or whatever limit being imposed.

- increasing the game its life with maps 400 percent more fit for modern source ports their updated rendering quality.

Share this post


Link to post
scifista42 said:

The term "limit-removing" is good, it means a purely vanilla-format map where you don't have to bother with VISPLANEs, DRAWSEGS, maximum of 64 scrolling lines, and other limits.


So, hypothetically, use over 64 scrolling lines, visplanes as far and bountiful as the eye can see, and.. what are drawsegs again? Does that have to do with how many sprites are shown on screen at once?

EDIT: doing some more research and found this:

http://doomwiki.org/wiki/Static_limits

Which I guess sort of answers my question. I guess what I'm trying to do is find the more obscure elements of vanilla limits and make a list of what I would have to make in a doom map in vanilla to 'break' compatibility with it, and think of way I could create something interesting with it.

i.e. MAXSPECIALCROSS - SPECHITS OVERFLOW - create a sequence of actions caused by 8 or more linedef actions activated at the same time.

then there's some more obscure ones that I can't seriously attempt to make any plausible use of, like MAXWADFILES, make a map that requires 20 or more seperate wad files to run.

Share this post


Link to post

The issue that bugs me is the separation between 'limit removing' and 'boom compatible'. That is, physically there's almost no reason to not consider the two interchangeable; what sane popular ports remove limits that haven't also implemented boom, by now? I mean, sure, boom has some weirdness issues between ports, and some even in its own specification (ledge-stuck monsters seem to be the big one?). I'd say vanilla-only (AKA complevel 2, I guess?) weirdness issues (NOT limits!) can also be annoyances, for different reasons. In any case, both have their workarounds, I'm finding.

If you're not using vanilla limits for reasons of humility or fun constraints, there doesn't seem to me to be a truly justifying reason to consider boom and 'limit removing' distinct, with the possible exception of making a "limit removing" map with potential intent to later back-port back to vanilla.

Share this post


Link to post

Different people prefer different limitations, I guess. Some of them want to make maps with strictly vanilla toolset, but without the most annoying vanilla problems.

Tuxlar said:

That is, physically there's almost no reason to not consider the two interchangeable; what sane popular ports remove limits that haven't also implemented boom, by now?

Doomsday?

Share this post


Link to post

Tuxlar: If a wad was specifically made as limit-removing (example: prboom-plus -complevel 2) then you shouldn't play it in boom compatibility because of how monsters fall off cliffs and no ghosts in boom, etc. Differentiating between boom and limit-removing is also helpful from an editing perspective because there are many more editing features in boom.

Share this post


Link to post
TimeOfDeath said:

Tuxlar: If a wad was specifically made as limit-removing (example: prboom-plus -complevel 2) then you shouldn't play it in boom compatibility because of how monsters fall off cliffs and no ghosts in boom, etc. Differentiating between boom and limit-removing is also helpful from an editing perspective because there are many more editing features in boom.

Ah, forgot about ghosts. That's a very definite boom-unfriendly situation, but I imagine trading ghosts for boom features is still a small price, for many purposes. It is possible (but not always elegant, maybe) to compensate for the ledge issue with design, though.

With all those conditions satisfied (and if you don't particularly care about Doomsday players, I guess), and if you don't have a logical reason (e.g. constraints for fun), THEN boom might be considered physically interchangeable with limit removing.



...I guess it's best to just consider them distinct, after all.

Share this post


Link to post

The issue I think that is being raised is that there is no universal agreement on what 'limit removing' actually means (or meant, as it probably can't be retroactively decided at this stage); which limits is it specifically referring to.

Certainly, things like visplanes are basically universally agreed to be 'limit removing'. But what about infinite Z height etc.

Share this post


Link to post
Vermil said:

The issue I think that is being raised is that there is no specific statement of what 'limit removing' actually means (or meant, as it probably can't be retroactively decided at this stage); which limits is it specifically referring to.

Certainly, things like visplanes are basically universally agreed to be 'limit removing'. But what about infinite Z height etc.

Or even things like MIDI vs MUS, technically-speaking.

Share this post


Link to post

It's pretty funny to me that I can read this thread, run a Google search for something about Boom and limit removal, and end up finding a Doomworld forums thread from literally a decade ago that features myk discussing limit removal.

Share this post


Link to post
Memfis said:

I think LR is a very bad term because it's so unclear what exactly different people mean by it. I don't recommend using it.

I have to agree with this. I see a lot of wads labeled "Limit removing" which really doesn't tell me anything in the way of compatibility. Specifying a compatibility level goes a long way, and I'm continuously stunned at the number of wads that fail to mention whether or not the wad was designed for Doom 2, Boom, Final Doom, etc.

Share this post


Link to post

Some modern users are probably legitimately unaware of how Vanilla Doom (or Doom95) plays because they can jump straight into modern ports.

Particularly as both can have issues or need additional software, on modern computers. But there is Chocolate Doom these days.

Share this post


Link to post

Complex outdoor environments, or outdoor environments with large backdrops. Neither were really possible with vanilla limits.

Share this post


Link to post
Tuxlar said:

The issue that bugs me is the separation between 'limit removing' and 'boom compatible'. That is, physically there's almost no reason to not consider the two interchangeable; what sane popular ports remove limits that haven't also implemented boom, by now?


I doubt they fit your definition of 'sane' or 'popular' but the two ports for Acorn RISC OS fall into this category:

http://www.arsvcs.demon.co.uk/leisure/doom/DoomPlus.html
https://sites.google.com/site/jeffreyadoggett/

Share this post


Link to post

Call me a sloppy mapmaker, but half the time, I myself don't even know what makes my map require a "limit removing" one. I've never really given much thought to the matter, honestly. When I'm designing, I do most of my testing in source ports, because hey, that's what I play, even if I'm not designing a map specifically for any source port. At the end, when I'm ready to release, I run a quick test in vanilla to see if it runs, to know if I need to stipulate that it needs a limit-removing port. Never really thought to go over my maps to see specifically what is preventing them from running properly in vanilla.

Again, I realize this is the result of bad habits and sloppy mapmaking (even if you are going to use a limit-removing port, it does occur to me that one should pay attention to the choices they make that might break vanilla compatibility).

I don't really know what alternative to "limit removing" one could use, though. Maybe simply list the ports it's been tested with - would require a little extra work to run through the map with different ports, and you might miss one, but that might help give a better idea of specifically the issue is that requires one to use a source port for a map with no special features.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×