hfc2x

Well, we're trying to get this ready for "release" ASAP, but certainly very soon. Fine-tuning certain maps so they actually work together (because a lot of connections are currently broken.. consider for example that Supply Depot 2 alone has exits to at least 4 other maps), adding or removing story elements, having a functional pause menu, and so on and so forth. The main problem is that we all are currently extremely busy to consistently grind away at the project. @⇛Marnetmar⇛ is starting a new job, and I have a ton of work IRL as of late, for reasons I can't really go into. The reason "release" is in quotes is because this will be a mostly-completed, mostly-playable preview. Because we don't have an artist, things are gonna be a little bit rough-looking. Some maps will likely not be in their finished state either, but playable enough for everyone to see.

I feel like people who keep mentioning this forget the fact that this is a DOS game forcibly adapted to be played on modern consoles with modern controllers, not the other way around. The games that tend to have this degree of control usually are games developed with consoles in mind first and foremost, so they obviously need to get that part right. As a result, however, those games tend to end up having strange and wonky mouselook when ported to PC. There's specific cases where a game is developed at the same time for both PC and consoles, in which cases it controls fine on the target platform, but Quake is not really that. I could probably me misremembering, but I think I remember the devs already mentioned this is the same old PC Quake code base, which was never even conceived to be played with modern control schemes, so that part has been kinda hacked in.

Holy visplanes, Batman!

No, it wouldn't. I've been asked about it before, but Doom: Evil Unleashed isn't an alpha/beta "revival" project, so the alphas and betas (and most of their content) aren't of any use to us in the state they are preserved. The only thing they're useful for is to have an idea of what id Software wanted to put into the game in terms of content and game mechanics, but besides that, incomplete assets are just that: incomplete. Hell, I'd even go as far to say Doom v0.5 is the least useful for that purpose, because by that point the game had already diverged pretty far from the Doom Bible.

