Topic: STICKY: 2020 King's Field II port progress report (Read 111763 times)

Holey Moley · « **Reply #90 on:** September 30, 2020, 08:44:20 PM »

Some interesting things happened today, and my UPS battery died so I have to make an emergency trip into town tonight.

From yesterday I had an idea that the events that do the trap doors where monsters fall out of the ceiling (maybe these are always pirate skeletons) I'd reasoned it makes more sense to attach the event to the monster so that the door wouldn't open after it's defeated. But because of this the door opens when approaching the monster, even after they've fallen through the door.

So yesterday I made the event to progress to the next stage that would be its terminal stage. That way the door only opens once. Except in that case there is more than one skeleton in the hiding places, so the encounter could only happen once.

So this morning I tested this theory and added some new logic to SOM to reset monster attached events when a monster spawns. That way every instance of the monster can use the event. I limited this to multi-spawn monsters that are driven by chance encounter, and not the other modes. So if there is a single instance monster the event just has to do itself manually even though the monster technically can spawn many times if bypassed. I could reverse this choice but I felt like the spirit of this change is to deal with multi-instance events, not multi-spawn events. Come to think of it's possible that instances don't respawn because the value SOM uses to test this is a "floating-point" value that is loaded from the save file as a "boolean" byte. So it's possible that once an instance spawns it roams forever, and is retained by the save file. (The "float" value may be its opacity when it fades in.)

I've noticed Aleph is a little taller than SOM's default hero so I've been adjusting his measurements. It got me scrutinizing the "bob" effect, and one thing led to another. So I got an idea to increase the threshold for using the Action button to move stealthily, deemphasizing the jogging ability. I'd even like to make jogging only work when holding down all three buttons, but I'm not sure if acceleration would feel right in that case since you need to run some to get to a full run, and jogging handles that transition okay. (Note this change is just changing the default value of the dash_jogging_gait extension from 3 to 4.)

My idea really was to try to incorporate this into the swordplay element. But also too lately with my PS4 controller it seems like the stealth region is too small to be used easily, and it was always kind of touchy, which is not so bad for stealth since there's an element of taking care...

But I really wanted to instead be able to use it kind of like an alternative stance for fighting the monsters. Even expanded like I said to cover normal movement up to a full sprint/run. But I think the jogging ability still has a use here too. The stealth mode drains the gauges whereas the jogging mode restores them. In that case you can combine them by approaching monster cautiously in stealth mode. You have to do that slowly or else you sprint because the first few moments of running are a fast sprint, acceleration to full speed.

But if you want to move in on the monster then you can kick the gear up to jogging and restore your gauge that way before striking. And the stealth mode actually moves faster than walking when moving sideways, so circle strafing is actually beneficial there. It's a little bit like lock-on in the Souls games play style (that I don't like.)

I think this is a good direction. I think it will be built on. Right now I can't really see a path to transition literal jogging to the 3 button combo but I think that's the eventuality. But then the jogging will have to be replaced with some kind of generic fight mode that also looks like running somehow and that doesn't drain your gauge, so just like jogging mode without literal jogging. When jogging was added the 3-button mode didn't exist at the time. I might have made it use that then if it'd came about in the other order. At the time I just wanted a less intense style of movement that's faster than walking.

For KF2 I'm trying to exaggerate the bobbing effect a little just as homage to the original, but you really can't turn that up high without it becoming a distraction. Analog is really different from digital input and it was always pretty goofy, but there's something about bounding around that does feel pleasant compared to being stiff as board. And I haven't figured out how to cross that gap yet. You really notice it with the monsters so maybe having an alternative stance will be helpful.

In the stealth mode you duck down some always, so that makes it feel more dynamic. And it's probably better to be able to use it more easily just for role-playing scenarios, although someday monsters might be sensitive to stealth. In fact I could program that easily soon since SOM_PRM does have some settings for how alert monsters are that can be dialed down when using stealth movements without doing anything overly sophisticated.

EDITED: As much as I hate to complicate things further, it seems like the way of pressing/holding the action button when exiting dash mode to either crouch or transition to a squat-walk seamlessly is at odds with using the stealth mode because it is technically dashing mode and so does these things that feel natural when running but not if you're trying to circle a monster.

What I think is an interesting move is to always exit stealth mode into squat-walk mode so that you can switch between them easily, and it's a kind action button free stealth itself. In that case to go from stealth to normal walking you have to speed up a little in the transition, which also helps because that matches the walking speed better. And the squat-walk mode is actually interesting for combat so it may be nice to be able to use it in combination with this mode. I've been asked to have it be a more defensive mode or a sturdier stance.

In this case doing the tap/hold wouldn't crouch/squat but would instead do a squat dash/doge on tap or reenter stealth or run on hold... at least as long as you're moving. If stationary it will crouch. Which is useful in fighting too. But you can also do a standing up maneuver (exit squat mode) by doing the equivalent of a stationary jump, which is like crouching but letting go. Because of this you can't do a vertical jump in squat-walk mode. (It's mostly a curiosity... maybe could jump over some attacks. Though you can crouch first and then jump up. Same as a super standing jump.) Running leaves squat mode too, except in tight spaces. It's all very baroque TBH. It's a wonder it feels as natural as it does, at least once you get the hang of it. Kinesthetic controls are much better than push button controls. I can never remember what button does what when everything is just a push of a button.

