SaladBadger

There are a fair amount of visplane overflows possible in the last level boss arena. All I can recommend is not looking into the main area when too many doors are open at one moment.

I think I've played Descent long enough that I'm completely used to it's bullshit. Even the sluggish turning isn't too bad for me (though maybe I should finally get a good flight stick for constant turning...) A zero life loss run on even Hotshot is out of my grasp, but I can beat the game pretty effectively on Ace at this point. The later skills are odd because while you're much more likely to die, you're almost always getting at least one extra life every level simply due to the skill level based modifier applied at the end of each level.

It kinda reminds me of an early arcade game, though much more generous with the 1-ups.

Licensees of the engine have full reign over the engine and can transform it how they want. All id ever did with the console officially was create the simple one. I wouldn't be surprised if the developers of MOH:AA spent time creating a new UI library and they decided to make the console use it for convenience. It was in style, Unreal Tournament did it, the steam versions of HL did it.

Trying some ways to visualize the recursive rendering for the Article I Want to Write On The Alpha Doom Renderer. I think this works out quite nicely, and indicates some of the fun aspects of the recursive stepping problems John Romero brought up, like how sector 10 is stepped into twice and sector 1 is stepped into 4 times in this view.

The lines that appear before each iteration are the clipping bounds for that pass.

it was mentioned the last time this came up, but giving the projectile enough health to survive a hit doesn't work because whatever shoots the projectile first will claim ownership of the projectile because of the reused target field. Maybe you can implement maes idea of capturing revenant projectiles as "shields", but that's probably not the intended idea here. It's generally safest to just give them 1 HP so they die instantly.

web browsers aren't the only things capable of downloading from a FTP server. Specialized FTP clients like Filezilla are still a thing if you need to download from a FTP server. Browsers are just canning it because it's not a common use for them anymore.

FTP itself is a bit of a dinosaur protocol, with the web increasingly pushing for "secure by default" and FTP offering no security features whatsoever. It's not really a huge deal for a little Doom archive, but with the overall support for it plummeting, that bridge will have to be crossed at some point.

In theory it should be saved relative to whatever is mapped as the user's home folder, which I guess you overridden and placed on the F drive. Usually when someone says C:\Users\<username>\whatever they do mean the home folder, but use the C:\Users as a convenience because that's what the vast majority of users use.

