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

Holey Moley · « **Reply #60 on:** May 23, 2020, 07:48:21 PM »

I finished a makeshift kracken today. I may upload a picture tomorrow after a night's rest. Funnily enough for some reason SOM reproduces the KF2 behavior of alternating between the animations that I thought was impossible. It might not carry over if I change the AI settings, but for whatever reason even though the kracken can't move it alternates between the walking and idling animation.

I don't know if this is just SOM replicating how KF works, or more likely it's because the walking animation doesn't actually move, in which case it may think it's walking, I don't know. Technically the walking animation plays while turning around. So it might just play it through one cycle.

Either way it should be possible to take advantage of this to pretty good effect.

Holey Moley · « **Reply #61 on:** May 24, 2020, 05:52:55 AM »

Edited: For the record, these guys are fully animated, they like to spin around and play their walk/idle animations. They can't yet move off their spots because KF2 moves differently from SOM and I still haven't figured out what to do about it.

I sharpened this image a little bit because the filtered graphics look very blurry compared to the PlayStation. It's something I don't like about filters in general, I don't know if I will add a sharpen effect to SOM maybe or not. I don't like image based effects and I don't know if it's possible to do it practically. But it just doesn't look like KF so I'll cheat for now.

Holey Moley · « **Reply #62 on:** May 26, 2020, 08:27:43 AM »

Here is a new image, this time with a new do_sharp extension that I published yesterday, so no fake sharpness, and I noticed that monsters in KF2 aren't subject to the world's lighting, so I've attempted to approximate that in this image.

The headeater is enlarged, and the shadows under the monsters are softened. I don't intend to remove these shadows, however since they're not in the original I've made them fainter to be less distracting.

The chest and barrel shouldn't be subject to the fake lighting, but they don't look so different from in the original screenshot. I will work on excluding them from this lighting trick later.

I slipped the extension for doing this into the ones used to make KFII's unique color grading.

Code: [Select]

gamma_y = (pow(y*0.5+0.5,1.5)-0.355)*3
gamma_n = pow(n,1.2)*float3(-1,sign(n.y),1)*1.1

I don't know if this is exactly how KFII works, but it's very similar. It's still subject to the same lighting (maybe it shouldn't be) but it mirrors the X and Z axes to approximate the effect, and it boosts the values, which isn't normally done, but produces more dramatic highlights. I think maybe it's onto something because it makes the slimes look more vibrant like they are in the game. The headeaters seem to have exaggerated light coming off of them also. I thought that maybe the slimes are drawn twice to get a transparency effect that the hardware doesn't natively support, but I'm less certain now. I thought that about the flasks at first too, but finding the right grading formula mostly shook things out.

It's arguable why this would be the case, but either it can be said that transforming the lighting vectors would slow the game down, and they aren't animated anyway, or that it's distracting to have the monsters lit to match the walls since they're always moving around, and the wall lighting is asymmetric.

So I don't know if this is a useful effect for other projects. I wonder if KF or KFIII were like this. I don't know if I will keep the strategy to the end of the project, but perhaps it's necessary to give off the same feeling.

Holey Moley · « **Reply #63 on:** May 26, 2020, 03:40:49 PM »

I went nuts trying to improve on this formula.

Code: [Select]

gamma_n = normalize(pow(n,0.25)*float3(-1,sign(n.y)*0.4,-1))*1.5; Out.col.rgb-=0.25
It's the kind of thing that might never occur to someone making a game today, but the gist of it is the lighting on the monsters is pseudo-lighting that maybe helps to portray their character more than anything. You have to think of of the box to decide to throw out your established lighting scheme completely and just glue the highlights on.

Does that make KFII less than a modern 3D game? I don't know; it may be the soul of its charm. It may be something that catches on with SOM fans.

My new formula is design to capture the specific highlights on the headeaters. I'm skeptical it replicates what the game actually does, but I'm almost certain the game likely doesn't use the lighting coordinates in the model data by itself. To make pleasing pseudo-lighting you need I think to round off the sharp edges, it needs to feel evocative yet innocuous. I wonder if the NPC characters do this too, it could be key to how they come across as so organic if so. I know the secret doors at least must be lit accordingly or else you'd be able to see them, and I would have noticed if the treasure chests weren't so lit, but I might have not noticed the doors.

Honestly, I never really noticed the lighting was fake, and I never really noticed before the environment was lit either. I think it shows how subtle KF2 is. It's subliminal.

I'm warming up to the motto that graphics are for stupids. I think graphics is the path of least resistance in video games, and focusing on graphics is really a way to divert your attention from real difficult subjects. I think if you go in for graphics that you should at least be honest with yourself.

After spending so much time at it I think the krackens must have some setting that makes them darker than they'd otherwise be. I half remember StolenBattenberg reporting that they found a byte in the game that darkened and lightened them.

In the screenshot in the earlier post the kracken is darker, but after I applied myself more and more they became lighter again. I even cheated in that "gamma_n" extension by modifying the ambient light level because I know it must be darker for the headeater than for the map geometry and other elements, and I don't believe they're darkened.

