How to make edits to Doom to better intuit the Doom Movement Bible?

In the Doom Movement Bible thread the poster, Linguica, refers to things like tics, numbers with respect to speed, etc, and is even able to add a blue box around the cursor in-game.

How does one do this? I downloaded linuxdoom-1.10 which AFAICT is the Doom source code / decompressed it and can now poke around in the .c files. I imagine Linguica would just edit the automap code to provide the blue box, etc? 

One thing I wanted to do was display debug variables on the screen while I practice things, add that blue box to the automap, etc. I don't know if I could then load these changes into a modern-day source port. Is it difficult to edit / compile the source / run in Linux? Or do people usually compile it and run in Windows using DosBox?

Just curious if this is well-worn territory. It seems like a good project to learn from.

1 hour ago, DoomNoob said:

One thing I wanted to do was display debug variables on the screen while I practice things, add that blue box to the automap, etc. I don't know if I could then load these changes into a modern-day source port.

Don't edit the iwad to do this, edit a source port instead. Afaik, nobody who does "complicated" tricks in doom has that sort of info on display anyway, because the moment your brain has processed what's going on the situation is already a different one (because 35tics/sec). If anything, the best way to look at the game's inner workings is using tools like XDRE which is used to create tool assisted runs, or "read" demos to check for legitimacy. Most things like linedef skips are down to hands on practice anyway. Don't make things more complicated than they need to be, because book-smarts will only ever get you so far. Do some UV-speeds/maxes normally, look for ways to improve by comparing your demo to those of others. As soon as you are at a top tier level of skill you can concern yourself with fine tuning, before that it is a waste of time.

38 minutes ago, Nine Inch Heels said:

Don't edit the iwad to do this, edit a source port instead. Afaik, nobody who does "complicated" tricks in doom has that sort of info on display anyway, because the moment your brain has processed what's going on the situation is already a different one (because 35tics/sec). If anything, the best way to look at the game's inner workings is using tools like XDRE which is used to create tool assisted runs, or "read" demos to check for legitimacy. Most things like linedef skips are down to hands on practice anyway. Don't make things more complicated than they need to be, because book-smarts will only ever get you so far. Do some UV-speeds/maxes normally, look for ways to improve by comparing your demo to those of others. As soon as you are at a top tier level of skill you can concern yourself with fine tuning, before that it is a waste of time.

I agree with you in principle, it's just nice to even be able to know basic things like "35 tics / sec" or what a "linedef" represents and what it can do, or what the speed thresholds are for different axes of movement, or what kinds of events can occur at which times (simultaneous? sequential?), how clipping is handled, etc. Even if not familiar with the fine tuning it's helpful to have some kind of birds-eye understanding of how the engine works so that when I do copy a run I have some understanding of what's happening.

For example if I have the parameters for how the engine handles movement I should be able to mathematically derive SR40 / SR50, etc.

1 minute ago, DoomNoob said:

what a "linedef" represents and what it can do

linedefs are the edges of sectors. you can't have sectors without linedefs. Had you read the editing tutorials like I suggested to you already, you would have known that. What linedefs can do depends on what action is assigned to a linedef, if any at all. What actions you can assign depends on map format used.

3 minutes ago, DoomNoob said:

or what the speed thresholds are for different axes of movement

that is what the doom wiki and the movement bible are there for, and you don't need to extract this info yourself, people already did that.

4 minutes ago, DoomNoob said:

or what kinds of events can occur at which times (simultaneous? sequential?)

in vanilla there are limits to how many sectors can " move" at once (important for crushers, I guess), and basically anything limit removing can make it such that your computing power is the limit. How many "events" can occur also depends on how many monsters there are active at any given time, and whether or not you consider an attack by a monster an event or not.

7 minutes ago, DoomNoob said:

how clipping is handled, etc

Max height you can clip upwards per tic is 24 map units, that's why you can't climb up anything higher than that, which makes this limit an integral part of how maps work.

8 minutes ago, DoomNoob said:

For example if I have the parameters for how the engine handles movement I should be able to mathematically derive SR40 / SR50, etc.

and what's the point of this? SR40 is slower than SR50, but while doing SR40 you can still turn. SR50 locks your movement in a straight line unless you let go of whatever key you assigned to "strafelock", and therefore end SR50. And besides, people already worked out how fast SR40 and SR50 are in terms of map units per second, so there is no need for you to do that either.

@Nine Inch Heels (I do know what a linedef is -- I was just posting it as an example)

I know there's no need to do some of these things, but it's just my own approach to learning where I like being able to derive/discover things hands-on to confirm / understand the context of the results.