Topic: EXIT: Anti-aliasing announcement (Read 11258 times)

Holey Moley · « **on:** March 20, 2021, 07:06:09 PM »

Quote from: http://www.swordofmoonlight.net/archives/sword-of-moonlight/2021/03/anti-aliasing-announcement/

Something of note occurred a while ago. Briefly, for a long time now Sword of Moonlight has had a unique anti-aliasing technique for which I’ve continued to develop complementary 3D image-based graphical effects. This line of work has matured and now has reached a conclusion. It started when I had an idea I thought could address its main weakness: that is it takes more than one image frame to create a double exposure image, which means it can’t anti-alias a single image by itself, or put another way: when a picture is moving it can’t do its job.

This is an economical solution because it doesn’t require any resources or time on the computer to compute its results. When a picture is moving it can be hard to make out its edges, so anti-aliasing isn’t as important. So it mostly washes out, except it’s still a legitimate mark against this technique. To solve this problem (with an equally no resources solution) (as well as it can be solved) the new complementary technique works to remove contrast on moving edges. This looks like an unfocused image on the moving edge.

Shortly after developing this it made sense to implement supersampling for Sword of Moonlight because this anti-aliasing system seems finished, and to supersample an anti-aliasing technique is a common final step, although it does significantly increase the hardware budget to enable supersampling. Supersampling doesn’t automatically buy you much, especially considering its cost. It requires an anti-aliasing strategy to justify its cost, such as the one Sword of Moonlight has. So, long story short, combining these developments produces a very high quality image.

A third thing happened around the same time that’s worth including here: in short, intense scrutiny of the edge contrast technique made apparent deficiencies in the analog control system. A thorough investigation followed, in which not a fix, but a change was made that seemed miraculous in how it produced a much higher quality experience in terms of how movements are transferred from the analog game controller onto the screen. Without going too deep into a description how Sword of Moonlight actually works in this regard is to translate the sensor data from the controller into a very limited digital signal, and then convert that back into the movements you see on your screen. There are benefits to this process versus using the sensor data unprocessed but all that you need to know is the last conversion step is where the major leap occurred.

Finally, in the forum post attached to this blog item I’m going to be publishing previews of the next release, which will also include any patches in the meantime. I will explain the focus of the new release inside.

I've been meaning to sit down and write this blog post for a while now. I've written about this subject elsewhere but I want to commemorate it properly in the timeline.

I think the next release (I'm going to miss "1.2.3.4"

) may be a longer wait than usual. But I'm going to make it available in this topic/thread well before it's officially published. Its focus is on upgrading the magic and weapon buttons similar to the extensive additions to the action button over the years. I may decide to include my planned upgrade to the menu button at the same time to complete the set.

I want to share the new features and may publish them in an incomplete form in my KF2 demo as well as in here in preview form. The difference between the final release version and the preview is only that the preview won't be in the updater menu, so it must be downloaded from this forum thread when it appears. The preview will be 1.2.3.5 and the final version will be 1.2.3.6. I'm also halting patches on the current release, if I can help it. If I feel any "quality of life" changes are worth sharing I'll patch this preview release from hereon out. (If I stumble on a serious bug I will try to patch the current release if my conscience gets to me.)

Work on the shield system is going well. It's pretty labor intensive and time consuming. The work that led up to it actually happened a year or even two years ago. So it's been an ongoing project. The new work I've done this year is already dozens of hours. I couldn't tell you precisely, I just watch the days melt away. I decided I wanted to resume work on this because I was amped by this anti-aliasing/supersampling development, I wanted to treat myself to something I've withheld from myself since I first picked up Sword of Moonlight more than ten years ago.

