Old doom editor needing help

[mikenet2007]

Hey guys, I haven't touched a doom editor in almost a decade and getting back into the swing of things is proving a bit more tedious than I had figured. I know the basics, and have been mapping for Duke Nukem and Unreal Tournament/UT2004 in the meantime. So I know lines from verities, and a room from a sector, and that sort of thing. I'm just having a bit of trouble with the specifics. Today I created a room with a long hall about 400 x 1500 with triangular stairs reaching a large platform that overlooks a large field with a parallaxed sky. The platform at the the top of the stairs is about 4000 x 2500 and the field it overlooks is about 12000 x 7000, large enough for to require me to increase the draw distance in the 3d mode settings. The problem I'm having is a HOM effect in the stair case.

[mikenet2007]

What could be causing this? Is it really a good idea to create large open areas without dividing them into smaller sectors?
There are no crossed lines here and I didn't enclose any smaller sectors with parent sectors. I don't know how often its good to build the nodes though, it reminds me a bit of UnrealED but here I don't know if this has a visual or physical effect in the editor or if its something you only need to do before saving or launching a map. I will probably have a few more questions but the only other thing I can think of for now would be how do I take screen shots from within the editor, thanks in advance.

[Vegeta]

Build nodes each time you're going to test the map (you don't need to do that while only mapping). Be sure to use the "look for bugs" utility that your editor sure have.
Today nobody split big open sectors into smaller ones. The problem most probably is a missing lower texture, to fix it, select the lines that show the HOM, with ctrl-f put them all looking to the same side, mark them all and add some lower texture (if the lower textures aren't placed but are needed the editor will point that with red lettes).
It's allways helpful to look at other people maps. The from the iwad are a good choice for this kind of things as they're already in your computer and don't have too many lines that may dificult the exploration (just remember not to save if you do some modification to the iwad).

Some tutorials are very helpful. Also for this kind of problems with notorious visuals you may want to post a screenshot to get more specific help.

[mikenet2007]

Now the whole map has blown up just by changing a couple vertices's. BSP holes everywhere! No relevant errors listed on the error test either, just a notification that there is no 2nd player start, but other than that its reading nothing.

[mikenet2007]

Vegeta said:

Build nodes each time you're going to test the map (you don't need to do that while only mapping). Be sure to use the "look for bugs" utility that your editor sure have.
Today nobody split big open sectors into smaller ones. The problem most probably is a missing lower texture, to fix it, select the lines that show the HOM, with ctrl-f put them all looking to the same side, mark them all and add some lower texture (if the lower textures aren't placed but are needed the editor will point that with red lettes).
It's allways helpful to look at other people maps. The from the iwad are a good choice for this kind of things as they're already in your computer and don't have too many lines that may dificult the exploration (just remember not to save if you do some modification to the iwad).

Some tutorials are very helpful. Also for this kind of problems with notorious visuals you may want to post a screenshot to get more specific help.

Whats the hot key for an "in editor" screen shot?

[mikenet2007]

You were right about the missing textures causing the mirror effect so thats fixed but im still having serious glitching in the editor in the larger area. streaks and bands of color are bleeding through everything. Looks like bsp holes to me.

[Maes]

mikenet2007 said:

You were right about the missing textures causing the mirror effect so thats fixed but im still having serious glitching in the editor in the larger area. streaks and bands of color are bleeding through everything. Looks like bsp holes to me.

Ehm it would actually help if you specified what editor you're using and with what port you're testing your map. Since you're talking about a 3D preview, I assume that's Doombuilder. So we still need to know the port you're using for testing.

[mikenet2007]

oops I guess I figured most here were using Doom Builder, but yes I am. Nothing beats having a 3d mode for a 3d game, It certainly wasn't a cake walk back in the day without it :) I used a 2d editor for doom years back. Anyway I'm currently using the doom2 port if you were referring to what game.

[Maes]

Yeah, most people do use Doombuilder for its 3D mode, although certain types of editing may be easier on other editors...anyway, I meant what source port (ZDoom, BOom,prBOom etc.) you're using for playtesting your levels, or if you're using good old DOS doom (vanilla Doom) for that.

If you're using vanilla Doom or Chocolate Doom, well, expect them to break and bleed a lot with large linedefs. If you aim at making a level compatible with the Doom engine's limitations, you have to use the old trick of breaking down long linedefs into smallers ones with a maximum length of 1024 (?) or any value that doesn't break the engine.

[mikenet2007]

Its using the Doom2.exe, and wad, nothing else. I do have a win 98 partition that is formated in fat32 making it great for older games but luckily my Doom 2.exe functions on my winxp partition fairly well, just without sound.

Duke Nukem has a wall length limit as well, not a limit but you lose the ability to insert points after the wall gets exceptionally long. This is to encourage the player to split the walls so they don't get so long they cause clipping problems. What your speaking of is strictly a wall length restriction as well, not a sector mass restriction correct? Can you permanently corrupt a map by exceeding a wall length of 1024 "doubt it but gotta check :)"? Finlay, What are the advantages of using newer ports?? Ive been out of the swing of doom building for almost 10 years.

[Searcher]

Sounds like the medusa effect on the bleeding and color bands error. As mentioned above, you need to break those walls down as far as length between vertices. Just for fun have you tried to run the map with a port like prboom or zdoom yet to see if those errors still show up? Most tutorials cover the medusa effect and how to fix it. OR just search these forums for the word in the editing forum.

[mikenet2007]

Thanks guys, I'll give that a try.

This may be off topic a bit but who better to know this than doom editors,:) I just recently reinstalled doom95, Ultimate Doom, and Doom2, on my xp system. The last time I had these games installed was on an older system. Now I'm having both sound issues in doom2 and no mouse functionality in doom95 and Ultimate Doom, I'm sure this might have come up 100 times. I do have an older win98 partition but I like to get as many games on my xp partition because Its more convenient not to switch back and fourth. I couldn't find Internet drivers for my 98 partition either that are compatible with my dsl, so thats another problem. You guys know what might be the fix for the sound and mouse trouble?