I think the monsters likely just have a wholly different light scheme, but the trick I'm using for the time being makes use of the existing light scheme. Since the lighting is symmetrical it's possible to pick a direction in the lighting to look for that seems to work. It doesn't even have to be upright, and I did that by skewing the lighting away from the vertical direction because that's where it's harshest. You'll notice the ceilings are very bright, the lighting is basically pointing up like holding a flashlight under your face.

Something else I've noticed is there aren't any light sources in most of Melanat. I don't know if its subplot about being stuck in night relates to that reality, or if it's just an oversight. Maybe in a magic world light isn't an issue...

But I wonder what that will mean for my other project to resurrect King's Field, since I have a feeling I won't be able to get away with that luxury. I think how to approach the problem will likely lean on a new system to simulate how eyes adapt to low light levels, and also casting a magical "field" will provide some light. But there will have to be more light sources in a new Melanat. Maybe part of the magic system will be making light sources. It's a tricky subject. Since KFII is Aleph's story my plan (wrong project thread I know) is for Aleph to only have Wind magic, and the rest of his magic will have to come from weapons or items. Earth magic will be present in all of the games because the healing items will all work by casting an Earth field, and that's how you heal yourself. Dias has Earth magic, which is most associated with "necromancy" and may relate to the "monks" patrolling Melanat, who I imagine are undead soldiers taken from the soldier graveyard area of Melanat. Even though we won't call Dias "Necron", it's not far off. But that's not this project. The Wind magic will make green "ghost" light. There aren't really ghosts in the new series. It will have "monsters" that means plant-based creatures born of the Dragon Tree, that mimic life. But also "elementals" are a separate kind of entity, and ghosts are really elementals that animate material things. So, technically the undead army aren't people at all, they are just Earth elementals that animate things like old dry bones or even long dead soldiers. The Earth magic can even put flesh back on their bones.

Holey Moley · « **Reply #64 on:** June 02, 2020, 03:04:45 AM »

This is a look at how the KF2 style displays are progressing.

This image also shows a promising new effect to help with the cutout (colorkey) effect since that doesn't really benefit from do_aa like the edges of triangles do.

I think this effect will be here to stay. It works similar to do_aa and it may be possible to see the pixels changing from frame to frame, but I think only because of the relatively extreme white in this compass.

The color is extreme because KF2 crushes whites since its textures are all in the middle ranges. I can't see the effect on the compass at all in regular color. The benefit of the effect is hard to see elsewhere.

When I first tried to model a compass I thought that I would not use a texture but would make the lettering out of triangles to minimize aliasing artifacts but I didn't realize how that would mess up the smoothness of the surface for lighting purposes.

After I took pains to model it with a texture I wasn't happy with the cutout effect. You can see that version on the left. I also wished that I'd used more triangles for the sphere, so I will probably go back and redo it no matter what.

But this inspired me to think about how to improve the cutout effect. This wasn't as forgiving as the do_aa effect, but one specific setting seems to be acceptable, at least for my eyes. But I don't think it can be adjusted.

The compass on the right is using the new effect, which I think will be called do_aa2. The reason to separate it is it's more likely I think to be objectionable. It looks better than in this screen in motion, but there's also a possibility that you can see it in motion and be annoyed by its alternating between frames.

The displays on the left are the same, except one is over the mountainside so you can see its transparency. I'm not attempting to replicate KF2's menus and gauges. I want to do something more generic to be useful for SOM projects and I think having modern text invites doing a more modern presentation. The whiter frames are to match the white text. I tried using duller text and decided against it.

The "do_aa2" effect works by shifting the texture map over. It doesn't do it uniformly however, although maybe it should. That requires more work since the GPU "shader" doesn't know the size of the texture, so instead I have it shift according to the derivative of the UVs from pixel to pixel, which is something that's possible to do for texture sampling. It shifts by 25% of the derivative in either direction, and that means the cutout threshold varies and so it be superimposed just like the do_aa system. In theory do_aa helps with that a little too, but it tends not to have an AA like effect. Instead the jaggies are just accentuated instead of blended.

Because of this shifting all textures for regular geometry are being shifted, and I'm not sure what the effect there is entirely, but I don't notice it. For comparison I added a patch to the bottom left corner that shows what the textures look like without the effect. They don't seem particularly more crisp to me. The effect for higher resolution textures is even less. I tend to think solving the cutout problem is more important.

I don't know if the new "do_sharp" extension is going to survive since I found out it wasn't really necessary in the first place, but for what it's worth it still looks alright with this new technique. It lessens its effect, but it doesn't flicker particularly.

Before I thought to try my hand at a new technique I'd decided that I would go back to doing the lettering with triangles and just add a per-pixel shader that just does spherical lighting to solve the problem I ran into. It might be an interesting option someday but for now I want to stick with the texture approach since it's easier to customize the texture and can work with any kind of MDO file in case you wanted to do a custom compass. The only downside is to make it work like KF2 it will need this new extension to look nice.

