Sword of Moonlight > Devs
EXIT: 25th Anniversary Project
Holey Moley:
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.)
Holey Moley:
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.
Holey Moley:
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.)
Holey Moley:
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.
Holey Moley:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version