An important milestone has (finally) been reached by Sword of Moonlight by realizing the original King’s Field single environment experience of no “loading screens” after hopping into the game. This is something King’s Field fans always gloat about since it was pretty novel back in the day, and even to this day lately I’ve played a little bit of some PlayStation 4 games and am finding myself shocked how much of the time is really just spent on minutes long loading screens. In my opinion I would happily remove the high fidelity visuals in these games for practical seconds long loading screens. Of course, no load screens would be ideal.

I believe From Software published Sword of Moonlight so that it would be carried away by its public. This is a crucial facility no King’s Field Making Tool is complete without. I believe Sword of Moonlight would not have been published in this form except as a challenge to take it up. We should not forget that Sword of Moonlight is modeled on a sword after all.

I’m pleased to announce I’ve completed the most grueling round of work I’ve ever done on Sword of Moonlight and all the new files are online for the taking.

I did two long release cycles back-to-back except the first was not published because it didn’t have anything to offer to the general public. What it was instead was a big task to bolt on an OpenGL based alternative mode for SOM because new VR peripherals for PC don’t work with Direct3D 9. I chose OpenGL because I’ve used it plenty in the past and the newer systems like Vulkan and Direct3D 11 or 12 are completely different in terms of their design and are much more complicated, so it would be an even bigger effort to write code for those and it would be very alien to my past experience.

Once I completed that task the OpenGL performance wasn’t good enough, so I wanted to experiment with the dynamic vertex buffers, since SOM only uses dynamic buffers, which OpenGL is not good for. But to do that it’s necessary to rebuild all of the model files, like the MDO files, and remove the MDL files, so I realized that the time had finally come to do a project I’ve long been considering to unify SOM’s model files and build an art system into SOM to make it aware of the art development process.

SOM’s animated model files inherited a lot of quirks from the PlayStation’s design and the model format used by Sony’s SDK. These were unsuited for PC. SOM has a better format called MDO but it’s not animated, so you can say that its team were relying on this Sony style format as a crutch that shouldn’t have been published to an unsuited system. As a result this format has to be converted into a MDO like layout when the game loads, which is bad for performance, and both formats had used very small vertex chunks, which seem to be almost a clerical error, that would make them 32 times smaller than the target vertex buffer, which always remained until now only 1/32nd full, the rest going to disuse.

Working on this ended up being the culmination of all of my time working on the model conversion tools since I originally started working on SOM. These tools were the first things users at the time asked for, however I developed them and their reception was lukewarm at best, so don’t give people what they ask for I guess is the moral of this story, or don’t expect them to be grateful. I never know what to expect in terms of details when I start a programming task, it’s hard to predict, but this project turned into a never-ending slog very fast, to the point for the first time in my career I did what video game developers call “crunch” for weeks on end. I didn’t do this because I had to hit a deadline. I did it because if I hadn’t I would grow crazy forever pushing this rock up a proverbial Sisyphean ramp… and at least if you focus singularly on a task it tends to help to distract from the difficulty and monotony of the task. That was my thinking anyway. In the end it took hundreds of hours and add that to the hundreds of hours that I’ve already poured into the conversion tools, which had to be entirely battle tested for this effort, which itself proved to be a big part of the work.

In practical terms how to think about this development is SOM now will act as if it works directly with your art files, but in fact what it does is monitor changes to your art files and when they change it rebuilds its proprietary runtime files to reflect your changes. This can take a little bit of time, so it will be experienced as a pause with a busy cursor, or the splash screen taking longer to lower.

To make all of SOM’s components comply with this change it was necessary to upgrade its level editor. I had to rewrite all of that tool’s graphics from scratch. But this is good because it finally brought it up to the same standard as the rest of SOM, where before it had been noticeably lacking; another thing I long wanted to address. Its mouse input model has also been upgraded, and the screens that use gray and white squares has been upgraded to show an impression of the tiles underneath them so that they’re not so disorienting as before.

In addition I had to do forensics on all of SOM’s built-in models to reverse them back to the state of art files and archive them in an MM3D format I’m using for my King’s Field II project. You can download pretty competent 3D modeling software from my Github to work with them. I made some corrections to them where I found major non-cosmetic issues, however I haven’t yet made the effort to fix their many blemishes, although this work has moved that goal within reach. I will try to speak to more details in the forum post attached to this blog post.

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.

