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

Shadow Hog

Members
  • Content count

    1222
  • Joined

  • Last visited

3 Followers

About Shadow Hog

  • Rank
    Senior Member

Recent Profile Visitors

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

  1. Shadow Hog

    DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

    Just noting it here that my pull request has been accepted, so sound slots 500-699 now refer to DSFRE000-199 in repo builds of PrBoom+UM as well.
  2. Shadow Hog

    DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

    Double post, but I've submitted the pull request to Graf's fork. Hopefully the SNAFU with my local fork won't be hugely detrimental to his; else I guess I can figure out some way to trash my fork from GitHub and start over from the top with a fresh fork, it's not like I'm especially attached to that thing.
  3. Shadow Hog

    DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

    Sorry, got engrossed in touching up an SSF-MIDI-extractor I was writing in Java this weekend, and thus didn't touch this too much. Since reading your post I've been working on getting my old PrBoom+ fork up-to-snuff after gathering dust for years so I can do a proper pull request, but it decided that like 100 commits to Graf's repo simply never happened, and trying to merge the two repos so I'm at some level of parity has been like pulling teeth. For some reason, despite insisting I was merging in Graf's master branch, Git insists I want code from the DECOLITE branch instead. Except I don't. What the hell. (Even using Git regularly at work, I swear this program still finds ways to completely confound me.) Still working on it, hope to have something ASAP. Strictly speaking I can do any number, though I can't attest to how other port authors will take to having a large "reserved" block in their sound listings going completely unused before actually-used sounds. Suppose I'll have to wait and see on that. I already know WhackEd4's JSON configuration files can't handle sparse arrays like that (rather, JSON itself can't, by design), so I've had to pad it out with hundreds of "RESERVED" sound definitions - which is about as ugly as it sounds, and is presently completely visible to the end-user as such. On the subject of other ports - PrBoom+UM is one, and Eternity will be another, but what else was there that I'll probably need to make patches/pull requests for? Doom Retro?
  4. Shadow Hog

    DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

    Works for me. When I'm over this hard drive about-to-die slump (data should already be backed up, just trying to ID what's been lost to failing sectors if anything), I'll see what I can do to push this to PrBoom+UM and I guess we work from there.
  5. Shadow Hog

    DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

    It'd probably be best to be contiguous, regardless of what the final figure ends up being. I will say I have no inclination to go over 200, that seems like more than plenty for most use cases. What should we mark the range between the start of this range and the end of the standard MBF-compatible sounds, though? "Engine-specific"?
  6. Shadow Hog

    DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

    As long as the thread's been bumped up, I was kinda hoping for a response from anyone when I posted the video of the 200 sounds working - specifically, a bit of discussion as to what number to start them at. I've proven (to myself, if nobody else) that the starting number can be completely arbitrary and skip as many as needed in PrBoom+UM, and I'd like to try and make a pull request to at least that port at some point. Given this is a new standard we're writing here, though, I also don't want to either box people in too hard or leave so much empty room that it causes other issues. Unrelated to this, but as long as we're making requests while shooting for the stars, some sort of mechanism to group together specific sounds for randomization (e.g.: zombie seesound/deathsound, imp deathsound) would be nice, if entirely new to DEH. To some extent you can already randomize some things using A_RandomJump, but if it was, say, the ActiveSound you wanted to be randomized, that might not help you out too much.
  7. Shadow Hog

    PrBoom+/UMAPINFO v 2.5.1.7

    As of writing, this appears to be the full list (from umapinfo.cpp): I don't see anything for extra actors as yet. Maybe it's still on the todo list, maybe it's an oversight, IDK.
  8. These ports have the Wolf SS though. They say a different sound, but I believe their graphics are all accounted for.
  9. Had the bright idea of trying Doom 2 the Way id Did on here, cuz hey, that has some extensive DEHACKED stuff in MAP31 and 32! Well, MAP32 booted. I didn't stick around to see if I could find the custom enemy hunting you down though. Screenshot attached (spoilered in case you still weren't aware what that WAD did for its secret levels): However, MAP31 crashes instantly on warping to it. No log left that I can find for analysis. Annoying.
  10. Just thought I'd try a thing since the suggestion came up: 1.16a seems to work fine. Didn't add any information lumps that it might need or anything, so there's probably room for improvement, but yeah, just in case there was any doubt DEHACKED is really in, DEHACKED is really in. Did notice this visual glitch in E1M1, though. Should probably test it on a (probably emulated) DOS computer or Chocolate Doom to see if accurate...
  11. For what it's worth, as far as I know PCem is a full-on emulator, and one aiming for accuracy moreso than DOSBox does (down to needing BIOS ROMs and having to partition virtual hard drives to install the OS), but at the same time I wouldn't necessarily call it accurate enough to produce useful results for testing the real-world applicability of this source port. (It would be pretty close, though.)
  12. I'm impressed and definitely see the utility, but at the same time, those flat visplanes being incredibly bright against dark walls in dark sectors are kind of an eyesore. I do expect darkening the visplanes as they go into the distance would negate a lot of the speed gain - you'd probably still gain some speed, due to only having to poll one palette entry instead of calculating what pixel of the flat needs to be rendered and then polling its palette entry, but I imagine the removal of the darkening is where a lot of the speed gain actually lies here. Maybe it'd be a better compromise to render the entire visplane at a single color regardless of distance as it currently is, but change what color that is based on the light value of the sector it belongs to (based on what color it'd have been an arbitrary fixed distance from the camera, set to whatever looks most aesthetically-pleasing)? That said, if I'm wrong and reintroducing the visplanes getting darker into the distance isn't a huge performance-killer, it would certainly complete the SNES Doom look (since that did have that feature - with dithering, even, though I wouldn't expect that myself).
  13. Shadow Hog

    PrBoom+/UMAPINFO v 2.5.1.7

    IIRC it's more flexible w.r.t to having multiple texture WADs loaded at once - they're cumulative, while TEXTURESx/PNAMES, IIRC, only takes the last one loaded and ignores the rest.
  14. Shadow Hog

    DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

    I believe it is intended to extend BEX, which should have all of those things (the extra action specials at least), so, yes?
  15. Shadow Hog

    DEHEXTRA discussion (split from Pr+ UMAPINFO thread)

    Re: getting the sounds shifted over to accommodate Eternity: it appears I have it working. I'd never heard of "designated initializers" before this, but Visual Studio threw no errors, and one NULL check added to D_BuildBEXTables later, it works, as this (admittedly somewhat plain) video of the Half-Life VOX announcer counting from 200 to 0 every two seconds before you explode shows, so, sure: I suppose I should ask a follow-up question: what is a good offset for this? If I were to leave room for every Heretic, Hexen and Strife sound effect (including VOICES.WAD) as well (starting at 300, as Eternity currently has it), I'd have to set it to just under 1200 (which is where that video currently has it). That seems rather high for ports that would rather keep memory count low. FWIW, I don't know that I intend to add more than the 200 added sounds the video showcases (the "die" just being DSSKLDTH), if only because cutting together those VOX sounds in Audacity for the sake of making sure the slots are working is way too time-consuming. That said, I also don't want to completely write off the possibility for somebody else to do in the future, either. I also noticed Eternity had no entries for MINAT3, CHICPAI, CHICDTH, CHICACT, CHICPK1, CHICPK2, CHICPK3, RIPSLOP, BURN, GLOOP, HRNPOW, RAMPHIT, RAMRAIN, or LOBPOW from Heretic (but does have one for a nonexistent "NOWAY" sound - a clone of PLROOF I presume), though I have no idea if you guys care or not about that since I'm not certain how deep your Heretic implementation is at the moment. (This also isn't exactly material to the topic at hand, I suppose.)
×