Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content count

  • Joined

  • Last visited

Posts posted by SaladBadger

  1. 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.

  2. 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...

  3. 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.

  4. 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.

  5. 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.

  6. 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..

  7. 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.

  8. 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)

  9. 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.

  10. 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.

  11. 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.

  12. 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

  13. 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.

  14. TBH it's not too hard to see why affline texture mapping bugged Carmack so much. Here's another game that can optionally use affline texture mapping:

    If not managed properly, it can look hideous and pretty disorienting. I don't fully agree with Carmack, I think he should have let him experiment more with the old codebase, since perhaps there are some ways like how playstation devs would use the high triangle throughput of the machine to subdivide polygons that would let it run better, but if you're just drawing the world without any sort of compensation, you get something like this video.

  15. I believe the only sector special added in Doom 2 was the "fire flicker" one (17), this was probably in there beforehand. The idea of opening up a secret vault or something seems like the most likely culprit, but none of the mappers ended up using it. I dunno.

  16. Some of the lines in the upper loop are mistakenly assigned to sector 2 rather than sector 1, like the rest of the loop. This tends to mess with some algorithms to build floor/ceiling polygons, as can be observed in this SLADE screen shot:



    So far as I can tell, the mapper accidentally assigned a sector tag on those two lines, causing the DoomBSP sector making algorithm to think they belong to different sectors. A good GL renderer can work around this problem, since there's a lot of tricks mappers do that have such artifacts, but the iOS GL renderer was written for speed rather than compatibility, abandoning most of these fan-developed tricks, so the map needed to be fixed. (the current Doom Classic ports use the software renderer, so they have full compatibility with them)