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

128 visplanes limit

Recommended Posts

Sorry for the noob question, what's the most faithful to Vanilla Doom port, that doesn't have the 128 visplanes limit?

Thanks in advance :)

Share this post


Link to post

Chocorenderlimits? Still has a limit, but it's raised for the purposes of visplane overflow checking.

Beyond that... I dunno, Boom or something.

Share this post


Link to post

OK, I'll be a bit more specific: I need a port that doesn't have the visplanes limit, but does have another bugs like medusa effects and such :P

Share this post


Link to post
Fernito said:

OK, I'll be a bit more specific: I need a port that doesn't have the visplanes limit, but does have another bugs like medusa effects and such :P


Strawberry Doom, although there is still a visplane limit.

Share this post


Link to post

So, I guess then that every port that removes the visplane limits, also fixes medusa effects and such visual bugs?

Share this post


Link to post

And here are actual links:
Doom2+: http://sourceforge.net/projects/prboom-plus/files/doom2-plus/1.92.6/doom2-plus-1.92.6.zip/download
Doom+: http://sourceforge.net/projects/prboom-plus/files/doom-plus/1.92.2/doom-plus-1.92.2.zip/download
current info

As you can see, it raises several other limits. If you specifically want a version with just the raised visplane limit and no other change to limits, then the "source" is included, so you can customize it, but obviously this requires some technical know-how.

Share this post


Link to post

Thanks for your replies :)

Well, I'm asking this because I want to release a WAD I made, but I have only tested it using ZDoom (I know, I know...), so I don't know if it will run well on other ports. It's just an Ultimate Doom WAD though, it uses no ZDoom specific features, so the only thing I'm afraid of is that people playing it in "not-so-advanced" ports could experience medusa effects and/or other visual bugs, so I wanted to test it in a port as close as possible to Vanilla Doom to ensure it has no bugs of that kind.

I hope I made myself clear :P It's difficult for me to explain some ideas when English is not my native language.

Share this post


Link to post
Fernito said:

So, I guess then that every port that removes the visplane limits, also fixes medusa effects and such visual bugs?


Quite the opposite. Boom derivatives only fix the "Tutti frutti of the first kind" bug (garbage pixels due to texture tiling), but not the "tutti frutti of the second kind" bug (drawing masked textures as non-masked). That's because the tiling problem was explicitly fixed by Killough, but the others require much more complex handling, and thus not all ports address them. Since the medusa effect is related to the "tutti-frutti of the second kind" bug, it will similarly not be fixed in ports that don't address multi-patch or patch-on-void problems.

In practical terms: Chocolate-Doom fixes neither, so it's a quite "safe" choice if you really have to have those bugs.

Share this post


Link to post
Maes said:

Quite the opposite. Boom derivatives only fix the "Tutti frutti of the first kind" bug (garbage pixels due to texture tiling), but not the "tutti frutti of the second kind" bug (drawing masked textures as non-masked). That's because the tiling problem was explicitly fixed by Killough, but the others require much more complex handling, and thus not all ports address them. Since the medusa effect is related to the "tutti-frutti of the second kind" bug, it will similarly not be fixed in ports that don't address multi-patch or patch-on-void problems.

In practical terms: Chocolate-Doom fixes neither, so it's a quite "safe" choice if you really have to have those bugs.


But the point is that maps in my WAD exceed by a wide margin the 128 visplanes limit (and actually it's meant to be like that, it's not vanilla compatible), so I should test them in a port that doesn't have the visplanes limit, but does show visual bugs.

Share this post


Link to post

Well, I just tried the WAD with PrBoom/Chocolate-Doom, and many textures look ALL MESSED UP! Here are some comparisons:







