simple machines forum
Sword of Moonlight => Devs => Topic started by: Holey Moley on November 02, 2020, 07:05:51 PM
-
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.
(http://www.swordofmoonlight.net/wp-content/uploads/2020/11/KINGS-FIELD-25th-PROJECT.png)
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 blending alone.
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip is the new SomEx.dll file.
I'm trying to relax for a while after an extended period of focusing on publishing this demo before the end of the year. It's just the beginning of November, so I might have a little bit more in me yet, but I don't want to be in a hard-nosed mindset for the last months of 2020. I have a number of projects I've been neglecting, but too I think I will say I'm probably interested in, slowly and aimlessly, picking at the problem of how to make SOM's monster's behave like KF2's.
I should probably try to include a list of additions to this update here. I'm not sure I can do that very exhaustively this time. I'll try to over time.
As for the third paragraph, this is called "sRGB" that is kind of a misleading term, but it just means (I think) a standard for interpreting pixels in images. I don't know if VESA standards adhered to this interpretation, but graphics features started to appear to do conversions automatically. One of these converts pixel values in GPU shaders into wavelength values (CIEXYZ?) that is more correct for blending colors. Like blending red and green makes yellow instead of brown. I'd not considered using this with SOM because I didn't think about using it selectively just for blending colors. If it's used for lighting it wouldn't look good with SOM because in real life light is much harsher than in old school video games. You can't represent harsh light unless your model is very detailed and you use per-pixel lighting instead of per-vertex lighting. I tend to think this harsh light doesn't look very good. But it looks blemished with low-poly data, even if you use per-pixel lighting you can't approximate the surface correctly with low-poly data. So I had to think out of the box to see its use, and KFII forced me to, since there was no other way to match what its color looks like on the PlayStation. The reason that is-is the PlayStation does no blending whatsoever, no filtering, and so it doesn't even have this problem. Your eyes just see what they see.
Just off the top of my head there are a few things in the control system that excited me a lot. I will list those now.
1) I got lucky in finding a way to walk down stairs that doesn't stumble down them as if falling off platforms. I didn't think this was possible (without special stair detection/behavior) but I had to solve a problem with falling off short platforms feeling very bad. By this I mean something that's in between a ledge and a stair. The first thing I found that worked happen to work for walking down stairs. Before this to not stumble down stairs it was necessary to slowdown with the analog input. That's kind of neat too since you have to do that in real life, but I didn't think that was a long term solution since gamers don't want to have to remember to do that to avoid stumbling. Very steep stairs still require slowing down, but these are the stairs of nightmares that wouldn't exist for pedestrian building codes.
2) There's technically a sitting system now, so the PC can behave like the NPCs and sit down on things. One of my goals is to unify the PC and NPC models so that it feels like it's just another NPC it its world. This system is basically free because it's identical to the squatting system. It comes from a new ability to climb onto platforms by bending over them so that when you summit you end up in a squatting pose instead of a standing pose. For shorter platforms this results in your head being lower than when you started climbing so it's as if taking a seat. The height difference between squatting in a seat and sitting upright is about as tall as your ankle, so in video game terms you can't really tell a difference.
3) The bending over system that lets you look down very far and even backward is refined. I had to simplify it somewhat to make it stable. But it wouldn't feel right sweeping over arbitrary objects of different heights and sizes anyway. I had a difficult time keeping it from clipping through geometry. Especially when dashing immediately into walls. Of course you wouldn't normally do that kind of thing but it still requires special logic. crouching was another hard case because it can technically lean out even further than normal because the bending over ability is attenuated when leaning into walls and obstacles but not when leaning out in a crouch, but nevertheless it abuts walls and obstacles. I worked on this when tightening up regular clipping.
4) I've tweaked every aspect of the control system, and a lot of that may have ended up in the previous release's final patch. I will try to recount all of that one day. The last thing I want to touch on today is the "wall-grab" system is tightened up so you don't go as far when pulling backward (this tends to look exaggerated and I've lessened jumping backward for the same reason) so that it can work interchangeably for pulling open doors. This can be done to levers or other things if you want too. And it's now possible to activate objects by crouching or grabbing them and letting go. (I'm currently considering having pressing all three buttons while not moving do a wall-grab in thin air so it can be done anywhere without crouching or having a wall and even while sneaking with the action button held down.)
A problem with pulling doors is it's not obvious if doors are push or pull depending on the side you're on. I may make an exception for them so you don't have to let go of the action button. I'm also interested in letting doors be closed manually. Another new KF2 support feature is doors are held open until you navigate away from them. For that reason you might want to close them behind yourself ... for no reason other than I find if I want to do something and the game doesn't facilitate it I'm reminded I'm playing a game. For me the magic of King's Field is when it casts a spell that lulls me into a trance until I forget where I am in the real world. In that moment nothing matters and time could continue to pass by and I wouldn't know it. This can be seen as a destructive quality of video games, but I find this doesn't happen so easily and when it does it's very therapeutic if games aren't set up to be addictive never ending activities.
These new additions to the control system may seem frivolous but there are more practical additions and polish. I've already written about them but I will include what I can here again in omnibus fashion, another time. (For the record, for me the "frivolous" ones are the best part. They lend SOM a meditative quality. But I'd even like them for Armored Core's more arcade style format. Ultimately I'd like SOM to encompass everything so the controls aren't substantially different, so I don't have to think about them differently when I play them.)
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
https://swordofmoonlight.itch.io/k/devlog/193667/update-2 has details. The main takeaway is the bad jump bug on the edge of platforms seems to be eliminated now.
There is a bad distorted movement effect (I don't know how I didn't notice it before) that's undone by this patch, and some mouse cursor business.
-
I've uploaded a patch that makes the d-pad work in menus. It's not super noteworthy except for the fact that the idea never occurred to me before.
It does mean switching from the analog stick, but it makes some sense since the menus use the face buttons exclusively... so it's symmetrical IOW in case someone expects to use the buttons with the d-pad.
-
For the past couple weeks I've been working on my COLLADA-DOM project (https://sourceforge.net/p/collada-dom/discussion/531263/thread/5bcb94ee2c/) and now I feel I should maybe return to a Sword of Moonlight project.
It's hard to think there's just 50wks in a year. There goes two of them just like that.
I'm just checking in here in case anyone's wondering where I've gone. The reaction from my publishing project has not been a good one at all. Verdite shard the project on his (https://www.facebook.com/moratheia/posts/4053973624620030) but I would caution against the movie they included since the quality is very poor. I wish that someone would make a high quality video for sharing online, especially since the download count is very small, so far sitting at only 50. I haven't since heard from anyone I was speaking to before publishing. Virtually no feedback. I wish better reception for everyone else who's publishing creative projects, but don't let it get you down, because it's probably normal.
I'm not sure what I'm doing next but I'd really like to tackle the monsters' behavior patterns. I'm going to have to do it sooner or later, might as well now, maybe even before the year ends.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
This patch addresses a crash bug. It's a wonder I've never seen it crash before today. (I added some code to door clipping to try to update their control-points before doing the clip test because normally they don't update until the door is drawn, which happens after clipping. Unfortunately I forgot to route it through the new 60 fps system so it tries to access CPs for frames that aren't in the CP file.)
Also it lets monsters walk (move) while turning, and makes them turn around outside their view cone at 2x speed instead of 1/2x speed. This gives them a fighting chance so you can't just hangout behind their back so easily. I really think probably they should just turn faster depending on the angle between the NPC and PC. That would work even if they have a 360 degree view cone. (Why did SOM turn around at half speed? I'm not really sure myself. They only do this if they're aware of your presence, but I guess it's to make them seem like they're returning back to their quiet routine. I guess I need to check to see if they turn at half speed when unaware of your presence.)
NOTE: I should patch the itch.io demo. I probably will, but I haven't heard of anyone crashing yet. That reminds me I added a new crash dump system just before publishing the demo. If your game/project crashes you can now go to your %TEMP%\Swordofmoonlight.net folder and find a DMP file that gives me some idea of what caused the crash.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
This patch corresponds to a reupload (https://swordofmoonlight.itch.io/k/devlog/210578/4-update) I just did for the itch.io demo ZIP file. I think it markedly improves turning and changes movement a little bit. Maybe it's more loose, but there was a problem with jerks in the turning.
I also worked to make circling drift more angular and less linear so it feels more like turning. I did it by reducing linear drift while moving sideways except when dashing so it doesn't impede dodging... and I messed with the circling drift parameters. This was a change from the original demo. The reason its complicated is you don't want turning to drift just from looking around, it's too unwieldy, but if it doesn't drift when circling (turning plus moving sideways) it feels like the physics are wrong. (Really these are two different things, moving your body versus your head, but games only have one kind of turning, so it just has to do the best it can.)
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
This patch fixes a problem with the recent work to extend monsters beyond 128 per map, that arises when opening a new map from such a map. (I've even seen this before I thought I just had some monsters on my other maps from early attempts to convert the data on the PlayStation disc to SOM data.)
It also has a "really simple" shock absorber system that's very subtle but seems to help. It seems to fix or mask the jarring takeoff that happens sometime when jumping. I wanted to do something fancier for a while but the thought just occurred to me today that something simpler would be very quick to whip up.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
This corrects a recent mistake I made for item based event activation (I don't know how I got this wrong, I thought I had Ghidra when I did it but maybe I was just beginning to unravel the subroutines and was a little too cocky.)
Another interesting thing in this patch that obvious now is when the hit PC hit effect (do_hit) occurs the gauges are drained out just like when climbing. I probably need to base the gauge drain on the hit strength. I tried a complicated set up based on HP loss but it wasn't as nice as just enabling draining in the hit effect...
I thought the impact was determining the loss, but now I'm not sure. I have to spend more time with it I guess. I'm not sure why it took me this long to realize getting hit should drain the gauges. I guess at the time there wasn't anything draining the gauges, but now many things do.
Edited: I've reuploaded this patch a couple times, once to try to treat poison damage differently, and again after finding out I shot myself in the foot with a last minute change. The amount of drain is consistent with the effect's impact. I still can't quite make out what's happening. I can't find any code that suggests the impact holds down the ducking animation, but it seems like that must be part of it. It's weird talking about my own source code like it's unexplored binary code. Because the hit effect looks like dashing it makes sense that it should drain out the gauges. It should work well with a shield system (that's always just around the corner :redface:)
-
Patch (kind of)
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
If you downloaded in the past few days an upload I did to try to help with this (http://www.swordofmoonlight.net/bbs2/index.php?topic=320.0) accidentally had some of the work I was doing at the time that I didn't get to double-check (although I intended to.)
The misbehavior is rotating items/objects in SOM_MAP around one of the secondary axes is incorrect in combination with the others.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
The new power gauge drain on damage/hit got broke when I changed its math last second (I forgot its units) since past days of troubleshooting/corrective uploads.
This patch restores it. I think it's pretty cool, especially since I hardly understand it myself, even though no part of it was original to SOM. It makes poison especially interesting, and is cool when falling too.
I thought it always hit, and was fixed depending on critical status, but I was wrong. It doesn't always hit (which I was going to add anyway) and it scales with damage. Or at least the hit impact does. Like I said I don't understand it. In practice it feels like there's two modes, and I balanced them so the weaker one drains half the gauge and the stronger empties it and bottoms out for a moment.
There may be a reason for that, or it may be a coincidence. Partly I did adjust it so it drains more from a full gauge than an empty one, so it's a bit nonlinear/dampened.
I recommend trying it out. I feel it's a great addition, and regret that I messed it up.
-
EDITED: I reuploaded with another fix for object activation.
I recently worked on a problem I thought I fixed a while back but only made worse. The problem is regular object activation for box shaped objects treats them like balls (like items) so that the distance to the box edge isn't significant, and that becomes a problem when even the corners of boxes don't activate them (the original activation distance was much further, but not all boxes are square.)
Fortunately the event trigger system does consider the object's shape, so I ended up rerouting regular activation through that system (some things were already done like this) but while I was doing this I noticed the activation angle I chose was 360 and I thought that didn't make sense for objects.
But what I didn't realize is that angle is actually used to determine where the object is facing and not where the PC (player) is facing. So I've reuploaded the previous patch to fix this (only an hour later.)
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
Fair warning I just uploaded a patch in response to FlameScion getting stuck on how project preview behaves when SOM_SYS doesn't nominate a starting map. I guess it makes sense to try to find a map in that case since you have to choose the New Game option to get to this point.
Also I found fairly recent problems with do_start and the default behavior without a [Window] section (or an Ex.ini file?) while looking at basic starting projects.
Finally, following up on Reply #10 (previous post) there was a glitch with crouch activation introduced because the new path I described wasn't set up to include unanimated container objects.
I'm crossing my fingers I'm not introducing new problems by patching in live code I'm in the middle of working on.
EDITED: SOMETHING ELSE I wanted to post about recently: I noticed in SOM_PRM the setting that determines how likely a monster is to become aggressive unprovoked (or "recognize" you) is not implemented in a meaningful way because it's evaluated every single frame. So I've changed the behavior to be evaluated when animations cycle or change instead.
Why it didn't make sense? Consider a setting like 50%, if you do that every frame about say 33 ms that's 100%, or two frames at 60 fps. And if you use 1% instead, well, in one second that's 60%. So, this isn't really helpful or intelligible. Anyway, this change is included in this patch as well.
-
I've added a patch (usual URL) that uses the XInput API's buttons report for controllers that are detected as XInput. I hope this solves some troubles people seemed to be having with the button mapping, but I'm pretty skeptical it will. But it will remove one variable.
Background: Windows seems to emulate DirectInput controllers (which SOM uses) for XInput controllers, and I assumed that these virtual controllers always have the same button layout.
Either they do always or they don't always. I can't think of a good reason they wouldn't, so I'm guessing people having this trouble are using a native DirectInput driver for their controller. In that case if it can be detected as an XInput (also) controller, then hopefully it will work with these overridden button mappings. If it's a pure DirectInput controller (like the PS4 controller is) then short of building a database of known controllers (which I'd be fine doing) people just gotta figure out how to use their configuration files.
I'm hopeful this will work for the most part now. When I started writing this the scenario of being able to override it even if it is native DirectInput hadn't occurred to me. I think Sony's PS4 controller is probably an oddball in not having an XInput driver. I think it's trying to not compete against the Xbox on Windows (by using its input system) but still giving developers access to it to use with their workstations (and I imagine many or most games recognize it anyway, but they have to program a DirectInput layer to do so. So smaller games probably don't.)
-
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.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
This patch fixes a surprising number of bugs (mistakes I made) when trying to recall which Save/Load slots were last selected in the menu and auto selecting the last loaded file. And it had crashed trying to do this when loading a save file from the new Windows Explorer file association system :doh:
I've also increased the texture AA effect when using do_srgb (which is used automatically by do_lap/do_aa) and noticed that it's degraded by the new inter-frame contrast reduction effect because it has a constant amount of contrast even when it's not moving. I played around with trying to balance them but I wasn't successful to reduce the degradation. It's part of the reason I opted to increase the effect, partly in the hope of overpowering it and possibly it can reduce contrast a little by finding a perfect balance that mixes the edges 50/50 and makes the alpha mask cutouts fall dead center with do_smooth.
Ultimately what I optimize for with this new effect is to kind of look like an old web image that's progressively loaded so that the overall effect is a coherent experience that kind of looks like the game is intelligently anti-aliasing the edges in real-time. Of course you're not supposed overly scrutinize the edges when you're playing the game. The goal is to reduce the chance of noticing the effect.
EDITED: More technical crap, I did notice the texture AA effect seemed less degraded if the contrast is done on each color component separately, so I changed to that. If the texture/background is grayscale then it wouldn't matter I guess. It seems more sound to fuse the colors since otherwise the effect potentially makes new colors that weren't there in the first place, but so far I haven't seen an issue, and colors are relative, so in theory an artificial color put side by side can be better/stronger to trick the eye into seeing things.
-
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.
-
Patch (3)
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
Today I found a major glitch in the new AA effect. It was a good find because the code came from VR code. Fixing it may help with some bad vibes I was getting from VR that turned me off or made me feel something was wrong. I wrote about it in the thread/topic about the AA effect. I've also expressed some doubts, but I'm trying to keep a positive attitude about it so I don't go into a spiral of despair :xd:
I've tried to reevaluate the effect after finding/correcting the glitch. Also I think lately some bad frame rate timing (spasms) crept into recent releases/patches, that hopefully this patch will eliminate.
Strikeout: Nope, it's choppy without the change I made too... I guess I prefer spasms in the meantime :sick: (reuploaded 30min later)
P.S. I really love how great the control system has become. But I swear tomorrow I'm moving onto something new for a while. Something to add to and complement the budding control system.
-
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 + SVN Update
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
Today I changed the TXR colorkey to 0,0,0 for everything except SOM_MAP. I think the main thing that had held back this change was being able to distinguish between MDL and MDO textures in the player. I realized that was no longer an issue and the various bad TXR files would need to be fixed either way, and possibly they're not even bad with this change. (So this may fix them en masse, fingers crossed.)
I've spent some time doctoring the two magic circle objects since my reason for making this change is to provide a way to use color based blending (similar to having a full alpha channel) without the cutout effect interfering with soft images.
To do that (although this is probably not strictly necessary) what you want to do is create a 1 pixel wide buffer around your image and set those pixels equal to 1,1,1 (as black as possible) and set the rest to 0,0,0. This will probably be completely invisible, and it will push the cutout system out to this 1px fringe so you can't see it.
Before making this change (historically) the darkest black was 8,8,8 and although I haven't tested it, my guess is that would've been too visible.
Every since I added a much improved cutout effect (it's still possible to improve it a lot but I haven't been able to find better mask antialiasing code) these magic circle objects got the raw end of the deal. But honestly they're much too low resolution, so they look pretty crummy either way, so I didn't consider it a major loss at the time.
Sometimes flames looks better cutout. KFII's flames look better without the cutout, at least if I don't edit them.
-
Improvement Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
I could only work a half day today so I set about to try to enable the better gait smoothing code for directional movement and in the process I was able to solve some other things.
One big surprise that makes me feel dumber than usual is I realized the problem with the turning drift effect was really that the movement drift affect needed to track with turning. This is like your momentum transfers as you turn because of friction. I'm really surprised it took me like 10 years to realize this. It helps a lot with the bad feeling I was getting fighting monsters.
It still behaves the old way when jumping or falling, i.e. not having a footing. I think the way I was trying solve the problem wouldn't even work. I began to realize that it was just matching the angular and linear momentum but the direction was still incorrect.
I may have found the "wobble" I've been posting about. A while back I noticed when turning in one direction (or holding down the look/up down input) my code would still turn in the other direction even with no input. So I tried to make a change to fix that. I think I've found a better way to fix it. And the other way had issues as I suspected it might. I just forgot about it. It's really hard to implement joint rotation because you have to snap it when you get down to a certain point, but if you snap just one of one or more dependent axes it can feel like someone's grabbing the steering wheel. In my system there's some auto-centering logic but the stiffness for it in the middle is 0 so it offers no resistance in the beginning. The problem is the system is quantized so anything below 1 (which is also the dead-zone threshold) is 0 and so by right has/had no power to pull it in until the snap kicks in, which is suppressed while the other axis is engaged. Thinking aloud this makes me think I should at least try to tie the axes together with respect to this figure. (To see if it's an improvement.) Although what stiffness I can detect in the PS4 controller doesn't feel like this.
EDITED: There's also some code that suppresses the texture AA effect when the the screen is moving. It removes what can be pretty serious/unpleasant strobe patterns that can occur on bright, high contrast surfaces. (Edited: Right now it doesn't kick in for the the bounce and ducking effects. I'll have to reorganize it.)
-
A Feature Patch (mainly)
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
There's now (finally) some code to limit event/object activation to 1 meter above/below the PC's feet/height.
This is for layers mainly, although keeping monsters at bay is not so simple unless their ability to recognize the PC across elevations would be hampered. I still have to do a major round of work on this area.
I also noticed a problem with money pickup. Its timing was broken, too fast, but also it was switching to a new alternative subtitle height for crouch pickups. Since it would take a lot of work to treat it differently I've adjusted its timing so the subtitle appears as soon as possible after the crouch height kicks in. So its timing is the same crouching or not for now. On the plus side, I don't think crouching to pickup money had ever worked before. (Edited: I think I need to work on delaying item/event activation now, finally.)
Elsewhere today I announced a fix for NPC title animations WRT the new 60 fps system. And (no one cares) the new smaller VR menu is fixed for aspect ratios different from the PlayStation VR set's.
P.S. Except for the money glitch/fix these were all ideas that came to me as I was coming to (waking up) today. I'm impressed I was able to cover them all in one day (and I do a lot with NpcEdit too.)
-
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.)
-
Patch (SOM_PRM profile update misbehavior)
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
This patch fixes a long standing SOM_PRM misbehavior so PRF files can be edited while using it and and shared profiles can be updated at all.
Also there's a fix for a glitch related to the new gauge hit effect that got stuck if hit while jogging.
I'm trying not to make a patch for everything I do lately but this is a bug I want to write something to let people know it's solved. Note, more than once I've had my profiles get all mismatched. Whatever that is I don't believe it's solved by this.
-
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.
-
Important Improvement Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
Since working on the supersampling feature (F1 or Alt+F1) I've been trying to work lumps out of the movement system. This also started with the edge "defocusing" technique a little while ago. Today I tried to get a handle on the frame rate and I've been able to come up with a much better FPS readout on the F5 overlay, and rule out frame rate in the lumpiness dept.
The main remaining source of it I found was actually in the change I made to rotate the linear momentum when turning. Luckily what helps with it was to remove some ratcheting logic from the drift system ("pedals") gaits. The ratchet keeps them from bouncing between gaits but with this change it's much better without it and I really don't want to give up that change. I'm hoping the new much smoother gait transitions (gear shifting) will make any bouncing go unnoticed.
There's still some jerkiness if you quickly change from circling one way to the other but this is actually how it's supposed to behave, but I think in this case it's not ideal, but to solve it will take some special logic later.
-
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.
-
EDITED: DualSense (PS5) Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
This just detects a PS5 controller. It behaves identically to the PS4 controller but it has a different device ID so wasn't previously supported (BTW I got a DualSense and am looking at adding support for advanced PS4/PS5 controller features the XInput (XBox) system doesn't have analogues for.)
-
Important Fix Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
Somehow about half the resolutions were "cursed" by the change I made how the effects depth buffer is cleared (reset) to try to get a little bit better performance.
I still don't quite understand it, but only my KF2 project seemed to be affected, and the solution is when the "render target" changes it automatically resets the "view port" so it just needed to save/restore the view port. It looked just like the buffer wasn't getting cleared (water would disappear for one thing, sometime a pure black screen--yikes) but there must be another explanation.
Anyway this fixes it, and I hope no one had this bad experience with my demo in the past so many days since that change. The weirdest thing is it only hit some screen resolution settings, which makes absolutely no sense.
-
EDITED: Just for anyone getting notifications every time I reupload my KF2 demo there's a new patch that addresses a glitch where the menus showed the arm/weapon model incorrectly and a fix for unmuting the Master Volume at full volume (16) which wasn't working, and... also using F12 to manage the volume (with ctrl/shift) now repeats when held down (the R3 button is mapped to F12). Note, you can just press +/- on the keyboard.
(The glitch was caused by a recent change to "draw" the arms first so any pixels behind it can be skipped to reduce performance hiccups as a result of a large increase in pixels when your giant arms cover the whole screen.)
-
Final 1.2.3.4 Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
I've decided to finally retire this version (1.2.3.4) with this patch that (1) fixes the afterimages in the arm animation that I broke in recent patches (they were drawn on top of each other) and (2) fixes phantom pause that can happen when the program in "minimized" causing the game to keep playing and using potentially high CPU/GPU resources.
I'm planning to write a blog about the recent round of developments that culminated in the new supersampling mode and in its topic/thread I'm to float an odd numbered demo version 1.2.3.5 which will include important patches and tests of the new shield system as it's mid development. Odd numbered versions aren't available to the updater menu.
This was a very fun version but a hodgepodge of patches too. It's linked to my KF2 project's initial demo and happened to be "1-2-3-4" so I've stuck with it longer than I should, especially since my work has been unfocused here lately. I've got a lot of unfinished efforts underway. I've no particular goal in mind. I think the new "arm" enhancements is a good thing to structure a release around, but it's going to be a slow build to releasing it.
-
EDITED:
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
Never say never, this patch does 3 things: 1) fixes an equip bug I introduced probably in the previous patch (fails to equip more than one slot) and 2) likely fixes sword magic input, which may possibly have been broken in SomEx.dll for a long time if not for the last decade :doh: and 3) should significantly improve performance for the shadows under NPCs...
On (3) I noticed my supersampling frame rate dipping today when looking at the ground. Because there's a big shadow underneath your feet I reasoned that's the reason. I removed some "clip" operations from the shader that were completely unnecessary except the texture needed to be clamped. Part of me wonders why I would've left it that way, except later it occurred to me I might have speculated throwing out the pixels could avoid hypothetical work in blending them, and every pixel has a "clip" operation for colorkey so I might not have thought anything of it.
Now I wonder if "clip" can be so costly if it's just for that shadow's shader for some reason or if it could greatly increase frame rates to disable colorkey for textures that don't need it, except I don't like that because it will implicitly discourage artists from using colorkey to tell them it may seriously impact frame rate. (I will probably do it. Maybe it can get me more supersampling frame rate in Moratheia.)
EDITED: 2.5hrs later I had to reupload with some major fixes after testing Moratheia. For one its arm had 5 bones and a moving CP I hadn't anticipated, but also changing maps (in a real game) turned up a few different problems. And one major problem in a memory leak when unloading the map. (Which I probably wouldn't have found if not some new/untested equipment change code in there that broke.) :sweatdrop:
-
One last 1.2.3.4 patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
This patch addresses a few bugs I've since come across that don't really warrant mention. Some I probably have forgotten. (Edited: I remembered one important fix that's maybe what prompted me to upload a patch today. The first frame of the red damage flash was coming in at full color because of a change I made a little while ago. You wouldn't think it would matter since the first frame is nearly transparent, but I realized that's what was causing a bad feeling about the red flash that's been bugging me lately.)
I've added some sweeteners to update my itch.io KF2 demo, the main being using the action/menu buttons to confirm/cancel in menus. This is something I got some complaints about. I think it's good addition although I have to get used to it. Of course it's more intuitive. It only works if the buttons are assigned to the shoulder buttons because they're not used by menus. Since I expect people to use the shoulder buttons I think this is enough for now.
There's a quick fix for the arm covering up menus in the recent change I made to put 3D items in front of them. It's clearing the depth buffer when the arms are in front of menus... but now writing that I recall considering putting the menus in a depth-partition with KF2's 3D compass. The only drawback to that is less depth-buffer for the scene, but SOM games probably use very little of it, although I can remember it having problems with 16-bit depth buffers. The compass partition is very thin now, it might not be deep enough for a compass that really requires a depth buffer since it's effectively a 3D item.
I feel like my memory is getting worse trying to remember if there's anything else I should add to this post. It is possible now to set monsters up to attack from further than their damage radius (or less than) by using the second radius in EneEdit. I had to look at that for KF2's skeleton monster. I wrote about it yesterday in another topic/thread. I think it may be a bug that the wrong radius was used. Looking at how the skeleton works it seems like too much of an oversight and it's hard to explain why there would be an extra attack radius in the PRF files that matches the damage radius so closely in every instance.
-
Language packs patches
Japanese: http://www.swordofmoonlight.net/text/日本語/最新.zip (http://www.swordofmoonlight.net/text/日本語/最新.zip)
English: http://www.swordofmoonlight.net/text/English/Neutral.zip
You can copy these into your TEXT folder or use the updater tool to manually redownload these packs. Note, this process isn't currently automated. (It's difficult to devise a system to automatically detect changes. Not a priority ATM.)
These add page #2 to EneEdit and NpcEdit. They might have other backlogged changes too, but this is why I recommend downloading them (or one of them.)
Edited: There are several animation IDs on EneEdit's page 2 which haven't been implemented at this time but I want to publish it anyway to not sit on it further. #2 and #22 should work because those would've always worked if anyone knew about them. I haven't gotten around to the flight/swim envelope and the cryptic buttons in the turn table do the following:
*Fourth button (where 3 would go) may not last, I've used it to replicate slimes in KF2. IOW move without turning.
*F1 is unknown.
*F2 draws a shadow. I recommend disabling this only for something like the Stoneface monster that hangs on the wall.
*F3 enables "Evade" in SOM_PRM (you can do this from its animation button too.)
*F4 enables "Defend" in SOM_PRM (you can do this from its animation button too.)
I just included the last 4 for completeness. I didn't want to make space for them.
-
Important patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
I had a weird time today. And a long day. This patch seems to improve the antialiasing/supersampling modes significantly and fix a new problem on the Continue screen that hides the highlight among other things. And it restores the ability to jump over/onto fences in the Moratheia demo.
Briefly I noticed that one of the power gauges was doing something impossible pixel stuff wise that led me to realize the 1px black border that hides some issues on the outside pixels should be doubled in the source image when supersampling. This actually made the picture less stable in the moving high contrast regions, so I ultimately went back to before which was scaling the image down 2 pixels. For some reason doing it right made it possible to see the pixels behaving in a synchronized way... but my journey didn't stop there. In the final moments (just now) I really began to wonder if I'd introduced a problem at some point (some time ago) because disabling supersampling looked a lot worse than I ever remembered it. Luckily one of the same gauges started to twitch in a way that shouldn't be happening. So I found some code I thought had no effect at one point and turned it back on. And after that the change to double that border also looked alright. So I'm just patching this at the end of the day. Hopefully the supersampling is even better than before now. It really seems very stable on those problem edges, more so than I've seen it...
But I also realized something a little demoralizing along the way. In this supersampling mode, what seems to work is to double the size of the do_aa window. In that case the novel insight to do subpixel sampling by way of rounding error doesn't actually apply, and really it's just sliding the image over by 1 pixel in both directions. That's not nearly as interesting and defeats much of the original wow factor of doing it on the scale of a single pixel. It's like coming full circle and ending up having not really gone anywhere. It wouldn't be so bad except I really have difficulty going back to the 1x mode. I feel like now I have to find some new way to rehabilitate it.
April 23 Strikeout: Actually, this isn't true. I had another hellish day scrutinizing the system yesterday and I finally worked out that at some point I'd (intentionally) switched it over to clamping to half-pixel distances instead of whole pixels. Honestly I don't know how it ever worked with whole pixels... it's just to squirmy from what I can see... so (1) I wrote some notes down to remind myself of this in the future, and (2) I guess in supersampling mode it's not really shifting over the image by 1 pixel units. It's shifting a half pixel to either side, snapped to a point shifted over a quarter pixel from either the middle of the pixel or the edge of the pixel. But now that I have this better understanding I may find time to try different configurations in supersampling mode to see if it can be better.
Edited: Something else bittersweet is the extra sharpness seems to be gone away. That's probably why it looks more stable.
Update: http://www.swordofmoonlight.net/bbs2/index.php?topic=324.msg3151#msg3151
-
Important patch #2
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
This patch disables the do_smooth effect in supersampling mode so that the game is as crisp it can possibly be. It's not quite as antialiased but I think being crisp and adequate more than makes up for that.
It also defaults to turning on superMode in the INI file. Since yesterday's patch the native resolution mode is more blurry than before, although it might be a good fit for 4k monitors depending on circumstances. I don't like making supersampling the default but I think it's the intended way to play going forward and this helps to ensure a good first impression, especially for people with systems that can handle it... whereas people with systems that can't are probably used to negotiating performance adjustments.
The supersampling mode always announces itself when the game starts. I don't believe I've added an extension to hide it. So this can be a fair hint I think.
-
I give up!
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
This patch does several things:
1) Fix problem with magic SFX getting lost on map change or game over.
2) Fix problem opening SOM format save files from Windows Explorer with a WIP project... as opposed to a standalone game... which was what I tested the feature with.
3) [Bugfix] section now defaults to turning on all fixes, so you need to use "no" to selectively disable fixes or classes of fixes. This just makes it easier to set up.
4) do_fix_colorkey is added to [Bugfix] so you can use the weird pseudo 16-bit colorkey range for old games. Note, I've never found any explanation for why Direct3D 7 interprets pure black as a range of black up to 7,7,7 ... that makes no sense. FWIW SOM sets this range to 0-0... not 0-7. The Moratheia demo needs this turned on... or rather off.
5) I've uploaded a new itemsicon.bmp file that the Inventory menu uses for its icons adjusted for the new 0-0 range. I should get around to working on the other ones eventually.
6) This build restores an imbalance for the texture AA effect in regular non-supersampling mode. I also uploaded a slightly improved version for this a day or two ago but it severely undercut the texture AA effect that smooths textures with holes in them used for things like grass as seen in the Moratheia demo.
P.S. I've also added a "Strikeout" correction to Reply #33.
-
Impressive patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
First this patch fixes a memory bug in the Ex.ini config file that could be critical (in the [Numbers] section) and corrects the position of the power gauges in the new supersampling mode without do_smooth.
Second for a solid week I've been hard at work on some major improvements to NPC movement. This is an area that's never been touched on before. There a are 3 things to see here:
1) Main thing, NPCs (monsters too) should navigate around 90 corners without any glitches and generally appear to do so in a natural way. This works because of upgrading NPCs to get some of the same benefits as the PC (player character) for smoothing their movements. It's a little complicated because NPCs have very different needs from the PC so there's two layers of smoothing to adjust the NPCs to be properly distanced from each other and obstacles since they're not a ghostly singularity like the PC is. If the PC had a body of speak of it would need some of the same considerations. Unfortunately this is not so cut and dry, so I've done the best I can and expect for this area to improve with more time and experience.
2) NPCs now fall with gravity. Although it's pretty similar to before. Since they don't animate to suggest they're falling/landing it can be a little stiff and is maybe a little slower than the original falling rate (I haven't checked) but the main difference is for a brief moment they accelerate, and they need this time to get further out from the platform they're falling off. Also their radius is reduced to 1/3rd for purposes of climbing and falling, so they don't hover out in midair so much.
3) Climbing is now smoothed out and kicks in at 1/3rd radius. For very large monsters climbing stairs may not be possible (it would look funny anyway) and the default climbing height is now cut in half to 0.25 meters, meaning that monsters are only really meant to climb proper stairs. It would not look good for them to climb higher than that without animations. Also this is fixed, as it's always been, but there's an npc_fence extension in the [Adjust] section that can customize it and incorporate scale as necessary.
Also, off the top of my head monsters are now unable to attack if the PC is vertically out of their range. For non-ranged attacks this is not an issue, since the attacks wouldn't land. For range attacks it might well break something. I've made this change quickly to prevent monsters from making attack noises when they're on a floor above or below (layers) the PC for my KF2 demo on itch.io.
-
UPLOAD FAILURE NOTICE (PATCH)
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip (reuploaded)
Lately my satellite Internet has been overloaded (stretched thin) to the point I can't really use it in the daytime. This is the second time I've uploaded something and software and webpages tell me everything went swell only to later find out either the file didn't actually transfer or is just a part of the file on the host's side (the other time was GitHub, this time it's FileZilla... or my FTP host didn't provide the correct feedback to FileZilla one.)
Honestly if HTTP/FTP can't identify doomed uploads I don't know what the hell they're good for. What's going on with software these days beats me.
Anyway, I've luckily noticed it because I was just quietly uploading a minor, cosmetic fix for the EneEdit and NpcEdit tools (to insert animation frame metadata to the top of the list correctly). Normally I don't expect anyone to be installing SOM. Hopefully no one did yesterday, I did chat with someone earlier today who expressed an interest. Fingers crossed they were in no hurry.
-
New Project patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
I was given an idea to change the default button configuration when making an INI file for a new project because the original default was to use face buttons instead of shoulder buttons.
So I deleted the INI file to see what happened and this turned up a few nasty bugs which this patch fixes.
That's a bad first impression on making a New Project so I'm really glad to have realized this sooner than later, albeit too late.
I need to figure out something for default analog mode. It currently defaults to tank controls. I should probably just force this to 2.
EDITED: I had to reupload to account for the "paddfg6" & "pacCfg7" bug and added analogMode=2. Luckily I went back to encode the defaults as 0x02137645 or I wouldn't have found 6 and 7 not working. It would be cool if SOM games could share a default INI file somehow. I'll try to remember to build that into the Exselector program.
-
Patch Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)
I've had to patch this again concerning one of the "nasty bugs" from the last post. I accidentally made the left trigger to be treated like a regular button in the process because I changed the numeric "ID" for it and missed a place that assumed the old ID.
(I also normalized it when assigned to movement buttons, although I don't recommend doing that, it's technically possible to assign lateral/looking movements to the triggers in the Controls menu.)
Note, I missed this because I assign the menu button to the left trigger, but I suppose a left handed person might assign it to the action button. This patch isn't super critical but still has to be fixed.
Edited: I had to reupload to fix a problem with the keys leaking movements when overridden by [Button] in the INI. Also I've patched the 1.2.3.5 demo.
-
DualShock4/DualSense Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)
I may have messed up the PS4/PS5 controller detection code. I've written some thoughts here (https://swordofmoonlight.itch.io/k/devlog/258963/ps4-and-ps5-controllers-finally-detected) please let me know if you were able to use PS4/PS5 controllers before. If they weren't detected you'd be able to tell because they'd look straight down at the ground and fight you. Anyway this is giving me existential dread so I just want to quietly back away now :frown:
-
Antialiasing enhancement
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)
This patch is an addition to the AA system. I started working on it yesterday and finished it late today. This year I've worked on AA stuff a lot. I realized this would help with the last effect I did but I didn't have the energy leftover then to delve into it.
Edited: Here's (https://swordofmoonlight.itch.io/k/devlog/260491/10-new-final-antialiasing-upgrade) an alternative write-up with an imaginary checkerboard thought experiment to help illustrate the concept.
It seems to help a lot. And in ways I didn't anticipate. How it works is it modifies every other frame's mipmap buffer that's used by PSVR and the contrast reduction system that helps with AA when things are in motion.
The mipmap buffer is like the opposite of supersampling. It's 4x smaller than the resolution. In it every pixel is the average of 2x2 pixels. So what happens when you see this mipmap (usually just a ghost of it) is it looks like all of a sudden the picture is degrading into a grid of 2x2 pixels. (I don't know how to describe this in English, but that's my best shot.)
So what this effect does is on every other frame (the previous and current frames are blended together to make a blur effect that also helps with AA) instead of making a regular mipmap it downsamples starting at the odd pixels instead of the even pixels. That also has a side effect of creating a different downsampling pattern that (when combined) tends to make text look more smooth and probably other stuff too. This also means the pixels on the window's edge have to be thrown away so it's back a to a 1px black border in supersampling mode. (I kind of like how it looks in screenshots anyway.)
So when the picture degrades into 2x2 pixels instead now one of the screens is shifted over by 1x1 pixels (Edited: not the image, but the 2x2 sampling pattern) so that creates an illusion that there's pixel data on every pixel and you don't see the pixelation pattern. Plus I've gone back to enabling the linear filter in supersampling mode (technically when do_smooth is off) because I realized it can help when sampling from the mipmap buffer. It degrades performance (slightly) on the main buffer which shouldn't benefit because the sample should be in the center of its pixels. (The mipmaps are part of the texture so they're tied to the same filtering mode, although I could try to separate them it's probably not worth the effort for now.)
I started working on this because what I'm trying to work on right now has been a bit frustrating and having spent time away I think I could see the supersampling with fresh eyes (I think my eyes adjust to video effects through daily exposure) and was still a little bit unsatisfied. I wasn't sure this would work but it seems to have been just the thing. It helps a bit more with contrast artifacts and I think it improves movement blurring a lot, which is what I intended it for, and it might reduce the perception of little smudges in the antialiasing pattern.
In Moratheia (2.1 demo) I can now move through the spiny trees without seeing any temporal artifacts, at least up close. In my KF2 demo AA artifacts are pretty well nonexistent and I can enjoy playing it with supersampling turned off again. It must look better for that to be the case. For a while I couldn't stand to look at it, at least not in movement. Edited: Also the text is now acceptable in the PSVR mode with supersampling turned off... although the picture is a bit more jittery. I've left it this way just because it's more presentable than smudged text is.
I thought the effect would be messier than it turned out. I thought it would need to draw the odd frame shifted over one pixel. I realized either last night or this morning that it would work just as well to do the shift in the downsample step. That makes it a lot less complicated. It's less intuitive but guarantees no unwanted/unnoticed complications.
-
Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)
I accidentally enabled the contrast reduction effect in SOM_PRM where it doesn't look so great when viewing moving models.
-
Patch Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)
As I feared the last patch cocked something up (8 days ago) as a result of working on adding a new alternative/upgrade to/from D3D9. I just had to look down to see that the underfoot shadow effect was bungled.
I'm sure I'd seen the monster's shadows working earlier that day. It was probably a last minute change.
-
Patch Patch
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)
This time (last time) I (a typo) broke the "blt" function for pictures and the old style compass and gauge background :doh:
-
High DPI Windows Path
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)
Someone (https://youtu.be/TsJMLvlTgk4?t=660) had a monitor with a DPI setting to make the text larger. In that mode Windows would pretend the desktop is smaller than it really is. So in the game the full resolution wouldn't be available in the Options menu.
This patch just fixes that for games. I also spent some time trying to improve the 3D visuals in SOM_MAP because Windows just naively scales up their pixels so it looks likes chunky aliasing. I had some success there, but that's not in the patch. I'd have to work on SOM_PRM too before I can enable that.