Afterglow

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.

Yeah, to reiterate there's a glitch in the texture drawing of BIGDOOR7 rooted in the weird-ass way doom.wad composed the texture by re-using a 128x136 patch. Ultimate Doom E3M4: I just discovered this alongside a conversation with boris about the DB2 family of editors not considering this Doom "bug" (or error correction): https://doomwiki.org/wiki/Vertical_offsets_are_ignored_in_texture_patches in doom.wad & doom2.wad, W105_1 is a 128x136 patch IWAD doom.wad: the patch is applied to the BIGDOOR7 texture twice at (-4, -4) and (125, -5) however, Doom ignores the negative Y offsets so it becomes (-4, 0) and (125, 0) IWAD doom2.wad applies W105_1 (-5, 0) and (123, 0) so these alignments are unaffected According to the wiki article, the Doom II's STEP2 re-use of patch SW11_4 would also affected but NeuralUpdate2x_v1.0.pk3 already has a GZDoom texture filter workaround for that. It looks like the downscale didn't consider the W105_1 patch's odd dimensions as it glitched when cropped and resized: It would have to be regenerated and edited to be similar to `WOOD5` with half `SUPPORT3` patches along each edge; 24 pixels thick in a 256x256 texture.