Holey Moley · « **Reply #91 on:** October 02, 2020, 02:11:12 AM »

Update: I tested both the idea of not squatting/crouching when not running (or jogging) and to squat simply when releasing the action button when not running.

But first, I identified a long standing bug in the jump detection system that has been causing jumps to misfire (duds) for a while. I'd suspected my switch over to using triggers but the problem was because even though the button was held long enough the character hadn't ducked down to the level required to jump. I'm not sure how's that possible, so there may be another problem, but it is complicated when doing rebounds.

Back to the original topic, I felt not squatting to seem flat and encourage running when fighting monsters, which I don't consider to be normal way to engage monsters. I had a number of technical difficulties with the squat option but I've worked it out. The biggest hurdle in it is there's a pretty significant discrepancy in speed when switching. But I think it's the right direction to head in. The speed relationships (or lack thereof) may need rethinking. In the short term I made squat-walking move at the same speed as regular walking to make it a little faster, and increased my project walk speed 0.1 m/s, but I don't think these changes have a big impact. I probably would have increased the walk speed anyway since I think people will expect it to be a little faster.

Switching in and out of stealth like mode and squat-walk is an interesting addition. I think since the stealthy mode is slow I can probably figure out a way to make switching to a crouch seamless. I don't want to get rid of the new way to go from running to crouching/squatting. It's useful just to not have to stop.