[Maes]

Well according to the doom wiki, the Medusa Effect has to do with the presence of more than one texture patch on the middle texture of a two-sided linedef, but it's not the one causing the linedef HOM error.

I remember there was a precise hardcoded linedef length limit, after which the normal vanilla engine just doesn't draw stuff, resulting in secondary HOM. The oldskool workaround was, exactly, splitting linedefs into smaller ones.

There are subtler causes of HOM like e.g. exceeding a certain number of visible linedefs (especially double sided ones). Since you seem interested in vanilla doom mapping, maybe you should keep The Unofficial Doom specs 1.666 handy for reference, in order to keep withing engine limits.

Moving on to Boom-compatible engines will give you more freedom in that sense, so may want to consider a switch ;-)

[Maes]

mikenet2007 said:

Thanks guys, I'll give that a try.
I just recently reinstalled doom95, Ultimate Doom, and Doom2, on my xp system. The last time I had these games installed was on an older system. Now I'm having both sound issues in doom2 and no mouse functionality in doom95 and Ultimate Doom

OK...IMHO DOS doom under XP is a lost proposition for several reasons, however let's see what youcan do: if you can still use Windows 98 that would be great, as it still allows to DOS applications to "bang directly on the hardware" like Doom does, while Win XP/NT/2000 just don't, period.

You can try running DOS under XP with an emulator like DOSBOX with full sound and mouse support, but you will get 486DX/33-like performance out of a 3 GHz class machine, and that will be only after a lot of performance throttling.

Some XP configurations CAN run DOS DOOM in a window usually with MIDI music but without digital sound. To get mouse support you'd need to install a mouse.com-like DOS mouse driver. Other configurations, especially with XP SP2, are unable to start vanilla doom at all.

