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

Holey Moley · « **Reply #75 on:** August 18, 2020, 11:05:30 PM »

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.

Holey Moley · « **Reply #76 on:** August 20, 2020, 09:59:38 PM »

Environmental Acoustics

The PlayStation has a "reverb" effect that KF2 seems to make use of. It has acoustical modes like to simulate a room or a hall for example, but I'm not sure which modes KF2 uses or what the effect is or if emulators even emulate this.

But my concern was the Dagger weapon didn't sound right in SOM (compared to an emulator mind you) even though I could confirm (I think) with a PS dev tool called VABTOOL that SOM's pitch settings seem to match closely to the Note played on the virtual keyboard, so I felt that the dagger was using the right pitch so it seemed either the volume or reverb was different.

Thankfully KF2 doesn't seem to make use of most of the settings on its tones/voices so there isn't a need to try to reproduce more exotic effects.

It's possible it changes the parameters in the game, and I know it does so for the weapons, or at least plays them at different notes. I don't know if it changes their volume and I'll probably never know unless someone working with the game in an emulator informs me, since I'm not investigating it like that. At least two people are.

I could tweak the volume in tests by turning down the game's volume and I still felt the dagger was off somehow. So yesterday I looked into adding acoustics to SOM.

I think I wanted to try this before but found that DirectSound 7 didn't enable it. Fortunately it turned out using DirectSound 8 was a trivial change since they're nearly identical. I didn't have to change much and the new code just acts like it's using 7 instead of using a different layer.

I can't try to emulate the PlayStation however the new effects system offers the following presets that SOM can use. I'm going to eventually work an acoustics system into SOM_MAP's event interface.

Code: [Select]

DSFX_I3DL2_ENVIRONMENT_PRESET_DEFAULT,
		GENERIC,
		PADDEDCELL,
		ROOM,
		BATHROOM,
		LIVINGROOM,
		STONEROOM,
		AUDITORIUM,
		CONCERTHALL,
		CAVE,
		ARENA,
		HANGAR,
		CARPETEDHALLWAY,
		HALLWAY,
		STONECORRIDOR,
		ALLEY,
		FOREST,
		CITY,
		MOUNTAINS,
		QUARRY,
		PLAIN,
		PARKINGLOT,
		SEWERPIPE,
		UNDERWATER,
		SMALLROOM,
		MEDIUMROOM,
		LARGEROOM,
		MEDIUMHALL,
		LARGEHALL,
		PLATE

I've never added an entirely new event class to SOM_MAP but I think it should be possible to do by now. In the short term there will be a lower level Ex.ini way to change the acoustics. This will be in the next patches or releases. It does give sounds a fuller body and more natural feeling.

I'm going to be switching over some sounds to use 3D and to locate the sources relative to the head than the feet of the first person perspective. I think that NPCs and monsters should be attaching their sounds to control-points if they're not already. I don't know if SOM plays sounds relative to CPs but the PRF files do attach sound effects to CPs just like SFX particle emitters. I just know that most monsters don't have CPs around their mouths and the ones that do probably don't emit screeches from them.

Strikeout: It occurred to me that the sounds might not have CPs because they store a pitch modifier instead. The sounds do need more precise sources. There's enough bits to put the pitch in the sound effects field. It would not be back-compatible (so what) and it would complicate the PRF editors. (Edited: I think I'm more inclined to have sounds piggyback off the SFX control points, so if that's not desirable care will need to be taken to separate them in the PRF editors. If they're on the same frame then they will share the CP, and you can make two or more on the same frame, in which case they're taken in order. And of course this requires a dummy SFX assignment value for when no SFX is desired but a CP is desired for locating the sound, which might be most instances since SFX's have their sounds built-in... I think.)

Many monsters and NPCs have CPs of the wrong color that don't make it into the CP files and are actually a nuisance because they're technically visible in the game. A number of these are on the soles of their feet. I don't know if they were intended to be sound sources.