It could also be accomplished with a texture with an alpha channel, but those aren't officially supported yet, although there is an old system that can do it. It's possible color based blending would work too. I'll definitely have to try that as an alternative or if this new effect doesn't work out.

BTW: I couldn't find the compass model in KF2's files, but I don't know where its magic models are either, so I have to try to find them, and maybe it's wherever those are. I don't think it uses a 62 field-of-view like the game does because I found that looks extremely fish-eye on the compass and KF2's compass is actually very straight. It may even be an orthographic projection. If not I think it's probably low field-of-view or else it would require tricks of perspective on the level of Michelangelo.

BTW: Oh and too I meant to add a problem caused by the effect (like do_aa) is it can show seems in the texture even more than before, so it will require cleaning up SOM's original artwork even more and will keep artists on their toes. The reason being is it moves the UVs over a little so they can cross a seam.

EDITED: Something I worry about with these effects is that the brain can see them even if you don't know it and it's taxing the brain to NOT see them. The more you pile on the worse it may be, even though in theory it's a lot like film grain or interlacing.

EDITED: Also of note, this is the first time menu elements and MDO files have been displayed as part of "extension" work.

Holey Moley · « **Reply #65 on:** June 03, 2020, 01:06:01 AM »

Before bed last night I had an idea to improve the new "do_aa2" effect especially because I worried it's too visible in the bright ceilings in KF2. I usually have ideas when waking up. The do_aa effect works in an abstract subpixel space that is invisible, however this new effect is visible in the texture UV space, so instead of doing it by slashing across the pixel I fitted an equilateral triangle as best as can be and used its corners for the effect. The fit is weird since it's very asymmetric and the X/Y bias is variable, but because the effect is geometric it benefits from a 3 point system. The center isn't in the center of the pixel, but it needs to move equal distances I suspect, which is why I chose the triangle, and most importantly in the do_aa system when going from 0.5 to -0.5 that's a big jump that is theoretically a source of strobe effects in the new technique.

As a result I can't see anything happening in the bright ceilings and I've turned the effect up as high as possible to get the best result even in the bright white compass.

Speaking of the compass, today I played with adding effects to it. The overshot effect in the game proved hard to do without writing a full on inertial simulation, mainly I think because the inputs are analog and even in a simulation they'd need to be more digital to get the same behavior.

As a result I settled on just doing the overshot effect when canceling fast turns where it seems appropriate. It wobbles back and forth a little, and I couldn't get the wobble out. Mainly because I had to exaggerate it to get any overshot at all to occur.

Beyond this I had first put in a simple delay so that it doesn't exactly follow your movement, which is how it is in the original game.

But then I took it a step forward and started to have the compass mimic some of your bodily movements. These effects aren't on a delay since they kind of represent the compass housing bobbing around instead of orienting itself internally.

I felt that it was too stiff to not do something like this. And I think it admirably does a good job of acting like a player character avatar that helps illustrate how your body is moving.

I programmed it to lean forward as if transferring momentum and this is counteracted by footsteps. When you hit the ground it acts like you're looking down unless you're moving fast enough forward then it looks in the opposite direction (as if looking upward) as if you're falling forward.

Lately I made it less sensitive to looking up and down so that in the middle region the lettering remains visible so it can be used as a compass. I tend to not look straight ahead when I play so this way I can still read it.

As for "do_aa2" I think my intention is to rename the current "do_aa" extension to this can change the do_aa behavior to act more like a basket of extensions. That way old config files will still work and it will be easier to set up. This new technique can be used without the others, but it's probably no recommended. So it's good to just have all of them flip on with one switch.

I'm going to remove the new "do_sharp" extension from a recent patch since it will be replaced by the new do_aa extension, and I will something like "aa_sharpness" or something to give better control. I had no idea the do_aa extension was about to get a lot better by accident when I made the patch.

Holey Moley · « **Reply #66 on:** June 04, 2020, 07:28:50 PM »

I was in town yesterday but before that I got sucked into my world of computer watching the clock all the while, by the end of the day I found the time to further revise this new technique to claw back the lost fidelity in anisotropic filtered samples so that it wouldn't make things any more "smudgy" through its addition.

The modified effect is scaled by the square root of the UV derivative so that large deltas are less effected. Large deltas can occur for more than one reason, but anisotropic filtering is the desired reason. It applies to distance texture triangles, but I don't know if that's acceptable since by then you're down to smudgy, tiny mipmaps anyway. Another case is perhaps UV mappings that are highly distorted, which ideally artists should avoid. It could be further refined by determining how distorted the mapping is, which applies to anisotropic filtering, and might even be a better formulation than the current, that uses distance as a metric. It didn't occur to me to consider distortion until just a while ago. A benefit of using distortion is it would not penalize distant triangles, but perhaps it's right to do so too.

