Topic: EXIT: 25th Anniversary Project (Read 22831 times)

Holey Moley · « **on:** November 02, 2020, 07:05:51 PM »

Quote from: http://www.swordofmoonlight.net/archives/sword-of-moonlight/2020/11/25th-anniversary-project/

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.

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.)

Holey Moley · « **Reply #1 on:** November 06, 2020, 04:47:51 PM »

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.

Holey Moley · « **Reply #2 on:** November 07, 2020, 02:48:33 PM »

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.

Holey Moley · « **Reply #3 on:** November 18, 2020, 06:47:07 AM »

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.

Holey Moley · « **Reply #4 on:** November 26, 2020, 12:22:53 PM »

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.

Holey Moley · « **Reply #5 on:** January 06, 2021, 08:49:21 AM »

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.)

Holey Moley · « **Reply #6 on:** January 07, 2021, 08:27:38 AM »

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.

Holey Moley · « **Reply #7 on:** January 09, 2021, 07:53:12 AM »

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

)

Holey Moley · « **Reply #8 on:** January 14, 2021, 05:08:31 PM »

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.

Holey Moley · « **Reply #9 on:** January 15, 2021, 04:24:53 PM »

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.

Holey Moley · « **Reply #10 on:** January 15, 2021, 05:20:45 PM »

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 · « **Reply #11 on:** January 23, 2021, 08:54:57 PM »

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 · « **Reply #12 on:** January 28, 2021, 02:27:22 AM »

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 · « **Reply #13 on:** February 01, 2021, 02:51:04 AM »

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 · « **Reply #14 on:** February 02, 2021, 11:08:53 PM »

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

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.

simple machines forum

News:

Sword of Moonlight|

Devs|

EXIT: 25th Anniversary Project

Author Topic: EXIT: 25th Anniversary Project (Read 22831 times)

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

simple machines forum

News:

Sword of Moonlight| Devs| EXIT: 25th Anniversary Project

Author Topic: EXIT: 25th Anniversary Project (Read 22831 times)

Sword of Moonlight|

Devs|

EXIT: 25th Anniversary Project