Before long I'm going to be developing a system to replicate KF2's light map and adding it to SOM_MAP. There's already space for it made in its main screen. I'm going to make it possible to attach an arbitrary number of these maps so that you can add any data you want to the tiles this way. Hopefully this will be good enough for assigning acoustics to areas. There will be any way to go about it, but if you want to paint the acoustics on you could do it like that. Or you could set up events that detect entering regions and do it like that. There isn't a difference between doing that and having an acoustics UI inside SOM_MAP other than you could do it without using a counter and the Ex.ini file. I just think it's one of those things that would be nice to include in the basic UI. Not everything can go in the UI since it would be overwhelming and underpowered.

There will be a do_reverb extension just to be able to disable it because sounds can be a big user of the CPU and the reverb effect might not be worth not being able to play a game. But I think it is a better experience that maybe I would want to experience as opposed to disabling it. It might be possible to put DirectSound on a second CPU core if this becomes a problem.

I've also been looking at playing MIDI files. The current release actually breaks MIDI support I found out. But also when the MIDI files loop there is a long pause for some reason, that's normal. That's just bad Microsoft software for an under appreciated part of Windows. It could be fixed by putting the MIDI on another thread. It's not the song that pauses but the entire program. So for that reason it's unusable in its current state.

DirectSound also slows to a crawl at the start of the game if there's no BGM and it used to do this for MIDI too, but since I upgraded it last night I noticed it no longer does this for MIDI, but it still does for silence. I don't know why this could be. I don't think it's something SOM is doing because it returns to normal as soon as a sound effect plays, but it could very well be down to something since I don't know how something like this could not have been fixed in DirectSound in all of this time. SomEx solves this without MIDI by making a fake silence WAV file for maps without starting BGM, and I assume that cutting the BGM in an event won't be a problem since it's a start up only thing.

I also discovered last night SOM was still dropping out sounds. I noticed some code where it maintains 4 auxiliary buffers that I guess it must use to play sound effects. And this number 4 (actually 4+1) is also used to allocate multiple copies of each sound effect. So I thought it should be set to 0 to not do this since it was redundant and wasteful with the do_sounds extension.

But then I noticed it dropping sounds. I thought it was doing so when I restored it to 4, but I think probably I wasn't noticing that I was failing to overwrite the program with the change because I had another SOM program open.

But the behavior was not how I would have predicted it, so I still don't understand it. I would have thought it was storing a sound in each of these buffers while it plays and no more sounds could play until one opened up. But if that was the case then I think the do_sounds extension would not work. So I don't know what it's doing without trying to figure it out.

Instead I knocked out some code so that it acts like a buffer is always available, so now I'm confident it won't drop a sound.

I know it definitely rejects sounds when these buffers are occupied, but I don't understand how it decides to free up the buffers or why it would be before the sound finishes playing. It also doesn't explain why there are 4 copies of each sound. That suggests they are playing from static buffers after all. It's very strange, but I don't want to drop everything in order to investigate it right now.

Holey Moley · « **Reply #77 on:** August 25, 2020, 04:46:03 AM »

Looking more at sound yesterday I added two extensions to control the pitch and volume of sounds called sample_pitch_adjustment and sample_volume_adjustment.

SOM sometimes lets you control the pitch but never the volume, and it always uses the same volume. I've also built in lower volume on the menu beeps because I found the built in beep sounds too harsh compared to the attenuated 3D sounds, which is a problem because they share a volume setting.

I found out the falling sound in KF2 changes its volume depending on the height you fall from. Luckily the volume extension can factor the height into its volume. To do this in SOM_MAP's event framework the sound event function would need to have an option added to load a volume level from a "counter". Generally speaking it's easier to do things like this with your Ex.ini file than SOM_MAP. I even learned that SOM_MAP can't subtract a counter's value from your hit points (HP) for example, so in order to subtract a variable value from HP SOM_MAP makes you to first load the HP into a counter and then subtract the value, and then assign the counter to the HP. Needless to say it's very clumsy and I should make a point to add some more options to that one's drop-down menu.

