simple machines forum

Yesterday I tried (for a second time) to change the behavior of the "Bilinear" filter mode since it's pretty much useless. I would like it to keep the pixel look like the Point mode up close but do normal filtering from a distance, but this is impossible it seems (maybe it works on Nvidia drivers sometimes) without doing something radical in the shaders.

So I tried to hack something (for a second time) by forgoing anisotropic filtering and dynamically adjusting the mipmap sampling bias, but to no avail. In the process, in the aftermath really, I thought it might be simple enough to enlarge the textures in video memory, just for games with texture's like KF2's.

When I started looking into it I remembered SOM already does something like this, so it turned out to be very easy. It's something that could've been done a long time ago except that it only makes sense for games with small pixel art style textures like KF2.

It's not the final goal I have in mind, but it's a good middle ground for the time being, until I can figure out a more high-definition approach to upscaling KF2's textures.

I chose to call this mipmaps_pixel_art_power_of_two, which can only accept 0, 1, or 2 to enable 1x or 2x or 4x texture enlargement.

I guess it's a very niche extension, but it's worth sharing that this will let the forthcoming demo use the do_anisotropy extension and present a middle ground between the Point filter mode that's like the PlayStation (but more shimmering because much higher resolution presentation) and is more of a curiosity, and the regular mipmaps/anisotropic filtering mode that is too blurry up close with the original textures.

I'm setting it to 1, and this definitely gives it a more "pixel art" vibe, but it's like the original's, except there is a soft halo around the pixels that you can get rid of with 4x upscaling if you want. You might even want to see it without upscaling, which removes the pixel chunkiness entirely.

But the reality is the upscaling helps to hide seems on the tiles where they don't quite line up, like on the sandy beach floor corners. This misalignment is in the original game, but you don't notice it so much since the textures aren't filtered. This will eventually let me focus on straightening out the seams in the UV coordinates before moving on to try to perfect the textures and remap some problem cases.

Right now there's even a problem with the MDL format because it can't wrap textures and it's stuck to 8-bit UV coordinates. So this makes it too difficult to export models with mappings that cover the entire UV map since that looks ambiguous without wrapping. I could fix this by analyzing the triangles, but I don't want to do that, so the result right now is I tend to just stay away from the edges of the texture with MDL work.

Ultimately I want to replace the geometry with MDO fiels that don't have these problems. In the meantime it's pretty much impossible to be seamless with MDL files. So I plan to double back at some point and focus on texture maps, but for now I'm just working as fast as I can, quick and dirty.

There's no shortage of problems in converting KF2's data to SOM. Yesterday I had to rebuild the floor and ceiling around the small fountain because it can't work the way it is in the original data. The bottom of the fountain is flush with the ground, and the hole in the center goes through the ground. I actually extended the drain clear through the lower level so you can't see it when looking down into the drain, something you can't do in the original since you can't climb onto things.

The PlayStation doesn't have a depth-buffer solution, so it's like every polygon is sorted by depth like transparent polygons have to be sorted when they overlap. For that reason it doesn't matter that it sits flush on the ground, or goes through the ground, since the fountain simply replaces the ground irrespective of detph.

In order to get KF2's scraping door to work I had to do two things.

To make the sound work I modified the new/undocumented sample_pitch_adjustment extension to interpret values over 127 as frequency values, just like sample rates of audio recording data. For instance KF2 uses a 22050 rate (I guess it sets a max frequency) and since the door sound is extremely compressed (maybe this has a benefit of making less data or easier to process in memory) to extend it to 4 seconds I divided it by 12. so it becomes 1837 frequency.

SOM's pitch values, I think for at least a range are very similar to the PlayStation's note values. But they're limited to -24 to 20. I might try to extend that range, since the PlayStation seems to go much further, but they're stored as 8-bit values, so they can never go higher than 127, and a frequency that low probably doesn't make sense, so it's a good idea to be able to accept either kind of value. The notes are relative to the frequency of the PCM data, whereas the frequency isn't. The notes may also undergo some kind of mapping, I haven't really dug into it. It's very simple if so.

