simple machines forum
Sword of Moonlight => Devs => Topic started by: Holey Moley on May 16, 2020, 10:57:40 AM
-
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.
I'm penning this blog post at the end of a long day and it occurs to me I likely need to go over it again, but I don't have the energy or presence of mind to do it right now. But I want to go ahead and put this release out. Mostly these blog posts are just a formality. I do my best.
The new release is here (http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip) although I recommend updating with Subversion and using the updater software. I recently updated some of SOM's art files that isn't part of any release, just spur of the moment touch ups.
Other than the save system changes there isn't a lot to gain from this release, but I will probably patch it later with some new unrelated developments. This is kind of a trial release but I don't feel like putting it out as a demo.
I'm releasing it and writing about it because it constitutes a body of work that I want to document and it's a big development too I think, but unless you're working on a game project that stands to benefit from more monsters per map, it's not something you can do much with except to read all about it!
I'm filling tired right now... I hope it doesn't come through in my writing, but I can't wait to wake up tomorrow refreshed and finally not have to stare down the barrel of this unexpected hiccup any longer.
It represents one more step closer to realizing KFII via SOM. I really want to get to a point with my project before the end of the year that is semi-complete and worthy of sharing. I really hope there's enough time. I want to at a minimum have all of the content in the game and get to the point where it's in a playable state even if there's still room for improvement before December. I want to use December to promote it and not to work on it. But I have no idea if there's enough time or not. I'm not good with time estimates. And even when I can estimate time reasonably I'm always off by a factor of two or more.
-
Update
I completely scrapped what I wrote yesterday for the blog post, and did it from scratch. I've also patched the DLL to make it refuse to load newer save files than it's designed to.
I'm going to come back later today or tomorrow and write down the details.
-
Patch
It turns out this release didn't work for me with the "release mode" build, but the problem had to do with command-line arguments (to the launcher) so it's not something you're likely to notice, but this patch fixes it so it works with arguments.
Almost everything I do uses arguments, except I tested it before publishing through the new save file system, which doesn't have any arguments. With arguments you can make Windows shortcuts to everything in your project, so I don't go through SOM_MAIN or SOM_EDIT to do things. Because I'm always working on features that would be a nightmare, since I often have to rebuild the SomEx.dll file, which you can't do while SOM programs or games are using it.
-
Details
Sorry, I almost forgot to share some specifics.
The SOM_MAP enemy limit now defaults to 512 and can be increased up to 4096 with map_enemies_limit in the [Editor] section of the config file.
Technically this maximum can be 65535 but I soft limited it to 4096. It has to fit into a 16-bit CPU instruction, so it can't go higher. I don't think games need this to go higher on a 100x100 map. 65536 would be the more natural limit here, but it won't fit. Usually the limits are powers of two, but not always, like the item limit is 250.
The player doesn't actually have a limit, so if you could make your MAP file without SOM_MAP you could go until the game grinds to a halt or runs out of 32-bit address space.
The save file extension can be changed for standalone games (playing games without SOM) with player_file_extension in the [Player] section of the config file. This is limited to 15 characters. Extensions are usually 3 characters. The reason this exists is so you can "associate" your save files with the game and not have conflicts. I think if SOM is installed the difference between using it and not is negligible to nonexistent, but it may not be installed, so a properly published game would want to provide a default setting for this extension. It's in the Player section since ultimately end users are encouraged to change it.
Finally do_2000_compatible_player_file ([Player]) is an opt out just in case there's any reason to do so. It doesn't work unless the game can fit into the original save game format, and it forces the "dat" extension and removes extra information in the file name.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
This is a fix for a loop that was still counting up to 128 enemies when loading layers in SOM_MAP.
-
Feature
Strikeout: as fate would have it like one day after this patch I stumbled upon a mistake in the original do_aa formulation that made "do_sharp" immediately obsolete, so it's removed in future patches, and this patch is no longer available, so this post just serves (I guess) to document the course of events.
I've added a new extension (do_sharp) to a patch:
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
I think this is a groundbreaking development, I describe it in detail in a comment here (https://www.reddit.com/r/KingsField/comments/gpkou9/early_image_of_kings_field_ii_converted_to_sword/) but the basic idea is by leveraging the do_aa and do_lap extensions it's possible to make the do_smooth extension only apply to the after-image composite of do_lap.
The do_smooth extension is nice, but it's a little too smooth. For my King's Field project I didn't like that it didn't feel sharp like a PlayStation game. Plus it's always kind of made things overly blurry.
But it always looked better and the do_aa/do_lap extensions don't really work without it.
What do_smooth does is it makes a half-tone image by sampling between pixels in the effects compositing stage. This is functionally no-cost effect.
I tend to only use no-cost effects. So I had an idea this morning how to sharpen the picture at no-cost. At first I thought of something elaborate to retain as much as the do_aa extension as I could.
But I decided that the results of just going half-and-half was good enough and that the potential side-effects of the more complicated approach were too risky.
I may experiment with adding a third composite image to do_lap, which could stabilize the bad side-effects, but each image is like an after-image and I have a feeling 3 will be too many when moving/turning, so it could get quite complicated if it were necessary to weight the dissolve according to movement to minimize blurring.
That's an interesting area of study, and could help make the images in the tools look nicer (I would rather wait until SOM_MAP has better visuals) but I think I'm happy with this result for now and won't spend time taking this further.
The default Ex.ini file in the /data/my/prof folder has been updated, but that's Japanese, so I recommend getting the latest English data pack (Default.zip) at http://www.swordofmoonlight.net/swordofmoonlight.com/text/English/ or redownloading it via your updater's translation settings.
This change just adds do_sharp to it like this (http://svn.swordofmoonlight.net/data/my/prof/Ex.ini) file's.
I need to add some extensions to the documentation, but for how do_sharp works, it enables do_smooth, do_aa, and do_lap in addition to itself, so going forward it may be thought of as a basket way to dispense with all of these extensions, but it can be confusing if you don't understand how it works.
The effect itself looks a lot like classic SOM, just with anti-aliasing, and no circa 2000 defects. Which is nice.
Edited: My favorite thing about this other than the sharper image is the stars in King's Field II tend to be only a pixel onscreen, so in the half-tone image they're dimmed by being blended into the sky. Now they're restored to their full brilliance. I think that the animated sky effect SOM has actually suits KFII and I will leave it alone. It looks like a kaleidoscope of spirits ascending and they appear to ascend more slowly the closer they're to the ground. It looks like motes of dust near the ground...
It's not how SOM's sky effect is intended to be used because the UV map for its sky dome is different from SOM's own sky domes. I think when you can see the stars indoors it's easier to see they're part of the sky if they're drifting upward, and it feels more magical. I'm feeling more confident for this project now. I could fix the indoor stars too, even without programming anything new, but I intend to leave them in as well.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
I noticed when poisoned by a headeater bite the do_hit effect was getting stuck and preventing dashing.
I'm not sure why, but I've relaxed the condition that prevented it from going back to normal, that's based on how far you're ducking. It was set to recover as soon as you stop ducking, but it was stuck at like 96% ducking, so I made it stop at 95%.
Note, this isn't a part of SOM originally, it's a stagger effect for the PC like monsters have, and it actually makes poison a more interesting status because it causes you to stagger as the poison bites. I think this stagger is enforced even with do_red that makes it so staggering works like in KFIII, which is a much better system, but I think I made poison exempt to this, so even if it only hits for 1HP it is debilitating physically.
I think there is a way to adjust the poison HP loss too, but that it might be nice too to make the stagger more infrequent or irregular so it'd be unpredictable.
Edited: For the record, I'm going to leave the KFIII system in for my KFII project. I'm not overly fastidious about reproducing anything other than its audiovisual style and story. The rest, I'm just going to do whatever is expedient or seems for best. If anybody wants a completely faithful reproduction they have everything they need to make one.
-
CRITICAL PATCH
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
I think this is last layer system patch dealing with SOM_MAP integrity (knock on wood) that corrects a problem with the base layer elevations so that some things on layers would end up at the wrong elevation.
I think this release is the first official release that layers actually work in. After patching some other things, like the "checkpoint" system of course.
What happened in this case is I used the line number in the file to fill out the base layer, but didn't realize the number was only incremented when the line-ending was present, so when the line was partially buffered it put them in the previous tile row. It's a wonder something like this wasn't immediately apparent, but such is the nature of all bugs.
I couldn't have seen it unless it had hit some of my tests, which I guess it didn't. It took me a long time working with a map with a lot of monsters on the second layer to notice it. But I've only been doing that since this release was published 10 days ago. I've been looking over every single monster to try to understand some data on the discs as it relates to them, and I think I only found one monster with this problem in the whole time. Anyway, I'm glad I did!
I remember thinking I was clever to change the code to use the line number, since it's a much simpler calculation, just for readability sake, and to remove the dependency on the map height/width, which is historically fixed to 100x100 but may not always be the case.
-
MONUMENTAL PATCH
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
I knew I felt something special about this release. I had an accidental breakthrough yesterday described below that unleashed the true power of the "do_aa" extension. I describe it in the post quoted below, over on Reddit.
The power basically doubled overnight and now the visual fidelity is perfection. It just happened to come at the same time as the new "do_sharp" extension, but there is no relationship. The old way without do_sharp (strikeout: "do_sharp" was subsequently patched out) is now also perfectly sharp, without objection, and you might even prefer it less sharp since it's by no means smudgy and there are reasons it might be superior.
This is actually a big deal and it couldn't have come at a better time (before publishing by KFII project) even though it's a funny story that it was 5 years working with an inferior effect.
It would've been 5 more years, or who knows how long, except for the scenario I relate that allowed me to discover the error that made the difference. And it's very strange now that SOM is unique in the world for having this technique at its disposal, since it works absolutely flawlessly.
Anyway, I encourage you to see for yourself. This patch updates the fix.
It also includes (for the record) an obscure fix for the script editor that could ruin your day. I think last time I worked on it I broke the "meta" message ("" msgid) that isn't normally edited, but it would fail to save/read your script (and give you a 0 sized file) if you do edit it, without this fix.
I wish that I could patent and communicate this technique to people, but alas I'm not really up to the task and nobody listens. I think I would have to go on a big quest, like try to speak at conferences, to even get anyone to listen. And the whole patent thing, while it could be a solid foundation for making money for SOM and art, I'm afraid I'm not up to it, and I tried to approach Khronos to patent it for hardware, and got the webmaster to send a few letters to the president, but I never received a reply.
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.
-
CRITICAL PATCH
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
This patch fixes a bug loading save files with the new system! That was fast :doh:
There was also a problem with showing the wrong file times in the save menus. I think it got introduced in one of these patches.
I'm planning to just keep adding patches to this release for a little while if nothing comes up.
There's a lot extra in this patch...
Just last minute I added an ability to use the controller to switch to vertical movement while flying with F4. I remember ensuring this didn't happen, but I'm not sure why. I know it's annoying if you're used to running with all three buttons down, but while flying you already move super fast, so you don't really need top speed run, and I may make it always top speed. To do it you just hold both attack buttons, which is how you do alt combos, but this was previously exempt. Note, "flying" is a developer/debug/cheat thing.
Mainly this patch "antialiases" cutout (colorkey) textures, which previously didn't get the full benefits of the do_aa extension. In these screens below the tree limbs and grass are getting this new effect. The second is a closeup on a single blade, although it looks better in person than in a screenshot.
(http://www.swordofmoonlight.net/bbs2/index.php?action=dlattach;topic=154.0;attach=1039;image)
(http://www.swordofmoonlight.net/bbs2/index.php?action=dlattach;topic=154.0;attach=1041;image)
The UI elements are also party to the effect, and speaking of that, there are two new Option extensions called "do_kf2" and "do_nwse" that enable a King's Field II style compass. The latter does so, whereas the former automatically enables the latter and also adds a KF2 style HP/MP display.
I'm more impressed by the compass than the display, which just uses the menu system, like KF2 does. But I wonder if there's a way to improve it, so it better complements the new compass. I think VR may require 3D menus, which is my first instinct on how to improve it.
To see the compass you'll have to SVN Update your data/menu folder to get the MDO and TXR file. Actually these displays are the first time I've added both menu and MDO elements to SOM. Slowly but surely I'm inching closer to more sexy extensions. I don't know why it's taken so long to get to model extensions, it just has. Ultimately it's not as high priority as it seems.
The compass is kind of cute. It tracks your movement in a lot of ways, not just to indicate where you're facing, but it acts like a little bobble head that's on your person. It doesn't really look up and down like in KF2 so that instead it stays readable. It's also angled down so it feels like you're looking up at it, which you are since it's on the the top edge of the screen.
The lettering on the compass is what inspired the new extension to do_aa. Technically I renamed the old extension to do_aa2, in a bit of an odd choice. It's relegated to being used to manually control effects, whereas the new do_aa automatically turns on its accessory effects that it requires to look nice, which includes do_aa2, do_smooth, and do_lap. Those all get packaged into do_aa now. But how this works is if you turn off do_aa they all remain on, so turning it on and off (weirdly) is what you might do to have everything except the new texture effect.
In theory these do_aa effects might be unpleasant for some, or not work with monitor settings or be incompatible with a monitor altogether. I haven't had enough feedback to know how many can use them happily. My monitor has a "Response Time" setting, which if I turn it on it makes motion in movies choppy (which is what it's for) and shows heavy black bands in games. So I'm thinking this option (it inserts black frames between real frames) is for people who see very differently from how I do. I think my eyes or brain are different in this regard.
EDITED: Ooh! I just spotted the compass in the second screenshot, so it's technically included. I wasn't going to include it. It's still early. Part of the problem it has right now is it's subject to the level's lighting. In Moratheia, and most games, it's not enough to light it properly. I have to add some extensions too to control its colors and opacity. In the final version (not seen here) I have colored each letter to be very white, but still technically different complementary colors. N is green, W is yellow/peach/tan color, and S is purple/pinkish, and E is bluish/greenish. There actually weren't more distinct hues than this. Luckily they bleed nicely into one another forming a kind of rainbow spectra, albeit not ROYGBIV. They are more like off-white.
Edited: For 2.5hrs I'd uploaded a debug build instead. I really doubt anyone downloaded, but just in case, maybe you will or won't see this.
-
For the record, earlier today I uploaded a fix for the F4 flying thing that by changing it to work with the controller, I broke it working with the Alt key, and also, to repeat some edited into yesterday's announcement, I had to reupload because I put a debug mode build up the first time.
Edited: Crap, actually I didn't upload the F4 fix because rain had knocked out my Internet access, so I thought I did, and I couldn't upload until the next morning. I have to go out and trim some tree limbs around the satellite dish. I'm pretty sure it wouldn't have been as bad without those tree limbs in the way in way. I feel dumb making these updates since unlikely anyone downloaded it. The patch to my KFII demo yesterday should include the fix.
-
Neato Patch (some under the radar fixes)
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
This patch holds a bevvy of quality upgrades for the movement system.
I got sucked into working more on trying to minimize false positives in the jumping system yesterday and began to notice the jumps were sometimes a bit halted in their movement, so I really dug into what the problem could be, investigating everything. The old jump system was designed to cancel out some assumptions based on how SOM's pseudo (flying squirrel) gravity works that seem to no longer hold.
I guess at some point one of the (many) changes to the clipping system changed this behavior. So the extra oomph it was programmed to give on the first frame of the jump was adding to it instead of canceling out and throwing off the descent as well. So I just removed that and some other stuff and tried to figure out why the jump was underpowered, which related to some new changes in this patch that smooths out the frame rate (I was keeping the fractional part of the smoothed frame rate for some stuff and not others and the difference in rounding was enough to reduce the jump height/impact.)
So, this fix is the biggest non-feature part of this patch. The jump arc is smoother than ever and very fluid.
This fix also solved some ceiling interaction issues I was having with my KF2 demo.
I've done so many upgrades to the movement system this week I probably can't recount them all. One of the biggest is there is now a tentative system for making the bounce effect depend on the field-of-view so I was really able to push it to the limit instead of trying to find a one-size-fits-all compromise.
Climbing now has a bounce like effect, but just the head tilt and not the knee bend part. Landing a jump without stopping feels a lot better now. There are two ways to land a jump, one (stopping) is a deep knee bend, while the other is just kind of hits the ground running. This one is far more dramatic now but somehow less noticeable.
There's a friction system that ties into grabbing the wall. It slows you down when you rub harder and harder against the wall. I added it just so it feels less slippery (don't slide off things when pushing against them) and it's very subtle by design, so you might not even notice it.
It's now possible to look all the way down while crouching and even while leaning out. You can even look the furthest down I think by crouching and leaning out. I guess that feels about right if you wanted to look down the side of a cliff. This may tie into a system for climbing down off ledges at some point. All the way down now means like 110 degrees or more.
Like I said, there's a new system for eliminating false positives so you jump by accident less. But I ran into some problems with my controller momentarily crossing over to the opposite side of the sticks when releasing it, instead of stopping in the center. This is what got me looking at it again yesterday. I made a lot of other changes and by the end the problem wasn't occurring for me, but it could just be my stick was having a good day. But I just left it alone for now. (One fix could be just one frame of smoothing the input data would probably prevent it from going that far, but I know I'm using a much smaller dead-zone than PS4 games do, so the obvious fix would be to increase the dead-zone, but I'm hesitant to do that. But too I worry other peoples controllers aren't going to work if I don't increase the default anyway.)
In short, I want to push this patch out since it presents a more competent movement system.
-
Patch Patch
EDITED: http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
Unfortunately, I've had to compromise the new filter that prevents some jumps because the logic it uses is to cancel jumps that crossover the middle of the direction pad, taking that to mean it's not a jump input... but it turns out that even though you can't see it in the DualShock4 controller, it crosses over up to like 33% of its effective output, so it's really not possible to tell if the stick is let go or pushed. I mean, it'd be really hard to push it to the center without going over, and I wish that was how they worked, because then the jump could know you let the stick go and didn't just move it.
It's also counterintuitive that the sensors are saying the stick is at 30% (for a split second) even though the stick itself isn't. It took me a while to convince myself this was happening. Even the Control Panel calibration too doesn't seem to show the stick bouncing over.
How I've dealt with this is to make the detector less sensitive during the jump window so that when it goes up to 33% it doesn't appear to get out of the dead zone, but this also diminishes the filter's ability to detect crossover...
So, after the jump is initiated it starts returning sensitivity, with the thinking that the springs will snap into place faster than a player's finger, and so to get the desired effect you have to overcome this insensitivity and you only have one or two input frames to do so, depending on the frame rate (2 at more than 30fps.)
Because of the short window the system works best for fast movements, like sudden stops. If you're moving your thumb slowly it's going to register as a jump most likely. That's why you shouldn't make a habit of releasing the action button while moving/releasing the dpad.
-
Feature/crash fix patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
http://svn.swordofmoonlight.net/data/my/model/ARM.MDL
I was about to possibly put out a new release but in the last minute I somehow crashed the program in a way that hadn't happened before, so as a result I want to patch this crash that was introduced in the previous patch, and as it just so happens the patch includes what would be in a new release, so I'm possibly just going to keep rolling things into this release via patches.
I may make a blog post with or without a release. I will have to see what I feel like doing.
The crash happens in the jump system because I had it to read past the end of a buffer. It's a wonder it didn't show up until weeks later, but that stuff just happens.
This patch includes the new 60fps code I've been working on for a long time, and it changes how the arm is displayed when attacking, so I've included a new-and-improved ARM.MDL file (link above) that you want to make sure is in your DATA/MY folder.
This ARM.MDL is a lot better but the animations are identical to the old one. I think that its animations should probably be changed too, eventually, but what to change them to is a major decision I can't deal with right now. I do think the chop should be centered and not twist around. The thrust seems pretty lame too.
A lot of work has gone into this upgrade to 60fps animations and effects. The attack animations now have four times as many frames, but to do that they are blurred together to form a sweep of afterimages. And the transparency effect used is not great, but it's the same as the one for fading things in.
I definitely want to program a better system for the transparent elements before long. By that I mean a full BSP triangle sorting/partitioning system.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
Yesterday I forgot about how the arm/hand equipment pieces have extra models that displace the ARM.MDL sections.
This patch addresses that omission and makes that system a little more flexible since before all 3 MDO files were required, but now if one is absent it will use the ARM.MDL geometry.
Most of these items have dummy models for the shoulder/bicep part of the arm so I took the drastic option of deleting those files. The problem with this approach is you need this version/patch of SomEx.dll to make it work without those models. I didn't want to upgrade the models with the new bicep/shoulder work I did.
Two items have alternative models for this section. I have to take a look at them. One seems to have a pauldron or something that is closed off, so technically it's okay I guess. The other has a hole in its shoulder like the old ARM.MDL that I have to fix when I can get around to it.
All of these models require work to switch over to soft shading to match the new ARM.MDL file and I think that this system should be more flexible, and ideally the ARM.MDL should not be displaced as long as the pieces aren't in conflict with it, so that they don't have to copy its geometry since that's error prone and inflexible. But changing how this works on a more fundamental level will require more elaborate extensions and even more work.
Luckily unless you pause the game these arm models fly by so fast you can't see them well. But the hole in the shoulder is definitely possible to pick out. I have to fix that. Really it seems to me that the body equipment should cover the shoulder. Of course both can as long as they don't come into conflict. I actually thought maybe that's how it worked, but it turns out not to be the case. (I'm not as familiar with SOM as you might guess, yes I know more than anyone surely, but there's a lot I haven't looked at that people who've made games all have to deal with at some point. That's caused communication problems is the past. Making my own game with SOM is a big help here, although unfortunately my memory tends to slip away faster than normal.)
-
For the record I fixed a bug yesterday that made the bicep equipment piece not show for full body armor like the Forest Armor (although technically it doesn't have anything covering the bicep) and Full Plate armor (which does.) I think Verdite may have tried to explain this to me once.
I also fixed a SomEx.dll bug that didn't update the arm equipment for full body armor. This started only since back when I worked on making the inventory sortable/reordable and recalling the menu state.
I haven't published a patch for this since I've identified a new problem with clipping that requires (I think) a change to the clip test. I changed the MHM model for columns with a beveled base, and forming a 1m passage from two of these reveals the problem since it's impassible. It happens I think because the clip planes of the walls extend beyond their edges, so two diagonal clip planes cut into each other forming an invisible wall.
I may look into why projectiles sometimes go through walls at joints, which may be related to this problem. I'm also considering making platforms take friction into account so that when you walk past these columns you don't climb up onto the base like someone who doesn't know how walking works. (They're the same height as stairs but they're not meant to be stood on.)
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
Continuing to update via patches, this patch fixes a twitch when bending over in front of walls I introduced in a recent patch and fixes a bug that had let projectiles pass between level geometry polygons when aimed at the seams, and upgrades the wall clipping math.
The last detail is significant, but first I must add there are some files changed that require using SVN Update. These are upper arm sections for two arm equipment items and a new MHM clip model for the tile that is like half of a column embedded into a wall, and changes to their PRT files.
After I made the change to this MHM model (the old one modeled the column with just a slab) they revealed the clipping issue I sought to address in the past days. After I finished that yesterday I looked into the projectile bug which I've been aware of for a least a couple years, and I discovered the MHM hit detection code there was particularly bad (SOM's code is not the work of geniuses, in case anyone is wondering) so I just rewrote it all and managed to fix the bug along the way.
As for the new wall clipping logic, it uses a significantly different approach that is much more accurate with the goal of being able to pass through any opening that will accommodate the clipping radius (developers should be able to assume if there is a 1 meter opening players will be able to pass through it.)
I'm pretty confident I implemented this correctly, but it's new. Because it's more accurate a problem arises because if you consider a corner, if you approach it, you might hit both walls, in which case whichever side happens to be first in the model data will predominate. If the code is very accurate it will make it impossible to touch the other wall. I might change this by adding some reflection logic, but the end of result of this change is the model is more "sticky" so to remedy this the best I could think of was to reverse the order that the polygons are considered every other time. That way the other wall in the corner can exert an influence in the case of a draw. In this way the stickiness mostly goes away, but it's a short order fix to a brand new system. I just have to get it off my work stack right now.
The old system was sticky too, so I guess very possibly this new system is better, but the top priority is removing those instances where the old model resulted in invisible barriers. I guess I never noticed since as long as they don't create a passage narrower than the clip radius usually you wouldn't notice them.
The technical differences is I used the section of the clipping circle (on the ground) and the wall's plane (upright) as the clipping radius for testing 2D penetration of the polygon outline. Usually this is much smaller than the fixed radius that was being used. But in one case at least, it can be a problem, so I resorted to a hybrid system that maxes out at a half radius, which was the old system's way. That problem case is if you find yourself right on the wall's plane, which can happen if you approach it from beneath an archway.
Another step lessens how far the clip shape is ejected from the wall so that if it's on the wall's lip instead of being ejected all the way out, it just ejects to where the clip shape (column) would be stopped by its own geometry. Like if you pushed a cylinder against the edge of a wall forming an exterior corner then depending on how far the cylinder is from the corner, more of the cylinder can pass behind the plane of that wall before actually coming into contact with it.
I think the old system dealt with this by using half the radius for the 2D geometry penetration test and using the full radius for the plane test. I think that's an interesting hack but leads to the problems this change addresses. In other words it had pretended like the walls were inset by half the radius. But only for some of its math. Part of me wonders if this is actually smart, but I think it's not something that can work with the new system since its radius isn't a fixed value.
Also for this second step (ejection) the code could be a lot better. Instead for time sake I've just treated every polygon like it's an upright rectangle. It can be improved (later when I have time) by clipping the top and bottom to the base and height of the clip shape and finding the point on the diagonal where the clip shape touches the polygon if it's not a rectangle polygon. Most clip geometry is rectangular, so this is good enough in the meantime.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
Ostensibly this patch is to remove some spurious code I missed that shifts that arm model over in wide screen mode.
It also fixes a recently added glitch that could occur when climbing a platform immediately after falling in front of it. It gave me an idea to try to implement wave interference for the bounce when falling to see if that's more pleasant than the current system. I wonder if I meant to do that originally or if it never occurred to me.
(I was also wondering today why my high school athletic team was called the Hurricanes when our state/city are land-locked and hurricanes don't happen here .. or really why this never came up in all my time in high school.)
Lately I've been converting KF2's arm model to use SOM's system. Today I tweaked the arm display system a lot. I was actually able to make it look like KF2's arm. But I decided it wouldn't do, especially in wide screen modes. I think probably (I'm not positive) KF2 uses some tricks on its arm. As opposed to displaying it as-is like SOM does...
One thing I did was to rotate the arm up some, to create the illusion of having a top-down perspective on it. But ultimately I had to make it rotate down in the middle of the swing since I'm trying to make the arm aim for the center of the screen, and rotating it up can make it go higher.
Another thing I did is to have the arm move forward and back again. The reason for this is to fade it in and out of view, but after I set it up I have a feeling maybe KF2 does this, because it feels like lunging your body forward to attack, which the ARM.MDL file doesn't actually do by itself. It wasn't my goal, but it feels more like an attack and I think that KF2's model doesn't quite feel right, but after adding this it feels much better, even without sound.
Lastly, the Moratheia demo's arm animations had an issue rotated up and with the arm raised up higher and made prominent. The problem is the longer swords weren't animated to get out of view, since previously they were much lower, out of frame. So what I did is set up a system to fade in and out the weapon (like spawning) that only happens in the very beginning and end, so that it's probably not possible to see in the beginning using the new arm_ms_windup extension, and in the end it's only possible to see the weapon fade out if it's very long and sticks out in the end of its animation, or if you're jumping around with the do_arm extension and manage to catch it in a pause or menu screen. It's a very subtle effect, but it's applied to all weapons, even though it's mainly for super big weapons that are hard to get off the screen.
Also, the new arm_bicep extension I might have mentioned before wasn't set up to accept a value. Also although I've fixed the field-of-view for the arm, after the changes I made today it looked fine at 62 so I made it to use 62 if that's the FOV setting. 62 is what KF2 uses, and although I don't like how it makes things look like a fun house mirror, I've actually gotten used to it, and one of the nice things about it is when you look down you feel like there's room for a body beneath you. With lower settings it's like looking through a scope on a gun at the ground, so you feel like you're just down on the ground I guess, which is weird. In the lower settings I made a quick fix to pull the perspective back when looking up and down, but I'd like to do that even for the 50 setting, but I only did it below 50 right now, since I piggybacked the change onto an existing effect that's capped at 50.
I've actually taken to switching between 62 and 30 like a zoom scope system. It's very convenient since that's when you roll over from the highest to the lowest setting. I have like a zoom lens when I want it. One of the bad things about 62 is you can't ever get close to things.
-
Important patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
This patch fixes a problem where movement cancels out from the same code that crashed in the last blog post. Two of the buttons that were meant to be opposed used the wrong assignments.
But there's a bigger fix in jumping since while looking at this I was reminded about a bad effect when jumping while turning that had been flickery I think, it's hard to describe but it would look like a the line on the corner of a wall bounced back and forth when looking at it and turn jumping.
I'm not sure why it looked like that (maybe an optical illusion) but I thought I traced the problem to using the gait system to simulate jumping. When turning the system that simulates input rotates it as you turn and the gait code system converts the rotated values into 4 bit codes. I thought this resolution was inadequate, so I set up an alternative path.
Except I ran into problems there, that lead to a good discovery that jumping (at least when not running) movement was being stalled while the variable that is used to lock the position while crouching bled out. Then I made some changes to try improve the input smoothing system while jumping/falling and after this it was good enough even with the gait code values.
Either way, this is some major improvements for jumping feel. Jumping is complicated because the control system is on auto pilot. I went ahead and left in the new code I worked on to use the raw values instead of the gait codes, but I will revisit it sometime to see if it's really necessary or if it really feels better. The gait code system sounds primitive but it has a lot of benefits and can feel more organic than raw data. It's a quantization system.
-
Addendum patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
I've deleted 2 or 3 "EDITED" posts referring to the previous patch. This little bit of code it refers to has bitten me so many times I just have to chuckle at it. I think it's stabilized :crossfingers:
I also included some info on some features I happened to be working on in the past days. I will just say I've given them a lot more time than planned in order to refine them, and they are basically a feature where doors stay open until you move away from them, and a new "nosedive" feature that I had to moderate in this most recent patch because it was too much walking down 0.25m stairs...
It works by looking down some when you begin falling. I know KF2 does something like this. I don't know if it rolls sideways or in the direction of the fall. I generally don't implement head rolling because it's not realistic. (We have a vestibular system for that.) It also accentuates falls. I didn't design it to do that but in order to blend it with the "bounce" effect what seemed to work was to postpone it for the duration of the bounce, so that the recovery (looking back up) comes after the bounce, and the further the fall the more steep the "nosedive" so the longer the recovery. There's also a little bit a duck, that kind of feels like standing back up but is mostly not noticeable... maybe it should push the head forward, but I usually add a little dip when forcing a nod because it looks more natural. (Owing to us having necks and all.)
It's definitely pushing me to find a solution for the descending stairs problem, and falling into "cracks", that is between platforms using the system that makes it so you don't hover out over thin air. The solution is probably related or can be packaged together. It has to probe the space underneath the character's feet.
-
Layers patch (important)
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
The new SOM_MAP layer system was still "off by one" it seems, from the last time I thought I fixed this. This means it was pulling tile data from the wrong row, but very often rows have the same values.
This patch also maps the sound/music volume levels to a logarithmic scale. The full range of values is audible.
-
Final patch? (important)
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
Crap, uh, this patch fixes the "system-wide" event system when regular local events come after system-wide events in the event table.
I'm not sure what happened here, but I tended to put global events at the end of my tables, so I didn't notice, however the mistake in the code is very suspicious, it looks like my old mouse may have triggered the text drag-and-drop system in my code editor. I never use drag-and-drop, but it's not currently disabled, I should try to disable it.
On a technical note, this patch introduces a "breaking change" to do_sounds. I made the sound playing event use 3D sound for non-system events. Originally you had to arbitrarily attach an event to a dummy object or something, but now you can make system (unattached) events to get the old no-3D sound behavior. On the upside you can make an object, etc. play a sound now, via an event.
The old behavior was to play the "always on" and "use item anywhere" sounds non-3D. So like the fountain in KF2 makes a water sound, that sound is "always on" so it makes sense for it to be 3D sound coming from the source.
I considered given the last two patches to go ahead an establish a new release, finally, but I felt I didn't want this release to be left with this system event bug forever. I think I'm going to make a new release shortly, just to mark the time.
-
Full disclosure: I've reuploaded the previous patch after learning it broke the sound play event for "system" class events because back when I added system/system-wide events I mistakenly thought the "use item anywhere" event needed to be nominally attached to a subject (object/NPC) to work.
So I faked that by attaching them to the NPC type. So I needed to undo that, and so yesterday morning I mapped out all of the event handling code (honestly Ghidra is making mapping/reprogramming som_db.exe relatively straightforward these days; the tools are tougher cookies because they do a lot of indirect function calls) only to learn that it would've worked fine without that hack all along! I can almost remember that time, I think I would have tested it before making that change but there was probably another reason such a test failed. Anyway I tested it this time.
I also learned the play sound event/instruction is unique in referring back to the event's subject. I was surprised to see it has code for 3D sound effects, for that reason. The NPC conversation animations are another case but they're a bit more ambiguous in terms of if they're part of the event instruction.
The reupload also has some new code that I developed to camouflage secrets like King's Field hidden passages and compartments. I had to refine something I already written about elsewhere last night while working on the little compartments hidden in the walls (I'll probably write about this in my dev-log later) and I discovered that the map geometry that has baked in 8-bit lighting is for some reason darker than the regular geometry. I was able to (functionally) perfectly match it for my KF2 project down to replicating the dither patterns (which is actually a very precise way to do color matching) on all of KF2's walls with its fairly complex lighting. It's still possible it varies with the ambient light level, but the code in this upload is dimming the regular geometry 96.5% and quantizing the values to 8-bit intervals in the shader path.
The dimming is a mystery. I'm interested in finding the exact lighting code inside the MPX compiler but haven't come across it so far. It does make the games significantly darker (9 shades darker on a 0~255 scale) and I consider this a temporary fix. I tried brightening the map geometry without success, but I will try again. I did find that quantizing is important, so requantizing is generally not ideal. I can also add something to boost the brightness to make up the difference.
Update: I determined the lighting difference depends on the ambient light level setting, so I've disabled the light level balancing for future patches until I can refine it. In the meantime I've left it on with do_kf2 but that's an abuse on my part, in order to use it with my KF2 project until I get to it on my note pad's to-do list.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
I think I've been doing dither wrong all this time! But this patch is to fix lingering problems with the F12 (or Alt+F12) muting function, since I changed it to have 255 values instead of 16 (like the other volume levels.)
About dithering, this patch changes the "high color" mode with dither to match the same brightness as the "true color" mode, which is helpful for artists who want to match colors. I thought since it was darker I would just try to brighten it, but in the process I figured out for one reason or another the darkness was a mistake. I had centered the dither pattern on the color, but instead I think it's supposed to be added to the color, which is counterintuitive, and maybe differs from the source I was working from (I don't know.)
So now it matches exactly the other mode. When I added the missing brightness I realized the math was simpler to just add the dither pattern, but I was concerned this would be a problem for black/dark colors, but I think not, it's just that when the colors are quantized (reduced to 16-bit color) the brightness added by the pattern collapses neatly into the gradations, so that 0 remains 0 and 1 lights up 1 dot in the dither pattern, so it seems ideal. I wish I'd given it more critical thought. The screenshots I've been sharing lately are four shades darker than they should be, which really doesn't seem like much, but it definitely is noticeable.
P.S. When I went to write this earlier I couldn't access this website. It turned out it was being bombarded by requests to an xmlrpc.php file that's part of WordPress installations, effectively producing a denial-of-service scenario, but it was probably just a mindless "hacker" bot that hits any sites with this file. So I disabled that and the site came back to life. Hopefully no harm was done. I let my host know what occurred. They might have a way to see if anything happened.
-
CRITICAL PATCH
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
:doh: Sometime back I broke the most important [Option] section so that I discovered the do_red extension wasn't working, and it's a wonder more weren't. (I need to change the Ex.ini system to not require that I keep it alphabetized, since I can't even do that right.)
Also the do_hit extension has been misinterpreting monsters as traps ever since I extended the monster limit many months ago.
P.S. I should do a more in depth write up of this subject, but lately I've been working on traps, and enabling the spear traps to work for the first time, and changing some of the behavior. I discovered some weird stuff. Like for one you can (and it's not hard at all) actually climb onto traps, that are built out of CPs instead of regular shapes. That's not a feature in my book, it's a bug. Also weirdly the clip system uses different radii for the CPs for clipping and the hit test that can deal damage. The hit test was actually using half the height value in the PRF file. I wonder if this was a bug...
The clip test uses a radius value that is computed for boxes. I assume it's the distance to the corner of the box, but if so that would be a simple length, but the calculation that does it uses multiple trigonometry functions that I don't recognize what they're doing without analyzing it. I think this value used to be part of the PRF file, since it's in memory where there is an unused value in the PRF file that matches it. I think it was an activation radius. I may restore that value to use for traps since they're pretty ambiguous right now. (EDITED: I think I saw this activation radius value in the bogus screenshots on From Software's website that show the internal version of SOM instead of the commercial vesion.)
To activate the spear trap it needs to be like a normal box shape, so I stopped using the height for the hit test, bug or not, and went with the radius. But that came into conflict with the clip test, I actually believe the clip test pushes you out of the way so that the hit test can't detect a hit using the same radius. (EDITED: Maybe not, but I can't think of a good explanation. Two positions are maintained for the game's location, I think that one should be the previous location at the later stage of the loop cycle, but I don't know if they're used consistently if so.)
I couldn't figure out something that works, so for a quick fix I've made it so the do_hit (or do_hit2) extension is required to get better trap behavior by eliminating the clip test (this also solves the climbing problem) so that the do_hit response from the damage is all that there is to animate the trap knocking you out its way. I was also able to switch do_hit over to using the CP position instead of the object position for better accuracy. And I made it so only the first hit determines the knock back trajectory so that the trap can't cancel itself out.
Also the spare sound effect can be used to make the spear sound, so that the open/close sounds don't have to be combined with the trap mechanism.
-
:censored: Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
Great, I just found out SOM_MAIN wouldn't start since I changed something to load the Sys.dat file and it's the only tool that doesn't load a project, so it doesn't have a Sys.dat file.
Of course it crashes. Great look to have the first program that leads into SOM not start.
It's annoying to not realize something this for a while. And a reminder no one tries SOM or if they do they don't report when it doesn't work out. But I also really didn't want to patch this release again. It's going to be another deal where the last patch of the previous release is the same as the new release.
Incidentally there's a lot of cool stuff in this patch, but I can't divulge it now. I will say there's a new do_srgb extension that I've changed to always get turned on when the do_lap extension is turned on (but it can be turned off) because I think it really helps with ghost images that come from the do_lap extension. It superimposes two frames, so you always want it, but with the sRGB blending you get the proper colors for the blending and this makes it less funky and so it seems less blurry. Just some odd news. Of course the do_aa extension turns on do_lap. (I'm not crazy about the "do_lap" extension's name, but it's not one you normally turn on yourself.)