RadiusDebug - Actor radius (hitbox) tool (18/05/21 update!)

[Nash]

18th May 2021 Update
- Added menu option to toggle radius debug on several kinds of actors
- Fixed RadiusDebug.Disable(), it actually works now
- Added "actors infinitely tall" support
- Relicensed to MIT

Download in first post

To the 1 person who downloaded it: please redownload. I fixed a minor issue.

[Velaron]

When I try this on the latest version all it does is drop my FPS to single digits. Also would be useful to add some keywords like "hitbox" to the post, because I honestly couldn't find a mod like this because I was looking for the term hitboxes.

Actually, I managed to spot a single pink box for a frame, but after that the FPS just keeps dropping below 1 without me doing anything.

[Nash]

Added some words to help with the search engine.

I'll look into improving the performance improvement as soon as I can. Sorry about that!

[Sir Robin]

This is super useful! Thank you for creating and posting this.

I want to make it use a different color for non-solid actors. I'm looking at the files, I see the model file and the texture file but I don't see where they are associated. I'd like to create a second model def with a different color texture, then I can assign the proper model to the actor depending on whether it's solid or not. But I don't know how to do that.

As for optimization, a quick way to reduce work is to only do it when an input has changed. So I throw two new variables into class RadiusDebug:

Code: Select all • Expand view

   double rLast;
   double hLast;


and then I do the sizing like this:

Code: Select all • Expand view

         if (r!=rLast || h!=hLast)
         {
            A_SetSize(r, h, false);
         }
         rLast=r;
         hLast=h;


[Kzer-Za]

I'm looking at the files, I see the model file and the texture file but I don't see where they are associated. I'd like to create a second model def with a different color texture, then I can assign the proper model to the actor depending on whether it's solid or not.

Look at the modeldef.txt file. It references (includes) _models.txt in the very same folder as the model and skin file https://zdoom.org/wiki/MODELDEF

Concerning performance: must be something specific to the actor that Velaron was testing. I don't see any performance issues on my PC, which I assembled about 10 years ago, and even back then it was far from being top-tier.

Edit: looked more carefully at the _models.txt, and yes, it doesn't reference the skin file. Seems that the line assigning the skin can be omitted if it has the same name as the model, I didn't know that. Anyway, you need only to create a second definition, which is the copy of the first but with the skin line in it. Let's say, you create a second skin that is blue and name its file RadiusDebugBlue.png. Then the line should be Skin 0 "RadiusDebugBlue.png".

[Sir Robin]

Concerning performance: must be something specific to the actor that Velaron was testing. I don't see any performance issues on my PC, which I assembled about 10 years ago, and even back then it was far from being top-tier.

I didn't do any performance testing myself, I just saw in the comments it mentioned that the A_SetSize can be expensive, so I threw that in there.

you need only to create a second definition, which is the copy of the first but with the skin line in it. Let's say, you create a second skin that is blue and name its file RadiusDebugBlue.png. Then the line should be Skin 0 "RadiusDebugBlue.png".

Done! Color coded:
Red: Monsters
Yellow: Shootables
Green: Solids
Cyan: Pickups
Blue: Drops
Magenta: Everything else
White: Unused
I'm sure that a menu options panel could be created to customize that, but I'll leave that as an exercise for the next person.
here it is

and a screenie:

---

[Sir Robin]

If anyone is concerned with performance, I'd take a look at this:
In the event handler, every call to WorldThingSpawned past the first tic is calling UpdateRadiusDebugMode(). That function calls ClearRadiusDebug() and then DoRadiusDebug(radiusdebugmode) so it's essentially destroying all the radius debug models and rebuilding them every single time.
So when does WorldThingSpawned get called? Any time:
A hitscan weapon is fired and bullet puffs and/or blood splats are spawned
A projectile weapon is fired and a projectile is spawned
A projectile such as rockets are active which constantly spawn trail puffs
Any other spawns, for example pain elementals spawning skulls

So anytime any of those things happen, the entire set of radiusdeug models are destroyed and recreated. For people seeing performance issues, that's what I'd guess might be causing it. To verify, check your performance doing nothing vs something that constantly generates spawns, such as shooting chaingun, plasma rifle, or rocket launcher.

[Nash]

Yeah, that's exactly it. I just don't have free time right now (I'm on vacation). As I said a few posts up, I will be fixing it and uploading it as soon as I can!

[Sir Robin]

Yeah, that's exactly it. I just don't have free time right now (I'm on vacation). As I said a few posts up, I will be fixing it and uploading it as soon as I can!

No worries, enjoy your vacation! I was just pointing that out to anyone that wanted to look into the performance issues. I haven't tested it extensively but I'm not seeing any issues on my very-crappy-non-gamer system.