PrBoom+ 2.5.1.4 - ssg bug

I've noticed a recurring bug in prb 2.5.1.4 with "default" complevel mode in menu (not sure about other complevels) where the ssg pellets will not register with monsters - it seems to shoot through them. This has happened enough times that I could definitely get a demo of it occurring. I feel like I've noticed this in Crispy as well. Is this a vanilla bug? I don't see it mentioned on the wiki but it could be under a different name?

 

It's a blatant bug, I'll be very close to enemies and a full ssg blast to the face won't register at all. No blood and I think I can see the bullet puff behind them.

 

Anyone know what causes this or the name of the bug?

This could be what you're experiencing: https://doomwiki.org/wiki/Flawed_collision_detection.

 

10 minutes ago, bradharding said:

This could be what you're experiencing: https://doomwiki.org/wiki/Flawed_collision_detection.

 

 

That sounds like it. It's worded strangely though "a hitscan attack will pass through its target if it does not enter the block in which the center of the target thing is located." That makes it sound like you need to be within the block for hitscan to register which is obviously incorrect. Does it mean that if your shots hit the target in block A but it's center is in block B the shots don't register? I have noticed the issue the most with pinkies so that would make sense.

On 5/18/2019 at 2:03 AM, xvertigox said:

Does it mean that if your shots hit the target in block A but it's center is in block B the shots don't register?

Close. Your shots actually never get a chance to hit a monster in block A, because, to the engine, the monster simply isn't in block A., so, to the engine, there's nothing to hit in block A.

 

Some trivia: Original arcade games Pac-Man and Ms. Pac-Man had a similar bug that allows you to rarely pass right through a ghost without dying. The ghosts are drawn using a hardware sprite engine with pixel accuracy, but the game board is a rather coarse grid made up of cells that are about as big as the text characters, and the ghosts. Each object on the screen is in one and only one grid cell at a time, and, if you time it exactly right, Pac-Man and a ghost can simultaneously exchange cell positions within a frame, totally bypassing the collision detection, which is cell-based!

 

Every time it has ever happened to me, I end up getting killed anyway, because I flinch in shock, and end up turning around and running back into the ghost :)

That makes a lot of sense. What an annoying bug lol. Presumably this is fixed in some source ports? Was this done but rewriting the blockmap code entirely or by a fix?

 

I find the workings of the Doom engine very interesting since I know the game intimately however I lack any real programming experience. Have you read/would you recommend Game Engine Black Book: Doom ?

 

Edit: Looking at the blockmap page in the wiki; do ports that fix the bug check the block the thing is in and also all adjacent blocks?

Edited May 21, 2019 by xvertigox : https://doomwiki.org/wiki/Blockmap

3 hours ago, xvertigox said:

That makes a lot of sense. What an annoying bug lol.

It can be annoying at times. Often, though, it goes largely unnoticed, with some glaring exceptions. ZDoom was one of the first ports to fix it. But, it's a controversial fix. Here's why:

 

id Software tweaked all the weapons, monsters, ammo, and levels with this bug being present. Fixing the bug makes more bullets hit the target, and makes monsters *a lot* easier to kill.

 

When a clean shot misses due to this bug, except in some obvious situations, it could be argued that the player's aim was just not as good: they're hand was unsteady, the bullets didn't penetrate, whatever. In the large scheme of things, the bug is essentially part of the randomness/damage calculation, and fixing the bug makes the game a lot easier, which is not really acceptable to me.

 