With this augmentation there is no visible strobe to speak of, which is good for stability sake. The new code takes into consideration the dimensions of the textures since smaller textures need to reach further to find their neighbor pixels. I first found good settings for 512 x 512 textures, and then tried to work out how to adjust it to smaller or larger textures. I wasn't certain how too, so I just tried different ways, and ultimately I think what I ended up with works since it demonstrates the desired characteristics without ill effect.

I also took this opportunity to play around with mipmaps more, specifically in the Moratheia demo I tried to improve the spindly grasses armed with this new technique, which in theory should benefit them. This is an intrinsically fraught problem because there always comes a point where the width of the blades of grass becomes thinner than a single pixel on screen and suddenly they just pop in or out of thin air.

I don't think there is a perfect solution to this problem short of playing around with completely models that work differently or trying to blend them together somehow. I'm resistant to add alpha channel textures to SOM mainly because I think it brings with it all manner of complications. What I did was to boost the alpha in the mipmaps so that the grass has more body, since mipmaps tend to blur alpha, which is bad for cutout scenarios since it tends to make the mipmaps disappear into thin air more so than the higher levels in the texture. I boosted the alpha by a fourth, and that is folded back into the lower level mipmaps. Then I boosted mipmap sampling bias by about a third. That delays mipmapping effects until triangles are further in the distance. It's normally undesirable but it's been a common solution for grasses. But in the recent past I've not felt it had good enough effects to justify it. I don't know if it's actually helping now, but I read yesterday that companies are doing this when they are using "temporal antialiasing" which do_aa kind of is, by a loose definition. It kind of fulfills the same purposes, and anyway, there is a basket of techniques working in unison that ought to be able to counteract the side effects in theory. It's a common feeling that unbiased mipmapping is more smudgy than it ought to be, and it's part of the reason SOM looks more smudgy than the PlayStation, so I felt scaling back on mipmapping might help with sharpness.

But I can't say definitively at this point if it's a wise trade off. The only thing I can say is that for once the grasses in Moratheia seem to retain their same size and density on approach. And up close thanks to this new effect their edges could not be more perfect.

In fact, I'm now wondering if it's time to try to find a better algorithm than MLAA to generate the cutouts. What I liked about Intel's MLAA is that I could easily implement it using their source code attached to their research paper. I don't understand why exactly, but there is virtually no public code available for taking a simple 1 bit black and white image and generating a grayscale antialiased image from it. That's all we really need. Not a basic kernel based AA algorithm but a perfect one that at least does its best to do what an art program would if it had created the black and white image out of primitives. I know it's possible to do a lot better than MLAA. All of the code I could find to do better were giant projects that were as big as SOM and no way to simply copy/paste and rework the code into SOM. That doesn't seem necessary to me. I even wonder if there is something like neural-network code for doing this kind of AA today. I think it is a complicated problem, but it seems also like there might be a simple algorithm for converting a mask to grayscale that's just under lock and key somewhere and just obscure enough to not be public. It's certainly not something that's easy to think about and program. It risks getting sucked into a proverbial rabbit hole to try to do it from scratch.

Speaking of which, I wonder if I'm making good progress on KFII or not. I worry all of these weeks devoted to seemingly minor little micro projects are going to ultimately prevent me from doing the basic work of just getting all of the game's elements in place. I want to think I can just knuckle down on that once everything is in order.

Holey Moley · « **Reply #67 on:** June 09, 2020, 03:11:30 AM »

First, don't get your hopes up!!! this is a patch to the current demo at https://www.patreon.com/posts/23273769 which I'm preparing to share the do_aa effect. It just updates the SomEx.dll file, and adds new Ex.ini settings, and adds the volume effect to the water, and adds the gauges and compass elements, and changes the names of some items.

I'm still working on a new demo, but like it says, this is just a patch to the existing demo.

It also adds files for using a Nolo set for tracking with the PlayStation VR, but I used it yesterday, and as I recall the directional tracking feels far inferior to the PSVR's internal tracking, and I think I haven't yet worked on some kind of fusion to try to get the best of both. I did a VR session last night and I still sick the next night after. I hadn't done VR in probably 10 months, so all of the tolerance I'd built up while working on VR daily has been lost. The only takeaway I got was the color looks very good, which surprised me...

Oh yeah, two days ago I tweaked the color grading formula (not in a very intelligent way) to remove the smokiness from the PlayStation accurate formula. I probably should have done that a long time ago because I think the smokiness begins to play tricks on my eyes after a little while. So it's not healthy for me to work with the accurate color, and I think the new color is better, but just a shot in the dark. I'm sure there's probably better formulations, however there isn't a lot of wiggle room. By smokiness I just mean poor (low) contrast. That sounds odd because KF2 is incredibly colorful by game standards, but there's something about the color that's off, that gives the overall impression that the contrast is incorrect, and this could be because it's on a different style display from the original NTSC television standard. I matched it to the RetroArch Beetle emulator's color but I don't actually know its stance on the RGB output, that is if it outputs the exact same pixel values as the wires on the back of the PlayStation, or if it changes it to look pleasing. Of course I disabled all filter effects.

