Csonicgo

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.

If Doom didn't exist, Trump wouldn't have been president. Not saying that's a good thing, or Doom is a bad thing, it's just the truth. To explain why would take me eighty paragraphs, so, uh, trust me on that one.

I shall be doing that Monday. This was a test of the waters to see if this was viable in the first place. This would primarily be for modders to know what features will work in what ports and which ports to recommend or test on. Yes, the aim was to get something solid *enough* to post on a doom wiki sandbox, and then have corrections made there. I wanted to get the community's opinion on this before I wasted any time. :P

As far as I know, Eternity Engine only supports raster images in Doom formats or the DeepSea formats. No GIFs or PNGs. For sound effects, EE only supports the Doom sound format, and basic WAV format, 8-bit, mono. Not sure if 44.1kHz or higher is supported.

I've been working on a document tracking source port support of various "Vanilla features" that have popped up in the Doom community, that Vanilla Doom can technically support. I'm hoping to convert this into a Doom Wiki article very soon. This is by no means complete or 100% accurate. I am aiming to have everything in this table 100% sourced down to the lines of source code if possible. An explanation on some text on this chart: 100% DeHackEd support criteria is as follows: The source port has the correct DHE infighting behavior The source port handles situations in which an argument of a codepointer may be NULL (that is, it must NOT crash!) If the source port has extended features for DEH patches, Vanilla patches should not be affected Source ports should not be expected to load multiple DEH patches, unless any map/mapset/PC/TC expects this behavior. I have not found one in the wild yet. Source ports should not be expected to load DEH patches from earlier versions of DeHackEd. 100% COLORMAP support criteria is as follows: All of the COLORMAP used by Vanilla Doom must be used. If the source port has "high color" rendering, it must take this into account by interpolating between ramps. The COLORMAP must be applied correctly to orthogonal walls, as is in Vanilla Doom. 100% support for Irregular Nodes is as follows: Nodes that can work in Vanilla Doom should also work in the source port. The behavior of any engine using those nodes should match (or approximate) Vanilla Doom. Special effects involving NODES and the associated lumps which work in Vanilla Doom must also work in the source port. 100% support for irregular BLOCKMAP is as follows: The BLOCKMAP must be read and interpreted correctly (see Block Rocking Bytes). Rebuilding the BLOCKMAP is not allowed. 100% support for REJECT is as follows: The original REJECT must be read and interpreted correctly. 100% support for flat-bleeding is as follows: Mordeth bridge effects must be supported. No HOM holes in floors or ceilings. The effects seen in ksutra.wad MAP01 must be supported. Effects used in BTSX to simulate the appearance of 3D floors must be supported. Deep water effect must be supported. Things I'm not adding to the table: Buggy collision detection. This does not affect the loading of maps or assets in any way. Bugs involving actions with the player's movement. Savegames. Extremely out of scope. Demo Compatibility: As we are ditching collision detection criteria, this will not apply. Support for weird old DOS patching tools that assemble a PWAD from raw resources on disk. I'm also not trying to make this a "GZDoom bashing fest". GZDoom was expected to fail every single one of these tests, and the source port's maintainers are very aware of that fact. There are also other ports that I have missed, including Vavoom, Doomsday, Skulltag, and ZDaemon. I do not use these ports, I do not know their behavior. If anyone would like to correct this table, or add any more examples of vanilla maps/patches that do not work in common source ports, I would love to know those. As this is a work in progress, some data in this table may be incorrect if port maintainers add these compatibility features back in. When that happens, it should be noted: the date and commit. I might also go back and add the dates on which other source ports added/corrected behavior before making this chart.