Smh my head, this is why Nvidia is winning!!! AMD ARE YOU LISTENING??? lmao Thank you! This is exactly what I was looking for, because if this is really a Mesa bug (which I'm convinced it is), then it certainly needs to be reported as such. The problem is that I had no idea where to start poking, or even how to Google this because how specific this issue really is. I thought about looking at the Arch wiki, but then again, I had no idea how to even look for this specific level of troubleshooting. Fedora 40 should officially be dropping on April, so I think I'll just wait and then see if anything has changed (and if not, then install mesa-git to see if it's been fixed there lol). Guess we can close the thread now.

I don't know where I've given the impression that I have zero idea about any of this. Of course I know 320x200 doesn't perfectly scale to 1080p, and I know how integer scaling looks like with the black border and all. I don't expect things to look perfect, but this thread was mostly a question about Mesa drivers because I know for a fact on my Windows laptop things don't look like this, but that's a different and unrelated thing at that point because Windows doesn't use Mesa. This has nothing to do with what I'm asking. Aspect ratio correction should always be enabled because of how Doom's graphics were designed to look like. In any case, that's in Options>General>Video>Aspect Ratio. Funny that you imply GZDoom "does it correctly", because it has the exact same problem: Here, magnified in case you can't see it: Also, even funnier that it is Chocolate Doom of all things doesn't exhibit this problem at all: Which is exactly why I'm asking if there's some Mesa configuration that I'm currently unaware of that might be the cause because it's obviously not related to these source ports. And that's because it's undeniably a Mesa thing. And I already said it's not really that big of a deal that I care too much to fix, because it doesn't really hinder my enjoyment of Doom, but I digress. All I wanted to know was what particular part of Mesa causes this. No thanks. I don't really see the point of "upgrading" to a lower refresh rate than I currently have to "fix" something that's this inconsequential.

It's not that it particularly bothers me. It's not really noticeable most of the time, just that the fact that pixels were not actual rectangles when the game is set to hardware-accelerated that seemed curious to me. Software mode seemed to do a better job at scaling up pixels in a uniform way, and I just wanted to know if it can be adjusted somehow. If it can't be adjusted, well, it's not a big deal.

When the picture gets shrunk like that it's harder to see, but here, have a magnification:

Not really Linux problems, but I have no idea how to ask this, and I have no idea how I had not noticed until now. The other day I decided to switch over to DSDA Doom after I realized PrBoom+ had reached end of life. After setting the video mode to OpenGL, I noticed it looks a little bit weird: Notice how some of the pixels in some characters look out of place (the second E letter in "Fullscreen" looks pretty bad). Setting the video mode to Software makes it look better, but not perfect: And I thought it was probably just DSDA Doom, but then I realized that any game that uses hardware accelerated graphics has some weird things happening to the pixels if you look closely. Has anyone ever noticed this? Is this mipmapping or something? I'm pretty sure it's actually Mesa doing something funky, and I know it can likely be disabled. I'm running Fedora 39 KDE (X11, although Wayland makes no difference) with the freeworld drivers, and I have an AMD GPU. I have no idea how to Google this problem. Does anyone know what's going on?

This exactly is how some of the monster traps in E4M7 are constructed. The concept is the same, although in that case, it's the monsters who "reverse-raise"? (AKA insta-lower) to your position.

I have a similar, but different theory (which would be obvious by now). I think Sandy saw both the original and extended versions of the E1M1 map, and he thought it was not a bad idea, so he proceeded to make his very own interpretation of the concept from scratch, which became the E3M1/E3M9 we know today. This is probably what happened with E3M5 and E3M6. I don't think the 0.5 E1M1 map by Tom was ever intended to be a hell map or even a map meant for the final game at all, since it's pretty clear (at least to me) it was always meant to be just a "feature demonstration" map.

I don't think it's literally that Tom Hall made E3M6. What I'm assuming is that Sandy basically created his own version of E3M6 based on whatever unknown previous version of E3M6 Tom had made that incorporated the same themes and gimmicks. However, this is just me speculating over the fact maps like these exist:

That version of Doom was built on May 1993. Tom Hall didn't suddenly stop working on that map shortly before the release of that particular version and left the map intact like that. He left id Software on August that year, and he did a ton more work, including creating other maps that have been solely attributed to Petersen over the years: In the same video I posted above, Sandy himself claims the teleporter puzzle in E3M5 courtyard (that relies on light tricks to tell you the correct way out, wink wink) was an idea by Tom Hall, that Sandy says he didn't feel like removing from the map. Besides, the starting area of E2M4 has all of the Tom Hall tells, like all 2-sided linedefs having textures on both sides: And also the entire map fitting neatly within a predefined outline: This last fact is specifically because Tom Hall always made his maps fit a building outline first, and then filling the outline with the actual map. About the SSG, I think it probably was Sandy saying that they should include it in the game, but the Doom Bible already mentioned a weapon that sounded suspiciously similar to the SSG: This obviously didn't make it into the released version of Doom, but (this is just my theory) I think Sandy must have read that and he thought it was a cool concept, so he went and asked the rest of the guys to make it a thing for Doom 2. I suppose that means he technically "got it into the game", but I don't think he necessarily invented it.

This was just Tom Hall wanting to make the game look more like real spaces. The reason you don't see this often is because they fired him towards the end of development. There's a reason it's only seen on specific maps, like E2M4 (think of the first secret) and E2M7, and it's because Hall made those maps. Sandy Petersen talked about this in a longplay decino and dwars recorded of The Shores of Hell, where they chat with him. Romero liked his maps looking nice, but never really put much effort into light tricks, and Sandy didn't care at all. That's the reason why you stopped seeing those things. It had nothing to do with play testers. Btw, this is the video I'm referencing:

Pretty sure he's talking about this: Not exactly a 0-height sector, but something you don't really see in vanilla Doom often.