Quasar

Members
  • Content count

    7601
  • Joined

  • Last visited

About Quasar

  • Rank
    Moderator
  1. https://gifsound.com/?gif=https://i.imgur.com/7nYKUBP.gif&v=vZCCR-btg3o
  2. Almost certainly. Both fields are in the mapsector_t struct, though I have yet to figure out the meaning of the SPU control field's values in PSX. The lighting field is a byte index (0-255) into the LIGHTS lump. If you've isolated the assembly for P_LoadSectors, I'd be happy to post the MIPS ASM from the PSX version for a direct comparison.
  3. Doom's BSP data is entirely independent of the rest of the map, which is necessary considering you first need to make a map in order to apply a BSP tree builder to it. While it's unclear what kind of data Southpaw is using in place of Doom's BSP, it's bound to be something similar, and it is likewise independent. So, you don't need to know anything about it in order to extract the important bits (vertices, linedefs, sidedefs, sectors, and things) of the maps.
  4. http://eternity.mancubus.net/ee-old/
  5. Sourced? Specific examples will be appreciated.
  6. Fun fact: Strife Veteran Edition has a kerning table that's used at run-time for its big font, which I worked together on with ptoing.
  7. Effectively, we let Mac OS monopolize the music production industry, and that's why. Just about anybody in music production is doing it all on Macs even to this day. So MIDI is unimportant anywhere else platform-wise. The whole "hard drives got bigger" thing immediately shows you why - if people thought MIDI was meant for listening to music from your computer, that's about 1/16th of what it's actually useful for. MIDI is actually a synthesizer control language and data transport, to tie together musical instruments. Since nobody wants to do that with a Linux or Windows PC, why should those OSes bother supporting logical concepts like MIDI ports or devices? Or so goes the thinking of those with a say in the matter. Those of us that actually did have interest in using our PCs this way have gotten the big fat finger over and over again.
  8. I intend to stick with 7 for the foreseeable future. I like my OSes to be OSes, and not "services". I don't need a billion and one processes hogging up RAM to collect information on everything I'm doing and ship it off to Microsoft. I don't need an AI voice talking to me to use a computer efficiently. I don't want or need MS's cloud storage "solution." And I definitely don't need any more slippery-slope features that are gradually amounting to turning the PC into Microsoft's wet dream of a walled garden environment like iOS. No thanks. Of course I've had Windows Update disabled for a long time in Win7 now, ever since MS turned it into a malware delivery service with the pre-10 launch bullshit. Sometimes you can't win for losing.
  9. Independent volume control for the MIDI synth.
  10. He's the lead designer, he gets a major say in all the projects at the company, and he doesn't get along with most of the people I just listed, especially not American McGee. So I don't see these two groups cooperating to produce an add-on for Doom being a realistic scenario given that fact in particular.
  11. If the map data locations can ever be found, I'd definitely be interested in working on an extractor, since I'd like to have maps of the levels for the wiki in order to show the minor changes that were made to many of them, plus the two that were split. I've been wanting to do similar for SNES Doom for a long time as well.
  12. Naturally, because the Cyberdemon plays it when attacking.
  13. GBA Doom is perfectly doable. It is also directly based on the Jaguar version. Doom 2 is not doable however. It uses the proprietary Torus Engine and literally nothing is known about its code or its data formats. Too much work to get anywhere at all with it. Also, I believe MAP60.LCD *may* be for the Doom II cast call sequence. But I've never verified that.
  14. Yeah. The only difference here is that PSX clears the screen first, and also that there isn't a hardware offset applied to the buffer it uses to draw the message, so it actually appears at the top of the screen rather than over the status bar (the Jaguar port conceptually draws to the same coordinates but the hardware applies a weird offset to the buffer it uses - Calico does not emulate this when -devparm is enabled as I don't know how it is supposed to work, so the debug output in my port appears at the top, like in PSX).
  15. Messages that use this font are all generated by the function I_Error(); like in the Jaguar port, it is coded in the PSX version to write to its own dedicated screen and uses a monochrome bitmap font that is hard-coded into the executable file. Also like Jag, it functions by deliberately locking up the game into a short loop that does nothing but draw the error message, keeping execution from proceeding into the code after the I_Error call.