simple machines forum

Notice

Yesterday I ripped out the [Keygen] (IMAGES.INI) stuff. I'd been meaning to remove it for a very long time. The timing has to do with it no longer being able to function because I've restructured when the colorkey and mipmapping processing happens to not happen immediately. It had relied on the lowest level mipmaps to manage its database and so no longer could do so.

Funny story this caused a pretty drawn out and perplexing debugging session where many textures (I couldn't understand the pattern) were having the shadow effect applied to them thanks to their erroneously matching the shadow (kage.mdl) model's texture. Some bygone projects had benefitted from this system. It's high time I came with a replacement, that will be based on file names instead of mipmaps. Even the MENUS images that are broken up into smaller images have false names that can be used to address them.

I'd really like to allow for more image formats, like PNG at least. I think I disabled some alpha channel code in the shader that would have broken the ability to load real alpha channel textures. That should be fixed in the future by generating two shaders for textures with and without holes. I need to do that anyway to increase the FPS.

Right, anyway the next patches aren't going to have this system anymore, and it won't add IMAGES.INI to the new projects template.

High DPI Windows Path

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)

Someone (https://youtu.be/TsJMLvlTgk4?t=660) had a monitor with a DPI setting to make the text larger. In that mode Windows would pretend the desktop is smaller than it really is. So in the game the full resolution wouldn't be available in the Options menu.

This patch just fixes that for games. I also spent some time trying to improve the 3D visuals in SOM_MAP because Windows just naively scales up their pixels so it looks likes chunky aliasing. I had some success there, but that's not in the patch. I'd have to work on SOM_PRM too before I can enable that.

Here's something interesting from the past week.

https://en.wikipedia.org/wiki/Open_3D_Engine
https://github.com/o3de/o3de
https://o3d.foundation
https://o3de.org

It's a fully noncommercial game engine under the Linux Foundation (Microsoft and lots of other big companies) with Apache license. It's based on a defunct Amazon engine that was in turn based on CryEngine. So maybe it works with game consoles, but even with Unreal the console parts are withheld, so maybe not. If it's modular maybe in the future I could rig something up to make SOM work with it in some modes if that looks promising. There's many things I wouldn't care to work on with SOM that I wouldn't be opposed to plugging into a fully noncommercial system.

The most significant factor of O3DE is that the engine has been completely re-architected from the ground up as a modular system. This non-monolithic approach means that game developers can use what they want as plugins, according to LF.

Patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)

I accidentally enabled the contrast reduction effect in SOM_PRM where it doesn't look so great when viewing moving models.

PayPal

I've added a donation system to the http://www.swordofmoonlight.net/support/ page here. (Edited: I have serious reservations about it. But I don't want to overthink it, everyone uses PayPal nowadays. Mainly I feel like the financial companies should be taking small flat fees out of transcations, not percentages. Or the percentages should be much smaller as the transactions are larger. It looks overgenerous to PayPal to give them 30$ of every $1000 that trades hands.)

FWIW I think it's probably come time to let go of Windows XP because I'm setting up a new PC and finding out that Microsoft ended support for Visual Studio 2010 in mid 2020 (only 10yrs for such a major compiler, geez) and so I can't seem to get it to work on a new PC.

Without VS2010 it's not possible to debug software properly. It's still possible to make apps that will work on Windows XP in theory until Microsoft ends VS2017 but that's pretty hopeless because if for some reason they don't work you don't have any development tools to fix them with. So the only practical way to keep supporting Windows XP would be to use something other than Visual Studio and that's just not realistic. Especially if there's no movement to bring XP back to life without Microsoft.

By ending support for it it's possible to start freely using more up-to-date features of C++ but I worry those may run into problems on Vista and Windows 7 and 8 all of which I can't very easily support. I do still have an XP computer and a Windows 10 one with a working install of VS2010, but I it's been a while since I tested SOM with Windows XP and I don't expect to do that. Right now I've all but packed up that Windows XP system (which also has a Windows 7 install) to make space for a new PC. I haven't decided if I will mothball it. It doesn't seem practical to cling to the past without cause.

Strikeout: See next post/reply...

Antialiasing enhancement

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)

This patch is an addition to the AA system. I started working on it yesterday and finished it late today. This year I've worked on AA stuff a lot. I realized this would help with the last effect I did but I didn't have the energy leftover then to delve into it.

Edited: Here's (https://swordofmoonlight.itch.io/k/devlog/260491/10-new-final-antialiasing-upgrade) an alternative write-up with an imaginary checkerboard thought experiment to help illustrate the concept.

It seems to help a lot. And in ways I didn't anticipate. How it works is it modifies every other frame's mipmap buffer that's used by PSVR and the contrast reduction system that helps with AA when things are in motion.

The mipmap buffer is like the opposite of supersampling. It's 4x smaller than the resolution. In it every pixel is the average of 2x2 pixels. So what happens when you see this mipmap (usually just a ghost of it) is it looks like all of a sudden the picture is degrading into a grid of 2x2 pixels. (I don't know how to describe this in English, but that's my best shot.)

So what this effect does is on every other frame (the previous and current frames are blended together to make a blur effect that also helps with AA) instead of making a regular mipmap it downsamples starting at the odd pixels instead of the even pixels. That also has a side effect of creating a different downsampling pattern that (when combined) tends to make text look more smooth and probably other stuff too. This also means the pixels on the window's edge have to be thrown away so it's back a to a 1px black border in supersampling mode. (I kind of like how it looks in screenshots anyway.)

So when the picture degrades into 2x2 pixels instead now one of the screens is shifted over by 1x1 pixels (Edited: not the image, but the 2x2 sampling pattern) so that creates an illusion that there's pixel data on every pixel and you don't see the pixelation pattern. Plus I've gone back to enabling the linear filter in supersampling mode (technically when do_smooth is off) because I realized it can help when sampling from the mipmap buffer. It degrades performance (slightly) on the main buffer which shouldn't benefit because the sample should be in the center of its pixels. (The mipmaps are part of the texture so they're tied to the same filtering mode, although I could try to separate them it's probably not worth the effort for now.)

I started working on this because what I'm trying to work on right now has been a bit frustrating and having spent time away I think I could see the supersampling with fresh eyes (I think my eyes adjust to video effects through daily exposure) and was still a little bit unsatisfied. I wasn't sure this would work but it seems to have been just the thing. It helps a bit more with contrast artifacts and I think it improves movement blurring a lot, which is what I intended it for, and it might reduce the perception of little smudges in the antialiasing pattern.

In Moratheia (2.1 demo) I can now move through the spiny trees without seeing any temporal artifacts, at least up close. In my KF2 demo AA artifacts are pretty well nonexistent and I can enjoy playing it with supersampling turned off again. It must look better for that to be the case. For a while I couldn't stand to look at it, at least not in movement. Edited: Also the text is now acceptable in the PSVR mode with supersampling turned off... although the picture is a bit more jittery. I've left it this way just because it's more presentable than smudged text is.

I thought the effect would be messier than it turned out. I thought it would need to draw the odd frame shifted over one pixel. I realized either last night or this morning that it would work just as well to do the shift in the downsample step. That makes it a lot less complicated. It's less intuitive but guarantees no unwanted/unnoticed complications.

DualShock4/DualSense Patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)

I may have messed up the PS4/PS5 controller detection code. I've written some thoughts here (https://swordofmoonlight.itch.io/k/devlog/258963/ps4-and-ps5-controllers-finally-detected) please let me know if you were able to use PS4/PS5 controllers before. If they weren't detected you'd be able to tell because they'd look straight down at the ground and fight you. Anyway this is giving me existential dread so I just want to quietly back away now