Because the dash modes are so complex it's shifted my thinking about them to not be about 1-to-1 controls like in traditional games. I think that they serve a few different roles. One is to encourage body awareness that I think is important to a game like King's Field, to its mood. One is to just make the movements more complicated. I've been bothered for a while that the movement is too simple to seem robotic. It works fine in the original KF with its course digital controls, but it just doesn't suit analog controls. I wonder if From Software tried analog with its later games and decided against it for these same reasons. My personal preference in games (everyone's different) is for heroes who aren't exactly competent and proficient. The Ico and SOTC games have very awkward and clumsy heroes that seems to me to make more sense. So I think of making the movement controls convoluted as a way to introduce a challenge of just having your body get in your way like in real life. In "survival horror" games clumsy controls are often prized for causing suspense and terror of failure. King's Field is not so far away from that mode of game. For me personally my primary objective is to make an ultimate kind of VR experience that is very fixated on bodily movement, so it's a natural outcome of this I think to have many movement options on the table. As many as possible. And of course if you're really deeply attuned with the game you will want the character to carry out the movements you imagine for yourself, so it's good to be able to approximate that. If you're really absorbed you may find yourself learning to be proficient like a camera man. My biggest reservation is my lack of confidence in the DualShock style controller. I think it's not ideal or what I would prefer. It's very imprecise and noisy. I wonder sometimes if a traditional joystick would be better or if it's even possible to make a better controller in this style. For the dashing modes I wish I could reliably push the stick to get the mode I want but I find it's almost a crap shoot if I press it, will I be in the bottom third, middle, or max press, I really don't know. It feels different every time and the more strung out I am the more finicky it becomes. My fingers aren't very reliable devices either for that matter.

Holey Moley · « **Reply #92 on:** October 05, 2020, 05:13:51 PM »

Here is a first image of a new system to manage KF2's variable lighting needs. If you pay attention in the game these stairs are darker than normal. The color accuracy isn't quite to the level of the rest (and I'm not sure yet if I may need to take this into account for the rest--the baseline--since virtually all cells have lighting values but you can't really see the ones in the higher ranges and that may be because they're washed out or the values are really a lookup table that isn't a proper ramp function.)

I encountered two surprises. One is the dark room isn't actually dark at all, possibly not even at all, but instead it has a different "fog" coefficient. There's no easy way to reproduce this with SOM except be rewriting the level geometry rendering code from scratch. It's not like that's difficult, I've already done it for transparent map geometry, but there's just so many things to do. It might have to wait until next year.

This fog system may explain the ugly glitch on the starting platform. There are two dots on the map there. They probably apply an alternative fog factor. KF2 might be able to reasonably blend fog transitions but I'm pretty sure there's no way to do that with SOM because its fog (now at least) is per-pixel and it probably doesn't make sense to go back to vertex based fog. It will take a lot of work to manage alternative fog. I guess you'd want to put it behind a door at least.

Second surprise is the dark areas appear to have lower contrast. I couldn't match them until I noticed this. I could be wrong but it seems more dramatic than reducing the "diffuse" lighting contribution and it's certainly not equivalent to multiplying the light, although I'm pretty certain the effect is multiplicative and not additive. It seems like reducing the lighting would not be more dramatic than multiplication. It would only differ slightly by the baseline ambient level. So I'm inclined to think this is somehow part of KF2's system to make thing unnaturally vibrant. Or if not that it's cancelling out the vibrancy effect while it's applied.

IOW the per cell lighting levels seem to control the vibrancy/contrast in addition to darkness. It might be possible to think of them as variable gamma I really can't say.

My function for reproducing this is to weight the darkening according to the diffuse light level so that brighter color components are darkened more than darker ones. That's naturally how multiplication works but it's not enough of a change in contrast by itself. That means that the reflection of light is reduced until at the extreme all surfaces lose their definition as if all facing away from the light source.

I don't know if this behavior is desirable for every game that might want to use this feature. I'm going to come up with a raft of preset functions and probably a constant to be able to control how much contrast to sacrifice.

---------

Update on the control changes from the previous "Reply" ... I've since formalized a lot of the details. The ability to do the crouch/squat transition is now tied to forward/backward movement more than running/jogging. Or rather it's disabled when moving sideways you could say. You could argue why this is but it mostly has to do with play style, and that you spend a lot of time "circle-strafing" which is where it gets annoying, and these new changes are partly to formalize differences in a strafing game.

The new stealth->squat transition is disabled when the joystick pressed fully, meaning it shouldn't work with the keyboard, not that anyone should be using the keyboard. It's also so disabled when running and jogging.

The transition from squatting to stealth is canceled when doing a jump style input so that you stand up instead, just as if crouching in place. This is how you normally exit from squat to standing. So this means to do this transition you need to at least wait a moment and you shouldn't be doing it unless you're going to be moving for more than a single step. This also now happens for any exit out of squatting, so it's not possible to jump from a squatting position, instead you have to give it enough time to exit the squat first. You automatically do that when dashing. All of this makes it more likely to go from squatting to walking if you don't want to be squatting, or rather less likely to get stuck in the squatting mode unable to get out. Everything wants to pull you out of that mode.

There's now technically a hole in the control scheme when circle strafing while dashing and pumping the dash button that feels like it should do something. I'm just going to wait a while and see if I get an idea instead of forcing it. Some kind of visual feedback is probably in order. But it's not technically dodging since you're already ducked down at the bottom of the dodging height. There's no further down to go. Maybe going up instead like in squatting mode makes sense, I'm not sure yet. I'm hesitant to work on something because it'll have to be an entirely new state that will have to not collide with any of the existing states in an already packed to the gills system. It's hard to formulate a line of logic to explain why it seems that if you can do an input it should do something instead of nothing. It just seems in line with some kind of ethos of "use all of the controller" that begins to make more and more sense the more of the controller you're already using. It begins to feel weird whenever something is left out. It's like a hole where something is absent waiting to fill it.

The speed between dashing and walking still doesn't quite mesh but I feel like it's on the right track and it will inform decisions about speed later. When everything is self-reinforcing until there's no other way it can possibly be then you feel like you have a very refined and maybe even fateful design.

Holey Moley · « **Reply #93 on:** October 07, 2020, 01:33:47 AM »

Luckily I've discovered a way to vastly improve the "feel" of fighting monsters today and it could help smooth over the new problem when transitioning between stealth and squat modes some.

How it works is to increase the walking speed a little after dashing and have it bleed back to normal slow, more "cinematic", speed gradually after. Since stealth is technically dashing it speeds up the squat speed for a little while. So I've reinstated the slower squat speed.

You still have to jockey the thumb stick once in squat mode, but if you hit the sweet spot of 3 bars it's about the same speed as stealth mode. Problem is when not dashing the analog stick is a proper gradient of speeds. In dashing modes it's only 3-speed, each speed being a different mode entirely. So the stealth mode is single speed, but squat isn't. I don't really have any ideas how to improve this.

I added some guard frames to prevent the transition from happening just because computers are faster than human perception. I'm not publishing anything right now so all of this is in my unpublished code.

It feels really good now. If the Moratheia demo had tighter hit boxes it would feel like you're really in a very nuanced fighting game with very fluid and expressive controls. I can't stress enough how much the simple change of walking a little faster after dashing smooths things over. It's not really perceptible when just hitting the action button to open a door or anything. Or pick up money.

I'm thinking about dusting off my ancient Microsoft Sidewinder joystick to see if that's better than my Sony controller. I'm about tired of how tiny the thumb sticks are, since that really gives you nothing tactile to work with to do subtle inputs or gauge how firmly you're pressing it. It almost defeats the entire point of analog input.

EDITED: BTW it seems silly but I've planned for a long time to add a fast-walking gesture for when you're just feeling a little impatient. It will be inputted by twiddling the analog stick when walking forward. I think it will use whatever parameters this fast-walk system uses, it will just be inputted directionally instead of being a side effect of dashing. Having this variable in the system makes it a lot more likely I will add that feature. It will only work while moving forward, and I think really anything that adds motion can be welcome to make for a more organic experience.

Holey Moley · « **Reply #94 on:** October 08, 2020, 03:52:06 AM »

I'm down to 2 small things then I will try to package my work so far as a new demo. I'm going to strip all of my work files out of the demo, or at least to make it smaller this time. I'm not against providing a package with all of my work if anyone wants it. I will replace the old download with it I guess.

The last thing is I want to try to make a Fireball magic. I've decided not to attach sounds to monsters for the demo. In the end I felt sound should be the last thing to bring them to life, right now they're far from brought to life. I don't want them to seem like hollowed out sound effects emitters. My goal for this demo isn't to make fighting monsters fun or impressive. I've just made them to play their animation.

Finally, I think I want to try an idea I had to make a new way to input a jump or a hop by just tapping the stick and action button at the same time. Normally a jump requires holding until the bar drains, but this is an input that I think is rare and is sometimes done by mistake when wanting to jump. If it's not in the way it can be thought of as a short hop. But it might go the normal jump distance, that's less work for now. Also currently doing this input doesn't look very good, so I'm confident it's not an input I ever do or it would have bothered me. Plus it might be a source of jerkiness.

In any event I think this will only take me two or three days. Tomorrow I may only get a half day to do my regular work.

Holey Moley · « **Reply #95 on:** October 08, 2020, 09:06:36 PM »

Sidetracked

I had an idea that could be a big improvement to SOM.

I've been thinking about how strange it is that the green caves in KF2 look very gray/white in the emulator but very lime green in my project.

I decided today the problem may be one I've thought about before:

https://community.khronos.org/t/hw-discourse-texture-interpolation-of-color-by-average-alternatives/104779/16

So I was going to try to do texture interpolation manually instead of using the linear filter that just averages color.

So I returned to that link to see if I could take anything away from it, and sure enough in the first reply was an answer I totally overlooked before (I'm always guilty of this to the extent I think it's some kind of brain damage.)

The idea is to convert the textures from RGB to a luminosity based representation like some televisions use today because I think it lets them use less bandwidth, i don't know. But I worry it will make the color look funky.

But maybe not with high enough precision. I think 8:8:8 is considered very precise for these formats. But as far as I know it's not a special format, it just needs to store different values in the R G B values that aren't really RGB.

Because my current system for SOM depends so heavily on soft in between (half-tone) colors I have a feeling this could help it a lot and is worth a shot.

The link describes it like so, if you average red and green instead of getting yellow you get a brown color, with how graphics cards work on RGB. I don't know if it will look more correct with yellow, but brown is a dark color, so it looks like a line or stripe between two bright colors. So I think it should help. And I wonder if the green caves will look more correct then.

I want to try to do this today or tomorrow. I don't have much time left today. I'm feeling hopeful about this.

P.S. I was really admiring the control system this morning. I'm beginning to feel like it's really arrived to be what I wanted it to be always. It's been a very long journey.

Holey Moley · « **Reply #96 on:** October 09, 2020, 03:32:21 AM »

Follow-up

I couldn't convince myself the luminance based pixel formats could survive a linear filter but I did set up the next best thing, that is to do the filter in linear color space with D3DSAMP_SRGBTEXTURE and the results shown below speak for themselves.

The texture looks identical to me close up (*) but at a distance it becomes white like the emulator and what I assume the PlayStation looks like since neither has a filter that I can tell. I did a before and after screenshot comparison but I know this scene in particular used to be very green but now the white parts of the texture are preserved. (*Based on some tests I think I might be able to fix this.)

This is done with a new, undocumented do_srgb extension. It definitely helps with these sharp aliased PlayStation style textures. It probably helps in general and isn't costly. I kind of wish many of the [Option] extensions could be turned on by default. Maybe it needs something like "do_all_recommended", I don't know?

Holey Moley · « **Reply #97 on:** October 11, 2020, 02:45:53 AM »

Following up, I did complete the work on the do_srgb stuff that night. Funnily it transformed the sky map's stars from little points of light to bright colorful balls! The stars are lots of colors so they almost look more like planets.

And this helped me to see a glaring bug in the forthcoming mipmaps_pixel_art_power_of_two extension, thankfully before I published anything because the balls were smeared across few extra pixels. It's funny that the old sky so overpowered the stars that I didn't notice.

That means the sRGB stuff is working to show the true textures. The difference can be slight but major in textures like KF2's. And it helps with do_aa a lot if I haven't already said so. That said I can't see a big difference in the Moratheia project's demo. That doesn't mean it shouldn't be used, but the difference is dependent on the art style. If textures are already pretty well blended in then it matters less. The benefit to do_aa can be stark but it's more of a further refinement than "night and day".

After fixing the bug I had to change the weight on the mipmaps_pixel_art_power_of_two extension to get the same level of smoothness. I had to add sRGB aware code to the mipmap generation code (that this extension makes use of) to make the mipmaps not fade out. It uses lookup tables via some code I found online and I've included a copyright per its MIT license in the Ex.mipmap.cpp file (https://github.com/ncruces/go-image/blob/master/imageutil/srgb.go)

Oh yeah, I don't think the bright colored balls are acceptable in HD so I've enlarged the sky map so the stars could be made smaller, although I left them medium size and they're technically larger now, except the bulk is an antialiased halo around them.

When I used the generic upscale function in GIMP it put black halos around the stars. I guess that means that's what the sky was doing before when the stars looked like pin pricks of light. I kind of liked that look since it's probably more realistic. But like i said, I stuck with a happy medium. Note the sky isn't black, so it's strange that interpolating the colors makes a darker color, but that's exactly what happens when interpolating red and green this way, so it's not surprising. I never noticed. The green caves are "night and day" though. I'm actually glad they were so dramatic since it forced me to investigate the effect and this is one of the major developments of this project so far.

BTW: I think maybe I intend to work on a feature for the treasure chests and things that is to be able to open them and take the contents as separate actions. I have the secret compartments working but if you activate them the first thing that happens is you will take the contents instead, and only after they're cleared out of the way can you activate the doors to the compartments. The question I worry about is if I solve this then I'll be inclined to make the treasure chests work too, so I hope this doesn't become a multi day project. It's something I forgot about in a rush to publish a demo.

I have finished work on the "hop" feature I mentioned, and luckily that turned up at least two bugs in my recent changes to the movement code that I'm trying to publish as a new release soon. I will probably upload it in the next couple of days, but I don't intend to write a blog post for it until after doing the rounds with my new demo. So that will be a week or more from now. This new release will match the demo's release.

Since I have a lot more on my plate I wonder if I should tackle the Fireball magic or not. I may go for Windcutter instead if it looks easier. The fireball magic in KF2 is just a sprite. I assume Windcutter is 3D like SOM's fireball, but I'm not positive. Windcutter is the more classic magic when I think of KF. When I get to expand on the series (assuming I do) I think of Aleph as using Wind magic. In my plans only two games will have heroes who use more than one magic type. Aleph will use wind.

Holey Moley · « **Reply #98 on:** October 13, 2020, 05:05:33 AM »

In the past few days I've found myself on a roll improving niggling glitches in the movement controls and fixing hard cases where level geometry can be clipped through. I pushed back the "camera" plane an order of magnitude for basic clipping issues, that also added 25mm (1") (not much) to the space you can lean out, out of about 350mm (14") by default.

Then most of today I worked on clipping caused by the new feature that can look far down, even behind yourself some. That does like leaning your upper body out some, so it's possible to really clip if you try to dash straight into a wall (or do so by accident) but after several hours I managed to crack it.

Yesterday I identified a problem with jumping because the height was prone to changing over time, since it wasn't locked in. It depended on how long you'd been dashing, so I locked it into the time of the jump. That inspired me today to try to improve the experience of crouch jumps, which I just did. Their problem is you lean out from the crouch, and let go before releasing the action button to jump, and that causes you to draw back some before jumping forward. Which is unpleasant. It's like going forth-and-back-and-forth, when you really want forth.

The trick to fix that was to abuse the drift system so it keeps pushing you in the direction you're going even after you let go. There was already some old code doing that, but not aggressively as it could. I don't think it occurred to me to make the drift stronger than the actual input! But that's what I did. I think the old code was just patching over a glitch because it had reduced "drift" when leaning out, which I think may no longer be required, and it was creating a feedback effect so I removed it anyway. The new do_u2 system shouldn't require it since it's very accurate.

I've been trying to understand the drift code (called "pedals" on the F5 overlay) better lately. I think I've got a formulation that feels much better. I had a bit a breakthrough yesterday that makes circle drifting feel much better.

The problem is there's tension between two ideal situations that can't be met.

If there's too much drift in the look/turn inputs it's too hard to control like a camera person. It drifts around too much. But if it doesn't match the drift resulting from movement then it doesn't rotate when you turn at the rate of movement and so it can't make a clean tail on the circle you're making. The positional momentum doesn't match the rotational momentum in other words.

But you can't match them because turning is looking. And part of the reason too much drift is not fun is it's too blurry on our great modern LED displays. Even if it wasn't unwieldy with our not so great DualShock style controllers. (I don't mean to "dis" Sony. I assume their controllers are state of the art, but the state is just very dismal if so.)