I've added the menu sounds and death cry and falling sound and falling damage and red flash effect. I'm going to include sounds for door objects and traps in the demo I'm preparing.

EDITED: BTW I'm thinking about making the volume settings far more sensitive since as near as I can tell only settings 12 through 16 are really feasible. Anything below that is silence but these aren't an absolute scale, so maybe some people have sound hardware where this makes sense but I have a feeling not.

P.S. A couple days ago I finally got a camera for my PSVR and set it up. I had to move the PS4 to be beside where I do my work since I didn't want to deal with splitting the PSVR between my bedside and desk area. I've long wanted to compare the PSVR in a PS4 game to my experience with using it with SOM. It turned out pretty much exactly as I expected. The PSVR games were not different from my own efforts in other words and I could see and confirm there are filters in play to cope with the odd color profile the PSVR has for some reason. Whatever is wrong with its color Sony must have factored in many decisions and determined funky color is something the PSVR could live with. I really like the PSVR and I think its hybrid cinema mode is a very nice feature to have in a VR system that I don't think any other VR system has. I don't understand why it doesn't use the camera to stabilize itself though since it's always drifting off course. It seems like an odd decision with the camera already sitting there. PSVR seems like a better way to play video games, but the one thing missing from the PSVR is actual games. I mean I've scoured everything and cannot find a single game I really want to play on it.

I'm going to try to play a ZOE game with a VR mode that I learned yesterday was actually a PS2 game. It's maybe the only PSVR game I'm interested in. Maybe Moss and this Alice in Wonderland inspired game (Down the Rabbit Hole) look interesting but so far too expensive for me to bite. The PSVR games are noticeably more expensive than regular PS4 games. It seems like maybe that should be the other way around. I just don't understand games today. They all seem extremely generic looking to me, and not artistic enough. I don't understand why Sony goes to the trouble to bring out a VR set and can't be bothered to stock it with more games. It's like it had a Resident Evil game for people who want to experience Deliverance in VR (not me) and nothing else. I can't identify with video games anymore. The PlayStation store is flooded with amateur games that don't give the impression that amateur equals artisan. It just looks like a wall to wall bargain bin. It feels like video games have become very seedy.

Holey Moley · « **Reply #78 on:** August 29, 2020, 03:25:56 AM »

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.

Holey Moley · « **Reply #79 on:** September 04, 2020, 12:46:49 PM »

This isn't really specific to my KF2 project I'm just marking progress in this topic for now I think.

I'm pleased to announce the old "cpgen" program/project that makes CP files for MDL files is now able to work with the soft animation MDL format. (For those who don't know, MDL is "model" and CP is "control points", although these are just guesses.)

This has been the final step on my journey to be able to use the soft animation format for my KF2 project.

I also discovered the code I had was broken in spectacular ways for the rigid animation format. I don't know if I ever quasi-published it that way but I see evidence that I once tested it with all of the "enemy" models, so I suspect the broken code in question was added later, since that time.

I don't see cpgen.exe in the TOOL folder, so I've never officially published it. I'm going to make it and x2mdl (and mdl2x) available somehow before the end of the year. If anyone wants it I can upload it as I have in the past.

I intend to package it somehow with my modeling software. The problem with SOM's model formats is they were designed to work with Microsoft's X model format, that has been basically nonviable for at least 10yrs, ever since I started working with SOM. So, I have been hesitant to publish tools without supporting editing software. I now have editing software--I had to make myself--and intend to publish them together as a package, but I don't know if the editing software is ideal to package alongside SOM, so it's a bit of a catch-22.

I probably will include it with SOM since I can publish it almost as a single EXE. I'm just not sure how to present it all. Partly I think the future won't be to work directly with the MDL and CP formats, but there's going to be at least a year or two before that becomes a reality, so I can't hold back these tools in the meantime.

