simple machines forum

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.

Man I had a pretty bad time with this. The programming went alright, and I thought it would be a good opportunity to experiment with different parameters, but everything I tried essentially is indistinguishable from regular mipmaps.

And to make matters worse I hadn't really considered that I was using an extension that generates a double-wide pixel art texture, so that the first mipmap level was really the real texture.

And actually for the problem I'm trying to solve it mainly just shows the first mipmap. And it wasn't really interesting in this case. I wish I'd realized that from the start. It would've changed my strategy entirely.

At some point I realized what I really wanted was just a point (nearest neighbor) sampled mipmap, and that this new code can't deliver that. But it's actually simple to make a "point" mipmap and it doesn't shimmer like doing point sampling on the GPU does because it's really a mipmap, so it's stable.

Unfortunately it wasn't a eureka moment exactly, since by now I realized the problem wasn't really the mipmap so much as mipmaps/anisotropic filtering may be inadequate... this could even depend on your chipset. I think there is a little bit of the second mipmap blended in... so I switched over to using this point filter strategy, plus it's just as good really (for KF2 at least) and doesn't even require sRGB transformation.

I think it looks slightly better. A box filtered mipmap is naturally duller because it mixes the colors together until likely you get some kind of gray mush. So it helps that problem some to just keep the original colors intact. But it's not by much.

I wish I could think of something clever. I will probably try to increase the relative contrast some on them, I don't know. On the headeater monsters a problem with point-filter showed up, that is it can make stripes. So I added some bare minimum logic to jitter which pixels are chosen so you just get color noise. Not great if you expect more than that.

I will make this an extension at some point, right now I've just made "mipmaps_pixel_art_power_of_two" to use this point filter mode. It may not be a great choice if game depends on very accurate pixel art. But KF is just kind of grainy in this regard, and that's probably what you want anyway. With anisotropic filtering you don't tend to see much of the second level mipmap. Anything lower is going to be viewed at a shear angle.

My problem is it can become a gray film or sheen of mush that's just not attractive. This is mainly limited to the ceilings in the caves. It probably doesn't help they're pretty bright and contrast with the black fog.

P.S. Oh well, maybe this other code will come in handy one day.

If you do hang around you can help a lot by being the first to assist others and if you can write some guides from the beginner's perspective. (I really have difficulty seeing things from a regular user's perspective because my view of SOM is so close up. You'd expect me to know everything about it but the truth is I only see it very piecemeal and every week or even every day is a new project for me, it's always out with the old in with the new and I never retain information, plus I have memory issues I think caused by aphantasia.)

It really brings me grief that people aren't using SOM and talking about it.

PS: Again, this one was entirely on me, I'm not sure what happened. I'm pretty clumsy, fair warning. I'm not careless, I have blind spots you can drive a mack truck through.

Well, I will get to the problem, but in case you don't know it, you had left the do_log option on, and with the extensive settings in the [Output] section. Just in case you're leaving these on as you work normally, you definitely shouldn't do that, and it's a wonder if you can even get better than 1 fps with those on.

As for the problem, it seems somehow when I thought I uploaded that repaired patch, I either ****ed up, or it didn't make it, or maybe it got corrupted. Not only don't I have time to do proper release/patches, now I guess I have to double check everything I upload in the future j/k I wish I could manage it and get any work done. I owe you one though, please grin and bear it.

Since it seems like this is a clerical error (we're learning things) I will delete this thread after a little while, if I don't forget to. Ostensibly this entire board is subject to pruning, which is why it's separate. Some will take offense at "Beginner and other Nonsense" but don't take it personally, it's meant in a good way, we'll need both if SOM has a future. Sorry anyway. The only reason that bug happened is it was something I was working on that I didn't think would be an issue.

P.S. You can associate the SOM file extension with SOM_EX.exe to open your project with the SOM file, and you can make shortcuts directly to each tool, there's actually many things you can do by making shortcuts to SOM_EX.exe. (It can technically open PRT and PRF files too, but it's a little fuzzy which Ex.ini file to use in that case. I think it will generally use the TOOL/SOM_EX.INI file, which I'm a little unsure about future-wise. You can assign it a SOM file or just set the shortcut's directory to your project. There's more advanced stuff, but I don't know if there's a full write-up of everything anywhere.)

I thought I had another tip, but anyway you can also now open save files that way since they're SOM files.

Today I still don't have access to your Google Drive, but 100mb sounds very odd to me. A new project on my system is 1.2MB unzipped. Find out what files are big and remove them, since they can't be essential.

EDITED: I made this into its on topic since it's 8 posts long and seems likely to grow, and we're not getting anywhere. I hope you didn't have trouble finding it.

P.S. I'm going into town today, including a dentist appointment, so I won't be back until 24hrs. It's pretty rare I get out of the house

Please don't do a "clean install" for Christ's sake. If you have a problem that's not a way to solve it (and it won't) but we need to figure out what your problem is, to improve SOM, so please make a new thread/topic if we can't fix it in one or two posts here