Can anyone please explain me why that happens? :(

Share this post


Link to post

Looks like a texture lump issue. While ZDoom will cheerfully combine multiple TEXTURE* lumps, PrBoom and Chocolate only use the last ones loaded. So if your wad contains custom PNAMES/TEXTURE* lumps, they'll need to include all the IWAD textures as well.

Share this post


Link to post
Fernito said:

But the point is that maps in my WAD exceed by a wide margin the 128 visplanes limit (and actually it's meant to be like that, it's not vanilla compatible), so I should test them in a port that doesn't have the visplanes limit, but does show visual bugs.


Any limit removing or boom-compatible port should do the trick, then. Most do fix the texture tiling problem (which is necessary, if you don't want to map by constraining textures to start multiples of 128), but do not fix the masked-texture-on-single-sided-linedefs bug (which would be a bad practice to begin with, you shouldn't really rely on ANY engine to fix this for you).

Limit removing means: engine crashing, mapping-limiting or visually disrupting limits are totally removed or rendered harmless. The tutti-frutti of the SECOND KIND (the one you're experiencing is of the FIRST KIND, which indicates broken textures) is a mapping error for several reasons. Perhaps you're using custom PNG textures or some format that only ZDoom can actually handle?

Share this post


Link to post

@GreyGhost: Yeah!! That must be the problem, as I have some custom textures in there. I'm not very familiar with WAD resources editors (I used Slade3), but is there a way I can put all the textures in a single lump? Well, I'll try to figure it out when I get home.

@Maes: thanks for the info! By the way, when I said "medusa effect" earlier I actually meant "tutti-frutti effect", sorry for that :P I'm 99% sure my map doesn't have the former.

Thanks guys! I'll try to figure out how to correct these bugs putting all the graphics in a single lump in Slade3 or something like that.

Share this post


Link to post

Interestingly, the Doom 3: BFG Edition "Classic Doom" has a very lame way of dealing with visplane overflows: it simply returns the last valid one, so overflows should -theoretically- result in HOM floors and ceilings, with only the very last visplane beyond the limit being rendered correctly. All other visplanes between the limit and the final one would not be rendered.

About TEXTURE* lumps: those are actually "master lists" of textures, containing only descriptions of how to build the textures and their properties. The patches (actual images) used to assemble the textures can be anywhere in the IWAD/PWADs.

However, due to limitations in how Doom works, there can only be two such lumps: TEXTURE1 (mandatory for all DOOM versions) and TEXTURE2 (mandatory for all registered/retail Doom versions, in addition to TEXTURE1). Whenever you add new textures to a PWAD, you must also include a modified TEXTURE2 lump (shareware Doom can't read it) that includes any and all textures previously included in the TEXTURE2 lump PLUS any of your own, new ones.

But, because the default contents of the TEXTURE2 lump are IWAD-specific (Ultimate Doom has one, Doom II has another etc.) you must make sure that you're using your PWAD with a compatible IWAD. You can't e.g. build your new textures assuming a Doom II IWAD, and then play it with Ultimate Doom, even if you don't use any Doom II specific textures, monsters or features.

Most ports will crash as soon as you try loading such a combination, others might "forgive" the error (but look wrong), and some like ZDoom might even try correcting it on the fly for you. Don't rely on such mechanisms, and don't release broken PWADs.

Also, as others said, you can't have multiple TEXTURE1/TEXTURE2 lumps in a PWAD: only one of them will be read, they won't be automagically merged, so it's important that The One is correct for the intended IWAD.

Share this post


Link to post

Thanks for the very comprehensive explanation. I'll work on it later today and I'll let you know how it worked :)

Share this post


Link to post
Maes said:

some like ZDoom might even try correcting it on the fly for you.

It's not so much "correcting on the fly" as "adopting a sane approach to cumulative loading". The method employed is explained here:

ZDoom allows cumulative loading, though only one TEXTURE1 and one TEXTURE2 lump will be loaded for each archive; and in each archive TEXTURE1 is loaded before TEXTURE2. Each TEXTUREx lump uses the last previously-loaded PNAMES lump as a reference (so for example, the IWAD textures always use the IWAD patches).

A single texture can be redefined by a later TEXTUREx lump, however if a texture is defined more than once in the same TEXTUREx lump, the later definitions are skipped. In other words, a texture uses its first definition in the last lump.

Share this post


Link to post

Is there any Doom 2 -> Doom 1 converter for PNAMES and TEXTURE1? Way too many texture packs assume that I should only use Doom 2.

Share this post


Link to post
printz said:

Is there any Doom 2 -> Doom 1 converter for PNAMES and TEXTURE1? Way too many texture packs assume that I should only use Doom 2.


How could such a thing exist? Most stuff in Doom 2 doesn't exist in Doom 1, even if there is a common set of patches. Even if you add the missing texture and patch names, you'd still need to provide the patches they are referencing (unless you get creative and hack e.g. ZZWOLF textures to look like MARBFACE...)

The closest find you'll find is a sort of pack that made using Doom PWADs with Doom II possible (the opposite direction of what you're looking for), by supplying the missing patches and altering the TEXTURE and PNAMES lumps. I guess the "supplying the missing patches" part is why you won't find it on idgames nowadays... I could dig it out of its digital pit however ;-)

Share this post


Link to post

THANKS A LOT!!! I edited the WAD in Slade3 and followed your directions. Now it looks like it's meant to in PrBoom (if it looks good in this port, may I assume it will run well in any port?).

I'm so happy!! :D Thanks everyone for the help!

Share this post


Link to post
Fernito said:

(if it looks good in this port, may I assume it will run well in any port?)

Do you want me to confirm that for you?

Share this post


Link to post
Archy said:

Do you want me to confirm that for you?


Wow, that would be neat!! Thanks, I really appreciate it :) Here's the link: http://www.mediafire.com/?x7gd5blemaq8okt

PS1: too bad I didn't notice this before submiting it to idgames, it got published already :/ I think I learned an important leason here haha

PS2: BTW, are you the same Archy I send a LMP to on YouTube?

Share this post


Link to post
Fernito said:

PS2: BTW, are you the same Archy I send a LMP to on YouTube?

Yes.

Share this post


Link to post

EeewwWW!


Anyways, here's what it looks like under Vanilla Doom with a very well crafted binary hack:



Notice that in the sky towards the right of the ugly stairs in the image above, the sky is flashing like an idiotic moron. You can see this at 2:12 and 2:20, towards the right of the imp on the right piller.

Recorded with DOSBox. Sorry I didn't take the time to prepare it in good quality.

Share this post


Link to post

Hey, nice playthrough! (you got all secrets! :D)

Thanks a lot, fixed all the bugs, including that weird "shimmering" sky LOL.

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
×