P.S. When I awoke today this site was experiencing connectivity/response issues. It seems to be working now, I was really convinced something was wrong with my site. I logged into my account with my host, and its Disk Usage meter was beyond my 50GB limit, which is odd because I don't think the site is more than 10GB, and half of that is a backup of the old site (which for some reason is the same size even though it's BZ2 compressed???) so I think something might be wrong with the site. I've put out an email to the host's support staff. (Which could explain why it's working now, even though I've not heard back.)

Holey Moley · « **Reply #80 on:** September 04, 2020, 07:20:53 PM »

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.

Holey Moley · « **Reply #81 on:** September 09, 2020, 12:59:42 PM »

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.

Holey Moley · « **Reply #82 on:** September 09, 2020, 03:04:37 PM »

On a roll

To break up the new fat pixel feeling I decided to try to add a fat dither mode, and this is more of a retro emulation thing, but this mode feels much more like the PlayStation in High Color mode, so I think it's how people will want to play the game.

I called this do_dither2 and I was tempted to link it to the mipmaps_pixel_art_power_of_two extension instead, but felt it was more flexible to keep everything independent, even though it's harder to coordinate.

What's better is do_dither2 doesn't make my new Samsung monitor have seizures! It's crazy but these monitors can't actually cope with all video signals. I'm using it with VGA, and I guess either the pixel perfect dither sometimes causes freak electrical interference in the cables or there's some kind of compression or contrast trick that goes haywire. It only happens in some places in games. In KF2 it happens around the water.

It's identical to do_dither except the dots are 2x2 pixels instead of 1 pixel.

I think the new fat pixel look looks better in High Color mode, and this chunky dither helps to break it up so it's not so blocky. And the new texture space do_aa effect that the compass relies on is harsher on high contrast textures, so I think the dither helps to stabilize the more high contrast features caused by mipmaps_pixel_art_power_of_two.

When I finally release the new demo I'm going to set the options to High Color mode by default

EDITED: Show don't tell (screenshot incoming)

Holey Moley · « **Reply #83 on:** September 09, 2020, 06:54:35 PM »

A familiar scene

Holey Moley · « **Reply #84 on:** September 12, 2020, 02:55:07 AM »

Here are some more images. In the second I've tried to show off a change I made to the mipmaps_pixel_art_power_of_two extension to accept a fractional value to be used to soften the 2x2 pixels by applying a hand written filter to the blown up mipmap.

My goal is to make them vaguely unrecognizable as pixels so your brain doesn't shoot off "those are pixels!" some level of plausible deniability so you can see what you want to see in them. At the distance in the screenshot it shows off well how much closer you can get without seeing pixels, but it's not as close as you can go, since I wanted to have a nice photograph too, with the subject in frame.

I'm pretty happy with these results. It's very close to a successful upscaling of the textures, and certainly good enough at this stage, and I think it gels well, and is true to the spirit of the original.

EDITED: In case anyone is interested, the filter works differently from a regular linear filter, and it makes new pixels, that the regular linear magnification filter will sample between. Since there are are 4 times as many pixels instead of having them be the exact same color in blocks of four, what it does is to look at the corner of each block and blend it with the value sampled in the very corner of that quadrant. So the structure is still in 2x2 blocks, but the corners are softened, but they're not truly corners because there's only 4 pixels there, so really each one is a quadrant in the multipixel. So there's an organization to it. The pixel's own value is one of the four in the sample, since that's simplest, and the weight itself is quite small, like less than 20%, but very noticeable. You wouldn't want much more of a weight than that. It also wraps around as if the texture is repeating. In theory that can cause problems, but it's better than the alternative. I think even when the maps aren't designed to wrap around it kind of helps to soften the edges subtly, like in the lines in the ceiling.

