simple machines forum

Last patch for a while

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

I uploaded a patch yesterday because the code was at a stable place and I expect to be venturing into unstable territory for the next so many days, or weeks perhaps...

It has new code that draws the arm animation before everything else. This helps to keep performance more even when the arm/arms is/are taking up a lot of pixels on screen.

I recall fixing some timing code for subtitles, and (I'm sure there are other fixes) one odd change worth mentioning somewhere is the hop input won't any longer force you to stand up, so it's possible to hop mid squatting while remaining squatting. But it does stand up if you fall further than a jump height, so it only works (currently) on level ground.

P.S. I think I'm going to start playing with this (https://github.com/jibbsmart/JoyShockLibrary) library to add advanced features for Sony's PS4 and PS5 controllers (maybe Nintendo Switch can work too) shortly. My main plan for the accelerometer is to use it to lean over while standing still and look behind your self, like a rear-view glance. I will see about other uses when moving or attacking later. Since leaning forward and backward doesn't seem incredibly useful I will see about possibly making it an alternative way to look up and down instead. This is among the things I saw myself doing at the beginning of the new year.

Patch (same link as above)

There's a new supersampling mode in this patch that's entered by pressing F1 or Alt+F1. It takes a toll on your PC so if it makes the frame rate irregular (feel bad) you have to decide if you'd rather reduce the resolution or switch out. I recommend it over widescreen if you have to choose. Also, you can ignore the "Anisotropy" feature in this mode because I've made it to always use 4x for the time being. This helps it perform better and I can't personally see any difference when I increase it.

This is an official style announcement, I've already written about this everywhere. But I have since updated the DLL with a fix for some menu text layouts, mainly in weapon damage rating text.

Improvement Patch?

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

This patch switches over to a fixed frame rate. I don't know if it's best for everyone, but it certainly helps my system. I think Windows is just an unstable environment for games. But it could depend on hardware. I really don't think there's anything SOM can do to help this.

What I was using until now (since recently really) is average time over 20 or 30 frames. Not doing this caused smoothness to tank. Lately I've been having bad feedback in the control system intermittently and I took it to be frame rate irregularities most likely.

Edited: Note, my main motivation was to determine if the new much improved gait system had math issues or if the troubles with it lied elsewhere. So far it seems the frame rate mainly was at issue, which at least for the gait system is good news.

What I tried today was to fix the frame rate to the closest standard frame rate. That seemed to remove it, although it changes the experience a little bit. Ultimately I decided to defer to the display adapter's reported frame rate where available.

I also added a [Window] extension called "seconds_per_frame" (not fps since this doesn't change the frame rate) that sets the length of the fixed time step. It's not really meant to be used normally, but it can speed up and slow down the game effectively by covering more time. It can be used to speed up the game like people usually play KF2 on emulator.

But what I wanted to see was if the control system held up at different time steps. It's a little hard to judge because it's unnatural to play in slow-motion or sped up speed, but it doesn't appear to have any issues. It seems that the problems arise due to irregular timing. In that case they're probably purely down to human perception and not really errors.

I think this will be the best experience when hiccups occur, but more importantly it seems to eliminate turbulence from the control system. It seems to make jumping last longer or be more full. I might even reduce the jump height. I'm also thinking of reducing the do_lap extension when turning to see if it can make it a little less blurry. (In theory giving more weight to the more recent frame would give the blur some directionality, more like afterimages probably are IRL. Unfortunately this would degrade the do_aa effect. I wonder if the new contrast detection system can help to reason about if things are moving, then give a slight weight to the current frame if so. In that case the do_aa effect can't do its magic anyway, but I don't know if every pixel having a different weight would be odd or if small weights would be noticeable. It's possible even a slight weight could aid the brain to isolate the real image. Edited: in the debug mode build I can hit the grave/tilde key to turn off the effects pass. In that case the blur is not majorly reduced, so I think the improvement will be nice but not night and day.)

Today I worked on the timing for when NPCs show their titles, at 60 fps. There are 4 bytes in the profiles for the frame when the titles should appear. If they're set to 0 (as some are) the title will show at the end of the animation. This is because 1 is the first frame and 0 is never equal in the test.

I've added this to NpcEdit today along with the turning rate setting, on a second page. I've been meaning to publish EneEdit with two pages and this one now. There's nothing in the way really, except I feel like I should do the Japanese versions and publish at the same time. There's also a chance I will change them or discover something new in the meantime.

If someone needs these features by all means ask and you shall receive. I'd like to find out if there's room in NPC profiles to add a turn-table and flight/swim/incline parameters so they can have parity with the new enemy profile feature set.

Follow-up

I think I know how this happened now, I just did it again... I gotta lookout for this more...

What happens is if I build SomEx.dll while a SOM tool or game is running out of the installation, Windows won't let it be overwritten while it's in use. I always upload patches out of the TOOL folder, so if I'm in a hurry I don't notice that I'm uploading the old DLL

SVN Update (minor)

FWIW I've bumped the Sompaste.dll component up to 1.0.2.6 in order to add Windows/DOS "glob" pattern matching (FindFirstFile family) to its SET file parser.

This makes managing temporary SET files easier for projects in development. I probably need to give this area more thought. Especially for PRT files I can see having to edit each one into a SET file just to include them in the project would be a chore. Which is why I had to add this ability.

The only reason I set up sets at this stage is I'm adding some pseudo PRF files to a DATA/MY/ARM folder to do initial experiments for new arm facilities, and they get picked up as item profiles in SOM_PRM. I didn't want that so I made a meta.set file for them, but I (http://en.swordofmoonlight.org/wiki/SOM_file/list_of_environment_variables#DATASET) haven't provided a way to do a true blacklist style DATASET set at this time, so I actually just need to not include them. But to do that I needed to be able to (somehow) include everything else in my project, and around the time I got to PRT files I knew I needed to find a better way, and adding wildcards was obvious.

P.S. As a reminder, TOOL/SetComp.exe can generate SET files by dropping a directory on it. It's not very user-friendly in that regard, but you just have to make a temp directory and copy/paste the PRF/PRT files you want in your set into it. Then you can start using sets and categorizing your profiles.

Patch (2)

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

I noticed jumping sideways was badly affected by the change I made to improve drifting after circling, so this patch tries to claw that back.

I've also disabled the new gaits system for walking (not turning) because it's a bit floaty, especially after jumping, so I have to make time to reevaluate it. I think it is a better experience but walking has never been an issue before. (Don't fix it if it's not broken.) You just don't notice it like turning. Plus the turning system is nonlinear and so goes very very slow to very fast.

AMAZING PATCH

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

This patch has two back-to-back enhancements I hadn't anticipated that are some of the best things to happen in a long time.

The first happened a couple days ago, that is the final nail in the do_aa system (in a good sense, not a coffin, a structure) and I've made a topic/thread for it here (http://www.swordofmoonlight.net/bbs2/index.php?topic=324.0) but I don't know if I will have more to add to it. I'll have to wait and see. The day after I was able to look at with fresh eyes and I'm happy with it's current configuration. I don't think I will revisit it until I have a good system for adjusting its settings without rebuilding/restarting the program. I keep thinking I will finally break down and set that up, but I'd really like it to be part of the Exselector system I have had planned for a very long time. It seems like bad luck to force it.

Now the second development came about because I was spending so much time scrutinizing pixels while make subtle movements.

I started to notice a really unpleasant wobble when turning sometimes, depending on the approach and timing. I wasn't sure what it was, so I spent all this morning investigating it. I don't think it was so noticeable before I recently added a system that changes how you drift after circling. To see the problem it was necessary to turn inside and slowly.

This turned out to be one of the situations where I feel like the angels are on SOM's side. Whether or not this is the root of the problem, it was the solution. In a kind of act of desperation I just tried the most harebrained thing I could think of and it actually worked perfectly to make the movement system become suddenly angelic for lack of a better word. It's probably a case that the system is overdesigned, and there's a simpler way that a smarter person could express it, or the math, or whatever.

I'll try to explain it, but know that the result is now the movement system, turning, etc. is so smooth you can't even tell you're changing gaits, which is like changing gears I guess, and that kink is gone, and no doubt there were many kinks like it, but it just happened to easy to notice.

A short primer, in the beginning, the original solution to making SOM be kind of analog was very crazy, but actually kind of worked. At that point reprogramming it's binary was beyond my grasp. So what I did was like, to move at half speed, was to move every other frame. And so on. I was probably able to decouple the visual from the movement, I can't remember, but I can't see why not. So maybe what you saw was pretty smooth, but the underlying movement was kind of jerky like this. But even then I thought this was a good design, because controllers are very erratic, and thumbs don't have as much finesse as you may think. I didn't want a one-to-one connection between thumb or controller to what you see, and I wanted to have fixed speeds, and to potentially be able to assign an animation (a gait) to each speed someday. You can manage that if there's a small enough number of them. Plus I figured this would be more organic (i.e. less robotic.) Plus I think most commercial video games really only offer 3 speeds. So SOM actually offers 7. This is because the controllers are really garbage. Probably SOM is too sensitive as it is. Most games have a huge dead-zone because they know 70% of controllers are defective.

Eventually the system became more refined. Usually always because it had to for this reason or that. Like, this is a prime example. There was an unacceptable wobble, so I had to figure something out.

So one of the first things I did after increasing the resolution (this involved making the speed independent on each axis and modulating it based on the actual moving velocity) was add a spring simulation. It's probably not how you imagine a spring. It's more like a system for shifting gears smoothly. Each time you change your gait the stiffness and target for the spring changes. It's actually kind of weird to think of a spring with a dynamic stiffness.

So I calibrated that so it switches over as smoothly as possible, but you can (or could) still tell when it's switching over, just like a bicycle. The stiffness didn't change instantly. It would evolve at constant time to the new stiffness. So the problem, I guess, depended on the timing. If you approached slowly it would be fine. But if not it might look kinky, and I think whether it did or didn't also dependent on the micro frame rate at the transition point.

So, what the new change does, is it manages the rate of change of the stiffness depending on how far away the target stiffness is. I really felt like making a such a change was piling more derivatives onto an already too out of control situation. So I didn't expect it to work, and I certainly didn't expect it to behave like an optimal solution. I really felt like it was just a moment of grace to be honest.

The gear shifting analogy is a good one, but another way to think of the situation is as a quantum system (not quantum mechanics) meaning that you have some quantized states that must be translated into an analogue response. I never expected it to be like this. I will say this. It now feels like it has parity with mouse input FPS games. The mouse also feels better, but it's pretty underdeveloped. I may take another look at enabling high resolution mouse input. I already have the code but it wasn't a better experience.

What makes it more viable is I think the input is much closer to a one-to-one mapping. All the more remarkable because it's only working with 7 states.

P.S. I think I mean to write a blog to highlight these back-to-back developments. They're probably the highlight of the year, even in January.