In certain cases, I can see that. From what I understand, Doom 64 under load tended not to be as "well defined" as PC doom is (where the game will always execute tics the same regardless of whether it's running at 10 FPS or 35 FPS or whatever). Things like this though really can't be simulated effectively without emulating the entire console, which would be a lot more work, so the source code won't provide much on that front.

they wouldn't have to use this, because the official port achieves demo-sync level compatibility already. It's based off of Kaiser's own efforts to reverse engineer the game.

Apparently during Doom's development Romero was playing with some NeXT features in DoomED like shared objects, which allowed for DoomED to be networked. I can't remember the source on it, but there's a story of it where one person's laying down lines while someone else is busy placing things in the level.

I assume in practice it didn't get too much use, but it did exist apparently.

this is some good sleuthing, but it is frustrating there's very little documentation. My own searches turned up the potential phar lap connection, but also got caught up in a red herring in the form of an obscure gcc port that also used the "xm" prefix and had a dos extender named "xm" with similarly named modules like "xmdos", but the dates on all of the files I found are from 1990, so it's too early. Phar Lap does come up a lot seeing as it's one of the earliest DOS extenders, but I don't think I've ever seen any DOS binary use it or any actual documentation on using it, so that's annoying.

ed: re: floating point usage: The only floating point use I have found so far is creating the sine LUT. I haven't turned up anything that occurs in the game logic.

I dunno if anyone's too interested in hacking the 0.2 and 0.3 alphas, but I've found a brute-force way to generate a flat executable that can be loaded into a disassembler. I've tried Ghidra, but it should hopefully work with IDA

1. Locate the start of the code section (I dunno, I think it's a code section). this has the signature EB 0E 64 62 67 6F 74 6F 20 3D 6D 61 69 6E (ë dbgoto =main in ansi)
2. Nuke every byte in the binary before the EB
3. Add more bytes at the end for the data. How much? I dunno, there's probably a field somewhere in the header that says. I padded my executable to one meg to be safe.
4. Load that mess up in Ghidra as a flat binary. Can specify x86, 32 bit, GCC and it seems to work just fine.
5. Stare at that mess in the code browser.

This seems to work. Mostly (I've only tested it with 0.2 atm, since that has extensive debugging symbols). The compiler and linker used for Doom 0.2 and 0.3 is weird (does anyone know for certain which compiler was used to begin with?) and seems to group string and other literals by input file with its functions, and starting the flat binary at the start at the segment seems to align accesses to these literals properly. I wanted to figure out more about the executable format itself, which would probably be vital for any extensive hacks, but I honestly couldn't make heads and tails of the dos extender binary involved. It's pretty tiny, especially compared to DOS4GW, but still beyond my scope.

There are some problems I've observed with this. Some functions don't seem to get called right, and the main function isn't properly detected so it needs to be added manually, but unless I could figure out what sort of relocation data is present, this is the only way I've been able to make anything work.

I'm somewhat familiar with xttl and Quasar's work, and I remember many years ago Quasar talking about architectural differences in the pre-beta release. It's all very neat, and I admire the things the two have managed to pull off. So far as I'm aware though there's never been much work done with any of the earlier alpha versions, which is a shame since they bury lots of interesting secrets and tell a tale of the game's evolution, especially on the rendering front.

I added emulation of the high color modes for demonstration purposes, and I honestly can't tell if things like browns and pinks (and to some degree reds) not losing color as much in the distance is worth basically being forced into low-detail mode

for the past week. please send help.

gonna be honest, I can extrapolate from a single tutorial prompt "here's an arachnotron. he fucking sucks, but he sucks much less if you can blow up the bigass gun" that "if a demon has a bigass gun, you can shoot at it to break it" which is basically what all weak points are. The game is brutally honest that the "weak point" is basically always a bigass gun. The mecha-zombie's arm, on the other hand, isn't a bigass gun, it's a little blaster, so I wouldn't expect to be able to shoot it.

Doom had no online servers. The concept of game servers as we know them was pretty much nonexistent. There were some services that let you play online, the most famous being DWANGO, which was a dial-up service. I recall an attempt to emulate the DWANGO protocol, but I don't think it was ever finished. Other common options included Kali, which would allow tunneling the IPX packets over a TCP network, allowing Internet play.

If you're using DosBox, there's no reason to worry about any of these, as its IPX network emulation should be able to communicate over the internet, and you can set up your game as if you were just setting up for LAN play back in the day. The period options are simply unlikely to work under DosBox, since it doesn't provide adequate emulation (ie for Kali) or it would rely on a now-dead service (DWANGO)

Join me again next year, when I'll be listing the Top 35 sector tram lines.

Well I'm gonna have to step up my game in Evil Unleashed if I want a chance to place here...

All of these boats are so cute. Everyone says Doom shouldn't be done for these sorts of things, and to be fair that's usually true, but I love what mappers are able to pull off with both stock and custom resources to add just that extra familiar touch to their maps.

I'd definitely believe it for good monitors these days, but I am morbidly curious, have you done any testing with modern TVs? Their game modes help a lot (playing Project Diva with game mode off by accident was almost magical in how horrible it was), but the impression I've gotten from others is that they still tend to fall short of good monitors.

I remember ling proposing the idea that it's a heat distortion effect (a la the original Predator), he had some screenshots of the game modified to only copy pixels without darkening and it looked like that. It's possible the darkness was added later with the intention of making it more visible, but they didn't account for the same pixel being copied multiple times.

edit: I found the post in question

I recall Kaiser mentioning he had a trick where he'd go into automap before the BFG ball comes out in order to try to avoid this issue.