Sword of Moonlight > Devs

EXIT: Anti-aliasing announcement

(1/2) > >>

Holey Moley:

--- 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.
--- End quote ---

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" :razz:) 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:
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:
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:
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:
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 :rolleyes:

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.

Navigation

[0] Message Index

[#] Next page