The volume of the sound seems very low. I'm not sure if it has to do with lowering the frequency or something else. My emulator may increase the "gain" on its sounds, that makes them louder. DirectSound doesn't support this. It can only lower the volume, so the only way to make SOM louder is to increase the volume on your speaker system, assuming you can do that. Which is kind of annoying. I'm not sure what's required to increase the gain, but the PCM data would have to be modified in memory. (I may have to look into that if I'm unhappy with the door sound.)

Second, because the door animation is very simple, and it lasts about 4 seconds, it required 113 frames. The soft animation format should be able to store 255 frames in each keyframe. That is to say this limit isn't even the full length of the animation but just between frames. But som_db.exe treats this as a signed 7-bit value. So the limit is actually 127. 113 would fit except with the new 60fps animation system it's really 226 frames.

So, I could just have just inserted an artificial frame I think, but instead I reprogrammed the instructions to keep the values at 8-bit, and it actually worked. The animation code seems kind of daffy, in that for every delta it encounters it recomputes the step size by converting an 8-bit field into a floating-point value, and then it divides by this value. This practice doesn't really make sense, especially because the 8-bit value is the actual memory where the keyframe's length is stored. It should have at least put that onto the "stack" at the top of the subroutine, or even better put the floating point value on the FPU stack, since it's constant. And division is very expensive compared to multiplication, so it could have inverted this value. But anyway, each of these needed to be converted to 8-bit from 7-bit, but this is just an example of how SOM's code can be suboptimal. To some degree this is perhaps because it wasn't compiled with optimization enabled, but sometimes programmers should be doing commonsense optimizations themselves.

That said, I'm glad it doesn't have optimization enabled since that could have removed code or make its code more difficult to reason about. Except for high-volume code like this being unoptimized isn't generally a problem. Before too long the animation routines need to be rewritten from scratch anyway.

I can't recall why but I think the rigid animation format may have a hard limit of 255 frames in its total run length. I don't think the soft format is so limited with this change.

Addendum patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip

I've deleted 2 or 3 "EDITED" posts referring to the previous patch. This little bit of code it refers to has bitten me so many times I just have to chuckle at it. I think it's stabilized

I also included some info on some features I happened to be working on in the past days. I will just say I've given them a lot more time than planned in order to refine them, and they are basically a feature where doors stay open until you move away from them, and a new "nosedive" feature that I had to moderate in this most recent patch because it was too much walking down 0.25m stairs...

It works by looking down some when you begin falling. I know KF2 does something like this. I don't know if it rolls sideways or in the direction of the fall. I generally don't implement head rolling because it's not realistic. (We have a vestibular system for that.) It also accentuates falls. I didn't design it to do that but in order to blend it with the "bounce" effect what seemed to work was to postpone it for the duration of the bounce, so that the recovery (looking back up) comes after the bounce, and the further the fall the more steep the "nosedive" so the longer the recovery. There's also a little bit a duck, that kind of feels like standing back up but is mostly not noticeable... maybe it should push the head forward, but I usually add a little dip when forcing a nod because it looks more natural. (Owing to us having necks and all.)

It's definitely pushing me to find a solution for the descending stairs problem, and falling into "cracks", that is between platforms using the system that makes it so you don't hover out over thin air. The solution is probably related or can be packaged together. It has to probe the space underneath the character's feet.

Adding CPs (control points) to the soft animation format is proving more work than I thought, it's crazy how once you start doing something you think is one project it turns into about 14 problems.

In trying to set up a door (both firsts in SOM history) I learned that some code I did quite some time ago to make doors less clumsy hadn't taken into account the vertical dimension. I guess KF2's doors being technically 12 m up from 0 is the first time a door was further away vertically than its own height.

I also found, as near as I can tell, the stone door sound in KF2 is extremely far pitch shifted. It sounds like a little high pitch blip in the actual waveform. I guess to use it I have to see if SOM's lowest allowed pitch is a real limit or just an arbitrary limit, since it needs to be shifted maybe 3 times more than the built in minimum.

Working with sounds is pretty weird, I think game designers maybe just take random sounds from sample catalogues and see what they sound like shifted to different frequencies to make good enough sounds. I guess that's easier than actually constructing a novel sound from scratch.

I had to listen to every sound in KF2 before I reached the conclusion on what was the door sound, and I never could have found it without the VABTOOL program TheStolenBattenberg recommended to me since it actually shifts the sound to the right note or pitch. The stone door sound is still unrecognizable but I reasoned it must be the door sound because I think the one next to it is the creaking door sound. I think there's a copy of the creaking sound as the very last sound file, then I found it again in the sounds that are in the first VAB sound bank that include a lot of the iconic sounds.

I'm hoping it sounds close enough with some coaxing, and works with Direct Sound because if not it will have to be rerecorded somehow. I also noticed that my emulator is playing KF2 at 30fps, and I don't know if it always was or if it lost my custom settings, but this let me notice (thankfully) that the door's sound actually took twice as long as the animation, which answers a question I had about how emulators sync sound (they don't in this case) and another question I have about KF2's real  frame rate, that suggests it should be half this so to match the sound. So it should be 15fps. I think even the PS2 emulator doesn't play at 15fps. When I was young, I remember KF2 being a much slower experience, and I've always tried to recreate that experience, because I think that fits it much better than a manic video game pace.

I noticed do_sounds is missing from my Moratheia Ex.ini file. I guess I never included it or deleted it. I was a adding a new do_reverb extension when I noticed. Did you ever run into problems with sound dropping out? Unless I recently removed it I've never noticed sound drop out. (My guess is you avoided adding sound sources to make it work without extensions.)

