illYay1337

Before I bought an ultrawide monitor, I read Apex Legends is one of the games that does support it well. Maybe it's updated recently. I just played a bunch of Halo MCC and it was great. The score board in Halo Reach was off for some reason but otherwise halo 3 worked great. I then played a bunch of Quake 2 remastered and that worked really well too. It has the same low poly aesthetic as doom and somehow I didn't really get bothered by the warping. I never noticed it, I just beat half the Quake 64 campaign in 1 sitting and it was all great. In fact Quake 2 remastered seemed to 100% support ultrawide because it gave nice clean fades on the sides instead of a harsh transition to black on some screens where it wasn't meant for ultrawide. I might be getting used to it. I need to go and play Sigil 2 soon so I'll see how well that goes. Also for software development. Not bad. At work I have a slightly different setup where I have VS Code in a random smaller window and a bunch of other stuff open and it all works great. I can fit a ton on screen at once and it's very comfortable. My experience with my work monitor was what actually convinced me I like Ultrawide after all.

I swear guys, it's totally worth it! But yeah it seems to not be great for old school 90's low poly games on first impression until you adjust to it. Modern games all look amazing. I don't notice a curve what so ever. I tried Halflife even, and barely noticed any curves. Doom is literally a bunch of flat planes with no slopes, so that effect is exacerbated a bit. Checker patterns on the floor or ceiling also aren't great at first. Once you start moving a lot and get into the action it's better

I'm slowly starting to get used to it more and more as I use the monitor in all sorts of applications. Maybe such a setting will only make it harder to get used to and it's better to immerse myself in this curvedness. It would potentially be trivial to add such a warping setting into a 3D accelerated game, especially like GZDoom, but it might still look off in other ways.

So I finally got an ultrawide curved monitor. It looks great in most games. Doom, on the other hand, has a lot of flat lines, as we all know. Everything looks super warped and wonky. Is there some method to playing Doom well on a curved monitor without things looking so weird? Maybe there's some kind of warp deprojection that can happen. Here's a screenshot with me warping things just to give an idea of what the world looks like to me. The bottom stairs for example is so noticeable LOL. This is probably just the stupid thing I have to deal with due to splurging on an ultra wide curved monitor, but maybe there's a good fix? Maybe there can be a setting to warp the image to compensate for curved monitors.

Oh cool, people played my old map. I actually played it with ZDoom and never had those softlock issues. For some reason I decided to google search this to see if anything pops up. I'm gonna have fun seeing people play at least, and critique it's issues. There's something really fun about seeing people play your own maps and react to it. Well sorry about the softlock issues. Nothing to worry about in Zdoom. But yeah, everyone was super scared of those. I'd fix it if I felt it was worth it. Maybe I might just for the hell of it if idgames allows me to update things. I actually honestly thought this map pack would work in vanilla doom because I made it using only vanilla features and assets.

Ah it's actually hilarious what a mistake I made. It was brighter because of a mistake in the triplanar shader not because the engine was making things brighter. I tried regular solid colored textures and the same odd artifacts were visible for me. The brightness came from this: return // North / South getTexel(northSouthUVs) * blendWeights.z // Floor / Ceiling + getTexel(floorCeilUVs) * blendWeights.y // East / West + getTexel(eastWestUVs) * blendWeights.x; I was over brightening the pixels which happens with any angled surface but never with 90 degree surfaces. BlendWeights came from a normalized vector, but the sum of the components wasn't 1. I somehow forgot that a normalized vector is of length 1 but the sum of its components is not 1, which caused the 3 colors to blend incorrectly resulting in an overbrigthened pixel. Had to add this earlier in the shader. // make it so the sum of all components is 1 blendWeights /= blendWeights.x + blendWeights.y + blendWeights.z;

Maybe some versions of people's iwad does have this change since I've actually seen it's a common question.

Pretty sure you don't need to worry about this error. It's something I remember looking up a while ago too and is just a general error in doom2.wad that doom builder is catching. Guess they defined SD18_7 twice somehow. If you catch this in your own wads though it's a good idea to fix this warning.

