Afterglow

It has fixed https://doomwiki.org/wiki/Vertical_offsets_are_ignored_in_texture_patches (heading "Negative offsets") so negative patch offsets are now applied instead of having a guardrail starting from 0. Gez's link above for ZDoom's hardcoded backfill fixes only cover doom.wad IWAD patches of BIGDOOR7 & SKY1. There are another dozen or so other IWAD textures with negative patch offsets that I fixed in Eternity Engine: https://github.com/team-eternity/eternity/pull/579 & UDB. They're more subtle, only off by a pixel or 4 so they only affect obsessed level designers like myself that tightly bind geometry to texture material edges. I was going to submit the same PR to different ZDoom ports but we have 20yr+ of PWAD history now applying texture alignments to the negative offsets. Fixing that in ZDoom-derived ports could cause bug reports in the other direction.

I just confirmed the MAP36 intro portal conveyor sector behaves as intended in RC4 using dsda-doom v0.27.3 (Nov 5) and v0.27.5 (Dec 3).

Manitoba isn't even a real province.

This really isn't "lost" since I've posts teaser screenshots many times over the years on DW, Discord, my websites, etc. I've had a 3 map set using ukiro's old texture set finished for years now including one frankenmap that incorporates the unfinished pieces by Cocoon, Wiles, Covaro, & other mappers that people know. I tucked it away when Eviternity and the OTEX revival was happening in 2017/2018 and releasing maps with the old textures was a distraction from the main event. It still needs MIDI music and some menu graphics completed - and it's under a different title than Perfect. A dozen of more community members have given me playtesting feedback over the years. The levels are just OK. I was hoping to convert the lot to OTEX but most of the old textures don't have a like-for-like and all my geometry is opinionated around material/pattern edges. The texture set was also made immediately after darken2's set in 1999, but before darken2 was released in 2000. So it's heavily inspired by Quake 2 and 1990s drop shadows. There's a pfcttex.wad Mar 29, 1999 that's basically Surge 1/2 textures with some clones of tech textures Kurt Kesler made for his maps around that time.

I'm unsure about port compatibility for these maps that pre-date current source ports. dmdjm01 from 1999 was created for boom.exe but may have issues with current ZDoom-derived ports - maybe a softlock, although the map doesn't have voodoo dolls so that linked "scripting" bug report doesn't make much sense. dmdjm02 was only developed and tested on early ZDoom due to map size static limits. A quick bugfix was later done to stop a PrBoom+ on-load crash but it wasn't thoroughly re-tested. With DSDA/PrB+/EE I'm now aware of a few problems with the absence of ZDoom blockmap/physics changes, such as barriers that can be bypassed. If I ever get around to finishing dmdjm03 this century, I'll release bugfixes for these maps (with UV redone.) Either way, I'm looking forward to watching people die in very specific ambushes.

What are the lump counts shown in DoomBuilder's bottom right when no linedef/sector is highlighted? When beyond static limits, DB2 highlights it in red. The DB2 family of editors (including DBX & UDB) will auto-compress SIDEDEFS if they go beyond the limit but truthfully the SEGS lump has its limits reached before LINEDEFS/SIDEDEFS. I check that using SLADE: The SEGS limit of boom.exe was 2^15 = 32768 but PrBoom+, Eternity Engine, Woof, etc. raise that to 2^16 - 1 = 65535. I have a limit-removing map about the size of your automap screenshot and I had to cull some details because it was hitting both 65k SEGS and the blockmap limit.

4 years later I just noticed this thread today via the wiki. I recognize some XX* lumps from a mix of sources: XXWOLF17 and XXWOLF4 are taken from the 3D Game Alchemy CD by Justin Fisher of Aliens TC fame. XXROCKS1 is Quake 2's ROCKS19_1 converted to the Doom palette. XXWOLF2 is a green version of ER_BRK08 from Eternal Doom IV. XXFWAT2* animation might be edits of Hexen water textures X_WATER1/W_241-W_244 / flats X_005-X_008, although I haven't done a pixel-by-pixel comparison. XXWOLF1 looks like a re-creation of a Hexen grey brick texture CASTLE07/W_071 (Eternal Doom lump 3BIGRIK4) but I don't know the source. Adjacent info: Fanatic's unfinished Castle demo for EDGE from 2001 (not on /idgames) has some custom decoration sprites and textures by Espi. It artistically bridges his work between these Hellcore graphics and the more realized Eternal Doom IV texture set. In the text file Fanatic wrote "You MAY NOT use portions of this package in your project(s)!" but that could probably be loosened if he were contacted. Maybe @Lüt can answer whether some of those Castle textures were also used in the unreleased Doom Millennium upgraded levels.

Been working on (yet another) vanilla map this month. Half of the level is right up against the drawsegs limit because I enjoy torturous playtesting?

In vanilla, line specials "51 - S1 Exit Level (goes to secret)" & "124 - W1 Exit Level (goes to secret)" will restart the current level when used outside of MAP15 & MAP31. However this behavior changes in some circumstances when the global game state is different, e.g., when command line parameters -warp or -playdemo are used. If you progressively play MAP01, MAP02, MAP03, etc. in a continuous session and hit line special 124 on MAP05, doom2.exe will restart MAP05. With -warp or a loaded save game, it resets the game back to MAP01. (Some source ports like ZDoom "fix" that undefined behavior by treating the trigger like a regular exit when no secret map destination is defined.)

In E2M3 I ran into a soft lock behind a tree sprite: E3M3 texture misalignment near the exit:

Since returning have you had a look at OTEX? It has drop-in replacements for many textures in those scenes including some really good bricks. In the post-BTSX era, the SurgeDM stuff can look a bit dated now. Although we're making Doom levels here - dated is our jam.

One afternoon back in December I started a (hacky) experimental Eternity Engine branch that attempted to support the original /idgames cod.wad & codlev.wad as-is: https://github.com/team-eternity/eternity/compare/master...derekmd:caverns-of-darkness-support For ambient sounds, I added a thing type ID map that moved cod-engine.exe's hard-coded IDs into EE's 14001+ range. I didn't really do much else work on that branch beyond loading a custom .bex file when cod.wad is loaded. FYI printz also posted a Caverns of Darkness discussion on EE's GitHub issues about adding first-order support to the source port: https://github.com/team-eternity/eternity/issues/305 And if this helps with migrating the old code, my diff on the COD engine source and Eternity Engine beta5 found only these files were changed: D_deh.c D_deh.h D_englsh.h D_items.c Doomdef.h G_bind.c G_bind.h G_game.c I_VIDEO.H Info.c Info.h M_cheat.c M_misc.c Mn_menus.c P_enemy.c P_inter.c P_lights.c P_pspr.c P_spec.c P_spec.h R_sky.c Sounds.c Sounds.h Wi_stuff.c

Basic.

Yup, that's it. I have no clue why the original IWAD texture was assembled in such a complicated way. A single plain 128x128 patch would have even taken up less disk space.