dpJudas
Members-
Posts
434 -
Joined
-
Last visited
-
So, GZDoom has replaced its sector light options...
dpJudas replied to Jakub Majewski's topic in Source Ports
ZDoom (Randi) did also make changes the light calculations as well, but my comments back then wasn't about that. The original Doom light calculations differ between flats and walls, which is what I broke and then put back in the vanilla light mode. As for keeping it or not, I don't have a problem with it being removed again. Its not in my power to decide such things though. I don't know what you mean by sudden shift. My stance on these things haven't changed. I've contributed a lot of things to GZDoom but I don't have power to change the defaults of the source port. The lightmode CVAR changes weren't done by me. There seems to be this misunderstanding that all the GZDoom contributors is some unified group of people all having the same opinions and you can read what that opinion based on what is in GZDoom - that's not how open source projects work. -
So, GZDoom has replaced its sector light options...
dpJudas replied to Jakub Majewski's topic in Source Ports
I did indeed change it by accident, but that only really applied to the software renderer. At the time I saw the vanilla looks as a math bug that I then went to fix. The hardware renderer never had the vanilla looks at any point. This wasn't why I added the vanilla light mode though. It was a bit of a trolling move to be honest - after discovering what I broke in the software renderer I decided to emulate that specific look in the hardware renderer to prove a point: a lot of people actually prefer the software version over the vanilla version. By giving people both they could see for themselves that perhaps the better vanilla accuracy isn't always preferable. At least not to everyone. I wasn't the one that removed the extra sector light options, but my personal stance on this matter is that the diminishing light effect is an intended artistic design of how Doom is meant to look like. I don't have a problem with people being able to override it, but I do think the naming convention of the light modes made it extremely easy for a newcomer to Doom to think "Standard" or "Doom" was the intended looks of the game. It simply is not. Personally I would just have renamed the light modes so it would be clear which is the default (Software), make it default it to that one, and leave it up to users to change it if they really want something else. The game should default to looking how the game designer wanted it to look, and the user should have the power to override the artist - that's my basic point of view. -
Did Doom II feel like a slog when it was released?
dpJudas replied to princetontiger's topic in Doom General
I saw Doom 2 as basic "more maps" rerun game back in 1994 when comparing it to Doom 1. I saw Descent 2 as the same thing compared to Descent 1. We were used to each new game making interesting advancements on the engine for each new game and Doom 2 just didn't do that. I was 16 at the time. I think its important to note here that most people didn't focus on the maps or the monsters because we had just played Wolfenstein 3D. Then we saw Doom. Then we went to see Duke Nukem 3D, Descent, Terminal Velocity, Quake, Ultima Online, etc. Who cares about the maps when you have new worlds opening before your eyes when all you had prior to that was 2D games? :) Doom 2? that was just a filler while we were waiting for the next great thing. I can only speak for myself, but that also seemed like what most people felt in my town. -
Code question about Screen Melt and Row-Major Rendering
dpJudas replied to Sonim's topic in Doom General
That's why I said it depends on the scene. If what you see is primarily spans (flats) then the rotate will be slower, but if it is mostly columns (walls, sprites) then it will be faster. The biggest issue with the rotate solution is actually that you really want to avoid having some frames be expensive while others being really cheap. That's why Raisin eventually switched over to rendering everything horizontally. Raisin kept transforming everything by 90 degrees, but that's actually more because the entire engine "thinks" in columns. The clipper clips in columns and even flats are initially columns in the engine. It isn't really for performance concerns that you want to do this. It is just much easier if you can get the final transform for free via the GPU. -
Code question about Screen Melt and Row-Major Rendering
dpJudas replied to Sonim's topic in Doom General
I think it is worth pointing out that rendering everything as spans is only an optimization on modern computers. The original engine did not do this because it violates the principle of constant-Z: to do the perspective division only once per wall column. The reason it is faster on newer computers is simply that the CPU is now so much faster at doing multiply and divisions that the cache hit is greater than the extra math per pixel. If you simply transform the frame buffer 90 degrees you don't actually solve anything, because while your walls are now perfectly aligned with the cache lines the flats are now no longer aligned. If you look closely at the Raisin performance data you'll see a basic transform makes the scenes dominated by wall drawing faster, while being slower if the scene is dominated by flats. To truly gain the speed improvement consistently on a modern CPU you have to get rid of all column drawers and convert everything to use spans. -
Exactly this. We ported UDB to OpenGL and we ported the codebase/project files to support Mono's winforms implementation. The remaining issues requires someone daily driving Linux to be willing to look into doing the final adjustments. Boris isn't running Linux and while I did the work for the initial port, I don't daily drive Linux either. I'm also not a mapper, so I didn't even notice the problem with the node builders. This is one of those unfortunate situations where we need just the right kind of person that has the interest in Linux, Doom mapping with UDB and enough coding skills to debug each of the crashes/issues and find a workaround. We also could need someone with package management experience that will know how to properly build packages for the mono winforms build. Building it from source shouldn't really be something end users should be required to do.
-
So they redefined what the word spyware means. It doesn't really fit the definition that Google or Wikipedia uses. Their description even have to add FUD to justify it by saying we could add more telemetry in the future. We could also format your disk in the next update, you know. Paranoia at its finest.
-
Calling GZDoom spyware is simply wrong. Spyware is software where you're not even given the choice in participating in the hardware survey. GZDoom not only gives you the choice, but also explicitly announces which releases even contain the survey code.
-
The artifacts we see here happens between lines of the same text glyph. Each such glyph is drawn by two triangles. Even a bad projection matrix can't create this effect. It was already clear to me with just the DSDA screenshot that it was very unlikely the source port's doing. When it then is shown that it also happens for an entirely different application (GZDoom) then its goes to incredibly unlikely to be the game at all. Chocolate Doom is irrelevant because even if SDL is using OpenGL it would be outputting only one or two triangles covering the entire window surface. About the control panel thing, what I strongly suspect is going on here is that it isn't actually using a hardware GPU. It looks suspiciously like the kind of artifact the fastest SSE approximation instructions would produce (i.e. _mm_rcp_ps). I used the term control panel purely as a simple way of saying this could be something configured for speed rather than quality. Either way, I'm sure this is a "GPU" issue, not the game.
-
This can't be caused by integer scaling from what I can tell on the images. The most likely source is low quality math in the GPU itself. Maybe there's a setting somewhere in the control panel for your GPU where you can set some quality level. I'm about 99.99% sure that this isn't an issue with any of the source ports. Edit: if you have a spare cable for your computer, try replacing the one you are using for the monitor. This could theoretically be a transfer issue when sending the video signal to the monitor. Edit 2: never mind that theory, since then you wouldn't have been able to make screenshots of it. :)
-
I generally quit (or ammo cheat) any map that forces me into saving all my ammo and carefully consider on each encounter how I kill the monsters with as few bullets as theoretically possible. That's just not why I play this kind of shooter. About RNG in general, I think it great. It also makes you really respect the high damage weapons and enemies in a way you wouldn't do if you always knew exactly what damage it produce. For multiplayer, it makes the less good player sometimes win. Predictable gets boring very fast. Having always the best win is also boring.
-
When Doom 2 came out it seemed pretty clear to me that this was a filler game, recycling the Doom engine while they were primarily working on their next real game (Quake). They did the same thing with Wolfenstein 3D and the Spear of Destiny. In fact, loads of game studios have been doing this and many continue to do it to this day. With that said, Doom 2 actually does improve the game significantly in many ways, since Doom 1 got way too few enemies and the lack of SSG makes the bigger bosses of Doom 1 a chore to kill. Some of the maps you mention were kind of entertaining first time I encountered them and the kids I knew found them funny. If you don't like the maps then just don't play them. There's endless of maps from the community you can play instead.
-
I didn't read about how good Apex Legends works on such a monitor. I personally played it on one. Unless you can show me a screenshot of Apex Legends on a ultra widescreen where the HUD isn't placed all out to the sides I still think my argument holds for why it isn't ideal. As for software development, what I'm seeing on your screenshot is exactly what I don't like about it. Most of the monitor is going unused and its generally difficult to make much use of it. In any case, I'm happy you're enjoying your new monitor - I just wanted to add a bit of context to readers of the thread considering buy a new monitor that there are pros and cons to the form factor. :)
-
I think ultra widescreen monitors is one of those things that people either love or hate. Most games don't take them into account, so the HUD is spread out to the sides to such an extreme you can't really use it properly anymore. When I was playing Apex Legends on mine I would have to change the resolution of the entire monitor to get it letter boxed (16:9 in the game), otherwise I couldn't see the health of my squad members properly, which is a crucial component in decision making on what to do next in that game. On the other hand if you're more into relaxed single player gaming and graphical fidelity, then there's certainly more of an immersion effect if you use ultra widescreen. For desktop usage the story is the same. For some usages like video editing the extra space becomes very handy. For software development I find that it is very difficult to really take advantage of the form factor. For software development a 32" 16:9 retina monitor is so much nicer to use.
-
Ah yes the "lovely" curved monitor effect. I actually notice that even in normal applications. The good news is that at least for me I stopped noticing it after a while, but the funny thing is then I started seeing straight lines on normal monitors as curved instead (my brain had started to compensate). It is one of the reasons I sold my ultrawide monitor and don't intend on buying one again. There's no setting to compensate for this I'm afraid - the closest you can get is the Lens Distortion Effect post process filter. It bends things so maybe it will help on the effect (or make it worse?).