SaladBadger

a couple of people, me included, have had success working around the visual corruption bug by enabling 4x MSAA. No idea why that works..

I mean, I hate to be that guy, especially since the author has tragically passed away (RIP), but that doesn't really count either because it's nowhere near complete. If it was, then I'd gladly accept it as one of the weirder languages used for a Doom port. I think in general there's just not a lot of ports to non-C like languages because it's a lot of work for little gain. As a bored side project I've been considering doing a port to C#, but it's just following in the footsteps of Mocha Doom, with some additional conveniences that Java doesn't have. I think there's also been some attempts at porting it to Rust, which does implicate some architectural changes due to Rust's heavy focus on memory safety.

I experienced the same bug in Chocolate Descent, when I debugged it with RenderDoc what I noticed is that Discord was overwriting the texture bound at GL_TEXTURE0 with its new framebuffer texture, so I added code to rebind it before drawing the framebuffer and it fixed the problem for everyone who's ever reported it to me. I don't know why discord rebinds GL_TEXTURE0 and then fails to restore it, but it works? Not like it's a huge perf penalty or anything either, many games would already be doing at the very least one bind per frame...

I think the biggest barrier to changing monster spawns based on difficulty is that it opens a gigantic can of worms with regards to on-the-fly difficulty changing, a feature in 2016 and Eternal, and for that record almost all modern games... The only Doom game to have changed spawns based on difficulty and the ability to change on the fly was Doom 3, and it wasn't particularly well done. Damage traits would change normally, but spawns wouldn't. It's also more design work to set up, compared to adjusting AI traits and the like

Great success! It seems to work perfectly now. I checked with MSAA on and off and both seem to work just fine.

link since large screenshot I did a couple of tests. At the usual resolutions I run windowed old games at (1280x960 and 1920x1080), when turning off 4x MSAA, the game would simply become a seizurefest, sometimes rendering black, sometimes rendering a perfectly normal frame, so I tried some other resolutions, like fullscreen 2560x1440, which produced the exciting new artifacting that was seen in the screenshot above. This is definitely more what I would think of with a sync bug.

Regrettably not quite out of the woods on my machine, with a Radeon RX 580. I think you're on the right track though, occasionally a perfectly normal view flashes through the corruption. To be completely honest, I can't 100% rule out a problem on my end, but all other Vulkan programs I can try ATM, such as Doom 2016 or GZDoom all seem to work fine, so I'm not 100% sure. Hopefully the test hardware can reveal something...

It works out of the box now, still framebuffer corruption, though. Though apparently it works on other AMD hardware, from fenderc's post? that's interesting.

TBH there's two traits to the corruption that make me wonder if it's a side effect of me expanding the block size in the allocator to make it work in the first place. The two things I've noticed are that if you expand the canvas, like 1920x1080 here, there are some blocks of the screen that are perfectly fine, and there's also other odd traits like brown colors "winning" over the corruption

Sorry for the double post, but I'll stick this in a different post because it's a different bug: the idcloak cheat doesn't appear to work properly for AMBUSH monsters, they'll still see you if they hear you shoot.

I built it on my AMD machine, and got this Assert failure raised from here when I tried running it: The minimum alignment reported from getMinAlignment() on my machine is 4096, but the desired alignment is 65536. Confusing, since that comes out of the vkGetImageMemoryRequirements call. ed: looking at the code further, the 4096 is a constant on your end. I'm guessing AMD's alignment traits are too much for that. also weird. From further experimentation, they can vary wildly. 65536 is only what the dummy texture created at the start gets, I'm also getting 131072 and the like after bumping up the constant. (yet another edit: I think the alignment traits are to put it on a boundary that's the size of the required image data, rounded to the next power of 2 if it doesn't exactly fall on one, so it can get arbitrarily large... Definitely not a good idea to rely on a fixed alignment here...) ed2: the results of bumping that constant up to 131072 are certainly exciting and interesting: But it's fine when the menu is fading in and out? Still confusing. Switching to the classic renderer works fine.