If you need vanilla compatibility and limit respect with full Windows support, then perhaps your best choice is Chocolate Doom and veeeery secondarily Doom95 (Doom 95 however has a bit larger engine limits than vanilla, so it's not a good reference).

[myk]

mikenet2007 said:
Now I'm having both sound issues in doom2 and no mouse functionality in doom95 and Ultimate Doom, I'm sure this might have come up 100 times.

Doom95 uses a VXD to access the mouse, and that's not supported by Windows XP, and Doom2 tries to access the sound card like it would over DOS, which XP doesn't tolerate (the latter is possible with DOS emulation software, but not very efficient).

[mikenet2007]

Do Boom-compatible ports support all doom games, and do the the majority of builders today aim at building maps that are exceeding old limits to get the look they want for there map? Or if I create a map compatible with boom would I lose the target audience where most people find they cant even play the map? Well all this supposing I were to create a serious map.

[Hobbs]

While Boom compatability isn't supported in all ports, I doubt you'd be losing much, if any, of your audience if you make a Boom map. Most of the ports today support Boom, and I'd hazard a guess that people who use the ports that don't support Boom also have a port that does.

If you make a map compatable with Boom though, make sure its 100% compatable with Boom, and not Boom-in-ZDoom. Which is to say, don't test your map with ZDoom only.

[mikenet2007]

Hey man Zdoom is taking ideas from the dukester, lol. Well, its not like the duke build engine didn't build off the concepts of the doom series so perhaps I should hush up, hehe. Good job though modernizing Doom, whoever took the time with zdoom to incorporate stuff like mirrors, security cams, force fields, combo switches, level over level sectors, worked hard. I'm interested to see how those things play out in the game. Cool stuff, Whats Boom all about is it more popular than zdoom?

[Maes]

mikenet2007 said:

Whats Boom all about is it more popular than zdoom?

Let's say that Boom was a sort of "Doom after Doom" or "Doom the way it was meant to be": it basically is Doom-compatible platform based on Doom's source code which can play all standard Doom WADs, plus it removes many of the old hardcoded limits, such as limited visplanes, max. linedef length, and so on. That it also its main use: as a limit-removed for the Doom engine. Many older pre-Boom levels that showed rendering problems with the vanilla .exe, will no longer do so in Boom, and can be thought of as "requiring a limit-removing port", rather than being broken.

It also extended doom e.g. with slots for more color keys, more monsters, more weapons, and an unlimited (?) map range etc. etc.

Any source port claiming to "extend" Doom must at least remove engine limits the way Boom does (compatibility with extra keys etc. is secondary). The degree at which those non-engine features are supported varies, but Boom is a sort of "minimum standard" for modern source ports. Sure, there are some like Chocolate Doom that strive to recreate the original .exe's behavior and limits as close as possible ("bug compatible"), for compatibility/testing purposes.

ZDoom itself is just a superset of Boom: it fully supports it (limit removal and all) plus it has its own settings, scripting and additional non-Boom capabilities like mirrors or slopes.

As a guideline: if you want to make a level 100% compatible and engine-friendly with vanilla Doom, use Chocolate Doom for testing. If you want to make a "normal" level but bigger and beyond the limits of the original doom (that includes linedef length, among others) label it a "Boom" level or as one "requiring a limit removing port". If you want to go further, then there are a ton of different source ports each with its own scripting, slope support and whatnot.

But if you just want to make a level that is merely "too big for normal doom", then Boom is all you need.

[Hobbs]

Its like shitting nails saying this, but ZDoom is easily the most popular port out there. Not to say that everyone uses it, because I can think of clear examples of people who do not, but it is by far the most commonly used of all ports. Making a ZDoom map as opposed to a Boom map is a tradeoff of a few users not playing your map (mostly by choice) for a lot of 'features'.

Maes said:

"Doom the way it was meant to be"

No. This sort of idealism is how port authors get away with fixing bugs and making changes to suit their fancy. I hate for its use to justify certain things with ZDoom, and I hate it now. Doom the way it was meant to be was the 1.9 exe. End of story.

[Graf Zahl]

Maes said:

As a guideline: if you want to make a level 100% compatible and engine-friendly with vanilla Doom, use Chocolate Doom for testing.

Actually, if you do that you might fall into the same trap as when just testing with ZDoom. If the map accidentally depends on one of the countless glitches in Doom2.exe it might not work properly with some source ports or requires messing around with the compatibility options. Best test both ends to make sure that it works everywhere. Most of such conflicts are easily circumvented if you know they exist.

[Maes]

HobbsTiger1 said:

No. This sort of idealism is how port authors get away with fixing bugs and making changes to suit their fancy. I hate for its use to justify certain things with ZDoom, and I hate it now. Doom the way it was meant to be was the 1.9 exe. End of story.

I think they referred mostly to some hardcoded stuff, I mean, not drawing a linedef if it's longer than 1024 or not drawing more than 128 sprites at once is "the way it was meant to be"? Sure, it's in the source code, perhaps they did it for performance or whatnot, but removing those kinds of engine limitations can't be placed in the same category with e.g. adding slopes or port-specific scripting or helper dogs...what would YOU call a Doom without the "traditional" hardcoded engine limits?

[Graf Zahl]

HobbsTiger1 said:

Doom the way it was meant to be was the 1.9 exe. End of story.

Sorry, but I think that even John Carmack would disagree with that statement. Being a professional game programmer myself I know perfectly well what kind of decision making happens in the final stages before a game is released. If it costs too much time bugs aren't fixed - they are merely circumvented. And even known problems are being ignored if they don't have a critical impact on the game's stability.

For post-release updates it's even worse: You simply don't have the time to address all the things you would like to because essentially you invest work without any real chance of revenue so all that gets done is to fix the issues that really need addressing and leave the rest in.

To sum it up: The Doom 'as it was meant to be' doesn't exist - and it won't ever either. All you have is what the programmers managed to do with the limited time they had. And if they had had the time and desire to truly fix the engine you can rest assured it would look quite different from what ended up being the final official release.

[Hobbs]

k. I'll admit that even I am not hard and fast to the idea of doom2.exe being "the way it was meant to be", its more like my first pick (even though I just stated End of story above :P). But Boom certainly isn't the way it was meant to be. Closer than ZDoom, or Eternity, or some others arguably yes, but the real deal so to speak, no. And Maes if you want removal of engine limitations in your twiwmtb doom port I suggest you look towards doom2-plus before you look at Boom.

EDIT: Come to think of it I'm with Graf about the fact it doesn't exist. Not because of what he said, but because of the fact nobody could ever agree :P

[myk]

Maes said:
But if you just want to make a level that is merely "too big for normal doom", then Boom is all you need.

Actually, you have PrBoom with complevel 2 (or 3), and Doom+ for that. Boom is a different story, just like ZDoom or Legacy are. Granted Boom alone is more conservative than these, but it alters the game physics and adds new features. After all, if you make a plain map but test only with Boom (a Boom-like engine or with Boom compatibility) people running it with a plain engine or mode could have problems (this will likely at least affect people who like recording demos), even if you don't include any Boom line types or such.

Graf Zahl said:
If the map accidentally depends on one of the countless glitches in Doom2.exe it might not work properly with some source ports or requires messing around with the compatibility options. Best test both ends to make sure that it works everywhere. Most of such conflicts are easily circumvented if you know they exist.

Right, or if one isn't too aware of the intricacies of each engine, the best thing to do is not to test with only one engine (and of course the target one should certainly not be excluded).

Though, as for "vanilla" editing (or to a degree anything supported by a more encompassing engine), if a new map is going break due to a quirk, so could one made 6 or 12 years ago. In that case maybe the port developers should actually do something about the issue with their code (if they think its worth it.)

Personally if I were editing a standard map and a conflict ensued between pure Doom and a port I'd have to measure the effect of doing without whatever I was adding to the map, perhaps looking for an alternative method if possible, or otherwise reporting the issue to the developers of that engine. If they were to show no interest, I could decide again whether to remove that conflicting feature, or include it, with a note about how that engine will have problems with it (some issues could be critical, others merely glitches or slight messiness).

[Maes]

HobbsTiger1 said:

And Maes if you want removal of engine limitations in your twiwmtb doom port I suggest you look towards doom2-plus before you look at Boom.

Interesting, but it's for DOS, and I have stated above, I'm not a great fan of emulating a kind of 486DX/25 with disproportionately fast RAM and graphics in order to play Doom :-)

