Marscaleb

Is there a way to disable the normals from being displayed on the map? By which I mean: that short line that sticks out of every wall-line to show which way is the "front" of the wall. Can I turn that off? I know you it's important, but sometimes its in the way. Also, is there a way to not display the nodes? Or any sector line that is flat to adjacent sectors? Basically like, a way to display the lines as they are shown in the auto-map in-game, but with textures and lighting?

There's an automap mode in Doom Builder? I can't find it... I just did a search and found a video where someone used that mode, but it was tied to a button I don't have. Am I using an outdated copy, or is there some option that has hidden that toolbar?

Because what I'm trying to do is examine the geometry in a more pure state. I'm not talking about permanently disabling everything. But the extra lines and boxes get in the way of seeing the lines themselves, especially in tight regions.

Okay, I know that this is really just a matter of taste, but I just find Doom so much more fun to play than Heretic. But that said, I SHOULD like Heretic more. I like Heretic's theme better, and I'd rather play a game where I run around a fantasy world than one where I run around military bases. Heretic has some more interesting powerups and you can even activate them when you need them. But yet, I just have more fun playing Doom than I do Heretic. Even though I've played Doom so much more and neither Doom nor Doom II have many surprises left for me, I am more enticed by the idea of playing through Doom yet again on a new system than to play through Heretic. And yes, this is all just a subjective thing, and I'm not going to knock anyone who thinks Heretic is more fun. But still, I can't quite put my finger on why I like Doom more. Any thoughts? What is it that Doom is doing better than even Heretic, a nearly identical game (mechanically speaking) just can't quite do as well?

Heretic seems to make more use of strong saturated colors, especially for things like all the powerups that are all over the maps, projectiles, enemies, etc. Wheras Hexen doesn't use as much of the "bright" colors, the vibrant reds and the vibrant greens etc. But when you really compare the two, Hexen puts a lot more subtle coloring into its art. A slime-covered wall in heretic is a grey wall with big splotches of bright green slime. A slime-covered wall in Hexen is a grey-ish green-ish wall. So I get why someone would say that Heretic is more colorful than Hexen; you really have to look closely to see the more refined use of color that's going on in Hexen. But once all the enemies are killed and the power-ups are collected, the Heretic maps start to look more drab and dull than the Hexen maps do. I'd love to see them release some sort of remastered version. It doesn't need updated graphics, but an updated interface would be nice. Even just a version that plays nice with modern systems would be nice. Hell, I'd even settle for a DOS-Box version that comes from a legitimate site that I'm not worried is going to give my computer herpes.

Perhaps the problem is that it doesn't have enough muddy colors. For a medieval setting, you are going to have a lot of stone textures, and they only have their basic grey for regular stone, and then a tan-brown for alternate stones. So most of the game is just a basic gray. Compare that to the Hexen palatte, which retains most of the same colors, but shortens the vibrant colors (used mostly for magic effects anyway) and gives some more muddy colors. And the Hexen textures used those to add little pieces of detail to the textures. Of course, Hexen had fewer levels that were supposed to look like they were in a castle and more that were "outside" so the game doesn't look as grey, but still. Compare that further with the Hexen II palette and the vibrant colors are almost non-existant. There are four colors with four shades for some full-bright magic effects, and after that only the red and gold colors even get bright. But then again, ShadowCaster has even fewer muddy shades than Heretic, and nobody ever complains about that game's aesthetics, so what do I know?

That's what we need for Heretic mods, some weak fodder enemies! Though I never considered the chaingunner to be fodder; he may have only 70 HP but he will f*** you up hard!

That made sense in Karnov on the NES. It doesn't make so much sense in a game that uses a keyboard. (But it is good to know; thank you!)

Yeah but it becomes a problem when you are trying to navigate that stuff in the heat of battle. Sure, selecting a tome of power right before a tough section is good, but I rarely selected anything other than a quartz flask just so that I could hit that in the heat of the moment. Vanilla Heretic didn't let you bind artifacts to specific keys, and that was a HUGE problem. I would have used the inventory a lot more if I didn't have to always keep the health queued up to use in an emergency. Compare that to Duke 3D, which did a similar inventory system, but also had hot keys for all the items. When I needed that portable med kit, it was always one button away. (Not to mention, I could actually turn off the jetpack and save it for later.) In my opinion, the inventory in Heretic was basically useless because I couldn't *really* use stuff whenever I wanted it.

