Blastfrog

Members
  • Content count

    4866
  • Joined

  • Last visited

Community Reputation

124 Good

About Blastfrog

  • Rank
    Formerly Sodaholic
  1. Why does everyone assume that the shotgun is rested on Doomguy's chest? How do you know that he doesn't have his body angled, with the shotgun resting against his shoulder? That's always been my interpretation.
  2. I thought they were both the same thing. Frankly, I think both terms suck. Why not just call it "vertical look" and "horizontal look"? Unambiguous, straightforward, simple. Terminology conventions suck.
  3. Heh. I'm far more interested in seeing this as a GL renderer feature than as a software renderer feature by this point. Though, if it can feasibly be done in the latter without too much trouble, why not, I guess.
  4. I suppose. Here's the thing, I believe they took off of the Doom 3 plot with the martian thing, and that the movie still had demons, but they were metaphorical rather than literal. Really dumb, but think about it: bad people become monsters when they get the extra chromosome, the demons are among us. Everyone has demons inside of them, and only the pure of heart don't become mutants. Hey, I did say it was dumb.
  5. Okay, so I'm getting pretty tired of WASD. It's only on/off and 8 directions, and maybe an additional key as a speed modifier. The W key doesn't even line up with the S key like the up arrow is aligned with the down arrow. Clearly, the superior option is analog input, where I may move in any direction at any desired speed. I'm right-handed, so I'd need a left-handed joystick. Doesn't have to be a full joystick (in fact, I prefer thumbsticks), just something that I can use in my left hand that provides enough buttons that I can move with analog input in FPS games. Something like a Wii nunchuck would be ideal, but an actual Wii nunchuck will not do. First, I'd have to have it connected to an actual Wiimote, then I'd have to get it connected to my computer, then I'd have to fuck around with Glovepie (and I'm really not so sure I like its author). Not to mention it only has two buttons and an awful octagon rim around the thumbstick like Nintendo kept doing until the Wii U. Though really, I'd just prefer a gamepad with a trackball. Why do no hardware manufacturers cater to my insane desires?! D:
  6. Bumping just because I think it's worth reminding everyone how cool this would be, overambitious as it may be. (hopefully this isn't an issue that I did this, I don't plan to bump any more old threads of mine for quite some time. that and i also wanted to focus on the subject of gzdoom not supporting a lot of things just because it'd take significantly more steps in the rendering process) Would nevertheless be amazing if this (admittedly nontrivial and overambitious) feature could be done that way. Take a look at RNGPSY's third image here. Wouldn't that scene look just that much more breathtaking to turn the plain fog into mist? What if the mist was animated, and blended between frames like Doomsday does with its animated textures? ----- In general I'd like to see GZDoom do more fancy stuff, even if it means not supporting it on older hardware/OGL specs. Even just sprites drawing inside of the floor (a vital feature of Doom's software renderer, that even other ports do in GL now) is something I'm surprised still has yet to be done, clear into 2017. We got bloom and AO before supporting the full feature set of a 23 year old renderer... I know a large part of the userbase is on crusty old garbage. I say this: time marches on, it's their fault if they want to keep using Windows XP with their Voodoo whatever nonsense. Not sufficient reason to hold back much needed progress, IMO. Don't leave them entirely in the dust, but please stop pandering so heavily to them at the cost of everything else. Worth noting, I'm coming at this from the perspective of a relatively clueless layman. I know these things are really complex, please don't think I'm just demanding anything. It's much more about the philosophy than the technicalities or time/effort to implement these things.
  7. First off, apologies to Ling for starting another idea thread. I think this would be better off in its own thread, however, and isn't just my typical insanity. Hopefully you'll make a small exception, here, I'll chance it. Anyway, Deutex is still quite useful, Freedoom still uses it. However, it could use a facelift, for sure. Having to manually define patch offsets in a metadata text file is tedious, and GIF is a pain to deal with these days for use in a resource fork. Deutex doesn't even support transparency, you have to use a stand-in color. Support for PNGs with their own offsets would make life a thousand times easier. There's also the fact that the currently maintained version is not distributed with binaries and you have to compile from source if you want to use it and not a crusty old 16-bit DOS binary as the last official version was distributed as. Maybe it could even be absorbed into SLADE? Thoughts?
  8. Could you even -file with the shareware IWAD anyway? I don't think you could. Not that it was ever id's intention, Dehacked not being their creation. Still, that's what it amounts to; free stuff to hack.
  9. That is beyond cool. Those portraits look just like Strife! Seems that they're continuing work on the engine? Vavoom isn't so dead, after all.
  10. Hah, that is so cool. I wonder if id had any idea that this is where things would lead back in '93.
  11. This is a really cool project idea, but I agree with Fraggle. Perhaps this could have a more unique name?
  12. As heavy as my art edits are, this is directly counter to the goals of the project and beyond its scope.
  13. How about the exact same format as the palette translation lumps already in EE's data, such as the ones used for translating the crosshair? A simple 256 byte lump, nothing more, nothing less. Seems straightforward enough, no? EDIT: Just to make sure this base is covered too: any hardcoded color index assignments (namely, player translation and automap colors) should be translated in the same way as assets themselves are (taking care to keep them aligned, players must not become garbled). EDIT 2: Perhaps there could be 4 more lumps to replace the hardcoded color index assignements: PL2REMAP, PL3REMAP, PL4REMAP and MAPREMAP (last one sounds dumb, but whatever). The PLxREMAP lumps would define manual translations for the players, these would be 256 bytes as well. MAPREMAP would be a lot smaller, would just redefine the default automap colors. Should any of these additional 4 lumps not be included, PALREMAP is used as a fallback with the default hardcoded values referenced, translated to their equivalents. EDIT 3: Then again, Graf did mention handling things differently when in true color, as there are indeed cases where you might not want the colors to be degraded (DM2PAL comes to mind). I don't believe it should be part of the PALREMAP lump, could be part of some other metadata lump. Call it RMAPINFO maybe? TRUREMAP might be a good idea. EDIT 4: Just to keep things on the simpler side, let's focus on just PALREMAP itself for now.
  14. More than a bit of a bump this time! I haven't forgotten about this feature idea, I'm bumping the thread in the hope that it may renew interest and discussion on it. Perhaps actually seeing this thing through to reality, I hope. I mean, it's clearly quite useful and would be relatively trivial. Possibly tedious, but quite doable. I'd have done it myself, but I'm a pathetic script kiddie, I couldn't code myself out of a wet cardboard box. My whole "IWADs and the autoloaded WADs only" part was a terrible stipulation, but the concept of the lump and its purpose is solid. Instead, it should apply to all assets (and hardcoded colors like player translation and automap colors) loaded before the WAD with a PALREMAP in it (nothing in that wad would be translated, as it's assumed that they're already made for the new palette if they're in the same WAD as one with a PALERMAP lump in it). Just in case, if there's more than one WAD loaded with a PALREMAP lump, retranslate everything in the order that the PALREMAPS are loaded. To simplify and optimize engine-side implementation, just translate the tables themselves enough times to what is needed per individual WAD in the queue, and apply the translation step only once. Yes, there would be likely (though not necessarily guaranteed, depending on how it's all set up) degradation. Still better to have intercompatibility with multiple WADs loaded at once that use this feature, than to only use the latest PALREMAP and have everything become a garbled mess of mal-assigned indices. Besides, that's an edge case, most of the time the user would only be loading one, if any.
  15. That might not be such a bad idea. Worth some consideration, at the least. Which is exactly why I started this thread. Perhaps it is time to revisit the idea? I'd just do it myself if I were a more capable coder, best I can do is hack some primitive shit on top of existing programs. :/