Csonicgo

Congrats on the hottest take in the thread so far. Equinox in its time (2001) was unlike anything else that had come out at that point. Limit Removing was only 3 years old! Some maps like it were attempted but they always fell off as being "a small-medium map sized up" or a giant expanse of nothing. Equinox came swinging out of the gate with huge set pieces surrounding normal-sized maps, which made those maps feel way bigger than they were. BPRD was also a fan of high ceilings (very, very high ceilings) and big arenas clashing with cramped, small tunnels and twisty hallways, which had been a staple in BUILD maps for quite some time. You can make an argument that people took the wrong ideas from Equinox (SHAWN everywhere paired with solid color all the time, arenas connected by tunnels) but as a mapset from 2001 it's nowhere near "bad" releases of that year.

HDoom is actually good.

Thank you!

I only have one request: a small optional patch to replace the sprite fixing project lost souls with the v1.666 equivalents. I'm one of the few who finds those sprite edits distracting. I have made one personally, but one that honors the custom PLAYPAL by the official authors would be a godsend for me.

The plasma gun uses parts of the warped water textures for the shine. This was relatively easy to pull off in Deluxe Paint, because brushes could be images. Also, you can clearly see the seam in the middle from the plastic moulds - mostly in the bottom of the sprite.

Oh boy, This will be fun! I swear we've had this thread before. There are many technical but stupid things that are/were/should be/should have been deal breakers for me when it comes to source ports (not just Doom ones!) so, uh, here we go, the ones that ticked me off enough: Dropping 32-bit support: One popular source port (which I don't have to name because you and I both know which one it is) has done this, and I've re-written parts of said source port to get it running on 32-bit hardware, with little issue other than some routines breaking now and then, which I also track down and fix. I don't mean "not supplying 32-bit binaries to download", for that would stop 100% of the idiots on ancient machines wondering why they can't run Brutal Doom, but going as far to actively code in checks for word lengths and halt compiles, or any other related arch checks - what purpose does that serve? Is there someone out there who can set up a build environment for a source port and the required libraries for it but can't understand VM memory access violations on a toaster? At the risk of being hyperbolic for comedic effect - I shouldn't need a quantum computer from space to run MAP01 of Doom 2, and neither should you, but don't force me to make a fork out of spite, just let me "do the thing", and I'll deal with the problems. Requiring specific hardware acceleration: This is mostly an SDL2 port thing - not only does this make no sense for a source port that still runs the "software renderer", it also breaks the source port when running on new or niche hardware that can take advantage of the "surface" fallback SDL2 offers, and accelerate it. Eternity Engine still has a "vanilla" SDL surface fallback, which is so much faster on machines like the Raspberry Pi which substitutes its own accelerated routines, compared to the OpenGL routines, likely made for x86 PCs specifically. DISCLAIMER: Yes, I know some source ports might let you do crazy things with the screen elements and rotate the viewport and add plastic wrap but requiring users to be able to render that stuff because a mod might use it, is going beyond the scope of a "Doom Source Port" and into a different territory entirely. No one is seriously going to think worse of you if you can't provide 100% accurate experiences across all rendering modes. Requiring specific esoteric processor extensions: Don't. Also, Don't inline ASM anymore it's awful compilers still do NOT know how to handle it and you WILL cause more problems than you solve, write the code correctly the first time and let the compiler do the work AAAAGH Raising lower limits of options: I guess we ain't playing Doom properly if we can't mix 64 sounds simultaneously? Thankfully I can change the code and reduce the minimum to a saner 8, but 64 is a seriously HIGH minimum as is, why even let us set it in the first place? Who's mixing 128 sounds? Hijacking environment variables: Don't. You don't know what you're running on, don't assume you know. Even if you think you know what you're running on, you really don't. Adding Complex Features With No Options: I appreciate that ports are adding cool things like Fluidsynth, but please give us a way to control these features on a more granular level. Some ports don't even let you set Fluidsynth polyphony in its config files, which should be really easy to add. GZDoom is a great example of doing this part right. Everything can be tweaked in game menus, even if you would never need to! Unoptimized, Unmaintained Fallbacks: I love speed too, but make sure your fallbacks work. If you wouldn't play with your fallback, that's not a good position to be. Not asking for 9000fps on a sunder map, just something acceptable. Or just use a JIT solution that doesn't suck that could work I guess. Code that straight up breaks on anything that isn't a certain release of msvc: Thankfully this isn't a problem... any more. But it's here for completeness. Creating broken play styles for players from whole cloth: I once would get angry about silly things like "terrain effects" enabled by default and "limit lost souls" being off by default, and I will even let "crouching" slide because it's at least useful for modders - but these are nothing compared to a certain source port whose authors decided to change how doom works on a fundamental level - adding vertical spread to hitscans. Who in the world would want to do this? Well, do I have to say it? This neuters the shotgun. In fact, the only reason this change isn't more of a disaster is that the BLOCKMAP collision detection bugs are fixed. This breaks Doom's game balance, in insane ways that should be obvious to anyone who used the Doom shotgun, and since it's in a spot no one would think to check (Player Setup, where you change skins and colors and other harmless things) you might never find the stupid setting to turn it off if you accidentally turn it on - which I've done, somehow. Twice. Since this is in such a silly spot, and players who use this port may not be as knowledgeable about the game as most other players, they may think this is "how doom works" and wonder why they're getting owned by monsters on high ledges relative to the player, and their shotgun keeps missing, because someone thought it would be cool to add vertical spread to hitscans. We have weapon mods for this kind of stuff, right? Why are we building weapon mods into the port? Removing Y movement on the mouse: Am I the only one left who uses the mouse to move as well as turn? This has kept me from enjoying FastDoom and I really want to use that port but the mouse drives me crazy! Source Port Author Calls the community multiple slurs: Actually, this is the only true deal breaker in this list. Sorry you read this far.