I'm glad someone else noticed the palette. The palette in Doom is honestly not good. All of Id's games seem to have problems with their palettes, really, except maybe for the first Quake. Ditto. Because the two games are so compatible, I kind of want to be scientific about this. I want to try some wads that swap content between the games. People keep bringing up the weapons. If you played Heretic with Doom's weapons, how would it feel? People mention the aesthetic. Well, how would the maps look if you kept the layouts the same, but re-textured them with Doom's textures? (Can't just do a simple swap, you need to replace them intentionally.) Or perhaps take it the other way; start with some classic Doom maps, re-texture them with Heretic/Hexen art, and replace the monsters/weapons with Heretic ones. Is it still a fun map design? And then start swapping things back and forth. How does it play with Heretic monsters and Doom weapons, or with Doom monsters and Heretic weapons? Also, I will definitely admit that the sound design in Heretic is lacking. It demonstrates clearly how much sound design plays into a satisfying experience. The crossbow shouldn't sound like a shotgun, but it just isn't as satisfying to hear that soft "whipp-peh!" compared to that deep guttural "K-CHOOM!" (The same comparison can also be made to Doom 3's plasma rifle. Pitiful.) And the dragon claw, wow, that's a horrible sound. That said, the sounds in Hexen are some of the best I've heard in any video game. I don't know what happened to Raven between those two games.

I was curious about how the monsters in Doom calculate how to reach the player. I'm reasonably sure that Doom doesn't use true pathfinding code, given the processing power they had to work with, and how you don't have to lay out paths in the levels. I was watching a video that explained the basics; it finds the eight-way direction closest to the target, it moves in that direction until it hits something or runs down its move counter and then it recalculates it's direction. But I don't get what a monster does when it hits an object in its path. If a monster wants to move forward, but it detects that it will hit something, what is it doing to determine where it should go instead?

So wait, it doesn't actually detect that it has passed the player? The video made it sound like it could turn before its move counter hits zero.

Something else I've thought of that I don't get about this code. If an enemy walks past the player, it turns around. How does it know if it has walked past the player? I mean otherwise the player could easily walk around in circles around a monster. Perhaps not perpetually, but often enough the move counter would get set to a high enough value that a simple side-step could have a demon keep walking in the wrong direction for a long time. So how does the code detect that it has walked past the player?

I would. It just seems disconnected from the experience people were going for. Look at it outside of the code itself. If you were playing any kind of shooting game and you shot an enemy and they didn't react, wouldn't you think it was a bug?

What could cause them to be set to NODIR at this point?

