• Content count

  • Joined

  • Last visited

1 Follower

About Rachael

  • Rank
    Junior Member
  1. I can tell you that if no post is made on the Feature Suggestions forum at ZDF, no such thing will ever happen. Our only active Mac developer does not come here often that I know of.
  2. Congrats on getting this to a release version!
  3. Some people take their megalomania very seriously.
  4. I think that's much easier said than done, with how DEHACKED actually works. ZDoom has to process all of its internal stuff first in order for DEHACKED to be even functional - since all the actors are external now, not having them loaded beforehand makes them impossible to modify. Naturally, the LANGUAGE lump is loaded around the same time too - which is, before the IWAD is even checked for, since it kind of makes sense to have all the pre-IWAD script processing done in order to properly present the IWAD selection box as well as give basic diagnostics about the system it is being run on (in the user's own language, if possible...). To me, it seems like DEHACKED more or less suits its original purpose in ZDoom - it's simply a crude hacking tool, its operations are added in at the last minute for game processing after the resources are already loaded - which creates the problem we presently see now. This is why I suggested the //$commented meta-command killswitch - a special code that only GZDoom recognizes that shuts down DEHACKED processing and forces it to use the LANGUAGE lump, instead. It might be a bit unpleasant, but it's effective.
  5. I think the best solution to ZDoom is to include a directive that gets ignored (a pseudo-"comment" like how QuickBasic did it) by other ports, and forces the use of the language lump, instead. When ZDoom detects such a meta-command, it will cease processing on that DEHACKED file and let the mod's own LANGUAGE lumps take over. (For reference, here's how QuickBasic did it: https://en.wikibooks.org/wiki/QBasic/Appendix#INCLUDE_.28QUICKbasic_Only.29 By default, any line that starts with an apostrophe is a comment. That works in backwards with GWBASIC and prior versions of Basic. However, if a $ dollar sign is appended to the apostrophe, it creates a meta command that only QuickBasic understands.)
  6. Saints Row 2, and Dr. Who, Ghostbusters, and a lot of other things all prove one MAJOR thing: It matters the person and their actions, not their gender, in the end.
  7. Don't like it? Stop watching Dr. Who. Simple as that. I am sure the real Dr. Who fans will be happy not to count you among them any more - no real loss!
  8. Not everyone might agree with me on this, but this is my stance none the less. I think having it is a bit of an underrated benefit for users. Not because of the bad posts, but because a lot of context and history gets lost when posts are removed. It is actually the main motivation behind me creating the Hall of Unpleasantness (which, ironically and NOT intentionally enough, happened right around the time of DW's forum software shift, and hence, post hell hiding). Now - I am 100% against "glorifying" bad posts, I can definitely see where Ling was coming from, there. But I do not see a "post hell" or public "trash bin" as that sort of way - I do believe, if on a forum that I am moderating, if people are actually trying intentionally to get themselves into that forum, then I wasn't moderating enough, simple as that. Does that make me a bit heavy handed or harsh? I hope not. I try to be fair whenever I can. But you have to recognize when a person won't change their ways - and give them an excuse to find another community to be so unpleasant in. (Hopefully, eventually, they find their way into a community of like-minded people, but hey, wishful thinking)
  9. You can also report bugs without registering. Not every nook and cranny of the internet needs 500 pages of your life's story and your social security and/or national id number. :) (the bug is now fixed, btw)
  10. QZDoom 2.0.0 released! The main purpose of this release is to standardise and make available to modders the custom screen shader system. However, it comes with it a lot of updates, mostly from GZDoom since its latest release: Updates/fixes: Updated to GZDoom 3.1.0, plus some fixes after. (from GZDoom) "Software" light mode (in OpenGL) now supports radial fog setting (from GZDoom) Unsloped Flats can now use non-power-2 textures in software mode (from GZDoom) Menus now merge in with a mod's custom MENUDEF when it provides menu replacements. This is due to older mods' menus becoming very quickly outdated. (from GZDoom) Blade of Agony (Chapter 2) is now supported as an IWAD (from GZDoom) Rise of the Wool Ball is now supported as an IWAD (from GZDoom) "Classic Transparency" option - turn off ZDoom's additive transparency effects for the original game resources. (from GZDoom) Better non-accelerated buffer support for software rendering - when vid_hw2d is disabled or otherwise using an unaccelerated framebuffer, stencils and on-screen objects now show up better. (from GZDoom) (Windows only) vid_used3d is now renamed to vid_glswfb. This matches the same CVAR that is available on Mac/Linux. (from GZDoom) vid_glswfb is now exposed to the menu. (from GZDoom) r_visibility now affects GL's Software lightmode as well as Softpoly. Player Sprite overlays now support the PSPF_MIRROR flag which flips the sprite horizontally across the entire screen. Menu Blurring option - when running in OpenGL mode, a mod can now blur the screen when the menu is active. Unfriendly players - when a PlayerPawn object has -FRIENDLY set, they become a playable monster and interact with the game world as one. Additionally, they become deathmatch opponents, capable of dealing and taking damage from other players. Custom Screen Shaders - mods are now able to include their own post processing shaders, insertable before the bloom pass ("beforebloom"), before 2D objects are drawn ("scene"), and after everything is on the screen ("screen"). vid_saturation saturates/desaturates the screen - improves the appearance of the screen when using certain brightness/gamma settings as well as allowing the user to play in 'black and white' (similar to the display control panel option). (Requires post-processing shaders to be active and hardware gamma must be disabled) Downloads: Windows 64-bit Windows 32-bit - Source
  11. I disagree. I think this is a huge penalty, and it is not worth the extra compression especially since the resulting .pk3 is meant for local storage and not distribution. I think it would be better to use regular deflate compression, at the very least by default if an option must be offered for LZMA. It also would make GZDoom consume more resources since it has to both decompress and also keep the entire structure inside RAM, and with the systems that GZDoom is typically run on this can present a problem especially with larger mods. That being said, the pk3 should definitely be Deflate compressed by default, in my opinion. The one that's become pretty much the defacto standard for wad editing, these days, considering it's the only active project and also is open source (which apparently, its predecessors were originally not). If I had more time on my hands I would just drop in a decent compression library and plug it in, and submit a pull request.
  12. Yeah, that's really oddly specific for a bug like that.
  13. This problem is fully solved now. All I had to do was disable the fog boundaries after they were redrawn once in the "renew" pass. (In the unlikely event anyone is actually curious - it was done here -> https://github.com/coelckers/gzdoom/commit/e290274fb769a6059656842c8cf8d8398436a0c5)
  14. https://github.com/raa-eruanna/qzdoom/blob/8af9f56895629f4d35f09df80dff49480b857f7d/src/r_main.cpp#L650-L681 This is really old render code from ZDoom, but it comes from a time when I managed to fix a minor bug in it. The calculations for "mirror flipping" are here. I don't know if this helps you or not, but I hope it does. (I think this highlighted code block was written by ZZYZX, if you need to contact him for anything) Of course, you still have to render it backwards, but once you get this part down I think the rest will come a little easier. ;)
  15. So - here's my white whale. I've been trying to tackle this for months, and figured I might as well give this forum a try - there might be someone (well, honestly, a lot of people) who knows the software renderer better than I do - particularly ZDoom's, and in this case, hopefully, particularly ZDoom's 3D floor code. As a lot of you might know, there has been a bug in ZDoom's 3D floor code that if fog is present, it overdraws the fog boundary which causes it to not be properly clipped to the walls. If you attempt to run Unloved in the GZDoom software renderer, there are a few places you can see this bug very prominently. Here's a screenshot of the bug in action: So - yeah, I've been trying to tackle this one for months, and may have managed to make a break-through with this commit: https://github.com/raa-eruanna/qzdoom/commit/add0acc0c6c1c97a9998d568c070475735be2344 Here's a screenshot of the same scene after this commit is applied: That should be all she wrote, right? Not only that, it fixes the fog boundaries appearing way too dark, as well. Bonus! So - off we go packing, problem solved and everything, right? Not quite.... There's still some overdraw occurring, and I think it might help to have a fresh pair of eyes look at the code to see what I could be missing - or if there's a better way than this admittedly gross hack (which pales in comparison to what it originally took to get 3D floors working in the first place, in this case, to be honest) to fixing the problem. Any help would be appreciated. The room where I am primarily testing this is the room that leads to MAP04 inside MAP01, though MAP04 right at the very start works, too.