I don't know how much the recent changes to the do_aa system effected the PSVR experience, it's hard to say, but I didn't see them as a problem, which was the main reason I dawned the set, i.e. to verify it still looked acceptable under the new do_aa regime.

I may try to do a little more with VR because I noticed an unexpected effect with Nolo that when I turned by head the world seemed to zoom out a little bit, and I can't think of an explanation for this, so I think it might be a useful way to try to calibrate it, i.e. if I can make the effect go away then it probably means the result is a more sound system. That said, the funny thing about VR is effects can be purely in your brain, and they're always fuzzy, so you always feel like very paranoid if you can believe your eyes or not. This is because brains are so good at adapting (to visual stimuli) too good even.

Holey Moley · « **Reply #68 on:** June 09, 2020, 06:40:40 PM »

EDITED: I meant to post this yesterday before the previous post, but my Internet died on me.

Quote

For the record, I've now published this new dimension the do_aa extension(s). I'm only penning this addendum to say I eventually saw the value in having the effect applied in the distance (mipmap) and so changed course to a anisotropy based filter, only to find that the X and Y dimensions seemed to be linked in a way that merely canceling the effect for anisotropic surfaces was inadequate, so that the X and Y had to be independent and that maybe anisotropy is inherently ambiguous if the UV map is running in the opposite direction...

So I ended up trying to reformulate in many ways until after about 5 attempts, I tried the simplest way, and realized that I'd done the wrong thing in the very beginning in fusing the derivatives to create an X, Y area, and the key to independence was to treat them separately, and after this anisotropic filtered samples no longer degraded, so the whole problem of canceling the effect disappeared.

What I find funny is of all of the several attempts I made, they all did a good job of antialiasing, but they had undesirable edge cases. So, there was a kind of "local minima" at every turn where things basically worked, which was very misleading, so I'm very glad I was forced to stick with it. If there had been one of the solutions that worked acceptably I would have likely have settled on it and never discovered the original flaw.

Holey Moley · « **Reply #69 on:** June 18, 2020, 07:07:33 AM »

Random update

I told myself I would add the pirate skeletons, mosquitoes, and sigils today, rounding out the demo's monsters and NPCs, but instead I found myself (again) obsessing over the color function to see if I could make it better, just by luck I guess, since I've never had the good sense to set up a proper UI for dialing parameters up and down. And in this case it wouldn't work anyway since the function is hardwired into the shader.

Usually this just gets me on a roll whiling away hours possibly, playing with the numbers, but I decided to consider if my old formula was wrong to scale the texture colors when mapping them into the power function, mainly because I'd reached the limits of what I could do to try to improve the color because I always ran into the problem with the bright marbled ceilings becoming to garish to go on.

To my surprise I found out I could make almost anything look acceptable by scaling and shifting the outputs a little bit. I think this is a problem I often run into where either I assume that if a bug can exist that it will appear instantly, since it's hard to imagine most would not, or in this case, if something works, then I assume that there aren't other solutions that would work too. And so don't go further.

So I decided the old solution to the color was too baroque and so started looking for a simper solution, and I eventually convinced myself the power for the formula was 1.25 instead of 1.5. Even though a little surprised I was pleased that less power meant the ceiling situation could be less going forward, and I kind of knew the power had to be less because I thought probably the color in the textures just mapped far enough to cover the unused space in the palette.

Oh, and something important I forgot is my first experiment was to situate the middle of the color on 1 for the power function, whereas the old formula set the brightest color at 1 and shifted the darkest colors up, so instead of making a hump it was just a ramp. What surprised me is that both approaches can appear so similar even though they're radically different. (And as a reminder I sat down and compared individual pixel values with the old formula, so it was accurate over a large swath of the game's surfaces to the pixel value. But there were a few cases it couldn't cover. I checked all of those cases with the new formula and everything seems to match. But I haven't sat down to test pixel values and the new working formula is just an approximation. I actually don't like the standard color so much, so I'm not super concerned with perfecting it since the lighting is pretty much hammered out.)

Maybe this is more critical than figuring out that the power is 1.25. My motivation for shifting the center was the ceiling again. I thought if I could position it in the center then the power function would affect it least.

The black fog's power is 1.25 too. Speaking of which, yesterday I worked on the little fireflies around the lighthouse. I think these are called Fire Elementals in one version of the game or both?

The first problem was finding out if SOM could do them since something like them had never been demonstrated. Although I think I remember someone finding the necessary data in the SFX.dat file. I think KFII just copies the sprites directly onto the screen. SOM doesn't do that that I know of, at least not for its little "flame" sprites. I had to use a flame for the fireflies and was able to make it face the screen in both directions, however I think it needs some work because it doesn't take into account the direction you're looking, so it isn't as convincing up close as in KFII. I assume it's possible to refine it, but I don't know with certainty.