Because of this, I have not fixed the bug in my source port (yet), as my port is concerned with preserving the vanilla feel to a large extent. But, I will say this: If I ever do add an option to fix the bug (I've considered it), I will be inclined to compensate by lowering the amount of damage done, or something similar, to try to balance it out. Basically, I'll contrive some test level, and shoot 1,000 monsters with the fix off, then on, and count the # of bullets spent vs. the damage ratio, and adjust damage calculations to try to make both of these match as closely as possible. I cringe at the thought, but I cringe more at the thought of making Doom twice as easy by fixing this bug. It's not a problem for Total Conversions, but, for Doom games? It's not so easy to decide what the Right Thing to Do is.

 

3 hours ago, xvertigox said:

Presumably this is fixed in some source ports? Was this done but rewriting the blockmap code entirely or by a fix?

 

I find the workings of the Doom engine very interesting since I know the game intimately however I lack any real programming experience. Have you read/would you recommend Game Engine Black Book: Doom ?

 

Absolutely recommend both the Doom book and the Wolfenstein book - you really want both, if you want either. The Doom book expands on stuff learned in the Wolf book. These were both very enjoyable, and they provide lots of interesting info about the hardware back then, as well as lots of stuff about the software. This info is compiled in a rather unique way, from my perspective.

 

But, to understand Doom on the next level, you've got to study the source. In fact, this just might be a great way to start to learn programming, if you're interested. This method is especially good, because:

• Doom is a topic that you are really interested in
• You will recognize things in the Doom code that you've known all along

Even without programming experience, check this out:

//
// A_TroopAttack
//
void A_TroopAttack (mobj_t *actor)
{
	if (!actor->target)
		return;
				
	A_FaceTarget(actor);

	if (P_CheckMeleeRange(actor))
	{
		int damage = (P_Random(pr_troopattack) % 8 + 1) * 3;
		S_StartSound(actor, sound_claw, SF_NORMAL);
		P_DamageMobj(actor->target, actor, actor, damage, DAMAGETYPE_SCRATCH);
		return;
	}
	
	// launch a missile
	P_SpawnMissile(actor, actor->target, mt_troopshot);
}

Now, this is not vanilla code, but, by the name of it, you can tell it's for the Doom imp (Troop). You can identify some of what's going on, just by reading the function and variable names:

• FaceTarget
• CheckMeleeRange
• damage
• StartSound
• DamageMobj
• SpawnMissile

This can immediately bring your Doom knowledge to the next level. For example, from the 'damage' line, you can learn that a imp scratch does 3 to 24 points of damage (8 * 3). And, if you become interested in programming, you can research the keywords, like "if", "return", "int".

 

Actually, if you find a source port, and you learn how to compile it, you could immediately double the scratch damage by changing * 3 to * 6. Or you could make the imp fire a baron fireball! Sure, you can do that with DeHacked, but this is just the tip of the iceberg.

 

My point is that, because it's Doom, it carries it's own excitement. Coming up with cool ideas can spark the quest to learn more and more about the Doom code, and coding in general. And, there's lots of places where you can do simple modifications like I described above. And, you can move forward from there. Also, many source port authors add elaborate comments in the code, when they make big changes. These comments can also help make the changes easier to understand. I encourage you to try, if you're interested - it can be very rewarding!

 

3 hours ago, xvertigox said:

 

Edit: Looking at the blockmap page in the wiki; do ports that fix the bug check the block the thing is in and also all adjacent blocks?

Yes. Actually, I think the port carefully adds monsters to multiple blocks - each block that partially contains the monster. And, this is adjusted whenever the monster moves.

 

@kb1 That again makes a lot of sense. Some of those functions I've seen called via DECORATE so it'd be interesting to see how it's done in vanilla. I'm going to pick up the Wolf3d and Doom books for sure.

 

I understand some programming concepts but I've never done anything enough in one language to know one particular syntax very well. Is there a port you'd recommend digging through? Choc? Is the Doom source itself compilable and runnable? I know there was an issue with DMX but was that replaced with SDL? I don't even know if that makes sense tbh but I feel like it does.

 

In regards to fixing the bug - I thought the same thing, it shouldn't be fixed as a blanket change as it alters the balance so much. I wouldn't mess with damage to compensate either, personally, because that messes with the players learned expectations (7 ssg for baron, 3 for manc etc). I think it also adds a bit of flavour and classic charm. I could see this being a cvar though.

 

I'm sure I've asked you long ago but what's your port about? I gather it's aiming to produce a vanilla experience. Did you write it as an exercise and fun or were you trying to fill a personal niche?

 

QuakeC is another thing I've peripherally thought about. The types of modifications you can do there similarly noticeable due to familiarity.

I would preface everything by asking you to make sure you know what you're getting into. Programming is a life-long battle, where you're constantly learning and progressing. It's not for everyone. It takes a certain mindset. Particularly, an insanely sharp focus, and, almost a stubbornness. The computer doesn't care how difficult something is, and it absolutely will only do what you want, if you explicitly tell it exactly how to do it :)

 

On the other hand, it's massively rewarding when you actually get something working!

 

As far as which code to use: The C language can be unforgiving, but one nice thing is that it has very few keywords, so you can jump in and get started rather quickly. It's pretty easy to figure out the syntax. It's like Doom: Easy to learn, difficult to master.

 