I've been working on a custom shader and I figured things out from here: https://zdoom.org/wiki/GLDEFS I have my custom shaders working but I noticed some issues. First of all, the surfaces with my shader appear brighter but only at odd angles. 90 degree walls and ceilings are OK, and my map is currently using the default shading behavior on 90 degree walls. I haven't tried even lighting or smooth lighting mode yet. Slopes are also brightened. It also seems to do flat shading a bit while non-material surfaces use the sector brightness directly without shading. My rocky terrain ends up looking worse. (However notice how there's no ugly transition from flats to walls thanks to triplanar mapping 8D) Also there's this artifact that's especially visible on slopes. It's harder to see on a still image so I modified my shader to output solid red. These are issues that appear to be out of my control. I tried both using a material and a hardware shader with identical results. When using a material all I'm outputting is the Albedo color so lighting is all taken care of already by the engine and should just be using sector brightness. Hardware shader has identical behavior visually. I have quite a lot of experience with computer graphics and GLSL. I've seen this pinprick artifact in the past when I made a mistake calculating the specular highlight in a custom engine. However here this pinprick is not created by me. Surfaces that are just assigned a texture render completely fine. Here are the material sources for reference. It's essentially to solve the ugly transition in a cave environment between the sidedefs and the sloped floors by doing away with texture mapping altogether. The UV's are determined by world coordinates. /** * Shader that does triplanar mapping which should be great for natural terrain textures * The UVs are procedurally determined based on world coordinates so caves, mountains, etc automatically look good * This can be very useful for Doom where it's otherwise difficult or nearly impossible to align walls and flats * At the moment it's built to take the passed in texture and triplanar map it. * * Made with the help of this article: https://www.martinpalko.com/triplanar-mapping/#The%20Theory * * Future versions or variations might get more advanced, and you could make snowy mountains for example, by having top facing normals use a snow texture * * Usage: Add to gldefs as explained here: https://zdoom.org/wiki/GLDEFS * * You can add either a worldScale define or uvScale define * By default it acts as if you passed worldScale 1.0 * worldScale 1.0 will try to map the texture as closely to how doom would map it as possible in doom's world coordinates * Other values will multiply the scale * * uvScale won't take world scale into account and will just base UV's one to one with world position, so you may want very low values like .001 to look good. * uvScale is slightly more optimized since there's no division by texture size * * e.g. * material texture "textures/ogrodtex/OGRIDRST_triplanar.png" * { * shader "shaders/triplanar.fp" * define worldScale = 2 * } */ Material ProcessMaterial() { Material material; vec2 uvScaleActual = #ifdef uvScale vec2(uvScale); #else #ifndef worldScale #define worldScale 1.0 #endif //to sample the texture in "DooM" world units we divide by its size 1.0 / textureSize(tex, 0) * worldScale; #endif vec3 normals = normalize(vWorldNormal.xyz); vec3 blendWeights = abs(normals); // Z normal faces north/south // Y normal faces floor/ceiling or up/down // X normal faces east/west // Floor / Ceiling need to sample in the -v direction // Walls sample in the -v direction as well, but also flip u depending on facing direction to more roughly match doom's texture mapping vec2 northSouthUVs = pixelpos.xy * vec2(sign(-normals.z), -1.0) * uvScaleActual; vec2 floorCeilUVs = pixelpos.xz * vec2(1.0, -1.0) * uvScaleActual; vec2 eastWestUVs = pixelpos.zy * vec2(sign(normals.x), -1.0) * uvScaleActual; material.Base = // North / South getTexel(northSouthUVs) * blendWeights.z // Floor / Ceiling + getTexel(floorCeilUVs) * blendWeights.y // East / West + getTexel(eastWestUVs) * blendWeights.x; // In the future, if more textures are used for other material components, sample them in a similar way // Future versions can also sample a totally different texture for Floor, for example, to add snow or grass to tops of hills // You could also sample different textures based on elevation in world coordinates, so high peaks are snowy while low areas are grassy return material; }

Oh cool, I could potentially make a library of more complex things if needed in zscript. But yeah it sounds like for basic things like an elevator I should be able to just do most things with ACS still.

I'm familiar with ACS and DECORATE from back in the day. Zscript seems like a great replacement for Decorate, but I'm slightly confused on whether it's usable in level scripting, or do we still use ACS for everything? I can't find specific examples of ZScript used in levels, but it seems like a really powerful thing otherwise. Like if I walk over a linedef I'm familiar with how to trigger a script in ACS, and if that's not possible with ZScript then I guess still use ACS?

I have finished 1.0 of my massive texture compilation. This should be a good base with a variety of themes to build wads. I basically took a lot of the texture packs from Realm 667 for now and cleaned things up for GZdoom. Future versions may include more texture packs. I wrote some new tools for SLADE to help clean everything up and make sure everything is set up the modern Zdoom way, and there are no naming conflicts. The readme has more details. https://github.com/ill/DooM_illTextureCompilation Just as a preview, this is the library of textures you have to work with in Doom Builder 2, and it's all automatically organized by Doom Builder by internal directory names.

I made another update. https://github.com/sirjuddington/SLADE/pull/1391 This time it helps find duplicate texture names across all flats and textures defined as individual images while also cross referencing all TEXTURE files in original doom and also zdoom format. Also it checks for duplicate patches across the ptable file and all patches that may be raw images in a zdoom archive. This should help make sure you have no name clashes when working on a giant texture pack. Especially when merging multiple texture packs together. I also briefly looked at the GZDoom source to see how possible it may be to bring over some of that code over to SLADE to make it read all the different GZDoom language files natively in the exact way GZDoom does so you don't need some special language parsers. It'd be especially awesome to some day have a specialized ZDoom project editor with an interface similar to Unreal/Unity with fancy tools for textures/switches/animdefs/sprites, etc... I'd still leave the level editing to Doom Builder 2 though hands down. Another tool I'm really considering adding is a way to detect textures made in the Textures files that just consist of tiled patches that result in an unnecessary texture. There are so many texture packs where people made a texture that is 64x128 that is just the same 64x64 patch tiled one on top of the other. Being able to detect that and remove the texture entry along with my "Delete single patch textures" tool would really help clean up texture packs.

YES! DooM made it!

Yeah and it seems like tools to find duplicate named entries would help too.