Finally, I knew that I would have to add something to make them blend into the fog. I think ever since I added the "shader" system to SOM I purposefully made sprites to not disappear into the fog. I also found out yesterday that the sprite system always treats sprites as transparent elements, so you can't even make one that isn't part of the transparency layer.

Originally SOM didn't apply fog to any transparent elements, so technically speaking sprites were never in the fog, although they were as some point, and still may be if you bypassed the shader system.

My reason for excluding them is I thought that they just looked better if you could see the flames even when everything around them were still in fog. It makes sense since the flame should stand out from the fog. Some of the monsters with flames are more ominous since you can see the flames peeking through the darkness before you can see the source.

But the sprites appear out of nowhere since they aren't blended into the fog. I never really noticed until now. I guess it needs certain conditions to be noticeable, like for one, a short draw distance, otherwise the flames might first be so small in the distance as to go unnoticed.

Nevertheless what's called for is a smooth transition, as always. In fact I don't put a lot of stock into "graphics" for SOM but I do take seriously smooth transitions, no sharp edges in other words. So what I've done is to change the fog factors just for sprites, and add some new extensions to cover this, that are fov_sky_and_fog_powers3 and fov_sky_and_fog_powers4. The default behavior is to use 70% of the sky power and 35% of the fog power. This may not always be acceptable.

The idea is for the sprites to just appear almost like a lamp turning on. Not out of the blue but pretty quickly so they're at their full brightness almost as fast as snapping your fingers.

Holey Moley · « **Reply #70 on:** June 21, 2020, 01:32:12 PM »

For the record I'm happy to report that the new color formula is really growing on me, and that I haven't augmented it, and so I'm feeling more optimistic for this project since it's using the original (PlayStation) color now and looks very nice.

The only thing I have to remember is something I realized a week or so ago when I was trying to improve the color, that on my monitor I need to keep my head down low enough so I'm not looking over the monitor or else it appears too bright and washed out. I had completely forgot about that, and I added another book under my monitor to raise it higher. But it still didn't look as good as it does now with the new formula.

I might need to find an arm system like I have for my television, I just rarely need to swivel my monitor around like my television, but it would give me a lot more ability to adjust its angle. It might even have a sweet spot to eliminate back light bleeding (edge-lit) which I'm coming to regret. It's not usually visible but it really ruins video games. I think that probably edge-lit monitors are one of those things that shouldn't be on the market because people don't realize the crap factor until long after their purchase, and it might even be something that gets worse with age. I'm learning if I ever need a new monitor to try to find a truly backlit display instead. But buying monitors is so difficult since there aren't many models to choose from and ordering them I've returned more to the store than I've ever kept. They are really so bad I'm surprised anyone wants half the LED monitors out there.

Holey Moley · « **Reply #71 on:** July 03, 2020, 08:06:20 PM »

Good news! I think there's finally an appropriate way to access more of the DS4 controller with SOM:

https://github.com/jibbsmart/JoyShockLibrary
https://www.youtube.com/watch?v=3qlZmXnE1mw

I've wasted a lot of time in the last few days wrestling with KF2's arm animation, namely the knife.

Part of the problem is I'm using it to dip my toe into working on the rigid body style of animation which I've neglected adding to my new tools and software since KF2 doesn't really use it. But I had to use it since SOM's arm system uses it and I need to work on it anyway. So instead of adding soft animations to SOM's arm system I'm going the safer route of converting (by hand) the arm animations to the rigid body style of animation. Luckily the arm in KF2 is segmented instead of one solid body and it doesn't really move, so you can tell it was built with a rigid body system and converted to the soft body format.

I think the soft body format feels more organic even when it's converting rigid body data, which is why I'm interested in favoring the soft body format.

Because my code is still in the growing pains stages with rigid body animation I ran into some problems and wasn't sure the source of them until finally today I figured it out. I went down a lot of detours into SOM's arm system which should bear some fruit, but I wish I'd not wasted so much precious time

But that's what I've been up to in case anyone's wondering. Speaking of that, I was also contacted by someone working with KF2's data and we've been pretty busy in the team chat room. They're not really known to anyone as far as I know. They've already helped me some and hopefully they will continue to help accelerate development. And we've discussed trying to upgrade the old PlayStation FMVs with machine learning, and it looks like maybe even that will be in the final product, or maybe even in the new demo

Holey Moley · « **Reply #72 on:** July 09, 2020, 07:20:17 AM »

Before I forget, I added a lot today, but I'm a little too tired to speak to it. Before I switched over to fixing the recent security breach problem I think I got the jump direction straightened out to a large degree just by adding some code that cancels out antagonistic inputs, that I thought already existed. (The jump system is a chief source of these because it acts like a capacitor of inputs, which it remembers even if they're antagonistic.)

Because I was working on SFX things today I was all over the place in the code in the new Ghidra decompiler and project manager software so I ended up doing a lot of miscellaneous things.

I added an arm_ms_windup [Player] extension that compensates for the fact that I've made SOM to not issue attacks until buttons are released. It can shave a few animation frames off the front of the attack animations. I set it to jump 150ms into the attack by default, but KF2 I set to 300ms (which is the limit) at least until I decide to remove the front of the its animations to try to make it usable to other projects. This can be used by players who want more or less responsive attack timing.