Yesterday I was going to write this blog post but the day was consumed by first working on refining an effect where the shield must be pushed back when pushing against a wall (because there isn't room for it between the character and the wall and it creates strange optical illusions because it doesn't poke through the wall) by having the shield only push back when the said wall is in front of it. Usually push effects are 360 degrees because there's no sense of a "front" in a full 360 degree game (which most games aren't) however a shield is definitely in the front. It gets more complicated when turning a corner like this since cornering can be very iffy. The effect has to be stable rounding a corner, and also react to dashing (high speed) into a wall or other obstacle. But the worst of yesterday came later, that was a struggle with the walking effect that arises because the shield needs to be not synchronized with the walking effect (so the arm doesn't appeared glued to your head) but at the same time it's very close up and so any sudden movement in the effect is amplified by having the shield as a point of reference. This really put the walking effect code to the test. I got very close to burning out on it. The nastiest problem was since I've so far decided to let the "hop" input work with the shield raised. Hopping is inputted by poking the direction pad and tapping the action button simultaneously, which results in pretty high frequency input into the walking effect system that's followed up by a leap. That's probably the hardest test, i.e. to not glitch too badly, or ideally at all. I mostly got it working. Good enough for now. (This easily becomes a full day of work.)

For the record, right now the shield is pretty high quality in terms of button presses and movements. I've also improved my animation to the point it's presentable. I still have a number of aspects to address. I haven't decided how everything works. For regular jumping so far the shield is just forced to be lowered. That may not make sense if lugging a shield by your side is unbalanced for jumping. But as general rule most kinds of inputs force the shield to be lowered unless there's a reason not to do so. So far regular running doesn't lower it. Dashing and crouching doesn't. Most other things do. It comes back automatically if you're holding down the button.

May 12 Update:

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip

https://swordofmoonlight.itch.io/k/devlog/252682/shield-and-counterheavy-attack-demo

Attached is a DATA/MY folder that shows how to set this up. ItemEdit is needed to make Move Set profiles that just need to assign the number of these files to the first slot. It currently only supports the first slot. If left blank it uses the equipment type number, which is what the 2 and 5 files are. These are also used by the Nothing equipment. Note, to use the Nothing equipment you have to leave at least 2 item slots open. I've actually reserved 5 for later on.

Holey Moley · « **Reply #1 on:** May 12, 2021, 04:36:09 PM »

Update

I've FINALLY published a shield/counter system preview. I've edited basic information into the original post. I'm doing this pretty low key right now because I'm not enabling shields for SOM's original (Shadow Tower looking) arm model. I would if I had more confidence in my animation software. I'd like to add some features to it first. A shield animation would not be difficult, but I feel like the other system is needed for the control scheme to be balanced.

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip

Like I said before I'm going to try to switch to patching this preview for right now. The difference between it and a public release is the updater tool doesn't offer this one in its menu so you have to download manually... although you could edit it into its CSV file if you wanted to.

Holey Moley · « **Reply #2 on:** May 14, 2021, 02:47:29 PM »

Notice

Right now I'm planning to switch gears into less intense work and some R&R (rest and relaxation) and won't likely be posting a lot of updates for a while while I do some exploratory work.

I'm mainly interested in getting into my Exselector project and looking at making a switch to using MDO files for everything except animation and I want to try to play more PSVR games and see what I can do with it with a new work computer I'm going to have to be setting up. If I get deep into Exselector it can easily be a many month project that I might keep mostly to myself until it's ready to be published in some form. It's going to be pretty ambitious, it's like a cross-platform addition to SOM that will provide a lot of technical support stuff.

The SomEx source code is very geared to Windows and it's already pretty bloated. The Exselector code will be self contained and auxiliary to it. It's going to have a lot of third party code which SomEx doesn't really use (Edited: I.e. it's virtually all "first party" code. And to the extent it will use the third party code I will probably try to do it in terms of an Exselector API "abstraction layer".) When it comes time to make SOM cross-platform this Exselector part shouldn't require any work. It's going to be quite a diversion and hopefully it will pay off and not steal too much time from core SOM stuff. Anyway, I need a diversion from time to time to stay sane.

Holey Moley · « **Reply #3 on:** August 05, 2021, 06:44:24 AM »

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.

Holey Moley · « **Reply #4 on:** October 10, 2021, 06:15:50 PM »

New SOM_MAP demo!

WARNING: Installing this patch changes the timing of when textures are processed that can manifest as hiccups in the frame rate, that I intend to address in the next release. Since I was thinking about demoing SOM_MAP I hadn't thought about it when I posted this demo announcement. It may linger until the release after since that's going to deal with dynamic loading/streaming maps that will require some infrastructure for trickle loading stuff mid play.

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip
http://csv.swordofmoonlight.net/Exselector.dll/0.0.0.1.zip

This has been a long release period, so I'm putting out another demo that can really make SOM_MAP a much better experience, so I highly recommend it to anyone actively using SOM.