So the compromise I made was to match the drifts progressively when moving sideways but not when standing still or moving forward. This means you can't really play camera person when moving sideways (or circling monsters) like you can when moving forward. But on the other hand the drift feels a lot better, and there is already a problem with trying to do that because fast-turning makes trying to look around asymmetrical, and so nearly impossible.

Plus, when you're turning you really want to match your movement to try to keep the picture from losing focus. It's hard to explain, but if you get the movement and turning lined up just right the picture comes into focus when turning. This is just a video game thing. It's probably why King's Field has that particular turn speed that everyone hates for being so slow.

I guess in analog controls it's still the same, but you can choose different speeds at least. When out of focus everything gets blurry, because you're moving in two directions or more at once. I think you can buy expensive monitors to solve this problem. I've never had more than a basic monitor. But I swear next time I'm going to pay extra for one that's not backlit from the sides!

The reason I'm going to such lengths is I'm getting self-conscious about putting out a flawless demo. Especially in the movement controls area. It's what I take the most pride in, and spend the most time on. And have the most interest in. And I worry it will be criticized if it doesn't feel like the most natural thing in the world. It's also the thing I think might bring attention to SOM since I really think it may be far more innovative than anything else that exists. Right now it's feeling very good. I'm sure it will be the center peice of the new release I'm angling for.