I've always found it fascinating how physically limiting the expansion support is - You must physically simulate the "Tower of Power" in the bus chain to get everything to work, which shouldn't matter for 99% of games, until it does on games like this. I have a CDX just for playing CD32X (and 1 or 2 homebrew games on genesis that request access to the Sega CD hardware) because it's the only way to reliably do it right now. You can "emulate" a Sega CD on the cart pins, but you can't run a genesis cart game that requests Sega CD features without a real Sega CD attached - at least, not on the Everdrive Pro or MegaSD. A very weird limitation. I'm hoping someone can make a port terminator that emulates a Sega CD to fix this non-issue :)

This is great news! The major issue with adding voxel support in doom source ports was that the fastest way to render them (or, given our abilities, rendering them at all) was using BUILD code, which was under that ridiculous license GPL ports couldn't use due to conflicts in distribution methods. Having a true replacement for that BUILD code was sorely needed, for way too long now.

Anyone who could access the Internet with a decent 386-486 class PS/2 clone. This was mostly the 18-35 demo who were either in university or worked in the tech sector. the barrier to entry was probably decent enough to keep the little ones from playing :)

Eternity is, for the most part, boom-compatible. The real issue is that it's based on SMMU, which is based on MBF, which did fix a lot of Boom's bugs. The issue in this case is silent teleporters. I did find a topic about this bug, which seems to be a nuisance to mappers, but in POOGERS, it's used as an esoteric strictness check.

Just a heads-up: This mapset isn't exactly "Boom-Compatible". It should be "PrBoom+ Compatible". For example, Eternity Engine cannot play this mapset reliably due to bugs in Boom that MBF-derived ports fixed. Woof! apparently plays this mapset using its new compatibility level feature based on PrBoom+. So if you were using another port besides zdoom-derived ports, that was "boom compatible", and noticed you were whisked away into a shame room on MAP01, this is why.

Can you share your methods in the thread? How did you manage to patch it?

Yes, the Mega Everdrive Pro has preliminary MegaSD support in beta. :-)

I think the new Mega Everdrive Pro Firmware allows for 32X+ features, so this soundtrack should work there as well, if you didn't want to support the MegaSD due to reasons I won't go into here.

The only thing unappealing in these photos is that unscaled status bar.