Remember to make your own backup of posts before submitting.
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.But even on a single layer 128 seems like a very tight budget for video games. Monsters are seen as the sole purpose of video games, so it’s kind of bizarre that From Software set the so-called NPC limit equal to 128 also. Your average King’s Field game has many monsters and very few NPCs. And KFII’s maps are only 80×80 tiles as compared to SOM’s 100×100. In KFII’s levels the first thing you notice is how dense they are with monsters. These are really so-called spawn-points, which means that you never see this density in the game because they don’t all spawn at the same time.I have all of these numbers handy because I’m working on porting KFII to SOM, and I could not make progress on that as long as this 128 limit remained, so two weeks ago I steeled myself to do whatever it took to overcome it. It was a grueling task as I knew it would be because monsters are a systemic aspect of SOM’s programs. Normally I wouldn’t work on this problem. I would wait until SOM is mature and I inevitably make a next-gen version of it, or write a specification for an interoperable media standard based on it. Luckily if you were to draw a diagram of SOM’s structure spawn-points would be out on the edge of the structure, meaning that they are self-contained and independent of its infrastructure, like leaves on trees. Because of this, even though they are referenced in a great number of places inside the program, they’re more like an ends than a means, or not foundational in other words.Despite this, it still took me a long time to complete work on this. It’s a bit absurd because how normal software development proceeds if you do have fixed numeric limits imposed, it’s normally as simple as pressing the delete key on the number and inputting a new upper limit. But SOM isn’t like that, it’s like hacking a video game without source code. It isn’t always, but it is for anything like this. But since I’ve done it once, if there was cause to I could increase the limit for the other map elements. It would still take a lot of work, but less since it’s been done before.Another aspect of this task is the so-called save file has to track spawning figures for the additional monsters. Enhancing the save data has never been done before now. I had to plan for future compatibility in addition to adding the new data, and because the new flexible save files can’t be used by old versions of SOM I’ve changed the file extension from “dat” to “som”. The “som” extension is also used by project files, which can be associated with the SOM_EX program to open them in Windows Explorer. Likewise the new save files can open the player component directly into the save game, bypassing all of the starting screens and menus.I’m releasing this work and writing about it to mark the occasion even though most can’t see the benefit of relaxing the monster cap. The save file system is also included in this new release, but I caution to use it with care because it’s new, so I don’t recommend using it to play games. There is a way to disable it. I was going to put this release forward as a demo but I don’t think the extra work entailed warrants it. I just recommend maybe skipping it or waiting for patches. I have increased the minor version number since I think this version is going to new and exciting places, and I think there will be patches to this release for some time since there are some loose ends in the layer system that I intend to iron out with my KFII project very shortly. The new feature doesn’t require patching, but I think that I will just be slipping in little things here and there that will help fill out this important milestone release.
Many years ago while I was working on SOM trying to make a system that works on every computer with a GPU I wanted to have clean lines because I feel geometry is essential to King's Field style and it's my personal preference, I like computerized images, but I don't like pixelated artifacts, though sometimes they have their charms (https://twitter.com/cuddigan/status/1068230670097338368/photo/1)I had pretty good images but they weren't good enough in the hardest cases, so I had a eureka moment that actually worked, like in 2015, and I think I made the first synthetic images that don't have "aliasing" in them. Technically the process graphics companies call "antialiasing" and have been in an arms race over forever is a post-process that steals a lot of power and compute time from your games, and so can't work on affordable systems, and is fundamentally flawed because it's trying to clean up a mess that ideally shouldn't exist in the first place, and you can't clean it up perfectly, since information is lost that can't be reconstructed.I think I discovered/invented a novel way to make images that don't have aliasing in the first place, and I started with a germ of an idea, and kept massaging the techniques that feed into that technique until I produced a working system.At the time I couldn't give away or popularize that idea, I tried, and I probably can't now either. I think the only way to make people listen is to produce a game with SOM that gains attention. People are just stupid, pigheaded, like that. It's why this technique (and many others I'm certain) are never discovered in the first place. Because this technique is no-cost (computationally) I'm certain that it could have been deployed on the PlayStation had it been discovered earlier. And the history of video games would've been very different.Well, lately, I have been worrying because part of the basket of techniques I used produced a kind of smudgy half-tone image, and I'm working on converting KFII to SOM and this isn't consonant with the PlayStation's hard-edge style. So in the last week I started to think about how I could sharpen it, and I came up with a way, that was very simple.But yesterday, just by happenstance, I was working on adding KF style onscreen elements to SOM, and so I was testing if they would survive destroying the device context, and you do that by changing the resolution in the Options. So I was just changing to the next resolution, and I ended up on a very weird resolution that is 1152 x 864.This resolution had anomalies in the frames around the menu elements using the technique that eliminates aliasing. I spent the back-half of my day trying to understand why, and I finally determined it was because of the colorkey system that clips out black pixels, because it's all or nothing, at a threshold, and that threshold just happened to be crossed.That made me to think about how the technique works, and I realized that it's actually very good for this colorkey system too, because it locks the 3D points (vertices) onto pixels, which should mean the threshold can't be arbitrarily crossed like this, and should improve (optimize) that. That made me to question if so, why on earth was this resolution doing this. And then I realized maybe it wasn't on the pixel center, all of these years.So I shifted it over by half a pixel, which never occurred to me to do, I guess because I assumed it was already so, and it's more instructions in the GPU shader program.But this fixed the problem with the 1152 x 864 mode, and I knew I was onto something. And it turned out the image after this was better than ever, and now even the half-tone smudgy image was super sharp. So, now the removal of aliasing seems absolutely perfect.And an extremely sharp option I tried the other day that flickered no longer flickers, so there are three degrees of sharpness, starting with the original "smooth" mode, that's now very sharp, so no complaints about being smudgy, and there is sharper still using the new technique, and there is extra sharp using an unpublished experimental technique.In short, the image quality doubled overnight because I'm just muddling through this shit, and made a slight error 5 years ago that halved the quality even though it was still very good. It was just dumb luck (or timely miracle) that this odd resolution setting revealed my mistake. It makes me even more to question how nobody has ever discovered this, since it works quite literally perfectly. There's no downside. It's just something everyone who claims to be committed to showstopping visuals overlooked because they're really just following each other's leads.
Page created in 0.085 seconds with 395 queries.