NOTE: The aliasing is less in the moving picture than in screenshots, because of its temporal nature. I think the chunky dither pattern helps to lend it a film grain kind of quality that can feel a little like CGI. But that depends a lot on if there are any crummy looking elements in the picture. When it comes time to polish it up I want to eliminate any crummy elements.

Holey Moley · « **Reply #85 on:** September 15, 2020, 04:54:53 AM »

I may have spent the entire day working on the first secret door model and frame.

I had a couple good ideas. One was to pump the door model through x2msm so it is subdivided as necessary to match the MSM geometry for do_aa to work. I don't know why, but I don't think it's ever occurred to me to do that. Maybe it's because I have a lot more flexibility now with the new MDL<->MM3D tools. I had to add a backdoor way to tell x2mdl to output the fully subdivided MSM model. It doesn't currently have a proper command-line options system.

The other good idea was to truncate the vertex coordinates in the vertex shader so small numerical differences between the walls and secrets don't become visible. There might not have been another way to do it since even after I got the seams to go away from far away they tended to open up.

The tile system doesn't do anything that can corrupt the MSM coordinates since it just swaps the XY coordinates or negates them as necessary, whch isn't destructive to floating-point data. However the objects and character models undergo extensive 3D transformations that are probably way more involved than is necessary and prone to inaccuracies. (Maybe the do_aa system requires more precision than normal, I'm not sure. I could try without it and see.)

Just because the art data already exists doesn't make it a breezy job. It takes me (maybe I work slow) a lot of time to do every little thing. But it's nowhere near as much work or pressure as making art for a game all by yourself like Moratheia did. I still can't really wrap my head around making a game with original art work, but converting KF2 is a test of my ability (and a display of SOM's ability too.)

Holey Moley · « **Reply #86 on:** September 18, 2020, 05:36:17 AM »

Holey Moley · « **Reply #87 on:** September 22, 2020, 11:19:38 PM »

I seem to be progressing very slowly, in the past few days I've worked on issues around MDL models, to make them precise for hiding secret doors and compartments, including adding an extension to the MDL format so the texture can cover the last pixel on the end opposite of the 0,0 origin. The extension works by setting 6 bits is the back of the TSB field that are ignored (not allocated) by the PlayStation and MDL code. The bits are interpreted as meaning the UV coordinate is 1.0. The PlayStation doesn't need this because it doesn't filter its textures. SOM sorely needs it, although I intend to phase out using MDL for texture coordinates.

Yesterday I began work on the spear traps that spring out of the walls from secret compartments. SOM has some spear traps but I've long suspected they don't actually work. That appears to be the case. Today I will probably be investigating the code responsible for traps. It should be fun, but its continuing the trend of piling on delays.

I haven't decided if I will try to do something about KF2's trap doors at this stage. It seems like the something I'd like to include in a new demo, but it's a technical challenge.

P.S. I bought $40 of PSVR games the other day in a digital sale, including From Software's game, that cost $7. I don't know if I have time to actually play them, I'm sure I'll try, but I'd really like to play more games with a PSVR.

Holey Moley · « **Reply #88 on:** September 27, 2020, 12:43:09 PM »

I've started to look at selectively darkening some groups of tiles but I'm feeling intimidated by the project, so lately I've found myself working on these trap elements instead.

The blades work pretty well. I didn't replicate having one swing as if it's broken down over time, or whatever it's doing. I think KF2's worked that way because I suspect it's responsible for the interesting grinding sound that's like sharpening knives, and I think because neither is synchronized with the sound effect that their asymmetry helps to make it less noticeable.

I made it so that the only way to pass through is to walk directly through the middle very accurately or to try to slip between at a diagonal with good timing. To do this I had to make the hit box virtually square, which is a little counterintutive. There are two CPs positioned on the mid points of either side, that SOM must treat like balls. Not a very scythe like shape but you can't exactly tell.

I manipulated the sound effect by doubling it and making it more symmetrical. It sounds alright. The animation has to make two swings in order to loop back but the sound is only one swipe. I don't think there are two swipes in the original game.