I'm thinking that do_sounds should probably be retired and replaced with a Bugfix extension.

Follow-up

I've been messing around with the sound and music elements ostensibly to try to utilize the sound that weapons make to complement my work on the arms.

I have to modify things I said in my previous reply because ultimately I scaled up the arms 25% because they didn't look proportional to NPCs. And they made monsters seem a bit larger than they ought to. KF2 uses larger and closer views of the two arm sword. I'm not sure about the others. This is partly an illusion owing to how small field-of-view works and because the arms don't actually clip through things. Like you can't penetrate walls with your arms, so you don't have a good sense of their scale.

The result of scaling up is a lot less shoulder in square aspect ratios. But I think it's a good move because it situates the shoulders in the corners in widescreen aspects and looks pretty much how I designed it at scale=1 there. It's closer to KF2's original style, cutting the arms off on the side of the screen.

I've also implemented pitch control for weapons. I added a pitch field to the PRF files a long time ago when I was desiging the enhanced ItemEdit layout, but I only got to implement it this morning. KF2's weapons use the same sound but at different pitches.

The PlayStation sound system has a lot more settings that replicate a MIDI system like an electronic piano or keyboard. Not your computer's keyboard. I think that DirectSound can replicate a lot of this stuff and I'm interested in turning SOM into a full featured MIDI system. I think any video game is basically like a musical instrument since it can play sound effects at any time in any combination.

Right now my Dagger sound doesn't quite sound right. But I'm just using a naive conversion of the sound effect with a raised pitch. I will have to dig much deeper into it. The weapon sound is the very first voice among the files. That made it easy to locate.

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.

Patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip

Ostensibly this patch is to remove some spurious code I missed that shifts that arm model over in wide screen mode.

It also fixes a recently added glitch that could occur when climbing a platform immediately after falling in front of it. It gave me an idea to try to implement wave interference for the bounce when falling to see if that's more pleasant than the current system. I wonder if I meant to do that originally or if it never occurred to me.

(I was also wondering today why my high school athletic team was called the Hurricanes when our state/city are land-locked and hurricanes don't happen here .. or really why this never came up in all my time in high school.)

Lately I've been converting KF2's arm model to use SOM's system. Today I tweaked the arm display system a lot. I was actually able to make it look like KF2's arm. But I decided it wouldn't do, especially in wide screen modes. I think probably (I'm not positive) KF2 uses some tricks on its arm. As opposed to displaying it as-is like SOM does...

One thing I did was to rotate the arm up some, to create the illusion of having a top-down perspective on it. But ultimately I had to make it rotate down in the middle of the swing since I'm trying to make the arm aim for the center of the screen, and rotating it up can make it go higher.

Another thing I did is to have the arm move forward and back again. The reason for this is to fade it in and out of view, but after I set it up I have a feeling maybe KF2 does this, because it feels like lunging your body forward to attack, which the ARM.MDL file doesn't actually do by itself. It wasn't my goal, but it feels more like an attack and I think that KF2's model doesn't quite feel right, but after adding this it feels much better, even without sound.

Lastly, the Moratheia demo's arm animations had an issue rotated up and with the arm raised up higher and made prominent. The problem is the longer swords weren't animated to get out of view, since previously they were much lower, out of frame. So what I did is set up a system to fade in and out the weapon (like spawning) that only happens in the very beginning and end, so that it's probably not possible to see in the beginning using the new arm_ms_windup extension, and in the end it's only possible to see the weapon fade out if it's very long and sticks out in the end of its animation, or if you're jumping around with the do_arm extension and manage to catch it in a pause or menu screen. It's a very subtle effect, but it's applied to all weapons, even though it's mainly for super big weapons that are hard to get off the screen.

Also, the new arm_bicep extension I might have mentioned before wasn't set up to accept a value. Also although I've fixed the field-of-view for the arm, after the changes I made today it looked fine at 62 so I made it to use 62 if that's the FOV setting. 62 is what KF2 uses, and although I don't like how it makes things look like a fun house mirror, I've actually gotten used to it, and one of the nice things about it is when you look down you feel like there's room for a body beneath you. With lower settings it's like looking through a scope on a gun at the ground, so you feel like you're just down on the ground I guess, which is weird. In the lower settings I made a quick fix to pull the perspective back when looking up and down, but I'd like to do that even for the 50 setting, but I only did it below 50 right now, since I piggybacked the change onto an existing effect that's capped at 50.

I've actually taken to switching between 62 and 30 like a zoom scope system. It's very convenient since that's when you roll over from the highest to the lowest setting. I have like a zoom lens when I want it. One of the bad things about 62 is you can't ever get close to things.