DoomNoob

Really hope you don't take down Titans with mechs. If Eternal is supposed to be power fantasy cranked up to 11, I want to take out Titans Kratos-style. Especially if you have the grappling thing, you should be able to get around easily enough.

In Doom 2016 there were all sorts of easter eggs hidden in the spectrograph view of the song files, has anyone already picked them apart for Eternal?

I understand which part it's referring to in E3M8, but what I mean is that I don't hear anything like it (backwards or forwards) in Doom 2016's Mastermind.

I was reading this page https://doomwiki.org/wiki/Doom_(Original_Game_Soundtrack) where it mentioned that, for Mick Gordon's track "Mastermind" from Doom 2016: "Contains several themes reprised from other tracks, including "Rust, Dust & Guts", "Flesh & Metal", "BFG Division" and "VEGA Core". The closing note is the opening note of "Facing the Spider" played backwards." I tried scouring the song for that Facing the Spider opening note but can't find it anywhere. Doesn't seem to be the first note, last note, reverse, forwards, anywhere. Do I just have terrible ears, or is this referencing a specific spot?

I can't find an answer to this on Google but in ZDL what is the difference (besides the obvious) of exporting the .ini versus the .zdl? Is there any reason to pick one over the other? They both seem to capture different things but also with a lot of overlap as well. I can't tell what the intended usage is supposed to be. Do people usually save off a bunch of .zdl's (or .ini's) on a per-wad basis and reload depending on what they wish to play?

Bought wolf 3d second edition and pre-ordered Doom... really wish I could get Doom sooner. If you buy one edition and a new one comes out with fixes do you get an upgrade to the new? E.g. in case Doom gets a second edition too.

I want. Can't get the digital version any earlier?

I've been looking through the Doom source code to get a sense for how things work. What immediately stood out to me was two things: 1. This "fixed_t" data type is used an awful lot. 2. Trig functions are done via lookup table From what I can tell, the fixed_t data type is really a 32-bit unsigned int where the rightmost 16 bits are used to represent a fractional-part numerator (where the implied denominator is 2^16 = 65536), and the leftmost 16 bits represent the actual whole number in question. So a fixed_t is like an encoded form of w + f/65536 where w and f are whole numbers. The actual value stored in the fixed_t data type is basically (w + f/65536) * 65536. Angles in DOOM appear to be done in a way where the unit circle is broken up to fill an entire unsigned 32-bit integer from 0 all the way up to 0xffffffff (0 to just under 360 degrees). So 45 degrees would be 0x20000000, 90 degrees 0x40000000, etc. Once nice side effect being that you can add/subtract angles and you get the modulo / wrap-arounds for free due to the data type used. But then when this angle is actually used for anything involving trig functions, it gets bitshifted down by 13 bits first, mapping us to a range from 0 all the way up to 8192 (providing a resolution of (1 / 8192) * 360 = about .04 degrees.) All that said, if you give me an angle x that's already been reduced to the 8192 range, the corresponding fixed_t value in the sine table should be: floor(sin((x / 8192) * 2 * pi) * 65536) If x = 0 then the result of this should still be 0. But in the table it's actually represented as 25, which means that sin(0) in Doom is really more like 25/65535 = 0.0003814755! I didn't know why this was the case because the output is pretty close to the hardcoded values but not quite there, but by chance found that the values match if I add 0.5 to x first: floor(sin(((x + 0.5) / 8192) * 2 * pi) * 65536) My question is basically "Why?" Why have these values been offset like this? Keeping the table symmetrical while avoiding any possibility of divide-by-zero errors, or something else?

@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.

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.

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.

How do you all like to make wads / make levels / etc? Does anyone ever mess with the Doom source code any? Does it take anything crazy to do something simple like add debug variables to the automap? (As an example)

Which MIDI devices do people like using? Seems kind of tricky to get things to sound similarly among all the different source ports. Right now I'm using SDL with PrBoom but Native MIDI with Crispy Doom because then they sound a little more consistent, at least I think?

Is there a particular reason more people don't just use screenrecorders instead of recording in-game demos if things like desyncs are a prevalent issue?

Last sentence made me lol. Yeah I guess mentally so far I've sort of placed GZDoom in its own sort of category. The impression I get is "use PrBoom+ for all WADs when possible, and GZDoom when it's required," and anything in the latter is sort of confined to its own ecosystem. Is that a fair assessment?