Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

DoomNoob

Members
  • Content count

    40
  • Joined

  • Last visited

1 Follower

About DoomNoob

  • Rank
    Green Marine

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. DoomNoob

    Stupid question about ZDL

    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?
  2. DoomNoob

    Game Engine Black Book: Doom

    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.
  3. DoomNoob

    Game Engine Black Book: Doom

    I want. Can't get the digital version any earlier?
  4. 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?
  5. @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.
  6. 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.
  7. 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.
  8. 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)
  9. 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?
  10. 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?
  11. 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?
  12. Hmm I don't see such an option in Crispy Doom... unless these max demo issues are just resolved by default in Crispy, PrBoom, GZDoom, etc? Only issue being that if someone were to replay that demo back in regular Dosbox Doom it'd crash or be unloadable, etc?
  13. Just trying to experiment and get a feel for what works well for classic DOOM because keyboards have changed a bit from the days when the game was originally designed. For example, on my laptop, the arrow keys are quite tiny and unsuitable, whereas back in the early 90's we were all playing on desktop computers with the full-sized keyboards and big arrow keys. What do you play on? 1. Separate keyboard? Laptop keyboard? 2. Keyboard only? Keyboard + Mouse? 3. What key bindings? How do you prefer to strafe? Move around? Fire? Open doors / use switches? Cycle between weapons?
  14. Very interesting... thanks for the detailed explanation. I also noticed this in the readme: From https://doomwiki.org/wiki/Parameter I see that: Why might a big map have anything to do with a specified max demo size? I assume people set a huge value for recording full playthrough but then somehow big maps break something during recording? Is it saying that it's only a problem for reaaaallllly long runs where you're trying to kill everything? What value would cause such a break?
  15. After reading that, I guess I don't see why such dehacked edits aren't part of the custom loadable wads to begin with
×