Duke 3D is weird like that. It's designed to look like a real place, but it still remains very abstract and strange when you apply logic to it. Some of it is engine limits, with things like why the freeway level is just a small span of road, and some of it's weird design decisions like this carpeted bathroom with a sofa, but somehow it still remains memorable to me, so I guess they did something right.

ok, but if things are "supposed" to write data to their working directory, how do you handle things on unix-y platforms, where normal users can't write to /bin/ or /usr/bin/? or are you saying that applications should never, ever be installed to a location where they can't write to their own working directory?

Carmack's rationalization for the decision, logged in his .plan file at the time, was that not having to focus on singleplayer PvE experiences results in a tighter PvP multiplayer experience, since they don't have to effectively design two games. All the time making single player levels, designing and balancing enemies, working out the game flow, and all of that can be devoted entirely to multiplayer PvP. MP was hot and many more people were getting internet connections by this time, so it made sense, and hey even Epic was doing it with Unreal Tournament.

trying to hack support for windowed mode into Descent 3. it's been tricky so far, but it almost works.

There's something about the binary that's tripping a lot of red flags in malware scanners. After fighting Chrome to download it, I successfully downloaded it only for Windows Defender to promptly quarantine it. I cannot confirm if the executable is actually tainted or if it's just tripping up false positives, though. It's one of those really generic signatures that don't give a lot of information, and there's a lot of reports of false positives on it. I guess that's just the annoying reality of this world. Bad software gets too good at blending in, so security software has to get overzealous..

for whatever it's worth Ling once found drivers that use Doom's external control API that allowed SR50+turning since they didn't scale sideways movement to the -40, 40 range like Doom's own input does. Of course, there's no reason to emulate this in a port, but it is something that actually did happen.