Doom+ would be hot like 10 years ago, but not now, not for me at least.

[mikenet2007]

Maes said:

I think they referred mostly to some hardcoded stuff, I mean, not drawing a linedef if it's longer than 1024 or not drawing more than 128 sprites at once is "the way it was meant to be"? Sure, it's in the source code, perhaps they did it for performance or whatnot, but removing those kinds of engine limitations can't be placed in the same category with e.g. adding slopes or port-specific scripting or helper dogs...what would YOU call a Doom without the "traditional" hardcoded engine limits?

I guess its safe to say that doom is doom and boom is boom, lol. Boom as well as zdoom both are improvements of a great game. The original engine will always be most respected but in this day & age I'm all for squeezing every last ounce of editing power from these older game editors. Thats if the map requires it, and apart from sole multi-player maps I say make it look sweet as honey. For Duke Nukem I use Mapster32 over ken Silverman's original Build engine because of the fact there are fewer limits, its more like boom than zdoom in comparison.

The map I've been working on for the last 10 months or so takes advantage of this. It contains 2200 sectors about 18000 walls and just over 5000 sprites. I did go over the extended wall limit of 16000, that was implemented in mapster so I split the map into two. I would show you some pics but I don't see where to upload them. Here are some from my post at 3drealms. This is going to be a futuristic military moon base using both standard duke3d textures and custom textures. My pics are under the screen name mikenet2005, there are pics from others at this thread as well........