Holey Moley · « **Reply #99 on:** October 16, 2020, 08:35:03 AM »

I've successfully made a windcutter magic for the demo (coming soon) that continues through monsters so it can hit more than one. I'm pretty sure none of the SFX types are able to do that by themselves. It also turned up a bug where when the SFX data is deleted SOM would try to delete an SFX instead of a SND (via its SND number) but I think that the SFX records aren't deleted until the end (it's not even necessary to delete things at the end of a program but most programs still do it dutifully, even though it makes it take longer for programs to close out.)

When I first tried to make the windcutter I had an out-of-the-box idea to make the windcutter SFX make another windcutter as its explosion SFX, that could in theory look like it went in and came out the other side. I might return to this idea in an attempt to generalize the idea to all SFX types. But instead I just ended up taking one type that happened to be #5 (that may or may not be used) and reprogrammed some stuff to treat the values -1,-1 (for the subordinate SFX and its SND) as if the SFX goes through the target (i.e. doesn't explode) and voila. I did try the other idea first, but it didn't survive. Maybe because it would hit the target again immediately over and over never coming out, I'm not sure exactly. But it crashed on program exit, but I could have fixed that, but I didn't want to go that far. It's possible that same bug made it crash in hindsight.

I couldn't find an SFX that rotated like windcutter. I didn't look that hard (it's actually really hard to make sense of the SFX system) but it doesn't seem possible to make the type that the fireball uses to rotate in a different direction. Instead I took one that doesn't rotate and made the MDL an animated MDL that rotates. Anyway, that's the extent of it. I also learned that I needed to apply the new npc_hitbox_clearance extension to projectiles, and did that. I also will need to look into if monsters are subject to traps, because if not I worry that what I did to remove the trap clipping code will make monsters walk right through traps. But the trap clipping code is bad anyway. It doesn't really work since a trap doesn't fit into a box shape. If monsters aren't subject to traps I'll have to make them to be. But this won't make it into a demo. That will at least make the trap clipping code cover the damaging parts of the traps. (Edited: I think maybe disarmed traps still clip. I guess I have to look into that too. Armed traps may still clip that way too if so.)

Finally, today I changed the new variable lighting formula to try to better match dark, unlit triangles.

I thought about it and ended up going back to a simple contrast formula and added one more simple darkening term that's just like reducing brightness by up to 25% and surprisingly it's a better and maybe even an exact match. I don't know if this formula would look good for a regular SOM project or not. I got the idea from seeing the unlit models in SOM_MAP. The dark, low contrast textures looked nearly identical to the darkened zones. So I thought in light of that idea I should give it another shot. Also things are going so well I'm making an effort to address any and all defects.

I just have two more things to do before I can start packaging a demo. I'm extremely happy with the results. They're storybook quality. I hope it has a good reaction. I realized I should work on finishing the code that makes the water flow. In the last demo I just enabled a hack for that build. I still haven't finished it. And I want to try to do something for the containers so that the items inside can't be taken until they're opened. That might sound like a weird thing to say but it's because KF2 doesn't work like SOM in this regard. Speaking of the water yesterday I did a lot of digging around in the code to confirm the new 60 fps upgrade wasn't playing the colored flashes too fast...

I think some things are too fast. It seems that the pulse in the power gauges is the same as the pulse in the blindness effect and that these will be too fast. I don't plan to fix this for the demo, and I think the menu pulse is probably too fast also. It will get fixed eventually. There are always unfinished things. (If someone hypothetically used SOM they're invited to either use it unfinished or disable each enhancement until finished. That's the way it will always be.)

It may take me a few days to package a demo after I'm finished with the work. I think I'm going to put it on a site like itch.io instead of self hosting it. That will save me from using up space and get some metrics going and a way for feedback.

Holey Moley · « **Reply #100 on:** October 19, 2020, 01:07:29 AM »

Almost there, I've identified a problem with jumping off the edge of platforms that happens maybe 1/20 times but it's really annoying since it short-circuits the jump at the worst possible time so I devoted a lot of time to it yesterday and intend to drill down it again today. It's not fun stuff but it will feel good to get past it.

Scrutinizing it did make for some improvements. I've got the water/waterfall animation working properly without need to build a hack into the DLL. I recently came across the relevant code that does this kind of animation (moving texture UV coordinates uniformly) and it looks like the sky model moves at 1/40th per second, and objects move at 1 per second, and the new system I've added I left to move at 1/4th per second.

The sky doesn't seem that slow to me but I presume it must be so. Anyway, it's kind of patchy that all of these things are on different time scales and there's not a lot of control over it. At some point I will attach it to an Ex.ini extension that can change and even regulate the animation speed on a case by case basis to some extent. I don't think the slime monster will be animated in my demo, but I do intend to add support for other models besides level geometry. The obj and sky paths will probably become anachronisms at some point.

KF2 has duplicate map pieces for every direction the water flows in, but the new system I've set up has an option to rotate the UV direction to match the tiling so that duplication isn't required. And I will eventually get around to removing the duplicated pieces.

Nothing more to report except more delays. I've increased the resolution of the Sword of Moonlight splash screen stored in the EXE file. It takes up the bulk of the EXE size. And I've decided to add a title screen to the demo that I stole from online, that's just a good quality cropped shot of the Japanese cover. I guess the cropping suggests it's a sneak peek, since it's like closing your eyelids. It's just the best I can do on short notice. (NOTE: I changed the splash to the SOM_MAIN background a while back. The sword is used for SOM itself but this other splash screen is for games if they want to identify they're made with SOM. The SOM_MAIN background seems better for that purpose. It's more low key.)

I've added an interior_border extension to [Window] that enables some code I've been setting on for adding a black border to help with edge-lit monitors. I'm going to have it turned on in the demo. The Ex.ini file has a few sections moved to the top that may be of interest to players. One is this, in case it is undesired. I think probably most monitors are edge-lit, because they're cheaper but I think people don't know they're getting lemons until it's too late.

I did fix a bug that has been leaking the cancel button from the menus to the regular game context where it must be mapped to one of the movement controls. I'm not sure if this has never been fully addressed or if it started again because of some changes in past year or two.

Holey Moley · « **Reply #101 on:** October 21, 2020, 07:43:17 AM »

I've not been having a great time. ~~I did get the jumping problem straightened out pretty easily.~~ I've been trying to get so many things in order. Tweaking everything. When I start doing that you I find more and more little glitches in the control system.

Strikeout: Actually it turns out the problem persists, even into the new demo. I've narrowed it down so much it's hard to reproduce, since it requires perfect timing. Every time it happens to me the jump is right on the edge of the ground polygon, or feels like it's at the exact same place. I can detect it, but not before it happens.

The last thing was a real nightmare that I didn't expect to work out well. I noticed falling off the small fountain was very disjointed. I tried all kinds of things to get the bottom of it. By the end I'd just retaught myself everything about the gravity system. It's annoying to go down a rabbit hole you've been down time and again and just forgotten.

In the end I think I just got lucky (this project is really charmed I think, I'm just its "holy fool" really) and the fix I barely was able to arrive at also happens to make walking downstairs possible in the demo. So even though it feels very draining I think there's really a light at the end of the tunnel.

The problem is (in case anyone is curious) walking down stairs is hard because you can't really know what the player is doing since there is no thing called "stairs" there's just polygons. So the fountain was the right height to under certain circumstances to look like a very tall stairs. Actually everything is treated as stairs when not jumping off platforms.

Maybe this problem is because something else broke something or maybe I've just never really noticed or cared. But since I didn't want to make it into a huge project at this point I needed as simple, generic solution. And luckily now the normal stairs you can walk down at full speed, which is something I wasn't planning for the demo. And the walking is fast like when you walk down stairs in a hurry. You can still walk slow of course.

But you can't walk down the lighthouse full speed, and that's understandable I guess because it has stairs that in real life would be the death of lots of people. There's basically not room to put your feet on those stairs, so only the professional lighthouse person would dare climb those lighthouses. So yeah, it's appropriate to not be able to walk down them full speed ahead.

I've been working on everything. Footstep sounds, and all manner of climbing and squatting embellishments. Jumping is almost like a skateboarding game now. I even added something to get the slime lighting right since they differ from the other monsters. The slimes are lit like the NPCs and the rest of the environment.

I still have that one last project... maybe I've been avoiding it subconsciously... but yesterday I did study a lot of the relevant code to make sure I understand it. My goal is just to be able to open the secret compartments without taking out their contents first. I might try to do the same for things like barrels and graves but maybe not yet. Right now I'm just giving items a larger activation radius so they take priority.

It's almost the end of October, so I don't see any way to do anything in 2020 after this demo. I could crunch on more level geometry but I don't see the point if the monsters don't have their AI in place, and I don't see myself being able to do both the AI and level design in two months. If it was one or the other I could probably manage something. 60 days can be a long time but it can go very fast too, and I tend to work slow. As usual I want to highlight the control system in the new demo. I've done a lot of work on it in recent months that I hadn't anticipated at all. And it's really come together.

Holey Moley · « **Reply #102 on:** October 24, 2020, 12:24:08 PM »

Okay, I'm at a stopping point work wise. It's really good. Tomorrow I will start packaging the files and trying to prepare a statement and make a home to publish it at.

Holey Moley · « **Reply #103 on:** October 26, 2020, 09:01:30 AM »

Quote from: Holy Diver on October 24, 2020, 12:24:08 PM

Okay, I'm at a stopping point work wise. It's really good. Tomorrow I will start packaging the files and trying to prepare a statement and make a home to publish it at.

So yesterday I woke up with a lot of ideas about things that I'd got wrong, and spent another day like the past few fixing things, and some that were flat wrong that I'm glad didn't get published. And a number of mistakes I discovered along my way.

(I also tried to add a high DPI mouse option, since so many people have insisted they want to play KF with a mouse that just sounds silly to me, but also because the current mouse doesn't feel so great for just doing programmer test work when moving it slowly. The up side is there is some code for this in place, but I couldn't make it work satisfactorily for a demo. I don't know enough about mouse input since I don't enjoy first person games that use a mouse and keyboard, much less do I want to develop them. But it's a little closer, not that you should ever use it for playing SOM games. It just doesn't feel good enough.)

I kind of want to make a post about this, but I just now did work adding a new sitting down feature I've long wanted to have in SOM. The design of it grew out of an idea to let you manually squat when climbing by using light pressure to initiate your climb. The difference is do you come up on the summit hunched over and have to stand up or do you automatically stand up and keep going. Of course if you're doing a sneaking scenario you might have a reason to not stand up at the summit. Of course if you start climbing in a squat you won't stand up at the summit.

So I didn't know if this would work or be one of those things that's more annoying than added value. I will have to keep working on making the detection more subtle.

But I realized that this was like taking a seat if you think of "squatting" as ambiguous. Like if you're squatting on a ledge, you are sitting if you want to think of it this way. This seems like an elegant system to me. But it will raise questions when a body double system is added. My preference would be for a body double to prefer to sit to represent the state. If it's unworkable a manual system might have to be considered.

The detection is a little more complicated than this. If you give it a constant force that is not close to full then it does this kind of climb. But if the pressure is 3 or less (stealth gait in dashing mode) it always happens. But it's a little complicated with diagonals. This should probably be synchronized with the stealth gait sometime. Then another way is to look down in the middle of climbing. If you're taking a seat then you'll probably look down anyway. But here down means providing pressure and being far enough down that if you let go the look recoils back up.

In addition to this you can sit further out on a ledge when squatting now. This actually helps with slow climbing since if you don't do this you might fall off the ledge, but it simulates having your butt on a seat too, as opposed to balancing on your feat.

Finally, speaking of body doubles, I was planning to do a round of VR work today because I know the arm doesn't look like it's in the right position in VR even though I think it is centered in the middle of where you shoulder should be, but it didn't feel right last time I tried the experimental VR mode. I'm not trying to demo VR this time, but I think it's probably wise to fix this and the compass too, since the compass can't be displayed the same in VR. (I also want to see VR with the new sRGB blending. I think it will look a lot better.)

So I still have these two jobs to do in VR before I can publish, and I have to go into town sometime in the next couple days. On the plus side this morning everything (in the game) was feeling amazing. Sometimes it feels silky smooth, sometimes it feels choppy. I don't know if that's Window's or at the end of the day my brain is just choppy and my fingers are unstable. At the end of the day everything looks too bright. I don't know if that's my monitor or my eyes are shot. My eyes definitely do need to adjust my monitor to eye-saver mode to do programming work at the end of the day, but I don't know if the sense of being too bright is the same thing as that. I wonder sometimes if the monitor just gets warmed up or something. (Note, I don't keep regular hours, so my "morning" and "night" can be any time of the day, depending on when I wake up. I mean after I wake up and before bed. The eye-saver stuff isn't related to time of day or light if you ask me, I think it's about how long you've been awake.)

EDITED: I'm sure there's further work to be done to try to eliminate the "choppy" parts in SOM. I don't know if my work on the control system is airtight or not but there are deeper questions deep in SOM that need further exploring, and right now the input is checked at 60 fps. It might work better to do input faster than that but it will require rewriting the main loop. There may be little inaccuracies in the clipper too. But these can be drilled down on later. I'm just wanting to express my surprise at how good and seamless it feels today. Some of that can be luck too. There are outstanding glitches. Sometimes you hit them, sometimes you don't. Speaking of hits, I increased the number of stun hits in the do_red system today because in my experience it wasn't doing enough hit animations with decent hits. To do that I just switched it to use square-root to do the "critical hit" chance against the random-number-generator.

Holey Moley · « **Reply #104 on:** October 27, 2020, 07:00:55 PM »

Update...

I did the compass yesterday, without turning on the VR set. I'm also looking at shrinking down the menus in VR so they fit on the screen. I was all set to do VR today but instead I got sucked into an idea I remembered to be able to make crouching activate objects, so that if you want you can do that when "objects" are on the ground. That feels more natural to me.

To even not do it when crouching interactions are put on a delay so the subtitle text can be canceled when it's not appropriate. Currently items are exempt from this, except animated treasure boxes. So are NPCs and custom events. That means you always do those things as soon as you hit the button.

They will get upgraded when it's convenient.

After adding this I felt like the new holding or "wall-grab" feature (I think I called it) should do likewise. So the second half of my day I worked on this. The main difference is "holding" prevents climbing now (which it should have but I had no reason to do otherwise) so you can activate objects by grabbing them, or just holding the button down longer. As soon as you let go they're activated. So, you can do this to a door if you want, to pull it open. You can push it too but that just looks like a regular button press since you have to push against it to grab it.

The work I did to make pulling the door look natural I think improves on the holding experience. Luckily it looks natural when just grabbing a wall. In the mature control system that's developed in the past month or so really a commonality is there's always multiple ways to do things. Which way depends on the current thing you're doing. But they all flow together and feel intuitive and unforced.

For the record, this holding system is at the point where I could enable it to move arbitrary objects around with little effort. Especially anything that can just be dragged on the floor. KF2 has items that fall from monsters and bounce (or at least the money bounces I know) so maybe after I work on that it will make sense to lift up objects and drop them down and pick them up.

Now I just have to get this damn VR helmet on my head tomorrow. I'm not trying to demo VR this time around. But I don't want to have it broken compared to the earlier demo either.

simple machines forum

News:

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

STICKY: 2020 King's Field II port progress report

Author Topic: STICKY: 2020 King's Field II port progress report (Read 111763 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| Archive (pre 2023)| Projects, demos, and games Information| STICKY: 2020 King's Field II port progress report

Author Topic: STICKY: 2020 King's Field II port progress report (Read 111763 times)

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

STICKY: 2020 King's Field II port progress report