TBH being my first time around my approach wasn't particularly rocket science, so I don't know how helpful I can be, but I'll gather up all I did here and some related notes. To get started, I was pointed to ghidra and the LX loader addon, and I recalled xttl's tip from the exe hacking thread on how to strip the dos extender: Delete all bytes in the executable up to the second MZ header. (I was also pointed out to the fact that there's a Watcom binding tool that can do it present by mistake in one of the earliest Descent shareware releases, but I couldn't find it. It's not needed, though). I chose Doom 0.5 specifically because it was built with full debugging information (though this does have some side effects, since it means stack checking is enabled, which interferes with the decompiler in some weird ways), which accelerated things a lot because it contained full information on all of the structures in the executable, as well as complete listings of all stack and register variables in every function. Sadly, I don't think there's been a lot of effort on figuring out the formats for this data, only the more limited symbol tables that are present in 0.4 up to the PRB. I just kinda brute forced it, since before each field name in a structure, there's a byte that starts at A, followed by a byte that contains the offset of the field. The A seems to be part of the offset, as it becomes B on some larger structures. This shouldn't be too hard to figure out in detail. With structures and function names in hand, I set out to map the functions and global variables, which was an adventure. This, in theory, could be done much faster with a script, since xttl has figured out the format of the symbol tables. Even then, though, Watcom's linker is simple and things simply appear in the order they appear in the symbol table (which is the order they appear in the core source code), so that's how I ended up mapping things. I started from the first couple of functions in the executable (though the ASM texture mappers are the first bits of code actually present), and did a first pass of the entire executable by simply naming functions and globals while filling in rough params, and then I went through to assign and verify types and clean things up on another pass. I've been pointed to this language spec file which implements Watcom's unusual calling convention (first four params are eax, edx, ebx, ecx, and then the remainders are passed RTL on the stack like usual), which helped make the work go faster. From there it was just smooth sailing as I figured out how to work the program. One thing I did have to get used to was identifying patterns. FixedMul and FixedDiv are inlined, unsurprisingly, which leads to some nasty looking C code: lVar1 = (longlong)(extraout_EDX << 3) * (longlong)cosines[temp_37f9af4087b]; player->momx = (uint)lVar1 >> 16 | (int)((ulonglong)lVar1 >> 32) << 16; lVar1 = (longlong)(extraout_EDX << 3) * (longlong)sines[temp_37f9af4087b]; player->momy = (uint)lVar1 >> 16 | (int)((ulonglong)lVar1 >> 32) << 16; FixedMuls can be identified as a IMUL reg; SHRD EAX, EDX, 0x10; in the disassembly, but eventually I just got used to identifying the pattern in the C code. (also the register work throws it off, in this function extraout_EDX is just one of the params to the function) Once it was time to port things, I mostly ported things by parts. Ported the low level code to my new SDL backend, ported the asm drawing routines, ported the level loader, then ported the renderer, ported the play loop, and then finally ported the overall game and demo loop. All throughout this I did cleanup on things that weren't quite correct or I messed up on. This is about all of the specific details I remember encountering on this project. Also, it's pretty cool that level IO code for this format is present in the DoomEd source. The general format of the level files has been known for a while, but it's pretty interesting to see that the level editor at one point was capable of reading/writing usable maps directly. It should also be a little helpful for the level convertor I'm slowly working on, since it shows how the variable length structures are created (which yeah, I can figure out myself, it's not hard, but given the option to be lazy and read something I'll take it)

To give the specifics, the Doom wad file only contains "patches" for wall textures (floors/ceilings are stored in another simpler format that can only be 64x64). The game takes these patches and composes them into final textures, the intention being that you could do something like take a base texture and put a sign patch on it to create a wall with a sign. These composed textures are stored in TEXTURE1 and TEXTURE2, and I suspect wadext either isn't capable of rendering out the composited textures, or doesn't do so by default. As mentioned, SLADE 3 is capable of looking at these composited textures and exporting them as images.

I'm playing Descent for the 450872346987th time, but since I've done it so many times, I'm doing something else this time. "Laser starts" on every level. I've done a number of the game's levels with laser starts, but forcing myself to do all of them... It's been very fun so far. Especially in Descent 2, where it actually gives the other weapons a chance to be useful instead of just invariably getting set aside for the Gauss and Helix, on some levels at least.

Half-Life is a game I feel I'd get a looot more out of if I played it for the first time in 1998 and not 2013. I think Civvie's video has done a decent job of patching the gap here, at least. Granted, as a kid, to me games were games, no matter if they had a complicated story or no story, or they did environmental story telling or just had you shoot a bunch of things, so I kinda wonder in practice what I would have thought at the time. It's entirely possible to me it may have just been Another Game, a good one sure, but I wouldn't have seen the implications.

Well, as per my usual trends of getting into things many, many years after their prime, I started playing DDR lately. Well, to be more fair, I'm playing StepMania... So I was playing Project Diva for a while. Then I hurt my wrist because I'm fucking stupid or something, I don't know, and a friend of mine recommended DDR as a rhythm game to play in the meantime. I had an aging cobalt flux pad in my basement from my siblings. hasn't been plugged in for over 10 years, probably. During our xmas gift exchange, he and some other friends bought me a PC-compatible control box for the pad. Conveniently the pad worked just fine when I hooked it up, and here I am now... I was more pleased than I had any right to learn that DDR A had created official charts for some of the vocaloid trash I play in Project Diva, so at least I had familiar songs to deal with

I think at least a little of that came from the original Doom press release mentioning that Doom was going to be an "open game," and hey id had seen the wolf3d stuff and was tolerant enough of it so that made sense that they'd do it. Sadly, that open game bullet point was about as representative of the final game as the point about the seamless gameplay, or the information terminals, or wall damage, or environment morphing, or okay this joke is getting old. Carmack and Romero claiming this is pretty good evidence that even those with otherwise fairly reliable memories can't remember everything so clearly, since human brains and memories are weird, man. The game being able to load external wads is about as much of a development aid as it is a means to load user-generated content.

I think the main thing that gave the chainsaw use in Doom 3 was the fact that the thing's DPS was 500, doing 50 damage every tenth of a second. That's kinda fuckin excessive, and apparently with some careful play it's possible to grind up even hellknights with that.

yeah it's not enabled by default, in Descent 2 it's a secret mode enabled by entering the cheat "bittersweet", which is so named because it increases your framerate while making the graphics look abysmal. It's actually a fair bit faster, perhaps a factor in why early consoles mostly used affine texture mapping.