Lollie

Oh yeah like, I mean in a similar vein, rather than 1:1 identical. And ah, well lol. Maybe with some additional tinting for floors and walls (based on facing direction, etc), or by making textures fainter somehow so environments don't become entirely featureless, oops.

If spectres are only meant to be barely visible, but the player's eyesight makes spectres impossible to see at all, then the effect becomes a detriment to gameplay by no fault of the player. The way to handle it would be an accessibility toggle, to either change the effect or disable it outright. We don't have to be precious about intended gameplay design here. On the topic of accessibility for visibility, I want to point at a couple modern games with great accessibility features: The Last of Us - Part II and Ratchet & Clank - Rift Apart. (Links point to Sony detailing TLoU-P2's accessibility features, and an accessibility review of R&C:RA) Both games feature a "High Contrast" mode, which allows for everything in the game to be given color tints based on what category of entity they are, eg: Enemies, Allies, Items, Hazards, the environment itself, etc. These colors are customizable to suit a player's preference - this also happens to aid color blindness, as color perception is subjective to the player. Links to videos that these screenshots came from: The Last of Us Part II: Accessibility Features - High Contrast Mode Comparison and Audio Cues Ratchet & Clank: Rift Apart - Accessibility Review I think this sort of visual feature would be a good fit for Doom ports. You could handle it by say, remapping color palettes for sprites and textures, or altering the way environments and lighting are displayed (eg: permanent light-visor lighting plus grayscale colors, or by disabling textures). Even a specialty-made graphics-replacement WAD could handle a good chunk of it, making it a vanilla-compatible option.

It's already been said, but I just want to echo the sentiment: The inclusion of an accessibility version rules, happy to see a port finally make an attempt at tackling this.

FWIW, the topic of flashing lights as potential epileptic triggers has come up in the Master Edition thread before (particularly around Pages 56 and 57). I suggested slowing down the speed (or smoothing the variance in brightness) of certain strobing light effects at an engine level, so that the lighting effect is still retained, just not as rapid/strong. Unfortunately there's only so much that can be done to account for epilepsy triggers, since a lot of potential flashing triggers are a result of gameplay. But I do still feel it's worth considering for map lighting, at the very least.

Ah, I didn't mean being able to switch limits! Good to see that this can be done with a custom build though. What I meant was a way to monitor when a map would exceed the original limits, even while higher limits are being used, and then pop up a message as a warning (or print to log.txt). Though now that I know that the "LIMIT_REMOVING" switch is available when building, I guess it'd be sensible for someone targeting compatibility with PSX Doom to just use a custom build. (Unless someone wants to make PsyDoom Render Limits)

This update is a wild one, I never expected any amount of Lua support! Doom 64-style gradient lighting is fun too, really hope map-makers take advantage of these features. Seeing that limits have been raised/removed, is there a way to warn/log when a map exceeds PSX Doom limits? Maybe via a command line option?

Does data need to be duplicated? It doesn't seem unreasonable to introduce a way to tell Doom, "We're playing New Levels Only, so here is the list of levels that we want to play," and then cherry-pick levels from the complete WAD. For example, a set of MAPINFO lumps for PSX Doom, where each one has a different list of "next map" definitions, depending on what playlist is selected. ;"Complete" MAPINFO1 map MAP13 "Downtown" { levelnum = 13 next = "MAP14" } ;"New Levels Only" MAPINFO2 map MAP13 "Downtown" { levelnum = 13 next = "MAP15" } I understand though, this would require a new feature that isn't native to Doom, let alone PSX Doom, and so it's obviously easier said than done. I don't know the inner workings of PSX Doom or what it's capable of, how the current "game select" feature works, etc. I'm just spitballing ideas here. --- What features, specifically? As far as I've seen, the whole point of the project was to convert the cut levels so that they'd fit the style and limits of PSX Doom. The cut levels are still reduced from their original PC form. Players aren't going to be bothered that some of the new levels have higher ceilings, or that some of the new levels have more detail than the commercial levels. If the problem is that the new levels still look better than the old levels after being chopped down, well. That's probably because the map team here has more experience (and time) than the Jaguar team did when they were chopping maps down to size — maps that ended up getting used across many different console ports, including PSX Doom. In comparison, this project doesn't have the time constraints of a commercial release, and only needs to worry about what PSX Doom can handle. Like, what else can people say? "Oops, these levels don't look simple enough. They look better than the old commercial levels. They need to stop looking so good." Y'know? lol The commercial levels would still benefit from the new engine features and fixes, without needing to touch them up at all. PSX Doom didn't have support for the PSX Mouse or analog controls, so that alone would be a huge step up for the commercial levels. Any optimizations made in the GEC version of PSX Doom also carry across, so the commercial levels would run better. --- The originals shouldn't need to be polished though, is the thing. Not if the map team has done their best to convert the cut levels to suit PSX Doom. At the very most, the originals could use some bug fixes, like the Baron of Hell stuck in the ceiling of a pillar in Command Center on Ultra Violence, but the changes required would be minimal in comparison. They're also not critical — fixes would be nice to have, but PSX Doom has survived as-is for 25 years. Does your secret exit in "They Will Repent" lead to "E4M9: Fear", or to another new map at least? Because as long as the secret map is also a new addition, TWR would always have the same secret map to exit to. Either way, no-one is asking for a strictly-PC set of levels, so: No, you wouldn't have to delete anything. It'd probably mean that the secret map after TWR would lead to a different map, depending on what maps are available. Ultimately, *how* the Master Edition's levels and the commercial levels get woven together isn't a big deal. There's plenty of options, and it sounds like it will happen in the end either way.

This sounds like the most ideal solution, if it's possible to set up, since it would mean there's only one "Master Edition" release to manage. You could choose whether you want the "Master Edition" playlist to play all the levels (old & new, mixed together), or the "New Levels Only" to only play the new additions. (And maybe, "Original Doom" to only play the old levels, with the new engine features + fixes?) ...That said, if the original maps were to be included, someone would want to fix some of the bugs in the original release. Compared to the new level additions, bug fixes would be much smaller changes, but it would still require time to fix + test. (a few bugs have been reported in the PsyDoom thread, for example: [one] and [two])

Doesn't matter how many times I see this response, it doesn't make sense. "Master Edition" implies it'd have everything, restoring cut content alongside the original. And it'd be a real shame to not allow the original content to take advantage of the improvements and fixes made to the engine.

It definitely shouldn't be empty. Doom.bin isn't human-readable in Notepad++ (it's a disc image full of game data), so you'd only see a bunch of garbled text and symbols, but the bin itself should be around 277mb. (Final Doom is around 238mb)

A little launcher would be great imo. Something that you can add each .cue + title to, or a little prompt that asks which game to launch if it detects more than one valid .cue (DOOM.CUE, FINALDOOM.CUE, etc).

But... At the very least, the old behavior results in a less wrong aspect ratio. Compared to this new behavior, which foregoes all forms of aspect ratio by stretching the output to fill whatever resolution is thrown at it. Oh well. I play with the corrected pixel aspect ratio anyway, the original behavior still exists, nothing is actually lost here. Just very weird to make this behavior the one that is available via the setup tool, while the old behavior is stuck behind config-editing.

Oh god no, it's spreading. Why is this the new behavior? Surely even less people would want this scaling mode as a feature, right? ...I say, glancing longingly at Tall Doomguy's beautiful monolith-like mugshot. How could I possibly say No to him. (I'm saying No though, this is hell.)

The internet tells me that it's 3.65:1! For comparison, theatrical widescreen is 2.39:1. But why stop there? We can go as wide as our monitors will allow. Tall Doom is also valid.

While this stance makes sense for Chocolate (my stance of "all configurable settings should be available in-program" is just one that I hold for all programs tbh, not specific to Doom), something needs to be brought up here. When "aspect_ratio_correct" is set to 0 in Crispy, its behavior is even more wrong: The frame will stretch to whatever size the window is set to. This is a deviation from how Chocolate handles this setting. Chocolate's "aspect_ratio_correct = 0" is identical to Crispy's "aspect_ratio_correct = 2". So, probably safe to assume that this is an unintended feature, lol. This explains a lot.

...Yeah, any setting that is only accessible via editing the config, should have at least one way to access it in-program, even if it's only via Setup. I agree with that. I actually had no idea "aspect_ratio_correct" went higher than 1! It has the effect of forcing 1:1 pixels, and handles the whole "when the user resizes the window, automatically calculate a new window size to fit" thing properly. Incidentally, it took until now for me to realize that the config does in fact have an "integer_scaling" option too. This setting isn't available to edit via Setup either. Both settings come from Chocolate Doom, so I guess these two settings would be better handled upstream — if they get handled at all.

This is... not a good car analogy. Your car analogy doesn't really apply here, sorry. I understand the pain of wanting cleanly-scaled pixels. Doom sadly does not easily lend itself to integer scaling, but there are options. #1: Use the Setup tool. Yes, it's inconvenient to have to use a separate program to access the one setting you need (and I truly don't think there's any problem with simply adding it to the Crispiness settings), but think of it this way: Once you've set up Crispy to look the way you like, you shouldn't ever need to change those settings ever again. #2: Edit the config file "crispy-doom.cfg" in a basic text editor, like Notepad. Look for "window_width" and "window_height". Yes, also inconvenient. #3: Get yourself a 1200p, 1440p, or 4k monitor. When Doom's 5:4 scaling is applied (turning 320x200 into 320x240), the adjusted height will scale up by 5x/6x/9x to fit the height of the screen perfectly. You can live in a world where a car can have four wheels, and it drives just fine, no magic required. (It just happens to be an expensive answer. Like a car. This is another bad car analogy. It's also inconvenient. There's no convenient options, I'm sorry.) The final option is to just, like, live with the scaling. Let it wash over you. You won't notice it while you're actually playing Doom, I promise.

@MAJ, in particular, you should read through the Doom Wiki article on Aspect Ratios. This is a detail that has already been established for a very long time, for good reason and with good evidence to back it up. It also isn't unique to Doom — this issue popped up in all sorts of games across all sorts of consoles and PCs from the era. Look towards NES, SNES, Sega Genesis, Amiga computers, etc. Nintendo in particular offers scaling options for NES and SNES games on Switch, and this is a feature that appears in a lot of classic game collections for the same reason. 320x200 isn't a 4:3 aspect ratio, but the thing is... CRTs didn't really care about aspect ratios like that, they would simply stretch the incoming video to fit their screen. And in an era where standard-definition CRTs were king, aspect ratio was rarely considered anyway. CRT resolution isn't measured in "pixels" the same way modern displays are, so resolution and aspect ratio didn't matter in the same way — performance was more important. Inside the spoiler tag below is a comparison image from this thread that I've linked a couple times already. It serves as a clear-cut example as to why the vertically-stretched pixel aspect ratio is the correct one.

That "normal" picture is actually incorrect. You're expecting the pixels to be perfectly square - a pixel aspect ratio of 1:1 - which is a perfectly understandable expectation. But the thing is, Doom was designed around the limitations of a 320x200 VGA resolution on 4:3 displays, causing a pixel aspect ratio of 5:4, making the individual pixel 120% taller. This is what Crispy emulates when "aspect_ratio_correct" is enabled. It's correcting the pixel aspect ratio to match DOS Doom's intended design. As for the black bars on the left and right sides of your screen: Set your Widescreen Aspect Ratio setting to "16:9" or "Match Screen". "16:10" fits screens with a resolution of 1920x1200. "16:9" is for your everyday widescreen monitor (eg: 1920x1080, 2560x1440, 3840x2160). Admittedly, I do agree with this. It's obvious why the Setup program exists for Chocolate Doom (and it's still useful for network and audio), but considering how many additional settings Crispy offers on top, maybe all of its Display settings should be accessible in-game.

Regarding the screenshot, what were you expecting to see after toggling Widescreen Aspect Ratio? Do you want the status bar to be scaled up so that it fills the width of the screen? Also, why would you need a second option for aspect ratio? Are you talking about the window's aspect ratio (4:3, widescreen, etc)? Or are you talking about pixel aspect ratio (force Crispy to render tall pixels)?

Just moving this into the Crispy thread since it's more relevant here, didn't want to derail the Marshmallow thread! ...I was totally unaware of this Windows shortcut for pinning windows to the corners of the screen, and now I see the problem that the new behavior causes. When pinning the window to the screen corner, Marshmallow tries to recalculate its window size based on the chosen aspect ratio, and it resizes itself beyond the current monitor's screen boundaries. In comparison, Crispy correctly pins itself to the screen corners. That's a fun trick, Windows. One idea that comes to mind (assuming Windows doesn't break this): Maybe one of Crispy's window dimensions could be forced to be always consistent when it's resizing itself, and then you do a test between three things: The current monitor's screen resolution Crispy's window position on the current monitor Crispy's new calculated window size If Crispy's new window size extends outside the current monitor's screen boundaries, bump Crispy's window position so that it fits back inside the screen. (And then, if Crispy's window simply won't fit the monitor's resolution, forcibly resize the larger dimension until the window fits)

Sure, the easiest way I can demonstrate the difference is with a gif. For what it's worth, I tried bringing up Crispy's widescreen behavior as an issue back when it was first introduced, but you seemed to be against changing this behavior. Or we might've had some miscommunication or something. 😅 Ahaa, good to know! I guess it'll appear in Crispy soon enough.

Very happy to see this port is still being actively worked on, I love its gameplay features! The only thing I can point out at the moment is that the Marshmallow menu doesn't function while paused: It lets you move the cursor once, and then no more until you unpause. This might be a little out there, but I'd love to see some presets for Marshmallow settings, for cases like having full-vanilla settings or "recommended" Marshmallow setups. Maybe a "Marshmallow" subfolder where different configs could be saved/stored and cycled through. Is there a command-line option for loading specific Marshmallow configs? Did you alter how the widescreen toggle works in the Crispiness settings? If so, highly recommend submitting a pull request to Crispy, it feels way better than the toggle's behavior in the current release of Crispy Doom 5.10.

Another one that you'll be happy to learn about: PsyDoom, a reverse-engineered port of PlayStation Doom to PC.