Likewise I relaxed the magic gauge requirement so that it's more like if the gauge is full when you are looking at it that you can still use magic, of course by the time you look at it and your brain hits the button and releases it that was a long time ago in computer time, so maybe by then it's drained away a little, but anyway that's the thinking behind it.

Part of the reason I did this is because I made the gauges more forgiving/responsive when crouching and holding onto walls so that there is bit of "cover" game you can play if you lean out from behind walls and fire off your magic and pull back.

I also made my project's fireball's clip radius even more slim than I already did partly so it doesn't blow up in your face when you fire it from behind a corner. (When crouching there's a tendency for it to shoot straight into the floor.)

And partly because I ran across the code that sets up the particle emitter for magic, so I could adjust it to factor in the crouching height and full range of looking up and down with the direction pad.

BTW, something I've been meaning to work on for a while is the problem in the demo (and with SOM right now) of falling between cracks. It's most obvious on the rope bridge. I've actually been meaning to address this for years... but I actually came up with a plan only a while ago. It's definitely something I hope to fit into the demo I'm working on, if I don't get so behind that I just rush it out without a lot of things I'd like it to have.

The reason this happens is because of an extension that's designed to not let you hover out over ledges like Wile E. Coyote, however the problem is, how it works, to be 360 degrees, like all features, is it shrinks down the width (radius) of the clip shape, so that works great if there isn't a crack on a ledge, but if there's a crack it means you fall between it as your shape gets smaller. (A "crack" is like a ledge sandwich, for example.)

For a while I thought I might need some kind of complex analysis to solve this, but I realized there is a real simple way that is probably for the best, that is just to do an additional clip test (a lot are done already) with the full width shape displaced by the ledges around it (at the elevation it will be after falling) and if the displaced shape still hits a ledge, then that means it can't fit into the hole it's trying to fall through. It's really so simple I don't know why I didn't set that up already. Maybe I'm missing something but I don't think so. A downside of this approach is it's extremely conservative and won't let you fall through any small holes, but I reckon that's probably actually a good thing.

EDITED: I also realized the Shift and Control buttons on the right side of the keyboard hadn't been considered for years, forever really. I guess I thought I'd merged them a long time ago. They're swapped like the left side now.

Holey Moley · « **Reply #73 on:** August 09, 2020, 11:47:51 PM »

Holey Moley · « **Reply #74 on:** August 14, 2020, 04:29:01 AM »

Just as the previous reply suggests, I've been working on difficulties around the arm set up of late. Sometimes it feels like instead of finishing this project I could end up just working on arms or something else right up to the deadline.

Adding a second arm to the mix has proven a series of mini projects, and I've been all the while working on the 3D modeling editing and conversion software. Really this modeling stuff is the bulk of 2020 for me.

The two-arm animations uses 0.4 m from shoulder to shoulder. This happened to be the value I chose for VR. SOM uses 0.5 m. But I had shortened for one arm so that vertical attacks would be center on screen. Except for two arms this wasn't symmetrical, so tentatively I'm using KF2's values, and maybe for one arm I will use the other, but it will have extension if so. I tend to think it looks better down the center. KF2's isn't, but it's not as far out as SOM's.

The model is actually centered on the right arm. This has proven a challenge for the arm_bicep extension because the bicep on the left arm can't be scaled so easily. But before I go into that (it's the bulk of what I plan to share) it also turns out SOM has some code for rolling the arm that isn't used. And I want to say something about how a dead arm is handled.

On the subject of rolling (twisting) I actually could have found this out when I worked on the do_arm extension. Maybe I did but I'm pretty sure not. I just had some code that set the rolling coordinate, but I crossed it out. I should have just tried it. I really didn't expect it to work I think. It sets the player character's roll status... now come to think of it I wonder it's possible to roll the picture on screen too. I should try that. I tend to not use rolling effects in first person since that's not how IRL vision works.

So, I've made the do_arm extension more modest in tweaking the arm. What it does is to make the arm looser and less robotic. Robotic and analog controls don't really go together well. There is dissonance there. The rolling is probably not normally even noticeable. It can't roll very much or the shoulders would be up in the middle of the screen, and it really depends on if you have a sword that cuts down the middle, like this two-hand one. It will just slash a little diagonally as a response to turning of moving sideways.

In the two arm system if one of the arms isn't animated there is code that detects this and hides it. I think it would be too confusing to try to split the ARM.MDL file up into two models, one per arm, since animations have to coordinate the hands.

With the skeleton I've used in the screenshot you can make the original SOM work with two arms, except it won't put your equipment on the other arm. I haven't gotten to equipping the second arm yet. Meaning I have more time to spend on this! No doubt there will be a series of new arm features coming down the road.

