SaladBadger

the date predates Heretic 2's existence, the guy probably got confused since Hexen calls itself Heretic 2 a few times in the source. No files in the shown listings seem particularly quake-y

I have these two from my archives Paul.rar Bucket of Weapons.zip

Just a heads up that the weird copy-pasting seems to still be present in the Finale lump specification. "castmembers" is still using the wrong description and the format of "castmember" isn't precisely defined anywhere. also just a small thing, but I've wondered for a while if an inverse colormap would have worked for tranmap emulation, so hearing an actual AAA graphics dev bring it up makes me kinda happy. I'd be happy if more ports ended up implementing it

So far as I'm aware, every single texture animates at 8 tics per frame, in every release of Doom. The source code indicates 8, and even the unmodified leaked DOS source code indicates 8 for all animations. Perhaps a custom ANIMATED lump is getting loaded somewhere?

I'd like to point out a problem in the specs, the finale lump seems incomplete and suffering from some copy-pasta, in particular for a cast call, it doesn't actually specify the structure of a cast member, and the description for the "castmembers" key is accidentally "Lump name of the patch to be stitched together with the background image from root", copy-pasted from the bunny scroller table.

Straferunning felt different somehow, but it might just be placebo. When recording a demo while straferunning, I would see SL40 and SR40, no 50s. Then, in case it was just a demo-only thing, I made a quick test map with two pads placed perfectly diagonally from one another, and when starting to straferun at the same time, I would end up short of the pad. So it doesn't seem like any changes were made on that front. I even tried running the wad with LoR just in case something changed there, but it doesn't seem like that (one side effect of not having turning keys and a strafe toggle is that it's no longer possible to SR50 at all, then)

I remember asking about the intro videos when the quake 2 port came out and it was said that they were removed because enough people disliked them. And you know what, thank fuck. Sure you can skip them on PC with an ini tweak but on console the video crawl is literally just a waste of time. I get that they want you to know who made these things possible, but it is grating after the 20th time.

the results of the STEP2 midtexture thing are consistent with it being unclipped and the STAR patch having a negative offset, but you are right in that the E3M1 door looks otherwise right except for the grab grid on the bottom sneaking up. Given that a fairly different pipeline is used for rendering 2s midtextures vs other textures, I assume the negative offset fix isn't 100% correct for textures drawn on 1S walls or the sky. time for more experiments I guess..

I'm not 100% sure there is a stable definition for how 2s midtexture clipping works in any of the community editing standards. For demonstration purposes I made a wad that clips a little bit of one of the grate textures to be 32 pixels tall, and numerous ports clipped it differently. Vanilla as well as legacy Boom and MBF show the entire patch unclipped, but with the negative y offset also removed. KEX allows negative y offsets, but does not do clipping of the midtexture. GZDoom and Eternity allow the negative y offset, and clipped the patch to be identical to the view in Slade 3. Woof clipped it, but didn't allow the negative Y offset, and I suspect DSDA is doing the same or similar. Given the amount of different behaviors I've seen across updated ports, I wonder if a specific behavior should be codified in one of the standards at some point. The Doom 1 E1 sky and E3M1 door being messed up is just due to the game allowing negative Y offsets now. One of the perils of making more flexible behavior in new engines.. GZdoom and Eternity have code to work around the few textures that get messed up by that. Test wad attached midclip.zip

dunno where else to shove this, but one of the WIP fonts in the id vault had a different set of lowercase characters that got tossed for the small caps, so here's my attempt at finalizing those characters in the same style as the final font.

You don't, the new engine and ID24 by specification does not automatically default to ID24 exactly for this reason. A wad you're loading explicitly has to ask for ID24 for these things to become available. In any case, even if this wasn't the case, why does this matter? If you didn't place any new weapons or monsters, players of your map wouldn't encounter the new weapons or monsters, and you don't need to balance around a player punching in IDKFA.

While looking at the font WIPs in the new id vault, I discovered that the source of the font's overall "texture" seems to be from FIREWALL. A crappy gif to maybe illustrate The C doesn't line up correctly, since a 64 wide portion of the base texture was used to overlay the initial grayscale font, and the C happens to be where that tiles. From this base texture, shading and an outline were then applied

The silent teleporters of boomedit.wad do seem to be fine, for whatever reason. All of boomedit seems to work fine overall, but I did notice one anomaly with transfer heights EDIT: THE ABOVE IS ACTUALLY ACCURATE TO BOOM'S ORIGINAL BEHAVIOR (mostly, but does an artifact count?), so disregard I guess? GZdoom renders it right, but given the weird sector setup of these lines, I'm kinda amazed it does. All other Boom derived engines mess up with it. While not related to boomedit directly, I did notice playing in the 320x200 scaling that the top/bottom borders for the fuzz effect only consider the top or bottom of the full screen, not the 3D viewport, so the status bar and screen border maybe? can be sucked into the fuzz. Edit: actually, this is incorrect. the top of the 3D viewport is correctly considered and it will never take from the top border, but the bottom has no such limit, and if you go to the highest screen size, it will start grabbing pixels from beyond the screen. In practice these always seem to match the top of the screen, so I wonder if it's wrapping

I think id1-res.wad is just a resource for usage to make new maps with the new content? hard to say. (edit: kinsie has it right above) From looking at the console it seems that id24res.wad and id1.wad are all that get mounted when you've played the new episode. I've also observed that the engine is coded specifically to add id24res when a wad's GAMECONF lump is set to ask for executable "id24". id24res.wad specifically lets you use both the plasma rifle/bfg, and the new two weapons. It even gives you a new status bar to show that .. though this appears to lack some of the actors used in the new episode, in particular there's a chair in there that's invisible. Sample wad attached. id24test.zip

2s line collision has always been a bit spotty in vanilla Doom. They're effectively invisible to the complicated mess that is P_SlideMove and end up using a much simpler collision routine that can cause issues, especially with non-axis aligned 2s lines

so with regards to mod loading, to no one's surprise you can still -file to load mods from the filesystem. You still have to pick the right game, but I wouldn't be surprised if there's another parameter that can get you into a game quickly, maybe -iwad? Of course I can't actually test that the map works because it's for doom 2 and every time I try to play Doom 2 the new port crashes at the skill select menu. As much as I like the new content and appreciate what id and NDS are doing, this has been one of the most crashy releases of Doom I've ever played. I verified the game in GOG Galaxy and no problems were found. This happens regardless of whether or not I'm trying to -file. edit: okay I loaded my test file into plutonia which is doom 2 enough to test it and it worked. so yeah you can just -file if you want to grab something from your FS with the new port. Passing an -iwad parameter will also get you straight into the game you want to play so you don't need to muck around with the game selector if you don't want. edit: the crashing has stopped. hmm

you can load external WADs in the new release? I couldn't find an obvious way to do it, though in fairness I remember it being a little weird with the unity ports (I never played them, though)

It seems like a lot of the new id24 stuff is new json files. In id1.wad I spy a SBARDEF file, a SKYDEFS for driving the new animated skies, an intermission map scripting thing (XINTER1 and XINTER2), and some new keys in UMAPINFO. Not sure about any Dehacked level changes, but if they can be played in GZDoom and DSDA already I imagine there's nothing significant

I guess I'm just not too worried about the proprietary nature of the releases, like yeah it sucks to some degree for a game that was made very open, but they're still being very open otherwise, incorporating community standards with just a few other features like the status bar lump, which I think is fine. it makes it more likely that more engines are going to adopt it, with completely GPL friendly releases. Maybe my optimism is a little misplaced, but it does seem like things went just fine for the Quake rerelease. The community status quo didn't actually change that much, the ports adopted the new features, and everyone seems happy. Doom's might change a bit if people want to start making for-ID24 releases, but I suppose we'll see.

seems you can't actually buy it on Steam atm, it's still unlisted. But I see the update drop in SteamDB. If you really need the Unity port for any reason it looks like there's a "previous-re-rerelease " branch available? (does that make the new Kex version a re-re-rerelease?)

An odd thing to add to that is that since fixed_t is signed, if the value is negative, the shift down is arithmetic, meaning that the sign bit saturates, so you can't actually shift it to 0 from negatives. This might slightly screw up the accuracy in some cases, but it does at least mean some relative comparison can be maintained.

I'm trying to think if that can even happen, given that vertices are specified in the level as integers, so it's entirely possible that the values will never go below one FRACUNIT.

I'm not 100% on this, but the shifts are probably to reduce the chance of (maybe outright prevent?) the FixedMul calls overflowing. With the same reduction being applied in both FixedMul calls, it's still reasonable to do a comparison to figure out what side it's on

modern CPUs still heavily use cachelines that favor a column major transform like this, when drawing vertical columns. at 320x200 on a modern CPU it doesn't matter much, but Gooberman, in an effort to make the Doom renderer run way faster at high resolutions, has determined that making the framebuffer column-major always significantly increased the speed, since rendering of walls and things (floors/ceilings cause a bit of trouble there, though) is done vertically.

Seemingly it's "fast water" and "splashing water", the SWATER flats are in the press release beta, but they're also in Romero's art dump: