Xaser

For community projects like these, it's generally best to not reserve specific map slots (aside from special places like 01, 30, the secret exits, maybe 07), or at least reserve the right to reorder the maps before release to fit, otherwise the difficulty curve is going to fly all over the place. The theme itself doesn't require an exact ordering, since mappers are free to combine whichever two maps they wish. Relatedly, you're probably best off not targeting exactly 32 maps, unless you're willing to open up more "slots" and then take the best-of-32 at the end of it. Inevitably, many people that claim a slot will end up dropping it for some reason, and even with the 3-week expiration, you'll inevitably wind up in a situation where there are less than 32 finished submissions at the end of it. In cases like that, it's best to release what you've got rather than overextend the project to try and hit exactly-32 -- lots of projects "bleed out" in this phase. Plus, if you're using UMAPINFO, you can tie off the set in a nice bow at the end of it (for ports that support it) regardless of length. I may be choir-preaching, just seen plenty of projects fall into these pitfalls, so I gotta give my usual cautionary spiel about it. :P

You're going to need to produce a finished sprite (or something close to it) to really gather any attention for this sort of project. It's all about the execution, and folks are going to be naturally skeptical since the vast majority of past attempts at this kind of thing have all fallen short.

OK, but counterpoint: https://www.doomworld.com/idgames/levels/doom2/Ports/g-i/impencse

Maybe the mystery at this point is the fact that it hasn't been done well, since the game's been around for a long while and it's not like we have any shortage of great artists around these parts. But those folks are always busy cranking out awesome new stuff -- e.g. I know Cage would be able to pull off an HD Doom set but he's putting those skills to good use on Supplice instead. :P There's one shining beacon of an exception: Cheello's voxel models -- those are fucking great, and nail the style exactly. But even then, those are at the OG resolution, so you couldn't really use 'em as a base for something like this. But you'd be looking at something in the vein of that level of complexity, at a minimum, and that was a Big Ass Project(tm).

True, the neural upscale is definitely the best result, but IMO a lot of the textures ended up looking like oil paintings. The sprites did fare much better though, which is a rarity -- somewhere in there, there's a hypothetical "perfect" HD sprite project if someone is brave enough to the time to go through and pixel-edit everything. Neural upscaling in general is a bit sketchy in hindsight, what with all the modern AI image generation shenanigans going on, but I dunno offhand how many of those troubles the old models from 2018 are subject to. I don't know the tech well enough to make a judgment call on that one, just mentioning it in advance before someone else does. :P

"HD Sprites" is one of those cursed project concepts that never, ever seems to work. The amount of time and effort it takes to replace Doom's entire sprite set, including every monster in the game, is absolutely herculean. Many people have tried (often having no idea how big the project is), and every attempt* has fallen well short of the goal in some way or another. That said, the sketches you're showing look less to me like an "HD Sprites" project and more like a "Stylized sprites" project -- which is actually a way more interesting concept. If you can produce sprites in the same style you're showing off in your sketches there, and just roll with that (rather than try and match the look of the originals "but HD" or whatever), you might just make something cool here. It's still a fuck-ton of work though. [*I'm talking Doom here -- other communities have managed to pull this off, e.g. Marathon, so it's certainly not impossible in theory. In practice, though, we're 30 years strong and still waiting. :P ]

GZDoom doesn't have a ton of fancy music-related features, but it does have a SetMusic ACS function that's pretty straightforward to use. If all you're wanting to do is change the music when you cross a line, toss it in a script and throw ACS_Execute on the line, and you'll be good to go. If you need to do something more complex than that, it's still a good starting point at least.

There are plenty of games that deserve a shout-out, but the one that comes to the top of my head at the moment is Dead Space. It's a rare case where the ideal way to play the game is to turn the music off and let the audio design do all the heavy lifting. Shit's great, yo.

What's with this response? The OP is relatively new to the community, and this is a fairly normal question to ask. I don't know what "memes" you're referring to here.

This sort of thing is pretty much expected when you're playing at low-resolutions -- it's part of The Look(tm). Even BTSX does this at parts. ;P

I still feel like this is a great case for GZDoom's auto-compatiblity stuff -- If a wad explicitly documents which lightmode to use, but doesn't set it in MAPINFO, add a hash for the map to gzdoom.pk3 to auto-set it. Then those of us goofballs who know how to make a GZDoom PR can patch 'em when we find 'em.

A side thought here: if the reasoning behind removing the save-on-exit behavior was to reset the option back to default for everyone, that could also be achieved by changing the name of the cvar to something new, so any previous configs just ignore the old value. If that gets done, and the new name gets saved to the config, that would only require folks to set it from the console once before it "sticks". Since MAPINFO takes precedence anyway, that won't trip up any GZ projects that need something explicit, and folks setting the cvar are consenting to modifying the base game at that point.

That's exactly what I'm saying said in the post you're quoting. I'm not sure what you're trying to say here, unless we're in agreement on this. :P

Ashes is a GZDoom project -- if it's designed to work with a particular lightmode, it should specify it in its MAPINFO. If the author does explicitly support multiple lightmodes or their stance on the topic is "yeah use whatever, they all look fine", then sure, it can be left out -- but far more often than not, mappers aren't using it because they don't realize it exists.

Random suggestion of the moment: none of the MAPINFOs currently specify a lightmode -- it'd be good to set that, so everything looks correct out of the box for folks who are using an existing GZDoom install instead of the standalone release.