Here's what I suggest: Find the simplest Doom port that you can get to compile. This can be harder than it sounds, because you have to find a development environment and compiler that can read the source port's code, and compile it without errors. This is complicated further by libraries (pre-built or pre-compiled portions of code, like sound and music code, network code, etc.). Libraries are code modules that generally you don't modify - you download them and use them as-is.

 

You may need to ask the developers exactly what tools are needed to compile their source.

 

Try to start with a simple, more vanilla port. These tend to be smaller, and less complicated, which is better for learning. Often, you will find that you can upgrade portions of your code, using code from other source ports.

 

Post-compile

Once you get a port to compile:

• Smile! This is when it starts to get interesting!
• Make a backup of everything, by copying it to another folder. Name the folder "MyPort_2019-05-22", using yyyy-mm-dd format (because it sorts perfectly). Get used to doing this after every significant change. Don't worry about the hard-drive space. When you need to revert some badly-working code, you NEED it!
• Run the port, and learn what it can do, and what it doesn't do.
• Go to p_enemy.c, into one of the monster functions. Change a number of something you understand (like damage amount).
• Create a log file, and mark this change. Include what you changed it from, what you changed it to, why you changed it, and what the effect was. Get used to doing this ALL THE TIME. You'll need it later, trust me.
• Compile it, run it, and see your change in action! You've just programmed Doom! (Now, put it back!)

What's next, short term?

• Go buy a good book on C (Yes, a physical book, not an online course.) You can read the book on the crapper, in bed, on the bus, etc.
• Also, check out online resources.
• Compare your source to the original Linux distro. Also, compare your source to other source ports. Try to understand the changes that have been made, why they were made, and what the changes do.

What's next, long term?

Write down a handful of goals for your port. These should be realistic, attainable, tangible goals. Don't write "Make Doom awesome" - that's useless. A good example: "Make fireballs translucent." Another goal: "Add look up/look down via y-shearing". Here's a good one: "Make an option that fixes the bad collision detection."

 

I can't stress this enough: To be able to learn programming, you must have a set of goals to accomplish. You must have specific needs - these will drive the direction of your learning. Instead of having to learn everything, for now, you just have to figure out: how do draw translucently, how to get your port to load a translucency table, how to write new drawing code that will draw your new fireballs. Knowledge builds upon knowledge, and necessity is the mother of all invention.

 

And, sure, you can find the code to draw translucent in many source ports. But each one does it a bit differently. PrBoom+ uses a 64k translucent lookup table. ZDoom uses a bizarre 8k table, with a color pre-sort algorithm that allows colors to be "added" together quickly.

 

It's okay to "borrow" translucency code, or any other code. It takes programming skill to be able to add code from other ports. You will learn something from it. Of course, you should try to understand the code you add. If you break your code, you can always go back to a previous version.

 

Work slowly, and thoroughly, and do your best to avoid frustration. Rome was not built in a day. What's cool is that you'll be learning a skill, and possibly building a career, working on something you love! Pretty cool, huh?

 

And, because it's Doom, you can get plenty of ideas and help right here in the forums. Give it a shot, and see if you can handle it (again, it's not for everyone, which is okay.

 

22 hours ago, xvertigox said:

 

QuakeC is another thing I've peripherally thought about. The types of modifications you can do there similarly noticeable due to familiarity.

QuakeC is pretty neat stuff. But, it's only for Quake, so it has limited application. You're better off learning a standard language, I think.

 

22 hours ago, xvertigox said:

I'm sure I've asked you long ago but what's your port about? I gather it's aiming to produce a vanilla experience. Did you write it as an exercise and fun or were you trying to fill a personal niche?

My port? It's...unreleased, which means that, currently, it doesn't do anything :)

 

Based on your question, I'd clarify as follows:

KBDoom aims to be *able* to provide a vanilla experience, as for this to be the basis upon which everything else is built. You should be able to turn off all custom features, and be left with a completely vanilla game. However, the port provides heavy modding capabilities, with the ultimate goal to provide those capabilities in a way that is easy for other ports to adopt.

 

So, strong points:

• Vanilla/Boom/MBF demo-level compatibility
• Performance
• Mod support
• Compatible extensions
• Strong SP/Coop/DM
• Internet play
• P2P and CS networking
• Big focus on fun

It's always been about fun - fun to play, fun to code. And, yeah, I have my own vision of what I want out of Doom. I'm big on player options, so I imagine a lot of other people will like it too, if I can ever get back to it, that is.

 

 

So, yeah, get in there and hack up a mod, and I'll check it out :) Have fun!