SaladBadger

I've been curious if any emulator can run the Doom alpha's high color mode. The Dr. Dobbs overview on the Sierra High Color DAC mentions that the Tseng Labs ET4000 can do high color rendering, but trying it with a ET4000 emulated in pcem produces weird artifacts

I also tried DosBox-X, which also emulates the ET4000, but the effect is even worse, with the screen being divided into a bunch of small tiles and flickering heavily. I don't know if the emulation is wrong or if Doom's high color mode is just incompatible.

I've been a little inspired by the "weirdest doom source port" thread so I'm trying to port the simplest known version of Doom to a platform that is absolutely, positively not suited for running such a game, but is technically capable of doing so.

A platform where the only scalar type is a 64-bit double, there's only extremely limited string support, no heap allocations, file IO only works one byte at a time from a specific file, and so on... I'm surprised I've gotten this far, and I know the entire game, hell, all of the final version of Doom could be run in this platform.

The urge to write "Doom05Heh" in any particular thread about "what's your favorite source port" is too high, but it's also too shitposty so I must resist.

While replaying scythe 2 I kept on seeing jumps and other skips while playing, and I'm noticing them enough now that I'm starting to consider giving some speedrunning a try.

Granted half my experience with things like straferun jumps and grabs is that I attempt them 20 times, all fail, then as a last resort I just casually bump myself against the surface and snag it immediately. Lots of practice still needed...

my life is full of bugs and more bugs now

Doom's renderer evolution is weird. If you're familiar with the final rendering code, with its use of polar coordinates for projection and clipping and the use of a BSP to determine rendering order, the 0.5 rendering code is completely different. Points are projected and clipped using relatively conventional algorithms (it's so by the book that the projected vertex structure uses x for position left/right on screen and z for depth, unlike the map format). Processed lines are shoved into subsectors, spans are generated and drawn (no visplanes here yet, but I haven't traced flat rendering just yet), then it flows into adjacent sectors by looking at 2s lines that made it into the subsector. This is depth-first rather than breadth-first. When the renderer is unable to draw further, it draws all the things in the current sector, and then backs up. This has the fun effect of making things standing on the line between sectors sometimes get cut off based on how the game walked the sectors.

I'm still working on the code cleanup, I want to be able to show how this works alongside fully functioning code.

I want to write an article discussing Doom rendering pre-BSP, and I have basically all the 0.5 rendering code mapped out at this point and a pretty good idea of how it works, but I'd like to get it reimplemented to actually demonstrate and verify functionality, but that's uh, going well...

It's just rendering sector 0 (the map border in map 1) while spinning ATM, but there's some bugs causing weird clipping ATM. Ugh. Fixing decompiler artifacts is certainly a special kind of fun. No flats and recursion quite yet.

random thoughts: I wonder how much Doom source code Apogee had gotten from id for Rise of the Triad. I noticed there's a lot of id's scripting library from the doom utilities in there, and what may be some alpha-era code (an an example, there's reference to mr_ variables and the MapRow function, the alpha's version of DrawSpan)

was exploring the avenue of reversing doom 0.2 to figure out what state it truly is in after just 2 months of dev, found myself falling down a rabbit hole of incredibly obscure dos extenders and compilers. I'm assuming that the executable was made with "xmgcc", an incredibly obscure dos port of gcc made in 1990, including its own dos extender that uses an executable format I'm assuming's too obscure to have a ghidra plugin or any usable documentation.

But why would it be made with an incredibly obscure gcc port from 1990? I know it took a while for Carmack to start using Watcom, but was Borland C (used for earlier id projects) completely unworkable with regards to doom that he'd be seeking out incredibly obscure compilers?

Before he uh, went away, I remember kb1 working on a program to interpret the HIGHBLIT lump in the 0.2 alpha, but didn't have any success with it. I was bored so I had my own try, and one attempt at writing the world's worst x86 emulator ever (it supports 5 instructions under really restricted parameters!) I made something that works. Well, kinda, there's issues since it copies only 4 bytes at a time, so some details are lost. I wonder if the VIEWINFO lump is responsible for masking that out.