I did the trap door today. SOM isn't really designed for this I don't think, but it basically works. I haven't tested it thoroughly but I think when the trap doesn't trigger the door is slightly leaky, which I could fix if necessary, and it looks like SOM doesn't have a way to make a door that is unresponsive to the Action button. I'm not sure how to approach that, but it means you can make it say "sealed" or "locked" but it is possible to hide those messages if you don't want them, but I'd like another alternative. I think the trigger is pretty reliable. I had to convert into having an open and close animation. Hopefully it isn't glitchy. It remains open like a regular door ever since I added the logic to hold doors open. That seems fine probably.

SOM's doors aren't designed to be placed in the floor. What I did is put the CP that designates the height of the door on the lip so that it goes down as it opens. And beside that I suspect it's more like an elevator door than a trap door, but that pretty much does the job. It can always be improved.

(EDITED: I'm thinking maybe the messages can be hidden if objects react to the phantom rod, since that ought to imply they're invisible secrets assuming games use that in the traditional way. It'd still be nice to add an inert option to SOM_MAP someday.)

P.S. I took some time off to play Moss on my PSVR yesterday. I can't believe sometimes I can't tell I'm looking at a display. I don't know what makes the difference but sometimes many things in the PSVR look like they're fully native vision without any pixel artifacts, it's really spooky when the simulation of materials is very realistic, it's like the thing is really there.

Holey Moley · « **Reply #89 on:** September 29, 2020, 10:47:52 PM »

A short note, I've been trying to improve SOM's "feel" to rise to the occasion of KF2. So far I've just tweaked the "pedals" to loosen it up since it's been feeling very stiff to me for a while, and after that I made some changes to attacks by having the gauge not wait for the animation to begin refilling, and I shaved some time off the back of the animation so it's not frustrating to swing after it's done.

I don't know if it needs a delay on the end or not. KF2 doesn't really seem to have one. You can kind of swing your arm like a windmill. Maybe some find that funny. Right now I have it stuck behind do_red so it can't be abused too much, although of course it can if strong enough to stun.

I've staked out a new release number for this stuff. Just now I've added a new npc_hitbox_clearance extension that somewhat decouples the clip shapes from the hit-boxes. I've made it default to 0.6, which feels very good with SOM's weapons and my KF2 project too. It makes it so you have to actually look like you're visually connecting with the monsters to hit them. (It doesn't scale and if the monster is less than that it's set to a minimum size. To handle extra large monsters it seems like the player needs to be able to actually get closer in order to make contact. This system just subtracts this amount.)

SOM's stock monsters have too much range on their direct attacks, so it doesn't seem fair. I don't think the player's hitbox is too large. They probably just need their PRF files gone over. Speaking of which I discovered today the enemy/NPC PRF files use diameters for their clip shape and shadow. I've changed the EneEdit and NpcEdit tools to show it as a radius to be consistent with ObjEdit. It's not great to multiply/divide by two to read/write the files but I couldn't fit "diameter" in the layout and it seems kind of funky to me. It's converted to a radius in the player program, hence why I've been confused about this for the longest time.

I also lost most of my day today trying to make crouching while moving (not "squat-walking", just not stopping fully to crouch, since there's momentum) smoother by removing the whiplash, but I just ended up convincing myself there isn't an easy fix. The reason it's like that is integral to how it works and does work well in that regard, but part of me wants it to not be a distraction. I have more reservations than this but it's part of a theme of trying to do a flurry of upgrades. Maybe the biggest weird feeling I have is I feel like it needs some kind of generic bounciness. In a way the exaggerated "bob" effect provides that but I've long since reduced the bob effect so it doesn't come close to classic KF or SOM except when running hard. It's just not how people move, but I feel like there should be some kind of sense of upper body movement and looser legs. I just have no idea how to translate that into a game system where you're in control.

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

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

STICKY: 2020 King's Field II port progress report