In the scheme of things this work on SOM_MAP is only about a 1wk or 1.5wk stop on the way, a little diversion, before moving onto the next leg of the next release's goal.

I will say something about it in a second, but I'm also uploading a new DLL called Exselector.dll that I don't recommend, but it can be used to try OpenGL with SomEx by setting directx_version_to_use_for_window=32 in the [Window] section of the Ex.ini file. There's not much use in this, but it's proof I actually worked on it for the past 3mo

EDITED: Exselector.dll is so huge because of ANGLE. To try angle use 95 instead of 32, but it will be very bright because of a bug (and slow) but the bug was announced fixed 5 days ago, so I just have to download the new source code (assuming it's publicly available) and rebuild ANGLE (which is a pretty big task) to fix this problem, in which case I'll reupload a new copy of the same file to the same place that will fix the brightness problem.

I think I'm going to check-in some CODE too, since it's been a while since I last did so. Speaking of that, when I uploaded these DLL files, it was the first time I uploaded a large file with my new fiber Internet service, which really took me by surprise by how fast it went!

There are some critical fixes in this demo for using the new layer system. In the screenshot I've attached you can see 2 layers (of 7 total) for the first time visible together in SOM_MAP. And also notice there are "objects" on display that belong to the outer 8 tiles, which is a new first that can be toggled with the new "neighbors" button.

It's hard to tell in this image but it also has accurate lighting for a change. Because lighting can tend to look much darker in SOM_MAP than in the game (even though the pixels are the same, except for some effects) I've increased the starting brightness some so that it's not necessary to manually do it every time you turn on SOM_MAP. To control the lighting you need a mouse with a middle button, and ideally a fast wheel. I think intend to add the ability to hold the middle button down and drag to adjust the brightness, but it's not there yet, so a wheel is required. Pressing the middle-button will reset the brightness to the default, but this will be less than the extra added brightness I mentioned, since the default reflects the real lighting as you see in-game.

I'm going to add an extension to control this startup brightness with. The starting boost also applies to if you disable lighting. I've reduced the disabled lighting in SOM_MAP so it's not blinding, and I would do the same for the game if I knew where to look in MapComp to make the change (as soon as I stumble across it.) SOM_MAP reflects the disabled lighting, although I'd like to have a way to disable it just in SOM_MAP and not in the game too.

Finally you can also see transparency in the water. Those are MSM models (not objects) and how material properties are being assigned to the level geometry is to make a MDO file in the DATA/MAP/TEXTURE folder that has the properties you want. Then you can either name that file to match the texture (TXR) you want to assign those properties to, which will take precedence, and if not that, then just assign the textures you want to the polygons in that MDO file. The actual model(s) can just be a square swatch. There's a way to assign a UV animation to them too by attaching a fin to the square, but I'm not going to go into that here. Transparency also works correctly for the other elements. It did not before. To do it correct it needs to draw the models in two passes (transparency second) and sort the transparent elements.

The 3D parts of SOM_MAP are recreated in Direct3D 7 code, so that after this all of the tools are using D3D7, which is then translated to D3D9, so it's really D3D9. Originally SOM_MAP and SOM_PRM were programmed in D3D6. You no longer see SOM_PRM's model viewer since a few years ago because it now uses the DLC editors to display the models, which are written in D3D7. You know I found out just a month or so ago (or less) that D3D7 was either not yet out to the general public when SOM was published, or had just came out, so From Software's staff either had early access or really scrambled to upgrade the player component to D3D7.

The new D3D9 path has most of the graphics effects of the player component. In this screenshot it even has the chunky (2x2) dither effect that I don't necessarily recommend for the tools, but I haven't tried to write anything to have the tools use a different dither size than the game does. My KF2 project is using it. Everything is antialiased and I really had to get creative to make the image sharp and fix a Microsoft bug in the line drawing system that the grid and RGB axes use that would kick in when getting the "camera" too close to its lines.

Holey Moley · « **Reply #5 on:** October 11, 2021, 04:00:08 PM »

EDITED: I've reuploaded (SomEx.dll) to add a fix (see next paragraph) and added a warning for a change to the games as a side-effect of this patch.

The fix has to do with "neighbors" on different elevations and cells without tiles (perhaps because their tile is on another layer) having been incorrect in the initial patch yesterday. There may still be some issues in this area.

Holey Moley · « **Reply #6 on:** October 14, 2021, 09:19:03 PM »

Bonus patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip

A few days ago I had an idea to work on giving definition to the other two map views that shown flat gray tiles, since they can be very disorienting, especially on a full map. A lot of unexpected things came of exploring/implementing this.

Before I forget, SOM_MAP now loads instantly. This is because it had kept two sets of icons, one turned 90 degrees. To make the turned versions it had used the notoriously bad GetPixel/SetPixelV APIs. I was surprised that using those to make turned icons could be the bulk of its load time, compared to opening/processing so many files (on an SSD drive) but it was. In the end I actually got rid of the second set altogether and used its memory to hold the gray versions of the tiles. To do this was a bit of a squeaker because the sideways tiles needed the PlgBlt API that doesn't offer any "ROPs" like the others, which is actually a problem for inverting the white tiles, but that's done the same way SOM inverts the multi-selection tiles. The 4 colored circle icons also had to be switched over to TransparentBlt to act like an overlay. Really this just removed the 4 corner pixels because there's very slight (unintentional) aliasing artifacts that are a different color, which I intend to remove from the language packs at some point.

Then because of this enhancement I had to finally add the right-button dragging function to the "checkpoints" screen. But I found that to be difficult without fully overhauling the new click logic (CtrlLock) on the main screen. And I found that even though I changed the button name to CtrlLock to be plainspoken, that it wasn't actually functioning as if the Ctrl button were automatically held down. I worked on this most of the morning today. It now works perfectly I think. And the Ctrl key state shouldn't be able to get stuck anymore.

The checkpoint screen now works with just the left button. It works better this way I think. It flips the first tile and sets drug over tiles to the same result. I think it would be nice to have a multi-select (Shift) mode for this. I can't tell if something is broken, but multi-select only seems to work with the keyboard arrow keys. I.e. shifting with the mouse doesn't form a multi-selection, but it can start one. I have to look into this, but I did all of this very fast and don't want to spend more time on it. It may be rough too, but I hope not. I just checked for keyboard input on the checkpoint screen, it seems to invert the tile, so that's good, now the mouse and keyboard use the same inversion logic.

Again, the big unexpected find/news here is load time in my book, but the rest is a big improvement too.

Holey Moley · « **Reply #7 on:** November 01, 2021, 07:15:29 AM »

Important patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip

This is a must patch to fix some new/significant animation problems in this latest "demo" I somehow didn't notice before publishing it.

The big one is some animations like SOM's skeletons were drifting off center. (The reason for this has to do with converting 8-bit data to 255 versus -1 to detect the root joint that's supposed to stay pinned to 0,0,0.) A more humorous bug is the new scale factor was not updated for the arm_bicep extension so the arm had been missing above the elbow. (I had fixed it for the new MDL+MDO animations but at that point hadn't yet decided to move plain MDL over to a common scale factor.)

Holey Moley · « **Reply #8 on:** November 20, 2021, 11:01:07 AM »

Bug in demo notice

ObjEdit (SOM_PRM) has a crash bug when opening a MDL file that I just learned about. I don't think I can easily fix this with a patch now.

I'm getting close to releasing it. But I still have a pretty long to-do list, so it could be a week or so...

It's really crazy how many little things there are to deal with in this area... they seem to never stop. I'm going to be very relieved to get this latest line of work somewhat behind me. It's been pretty miserable. Everything with the x2mdl project and MDL files has been really hard on me. Most of the troubles are just because of preserving the original set of MDL files. I've been working on this thing as much as I can stand at a time for 10 years, ever since the very beginning, but this time in particular has been rough... especially because it's time to tie up all the loose ends and pull it all together.

I even have a replacement for Assimp I started many years ago that I put a lot of work into, but this new release is still going to be using Assimp. I'm going to circle back and cleanup all of the code at some point. I just dread the work. If I don't do anything else in my life I want to preserve King's Field II for the future. Somehow that doesn't seem so bad.

simple machines forum

News:

Sword of Moonlight|

Devs|

EXIT: Anti-aliasing announcement

Author Topic: EXIT: Anti-aliasing announcement (Read 11258 times)

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

simple machines forum

News:

Sword of Moonlight| Devs| EXIT: Anti-aliasing announcement

Author Topic: EXIT: Anti-aliasing announcement (Read 11258 times)

Sword of Moonlight|

Devs|

EXIT: Anti-aliasing announcement