http://forums.3drealms.com/vb/showthread.php?t=23360

A bit of my custom texture work is here.....

http://forums.3drealms.com/vb/showthread.php?t=21221

And here are some very old pics, you will notice I converted some Doom2 textures and animation for fun into Duke3d like 8 yrs ago. I had most of the monsters animated, "not programed" also the sprite animated lamps, slime textures and other things, most of witch are not on the Doom pic at this link. Since then a backup was made and all doom2 textures were removed when I decided to turn the whole thing into a moon base. Plus I like being original if I'm going to release a map. Here is a question, could I take a Duke3d ART. file and import it into zdoom??? It would be cool to see some of them implemented in doom for fun.

http://forums.3drealms.com/vb/showthread.php?t=16970

[Maes]

It was expected it would all break down to a religious port war...but however it all boils down to that: if you want to map for classic doom, read documentation about its limits and use oldskool tricks like linedef splitting, where required, and keep the architecture relatively simple. Test whether it breaks the engine or not with Chocolate Doom or vanilla doom.

If all you need is using more linedefs/sectors and longer or bigger stuff than vanilla allows without glitching or breaking and you feel you can't cut down on that, just release your map as requiring "a limit removing port" or just "a Boom compatible" :-D

[mikenet2007]

Ill keep that in mind Ty. I liked what I read about zdoom and I have its features working in the game, but how do you incorporate its new build functionality into Doom Builder??

[EarthQuake]

Doombuilder has various editing configuration settings that you can choose from. You want to use one of the ZDoom configurations, of which there should be two: one for Doom format maps, and one for Hexen format maps (which are more flexible). Note that "Hexen format" does not imply the game Hexen, just it's map format.