Back to the arm_bicep thing. I could have maybe just scrapped the idea, but I think it is a useful thing to have. It doesn't look as nice with KF2's models as SOM's, for one because I think SOM's bicep is way bigger, but with KF2 the way the joint is formed makes making it skinnier pretty easy to see. I don't know if I will remodel maybe. KF2's forearm is way longer for some reason. I don't know if it's to try to reduce the appearance of distortion or not.

When I switched to using the larger shoulder span I had to find a way to narrow the appearance on screen. I tried to scale it down, but I soon figured out that scaling don't matter for the arms. It's conformal, in the sense that if you want the shoulders to be in a certain place and a certain height then the scale doesn't matter. You just zoom in IOW and there's not much you can do. As a result I've opted to show a lot more of behind the shoulder than I'd originally planned. This is because if the shoulder is behind the picture it seems to be kind of stretched out to infinity almost. The little joint between the arms can be used to add some body armor like a bib to cover the shoulders up. Right now it's very apparent the arms are disembodied. I don't have a problem with that myself.

So, last but not least, it turned out the issue with scaling the left bicep has been an interesting entry point into the MDL file's scaling ability. I figured out its mysteries and which files use it (very few SFX files) and I got those files working with x2mdl (some of the SFX files are the most difficult) but I haven't yet implemented scaling with x2mdl because I think some changes to how it works may be in order.

The receptacle objects appear to use scaling to hide the replica of the items that are included in their animations. I actually think that's a system that needs to go, and it should be using control-points instead, as soon as possible. But it turns out the reason the scaling doesn't work in this case is the scale data isn't inherited by downstream parts of the skeletons, and because the original MDL files have a knot between every piece of geometry, the artist had applied the scale changes to the knot instead of the geometry. It's not inherited so the geometry doesn't scale. That means only like 3 or 4 SFX files actually scale.

Making the scaling harder to use is it doesn't correct for the center of the geometry. That means any piece of geometry you want to scale in a sane way would need to centered at 0,0,0 in your model, which would not look good in SOM_MAP for example. And it's not a very good way to work. But it kind of makes some sense to not inherit scale, but not to require scaling from 0,0,0.

Like if scale is inherited you run into problems, for example if you scale the "parent" down to 0 size, and then you can't scale the "children" back because 0 times everything is still 0. And you probably run into precision issues since if you scale small then you need a large value to scale back up. MDL uses bytes to encode scale factors, which is another reason inheritance wouldn't work so well.

It stores this scale in a separate transformation matrix. I'm thinking about taking over that matrix to store the starting pose of the skeleton so that it can be used to find the center point for scaling, since that's a start to make it more user friendly, and is kind of needed for arm_bicep unless I just assume the center point is where it's expected to be, i.e. a constant hard coded value. (Which it might be for now.)

I don't know if storing the pose could have other applications. The encoding of the deltas (scaling isn't done with actual deltas) actually has room for 1 more bit after I discovered the 3 scaling bits. I think possibly a good use for this bit would be to mark if scaling data is inherited.

The problem with not inheriting scale is I've never in all my life come across a modeling package that works like that, even though it has its merits. So it's mainly a problem because it's kind of completely incompatible with everything. Actually finding a way to communicate not to inherit the scale could prove very difficult.

I also learned that SOM ignores the animation data that moves ("translate") from point to point in the case of the root node. That's I guess why you can't have more than one root since they won't animate. It must use the CP for this. And it only works in relative values when it tracks the CP. I wonder if the arms would track their CP. I think probably they don't. That was one more thing making scaling the left arm difficult before I figured out it was impossible.

I guess I knew that scaling wasn't inherited since scaling the bicep didn't change the rest of the arm. Another thing you can't scale is the length of the skeleton, since it's not inherited. But you could compensate in your editing software by moving it back into place. KF2's arms actually move around ("translate") quite a bit. I think SOM's tend to just rotate, but I'm not positive.

Some of the arm stuff I'm looking forward to is a shield and running animation.

P.S. It slipped my mind to mention I've ironically been in great pain with my arm in a sling and some mild painkillers while working on these arm things in the past week. It's definitely slowing me down. It's just a mystery pain. Two or three years ago I had for two days the greatest pain in my shoulder. It just reduced me to a babbling baby doubled over. It went away instantly after the second night. I was doing all I could in the second day to get medical attention. I have a history of mystery pain in my arm and shoulder and wrist, I'm not sure what it is, but it's annual. Luckily I had some medicine leftover from that incident that I remembered a couple days ago. It's been a lifesaver. I think probably it seems to come from sleeping incidents, or possibly my work carrying buckets of grain and hay for horses, or my chronic use of a computer mouse to work and type. I wear a wrist brace when I sleep I think that's very important. You don't have to wear it in the day. I had a lot of regular pain before I adopted that practice. It was like bringing me back to brand new, so I definitely will tell this to anyone who will listen. I've read this, but my theory is if you sleep on top of your wrist not held straight you make yourself very susceptible to computer based strain injuries.

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 61708 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 61708 times)

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

STICKY: 2020 King's Field II port progress report