Okay, I get it now. Honestly I'm pretty impressed; the one designation of not allowing them to choose a direction opposite of their current movement is such a tiny little thing, and yet it enables them to follow corridors. How did anyone think that up? Or was it just some sort of happy accident... I'm still a little curious about some other things. This is more about the specific code than the general process, but I'm wondering how they determine "second best option," or rather, how they determine that with optimal code. I can't think of how to do that without running a massive series of if statements that check all eight directions. I think I found the code that does this in P_NewChaseDir. I see it creates an array just called "d" (which it gives an array length of 3 but only uses the second two?) and it sets one to be either north or south and one to be either east or west. (I'm guessing a quick check of player position being greater or smaller in X and Y?) But I don't understand the logic of what it is doing; how it is quickly determining each possible route to the player and whether or not it is viable.

I did this, and I noticed several things. First of all, I noticed that if the player is just a little further forward they will manage to navigate through the long corridor all the way to reach the player, which is really what makes the AI "feel" more intelligent, because it (sort of) can navigate through the map to reach the player. If the player is south enough in the first room, then if a monster randomly shambles into the wall at the very tip of the hallway they recalculate which way to turn, and move south to face the player. But if the player is just north enough, when they hit that wall they turn north, and then they follow that wall all the way around and find their way to the first room. I also noticed that when a monster finished following a wall it tries to find the player again, which can produce a little random walking. It will quickly find its way to the next wall and follow it. But the key element here is that it is not actually tracing the whole curved path to the player, just following one wall at a time, which is going to lead the monster to find the next wall. I also noticed that while the monster randomly shambled around int he big room, sometimes they would bounce off a wall and then walk due east, (the exact opposite direction of the player,) and continue in that path perpetually until they hit another obstacle. They never get triggered by moveCount getting decremented again. So now I am left with wanting to understand these factors: One, how are they determining to follow a wall? What makes them decide to follow a wall instead of just trying another (random?) angle that might lead them to the player? Two, once they are following a wall, how are they tracking this wall? What are they doing to check if they've reached the end of the wall? Three, why are monsters sometimes walking due east into perpetuity? Off hand I wonder if they are trying to follow the wall, but since that wall is at an odd angle, they try to follow it moving straight north, bump into it and change their angle, but now are moving away from the wall in a way that they can never detect that they have reached the end of this wall. But this is pure conjecture since I don't understand the first two points I mentioned.

That video gets right up to it, but I'm missing something there. If it hits something, it has to pick a new direction. If the player is still standing where the closest angle to the player moves the monster into a wall or something, what does it do then? The video shows it walking the length of a wall and says that it turns around when it gets to the end of the wall. How is it determining that it had reached the end of the wall? And then what does it do at that point? Is it trying to move to the other side of the wall? In the video there is a gap in the wall, and if the pinky moved forward just a little bit to try to continue following the wall it would get around the wall and be able to reach the player, but if it just recalculates the angle closest to the player then it would turn around and walk the length of the wall again. And if the wall was very short then the pinky would get stuck perpetually walking a very small obstacle unable to cross it. I'm trying to understand how games programmed such behaviors back in the day. This was before we had modern pathfinding and nav mesh stuff; heck this doesn't even have path nodes like in UT99. I want to understand the logic they used to keep monsters from being stuck by simple obstacles. I tried looking at the source code, but I'm more familiar with C# than C++, so I don't quite follow the commands.

I am very interested in the prospect of being able to create maps in Doom Builder and then import them into Unity for projects I am working on. Just today I was thinking of something and trying to decide if I wanted to make it in Unity so I have greater control of various custom elements, or if i would rather build it in GZDoom so that I could create levels and other content faster. So yeah, I'm very interested with the idea of being able to port over Doom content into Unity. Is there support for maps with enhanced engine features, like slopes and room over room? Or even just poly objects? Do I have any capacity to edit the meshes it creates for level geometry? By any chance, can the level geometry work as a ProBuilder mesh, so I could adjust the geometry within Unity? I am also curious how much if this project is something I can legally use for a commercial project. Like if I tried to port over a project with an original iwad, would I be able to use the code for monster AI? Or what about the code for movement, animating sprites, and all the other things that technically needed to be written anew for Unity?

I'm looking for a mod for Hexen that just delivers some stronger weapons; something to make the player OP. But just a weapon mod, nothing that would change anything else from the Hexen experience. Any recommendations?

There are some crazy-awesome features that people have added to doom source ports, especially within GZDoom. I'm wondering if baked static lighting has ever been one. Like how lighting works within Quake 2 and UT99, individually-set lights that are calculated in 3D space and stored into light maps. I know there are several ports that support dynamic lighting, and you could use that to create something that looks pretty good. But static lighting is easier on the system, and I like to keep things so they can run on weaker systems. Plus, I haven't seen dynamic light support sunlight/directional light.

What ports support the lighting style from Doom64? Where it isn't just a sector color but you have them divided between various elements. ..Actually come to think of it I really just care about the gradient effect Doom 64 has between the top wall and bottom wall coloring. So obviously Doom64 EX supports this. And there is whatever fork that Doom 64 Absolution was made in, but that whole mod is basically irrelevant because of Doom 64 EX. But... Is that it? I recently saw some post somewhere where someone was making a new version of Doom Builder, and one of its many features was that it supported the Doom64 lighting. I can't fathom why someone would put that in their editor unless some other ports are starting to use it.

Sorry, I said that wrong, but also found that what I was upset about was also wrong. I revoke my qualms against GZDoom.

Huh? Even if I assume you meant "additive" then I'm still confused, because I don't recall that being a property within Doom 64. Thankfully it was easy to find in my history. https://forum.zdoom.org/viewtopic.php?f=232&t=66745 Hmm, GZDoom and all of its forks have really grown overly-complex, but I guess it is the most popular one for that reason.

That sounds like something that could be relatively-easily fixed. Once the lightmaps are calculated, save them in an external file. Include some simple checksum info so it can make sure the lighting is accurate to the map file. Since the lights aren't part of the original maps anyway, it would just be something to distribute with map. Even if there are compatibility issues, I should only need to calculate that lighting once on my end. Granted, this is something that I know almost nothing about, but it still *seems* like that would be easier to program than everything else involved in having static lighting. At any rate, those Vavoom screenshots look fantastic! The GZ fork looks great too, but those Vavoom ones actually match the visual quality I had in mind. That being said, Vavoom is irking me right out of the box for its lack of proper widescreen support. And I can't find where to download a compiled binary of K8Vavoom. Also, where could I download those sample maps that use the static lighting?