EDITED: If you're using SOM at this time you're going to have to think of yourself as a beta tester and follow through with anything you can turn up. You're not allowed to be a passive, griping user. You should make a topic/thread and upload a copy of your project. It will behave the same on my machine, then I can quickly address any problem you have. (Also in case you didn't my reply to your PM please make use of this http://www.swordofmoonlight.net/bbs2/index.php?topic=179.0 topic/thread if you prefer.)

Three monsters down so far. Tomorrow I think I'm going to try to find a new mipmap generation filter. The cave texture still turns into a kind of white fog in the distance, which runs counter to the black fog. It doesn't look sufficiently like the emulator.

The filters in general turn everything to mush. I think in the early 2000s when everyone said games looked like brown mush, that mostly to blame for this is mipmaps and filtering. I don't know that SOM is capable of going beyond that phase in general. I think the only thing that changed that perception was games switching over to very high fidelity techniques and maybe some post-processing.

Once I get the monsters in an acceptable state for early demos (I'm going to be polishing this forever I'm afraid) the next task is a huge overhaul of clipping code for NPCs. They're mostly in the same state as vanilla SOM left them. It will be a pretty big project. I'm going to try to give them all the same benefits the PC model currently enjoys and try to put that code under the same roof to the degree I can. So it's a big reorganization project. (The NPCs--monsters included--have lots of issues, it really feels like SOM was left in an unfinished state.)

I'm also going to fix the problem where you can fall between the slats in the bridge (the bridge isn't the problem) I've put that off too long. And the "checkpoint" system needs work, especially for layers, and I want to try to keep monsters from trying to attack the PC from different layers (you can hear them trying to bite you from above or below the ceiling or floor.) And everything else can be interacted with from the wrong level, irrespective of vertical distance. I have my work cut out for me. At some point I hope I can squeeze in time to work on the art side of it again.

I'm going to upload a new demo with mobile monsters, and I want to include better mipmaps in it, assuming they can be improved... I'm hopeful they can.

For some reasons the monster sound effects seem too quiet. I'm not sure what to do about it. I've turned the volume up to max and reduced the volume of everything to compensate. The only other option is to edit their waveforms in their files. That would make them impure, so I'm trying to avoid it. I wonder if the PlayStation amplifies them. Or it seems likely too that 3D attenuation is to blame. I may have to set something up for the giant kraken to make sure its cries carry far enough to be heard beyond its grasp.

So far only the slimes seem to have an idling sound effect. I can hear the occasional cries from other animals and I wonder if those are ambient or are actually monsters. I really thought attaching the idling sound to the slimes would make them play incessantly in SOM but for whatever reason they're not overwhelming. They're probably less frequent than in the original, so far.

I've set up a trick system for slimes so they can move without rotating. To do it I let them move normally but don't assign their rotation to their model data structure. Right now I'm using the #3 slot in the new turn table system for this, but I feel like it's probably not a long term way to mark the behavior, but I don't know yet. #3 shares the #1 slot since it's fused together for diagonal movement, so it doesn't need its own. I just feel like it's too obscure to be used for this purpose.

Today I added headeaters sounds that vary pitch based on their size (which KF2 does) and recently have added lateral movement. I actually can't tell if KF2 really has lateral movement or if monsters are just rubbing against invisible barriers. It's really hard to reason about how KF2 behaves. It seems random.

I think I want to add the rest of the sounds ASAP.