Continued: Anti-aliasing announcement

At https://swordofmoonlight.itch.io/k I’ve published an early demo of my King’s Field II project that’s haunted me for the past half year. At the speed I was able to work I’ve only produced a beginning that comprises my goals for the second demo I promised almost two years ago, to the day. Most the lost time was bound up in developing tools for working with the 3D models and ensuring compatibility with the existing models. This included developing a cross-platform UI system and 3D art package and utilities.

The demo is using a new update to Sword of Moonlight that’s also the subject of this announcement. It includes a number of features that aren’t yet readily accessible to projects, since they’re not fully developed and integrated into the basic tools. In the final month before publishing I found myself working furiously on the control system since it made some interesting leaps at the last moment and I wanted to take it as a sign I should ride that wave in order to use its public visibility to showcase the control system.

Also included is a significant graphical enhancement that grew out of needing to reproduce the PlayStation’s unfiltered colors, that has the effect of reducing ghosting and moire like artifacts. It works by converting the pixel values into physical units and blending before converting back. Most games do this for lighting calculations today but it doesn’t work very well for low-poly models so I’m limiting its use to color blending.

Today I published a body of work that’s been underway for some weeks. I’m doing a write up since things have been quiet around here in the meantime. I’ve been doing three projects with some overlap, 1 has been my ongoing work on the Sword of Moonlight animation file format, and 2 at some point I realized a simple way to have the animations playback at full speed at 60 frames per second, as opposed to playing out at 30 frames per second, and 3 because of this change numerous other parts of the player software had to be upgraded to double speed at the same time. At the same time I’ve been looking at the model of a human arm that appears when you use your weapon in the games, and how it is positioned on screen, since Sword of Moonlight does it differently from King’s Field. I don’t know if it’s based on Shadow Tower of if it just does it its own way.

All of these things have come to a head keeping me from publishing anything until now. By working on the animation front I’ve been able to refurbish the arm model in order to support changes to how it’s displayed. It’s long been at odds with some extensions. It’s been possible to make an all new arm model, but in this case I’ve been able to take the original and work on it further without disturbing its information content. That’s a milestone in its own right, since it shows it’s now possible to improve on the original animations that are included with Sword of Moonlight’s sample art work and retelling of King’s Field. I wanted to bring the arm up higher and make it larger on screen. I couldn’t do that without editing it to look nice up close.

The arm effect is also upgraded to look nice at 60 frames per second in what was one of the greater challenges I faced. It now has four times as many animation frames. It turns out showing something commonplace moving fast in your face in first-person is hard to do with great efficiency. I’m releasing this work as a patch to the current release this time around. It coincides with a crash fix and I’ve just been dumping patches into this release right now while I work on King’s Field II. I worry about getting swept up in a side project as its deadline draws near.

It turns out King’s Field II monsters exceed the limit Sword of Moonlight imposes. I feel like the limit doesn’t make much sense, but From Software saw fit to limit it to 128 so-called enemies for a given level in your project’s video game. KFII treats its characters and monsters identically, and caps them at 200 on each of its two-story zones. SOM had a layer system that was disabled before it was published. I’ve since restored it, some time last year I think. It would have allowed each layer to have 128 more monsters, in which case its limit may have been 256 for a two-story level, which would have exceeded KFII’s limit.

When I restored the new layer system I decided to limit it to level geometry, so that layers don’t bring in new elements like monsters. That’s a better system because I imagined layers can be used to tackle the artistic limits of SOM’s grid based level design. I suspect not many game systems use grids any longer, but it’s something I feel is a great strength for SOM. I think there is lost wisdom in many of its anachronisms. By putting monsters on layers it isn’t clear what happens when they cross between layers or if that would even have been possible in the original system that got disabled. By artistic limits, I mean things like, you might want a layer to just be a ceiling for example, so you can have a lower ceiling on some section, or just have the elevation of the ceiling be independent of the floor. If you can’t do that you have great limits in design possibilities since the only other way to do this is to make new tile models for every combination of floor and ceiling. The new layer system can represent many things like a plane of water or mist or fog or just plug holes in the existing tile configuration. Anybody who’s ever worked with SOM runs into these limits.

Continued: Unleashing monsters