Just spent an hour mapping out the player_t structures in doom 0.5 in cheat engine by pulling the names and general layout of the symbol table embedded into the executable, and learned some fun things in the process like every weapon being "implemented" (this includes the chainsaw, the dark claw, and the bfg, but they just use shotgun sprites)

what am I actually doing with my life? why is this the kind of thing I do for "fun?"

I wonder if there's a good archive of Quake 2 levelsets. I've had some fun playing the fan made level sets even if the base game isn't as fun anymore, but unlike Doom where sites like Doomworld have lived for such a long time, PlanetQuake eventually kicked the bucket, so it's hard to tell where to go for that.

In the ending of Doom E1, you die and go to hell. Is Doom an isekai?

Kinda cool to see that those infoboxes on Google are actually drawing information from doomwiki.org instead of the doom wikia.

A minor frustration I've run into with Chocolate Descent: I've encountered a bug where the game can go into an infinite loop if certain strange conditions are met when killing the level 7 boss. Unlike an algorithm bug, where something doesn't work 100% as expected in the game world, or a static limit or similar where the game exits with a given error message (like visplane overflows in doom), this kinda bug seems like a frustrating screw to the user, requiring them to mess around with the Task Manager or similar process management tools. With most bugs I can keep them as is, but this kind of bug makes me wonder what I should do. Should I fix it? Should I change it to an explicit game-ending error? Or should I just have the player muck about with task manager? I mean I guess that last option is comparable to what people would have to do if they encountered said bug back in the day...

I wonder a little if some of the link spam dropping members who register here are actually people being paid to vaguely pretend to be an actual member, or if its some sort of new elaborate bot tech. I dunno...

was having trouble finding what shows to watch over a upcoming vacation on my tablet, guess I'm gonna load some of the kyoani stuff I've missed in there (how the hell have I not watched Violet Evergarden in 2019???)

honestly despite being strapped for cash ATM I probably will toss something at the studio. At this point, I'm not even sure how the studio can recover, but I really would like to support the livelihoods and future creative careers for those who have survived.

well fuck, Kyoani's been burned in an arson attack, killing multiple people and injuring quite a lot more. That's kinda really fucked up.

honestly, the more I read it, the more I wonder if Fabien was allowed to access the unmodified Doom source for the Game Engine Black Book. I seemingly remember an effort to try to produce a relatively accurate set of source code for the DOS game, but he also brings up a lot of details about the NEXT side of things, which I don't remember ever getting released.

It's pretty cool that this does enable stats on how much time it took to build the game on nextstep and on DOS, though.

For whatever reason, i've found that Doom with all monster state durations reduced to 1 is a really ridiculous but also strangely fun challenge. it's sorta like nightmare, and is in ways both more and less ridiculous than Doom's normal nightmare. It's also really amusing watching every monster just go around like they're completely jacked up on caffeine or something.

the latest H_G thread had a picture of kdizd e1m2. I happen to have a collection of extremely early KDIZD maps and I'm a little confused on one thing:

Is this courtyard more detailed than the final game's one? (I need to dig out the missing textures, since the final kdizd archive was pruned) Floor detail is pretty annoying though.

Things I vaguely wonder: A lot of speedruns of other games tend to play on their easiest difficulty, while Doom speedruns are typically done a the highest "sane" difficulty, UV (with some also on the less sane difficulty NM). How did this come about?

1am thoughts: isn't Fabien Sanglard's Doom Engine Black Book a realization of Bernd's failed dreams of writing a book describing the Doom engine? if only fab's book could come with a CD including the source code on it, then the illusion would be complete.

the way times change is weird sometimes.

is this ranger's helmet? it seriously feels like it but i just can't feel 100% sure

I didn't quite want to derail the relatively technical discussion in the visplane thread, but while visplanes are in everyone's thoughts again I always remember this tweet, it really does give a fairly good impression of what's going on with visplanes. I wonder what it'd look like with merging...