simple machines forum

Sword of Moonlight => Archive (pre 2023) => Projects, demos, and games Information => Topic started by: Holey Moley on July 30, 2018, 04:42:51 AM

Title: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on July 30, 2018, 04:42:51 AM



UPDATE/DEMO: https://swordofmoonlight.itch.io/k



(https://img.itch.zone/aW1nLzQ1MDUzNzcucG5n/original/NpCHB5.png)


I'm officially doing this :biggrin:

Update: Here (www.swordofmoonlight.net/holy/KING'S%20FIELD%20II.zip) is a verbatim copy of my working project. It's primarily for safe keeping on my webhost's server, but you can see it for yourself. I will announce future updates in this topic/thread. They will be regular unceremonious posts. Not regularly, just quiet posts.

6/8/2020 Demo patch: http://www.swordofmoonlight.net/bbs2/index.php?action=dlattach;topic=286.0;attach=1043

ZIP update: http://www.swordofmoonlight.net/bbs2/index.php?topic=286.msg2679#msg2679

EDITED: For the record, I found out that SOM_MAP's arrow icon, which I based this image on, is backward, pointing north, when it should point south. After the fix, the arrows in the image flow naturally like a race course along the walls. This backward arrow long gave me a misunderstanding of SOM_MAP's directions. I realized today that they default to south, not because of 2D, but because in the 3D view, south facing, seems to be looking toward the monitor, at us, because we think of down as facing us, and up as facing away... possibly because we (I) see the map laid out like a table top.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on August 02, 2018, 12:30:40 AM
EDITED: I discovered how sub-layers are encoded into each level. I thought it would shed light on the "mystery" level that this post mentions. Especially because it seems to have models that are not used. However, its sub-layer is a blank. It also occurred to me that it could be a moat or some other feature not meant to be traversed, but I struggle to think of a place for it in the game. My memory of the game is pretty fuzzy though.

As a test case I've reconstituted (in SOM) a 9th/mystery level on the disc, both because it was smallest, and I was curious about what it could be. I still don't know what it could be, but as proof of concept, I have recreated a section of the game in SOM.

I will probably make everything without textures first, because the PlayStation basically only has one texture (its video memory) and how it is addressed is understandably anachronistic. So basically manual model work is required to apply the textures. At the same time I will likely consolidate many of the profiles (the squares in the palette area of the original picture/post) since they are duplicated for each level... although it's very possible that there are subtle differences in the duplications, as is often the case for SOM's stock art work, and so great care must be paid to not destroy any information in the consolidation process.

KF2 poses many challenges for SOM, that boil down to necessitating new features that must be added to SOM in order to faithfully recreate its experience. That's going to be the bulk of the work for this project.

While this is a devlog, I am not withholding the product itself; for its duration, I will periodically make demos available in various stages of undress, until one day it will get to the point where only fine polishing touches are required. It's up to individual interest in KF2/SOM as to when to engage with snapshots of the incomplete product.

P.S. As for the "mystery" level, I'm skeptical its purpose will ever be known. Perhaps if it is populated with "objects" etc. something of its purpose will be revealed... perhaps not. It doesn't seem to be part of the game, because it runs the full width of the level, which seems like too far of a trek even for many of Melanat's long corridors. I don't think the game's designers ever meant to subject its audience to it.

There is a doorway toward one end, and beyond it a side exit into a 2 tile wide (3.5m) hallway that ends in a very small chamber. I also developed 20x20 icons for this level, and selected 3x3 icons for SOM's auto-map function. I could share a screenshot, but it's really not very interesting. I would prefer to let downloaders explore it when a demo appears later.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on August 02, 2018, 06:33:55 AM
Here's a fun screenshot on the sub layer of Guyra's level. I am hopeful that the MPX format might have facilities for two layers... because I've seen code inside of SOM that looks like it is processing multiple layers or simultaneously loaded maps (connecting corridors) and I know where the jumping off point is in the internal structure of the MPX file in memory, and I know that this memory is reset when a level is loaded, and so it reasons that if the feature extends to the file format, that there is a field in the file format for at least one additional layer.

At the very least, I won't be surprised if the MPX file has a field that mirrors this field that it has in the program's memory.

The scale factors are pretty weird. A tile is 2068x2068. That means if it maps to 2 meters (as SOM does) that 10341024 is 1 meter. On the other hand, the elevation units, are 128 apart. This means that tiles go up and down by 128 at a time. To make this work in SOM without changing anything, the vertical dimension (Y) needs to scale by 0.1/128 instead of 1/10341024. It's possible this distorts the final experience. Especially because the horizontal and vertical dimensions differ. It's also possible that the game in the PlayStation compensates for this. It will become apparent when furnishings are added since the difference is almost 80%. (EDITED: 128 is actually 0.125 meters, which works out to 0.5 most of the time, which is SOM compatible, because elevation changes tend to be 4 at a time. I'm looking into modifying SOM_MAP for the other cases.)

If the vertical dimension were subjected to the same scale factor, the elevation values will be even weirder than 0.128, 0.256, etc. It might make more sense to tweak all of the tiles by hand, in order to find a balance.

Strikeout: I now think 1034 is a strategy to overlap tiled polygons so that cracks appear less after they are rotated into place, since the vertices lose precision. It will be a lot of work to remove all of this, so I might stick with 1034, and fix the problems that emerge from it instead. It does make a difference. I will decide when I start looking at UV maps. EDITED: I noticed this because the water tiles don't seem to use 1034, so I'm assuming 1000 like SOM uses. If they overlapped it would double the transparency effect.

Strike 2: turns out it's 1024, like PlayStation uses. Or 1 meter in SOM is 0.25 in PlayStation fixed-pont.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on August 03, 2018, 02:05:39 AM
Upon further work, it turns out that the "1034" overhanging tiles were only a difference of 10, because the tile unit is 1024, or 2048 from -1024 to +1024. I should've seen this coming really. Just for lack of imagination.

This works out well for elevation, because 128 is really 0.125, which sums to 0.5 every 4 units. I honestly don't know why I didn't see this. Mixing 128 with 1000 was really a red flag. I can be a real ditz sometimes. It's the dumb blonde in me. (Is dumb blonde still politically correct?)

I opted to bake in the conversion from 1034 to 1, because the game's art applies this to climbing pieces (e.g. staircases) but doesn't apply the same transformation to the vertical dimension, therefor the seams are thrown off. The conversion negatively effects diagonal walls, because it pinches them in. But they are fewer, and will be easier to fix later on.

Luckily there doesn't seem to be problems in the caves. Or not the ones I've looked at. In fact, they are seemingly airtight. Which bodes well for the conversion itself. I was worried that their many faceted walls would be more difficult to repair, but they seem to avoid the full extents of the tiles.

P.S. I'm inclined to look at the layering problem next. Wouldn't it be wonderful if MapComp.exe would produce a layered MPX file if it is given 2 MAP files?! That's the dream scenario anyway. I have a feeling it might accept multiple MAP files, but will probably just spit out multiple MPX files if so.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on August 15, 2018, 12:29:21 AM
Here is a triumphant two story false color tweaked rendering of KF2's opening level. You can see the lighthouse on the left, and the waterfall in the back.

In the last week or two I've worked almost nonstop on adding multi-layer functionality to SOM so that it can entertain its maps. Funnily, SOM has multi-layer code and provisions within its file formats. Unfortunately, From Software either did not complete these facilities or disabled them. It's not as simple as flipping a switch back on (or it wouldn't have taken me multiple full time workweeks to pull it off.)

The layer stuff is halfway finished. This is the first image of a full map. It has only a test pattern for "texture" at this stage, so I inverted the image, to create the appearance of a white fog instead of the customary black. And I thought a white background would be more striking. However, I couldn't resist adding some color, and arguably I may have gone overboard with it, but I think this treatment brings out some details lost in the haze, although, it washes others out, in the more boxy rooms, that are overpowered by the stripes. The stripes are enhanced by the saturation enhancements that give it its color. Slight sampling errors become colorful highlights through successive saturation enhancements.

I could somewhat guide the coloration, and chose a combination most befitting this zone. If it's harsh, it was my desire to eliminate dull grays from the final image, especially in the very back in the effervescent waterfall area.

Two strange sections appear in the foreground, and there is a third in the back left corner that got lost in the brightness/contrast enhancement. I think these must have some purpose. I wonder if they are parts of the corridors that appear between zones. Even Guyra's zone has some like them. Their inward facing walls are not visible.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on September 11, 2018, 12:09:58 AM
A section of KF2 in SOM without any lighting or decoration. It's just the first such image so far. The fog is not meant to match the game's.

EDITED: Here is another, in 16-bit color. I usually prefer this mode for screenshots, but wasn't thinking about it when I took the picture. The AA is better (although it looks very good in the other) and it has a more retro feel, and the colors seem to be less overcast. On the other hand, the stipple effect can be a little too obvious on the PlayStation VR display.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on September 14, 2018, 11:46:02 PM
A teaser after 3 days of hand editing the shore/cliff tiles, including the sky. I faked the moon. I think maybe one of the models is the moon itself, but SOM will not apply lighting to the model if so.

I haven't worked on any of the cave entrances, the lighthouse, or the bridges. The water interfacing tiles often come in sets of 4, so that the water flows in a different direction in each one. I just grin and bore the preparation of the copies, not wanting to give it a thought, so that the job was in many ways more like doing 3 zones than 1, and I have a feeling its shore is a lot more varied than other level geometry.

I wanted to go ahead and develop the water area so I can figure out how to get SOM to make the water transparent. It's the next programming job ahead. I think I want it to be more rewarding, to see all of the water become transparent at once. So the water in this screenshot is not see-through. It should look exactly as it would if was however... I believe.

It's funny to see it this way. I won't lie, it isn't the same. Something will have to be done to summon something approaching the PlayStation's charm, but without trying to emulate the past.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on September 16, 2018, 08:03:00 PM
SPOOKY STORY

I made this latest screenshot after having spent a lot of time trying to figure out what decides the order of the sky's layers in the MDO file. After I succeeded in getting everything to look right (the glow behind the moon was being animated) I made this screen, and didn't want to go so far as to fire up a game of KF2 to confirm the position of the moon in the sky.

I was just looking for a nice view of the moon, that also included the water (and no unfinished tiles) and liked this one... wanting to incorporate a familiar location if possible.

I didn't think this was where the moon was supposed to be (edited: I just chose this position in the sculpting software, having to pick a side.) But I liked the shot anyway. But I was just now in the emulator and it occurred to me to check... and as it just so happens this is the moon's position in the sky!

I kind of expected it to be on the opposite side, because I can now see that there is zone-wide directional lighting (which I've attempted to reproduce) and if the light was the result of the moon, then it would make more sense for the moon to be on the opposite side, or actually, now that I look again, on the SW side.

Strikeout: Maybe there are lights shining from both SE and SW so that more or less it is from the south. But also the lights point up at the ceiling, and so it's not cut and dry that the moon can be a source of the light... obviously not indoors. I think the moon is in the north.


I might move it to the south side yet, so that the light sides of the cliffs line up with moon's position.

The glow in the emulator seems much fainter. And the moon is smaller, but looks very similar. I thought the circle would have a 3D highlight, but it doesn't actually. It looks like the screenshot. Except it seems a little oval... which might back up my impression that the horizontal/vertical FOV is not in line with the aspect ratio... or it might be because it's said that old televisions would make the picture wider for Super Nintendo games, and so it might be the same for PlayStation... but if so, the emulator isn't simulating this.


EDITED: For what it's worth, I've left the sky model so that the stars actually move like the clouds in SOM's skies. I think I may leave it this way. The PlayStation's stars twinkle as you move, so something like movement in the stars is a substitute. Although, what I find funny is that the stars closer to the ground seem to not move at all. I can't understand why not. It likely means that the sky effect must not be so straightforward.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on September 17, 2018, 10:18:38 AM
This screenshot has a color function I cooked up that while not based on SOM's classic gamma ramp, is doing something like it. I think a normal gamma function just makes all of the colors progressively darker, but I don't know if that has effect of bringing out mid-range colors by pushing light and dark colors to the margin, but that is what I've attempted to do here.

It makes the picture look like KF2 on the PlayStation. I don't have the foggiest idea why it does. The colors are very dingy without being transformed. If I didn't know the PlayStation only has 32 shades to work with, I'd guess that KF2 modifies the palettes at run-time so that colors become more vibrant like this. It's possible it does so despite its limited number of shades.

The sky texture is much brighter than it appears in the game. Oddly the stars appear much larger than in SOM. There are two potential sky model files, one of which I couldn't successfully export/import. It is green for some reason. It might have a different UV map.

The next release will probably have a gamma_function extension for injecting arbitrary code into the effects shader, and something for stereo (PSVR) in case it requires a different function.

EDITED: The image looks kind of dark against a light frame. It looks just right on back bordered display. The textures look a little crumbier. I think higher resolution textures will help.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on September 28, 2018, 02:27:33 PM
This screenshot is the first zone with textures. The image is processed to make it easier to read. Midtones are inverted to make the outlines. The color is adjusted for better visibility.

Interactive doors and other elements are missing. The textures are assigned by hand. It took me several days to do ever tile's. The water tiles come in groups of four, so that the workload is quadrupled. I'm going to reduce everything down in time.

The section over the waterfall with the wind crystal is green, because it's actually identical to the cave areas. At some point the images in the PlayStation's memory are simply replaced. I am generating the MAP files right now, so it isn't worthwhile to edit them. I have a feeling the tiles are identical to some other section of the game's. It will be easier to replace them after the MAP files are finalized.

EDITED: A month later I'm now noticing things I missed, like the green cave floor is usually a different texture, and caves (which I couldn't readily access then) are identical to the polished stone walls, with sand floors. I guess the stone is carved out of the mountainside. (BTW: I didn't say so before, but the area across the bridge is actually identical to the green caves. The texture just gets swapped. The same happens to the floor texture of the green caves with the save point inside. Oh, and the stairs in the caves are green.)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 01, 2018, 06:42:51 PM
A backup of my project is now here (www.swordofmoonlight.net/holy/KING'S%20FIELD%20II.zip) on this website. You can play with it. Included is a program for using your PlayStation VR set, with instructions.

There are colorless versions of most if not all of the zones, however only the first zone has color, and it has no exits into the other zones. There is only level geometry. The water is inert. If you walk slowly it feels like it's moving... but I did not want to work on an animation feature before backing up my work for the first time. I may be taking a break from it. If I don't it's because I cannot peel myself away! I may put a little time aside to look at position tracking for the PlayStation VR, but don't expect anything too miraculous.

There is a sky and BGM, but nothing else. The FOV setting is higher than the highest setting I've allowed for the F3 function. It is 60, which is closer to the PS game's, however the PS game's picture does not appear to be square. Alt+F3 changes the FOV, but if it's taken off 55 or 60 then the INI file must be hand edited to restore the unnaturally high setting. (NOTE: 50 is SOM's default. 60 is nowhere near as high as VR mode, but higher setting don't translate to flat pictures.)

There are holes where doors go. They can be jumped over, or flown over with F4. I am most interested in getting doors in place before anything further.

Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 12, 2018, 08:43:32 PM
Just posting an image to hotlink elsewhere. Figuring out the coordinate system of these things was tricky. (The up direction is negative. The origin is in the corners of the tiles, instead of their center. The 16-bit values are signed, and the divisor is 1024 instead of 4096.)

UPDATE: I'm replacing this image 1mo later. The old image had unfinished lamps and crystal with a test pattern texture. It's just better to look at. At this stage all of the "objects" are finished for this zone. And I'm considering doing more items before updating the ZIP project file again. (In case you're wondering, the flames are fully animated :batman:)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 20, 2018, 10:11:20 AM
I was able to use my PS3 memory card adapter to make an emulation friendly save file. I'm attaching it for safe keeping. I realized the backup computer I use to test Windows XP and other things might be 32-bit. And it was. The adapter only talks to 32-bit PCs from what I can understand. It doesn't have its own mass-storage drivers (why the hell not!?) but it's not even recognized on 64-bit systems. I don't know why.

I used a funny little program called MCRWwin to interface with/dump the card in the adapter, and another called MemcardRex to convert it to an emulator friendly format.

P.S. I'm adding a feature to let the name of "objects" be used to generate captions. KF2 has many things that show real-time messages when pressing the O/X button (depending on region/convention.) I reckon this is the easiest way. It just adds a checkbox style button to SOM_PRM that overrides SOM_SYS's real-time messages.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 21, 2018, 08:04:39 AM
Here is "objects" integrated into the level geometry. Even though, really these two objects are more like tiles, and at some point I will probably look at converting parts of them into tiles, since that's more in keeping with SOM's way.

I'm using 16-bit screenshots from now on I think, because I checked and they are 1/3rd the size of full color PNG images produced by my software.

The process is very slow going... I really feel for anyone who tries to make a game from scratch with SOM (Moratheia is one such example, although incomplete.) KF2 is especially difficult because so many of the textures are tiny things. It's really hard to find the right ones, even if you know what you're doing. I don't know that I'll ever arrive at a better system.

(EDITED: I've gotten pretty good at locating the files by their VRAM addresses and UVs. I certainly don't have to guess, but the process is still a little on the slow/work intensive side. I could automate a lot, but I think I prefer doing it slow, by hand, since it helps to notice details, and is more endearing. I will only get to do this once after all.)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 25, 2018, 12:55:20 PM
I've come quite close (close enough) to correct colors. I don't know how the PlayStation produces these colors, however NTSC (composite or component) encoding is pretty weird.

The reference (pictured) is an emulator with an NTSC filter, which I assume is pretty well tested. It certainly appears much more authentic than the textures on the disc do... which come out nothing at all like this image, but are very gray and muted.

I'm partly sharing this to save the image since it has the lighting set up and hack color function I cooked up in short order, in case I go and lose these settings somehow. I don't know if every zone uses the same lighting, however this lighting can be produced with only 1 light instead of 3 with subtractive lighting, so I think I'm going to add that option. If I had to guess it is subtractive lighting in the game, since I have feeling the PlayStation probably only has one light source. I've added a Subtract checkbox to SOM_MAP's layout to remind myself to implement it.

I think there may be black fog in the back corner in the emulated image that isn't quite right yet... that can explain why it appears darker. The port's fog is going to be distance based, whereas the original fog appears to be a straight line/plane instead of a sphere.

I had to modify the water fountain, only temporarily because it fights with the ground, and the well in the middle goes underground. That's not a problem for the PlayStation because it doesn't have a depth-buffer, so the pixels behind it just get clobbered. It must be hell to sort its triangles.

NOTE-TO-SELF
The yellow tint is not necessary (it's built into the texture) once the brightness lines up. 1.4 is a better value for "gamma"  and "gamma2" here drops out of the equation. There's no reason for "gamma,gamma" both values are just very close together. Increasing roughly increases brightness, but also contrast/vibrancy.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 27, 2018, 01:43:32 PM
EDITED :cloud9:

I noticed some lighting discrepancies on the cave walls...

Thanks to their facets I was able to (somehow) work out the complete lighting picture... I still don't believe I was able to do this myself. I swear I'm channeling something. Whatever it is, it feels fantastic.

I also (not pictured) hacked in moving water, just to see it in motion, since everything is really coming together. Honestly everything is a perfect replica at this stage. I only tweaked the lights because it's so perfect, it's driven me to absolute perfection!!

I no longer feel like this lighting combination can be achieved with a single light source. It's possible, but it's not obvious. The previous lighting settings (attached yesterday) I devise with the assumption that it was really just one subtractive light. I don't know exactly how the PlayStation accomplished lighting calculations. I don't see anything in the data that suggests precalculation.

The lighting is accomplished with 3 directional light sources, which seems like a lot. But it's exactly what SOM affords.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 28, 2018, 09:11:41 AM
UPDATE: Final colors, accurate to within a infinitesimally small threshold using the following color transformation function:

UPDATE: Finally able to use 3 instead of 2.9, and had to change 0.35 to 0.355 to get banding out of sky when pure black pixels are not converted to 1 instead of 0 (a new extension is added for this, but not recommended: do_black.) Also, there are new light settings, that are very different, in the linked picture.


Code: [Select]
[Detail]
gamma_y_stage = 1
gamma_y = (pow(y*0.5+0.5,1.5)-0.355)*3

Stage 1 is applied to the texture value directly after sampling. The lighting values taken from the attached image are then applied on top of that.

EDITED: Better colors :drool:

UPDATE: Turns out the ambient level is much darker, and so everything needed adjusting. The southwest is not unlit, even though it appears dark. The top face of the teleportation pedestal is the only indicator I've found of this. There is a dark hole through the lighting that shines on that face like beam of light from above.

(http://www.swordofmoonlight.net/bbs2/index.php?action=dlattach;topic=286.0;attach=968;image)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 28, 2018, 03:59:14 PM
Here (pictured) are two unique challenges of late: crystal flasks and wall scrawls.

It's hard to see how KF2 does either one of these. The highlights on the flasks seem impossible with 50/50 blending mode. All of the models use 50/50 mode, or appear to. I becoming suspicious that the mode setting is not in the TMD files.

Transparency can be weird. Sometimes triangles have two back-to-back, other times there is just one triangle. I wonder if the PlayStation had a two-sided rendering mode or not... it seems like must have looking at the magic crystals and flasks. The waterfall and lamps on the other hand, have back-to-back triangles, as do others. And the lamp, I can see for certain that the pyramid on the top intentionally omits the outward facing triangles. It looks a little strange without them, but better, overall. With just 1 triangle there doesn't seem to be enough color, however with 2 (note you can see both sides with crystals) they are probably too bright...

The flasks look okay with two, but I wonder if there are too many edges visible. That said, I don't see how their model works without two, and they look almost identical to the model in the manual.


Strikeout: Okay, the savepoint helped me figure out that the Blender OBJ import script is garbage. Somehow not only does it remove triangles! it managed to get the UVs all messed up this time... maybe the UVs on the back side are different. I was able to switch to a different import format, but I will probably keep using OBJ when there are not issues with transparent (crystal things) because it doesn't generate a bunch of stuff that has to be deleted after importing.

To make the flasks so bright there is a secondary copy that is outward facing only, which uses the emission color. I observed that x2mdo changes the blending mode when the emission color is not black. This is annoying, but it is insight into how the program selects blending modes given an X file. I think maybe it multiplies the colors according to the opacity setting. I haven't looked into it. But it would otherwise have to discard the opacity/alpha value, which I don't believe it does.


As for the scrawl, KF2 somehow puts a black version of the scrawl behind the scrawl texture. So I've reproduced that. Combined with the cutout antialiasing feature it has an embossed look. It's very hard to tell how the black version is situated. Sometimes it looks like it's shifted over a pixel, but most of the time not. I tried three different approaches. With a 2D emboss look, it is the most defined, but it has narrower outlines, and so is hard to see from a distance, and looks a little too literal for my taste...

Ultimately I decided on a vertical only offset, but closed the separation so that the two versions at least always touch. The first version I tried is much easier to see from a distance than this version, but it is just double the separation, and so the strokes are much fatter that way. The version pictured is medium visibility compared to the others.

Strikeout: I realized the highlight is just part of the texture, but that it was deleted because it's black, and so I had to take into consideration the 16th bit in the PlayStation pixel format that knocks out pixels. (More in next post.)

P.S. I don't know if it's in the game or not, but there is a 5th potion, that is red, that I've called Vermillion. I think maybe the idea was to mix two water types. I don't know, but if so, that would require six instead of of five. I can't remember if the central fountain is dry until the gold water appears or not. Its model looks like it is designed to fill up with water. Possibly there is another place to draw water from?


EDITED: The cliffs' skin isn't much to look at from that distance. Ultimately there will be a new skin pack with high resolution SVG versions of the same images. SOM displays item menus too small I think. I don't know if it should be larger or if it would be better to work on a way to scale up/down with the controller, and remember the settings. (I sometimes think looking at items would be a good use for a SIXAXIS style motion control function.)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 29, 2018, 12:55:04 PM
EDITED! I realized (maybe after noticing the scrawl text is actually the same as the text/skin on the gravestones) that the black highlights must be part of the TIM images, and I'd just neglected to handle the extra see-through bit part of the the 5:5:5:1 pixels.

The black highlights may be needed for the gravestones unless they use another image with the same text. It must be posted on the gravestones like scrawl if not, however, I will likely make a proper, composite texture if so.

I'm actually glad that the black highlights were missing, since it prompted me to render the image twice with the clean emboss effect, whereas otherwise, it would look very dirty, and I'm not sure I would've come up with that idea.

EDITED: Part of the cleanness of the scrawl (pictured in previous post) is instead of having a linear filter effect like on the wall behind it (pictured) it is actually two almost solid images overlaid so that the color between them is just the combination of both. There is actually some dirty purple and tan pixels in there, but I set the front overlay to use very little diffuse color and emission style transparency so that it looks mostly solid... and the dirty filtered color that is visible is more likely bleeding through from the wall behind. Black is already mostly solid just by virtue of its darkness.

I don't know how much the between color looking purple is from the original image or from the background being basically purple. I did add a little purple and tan to the diffuse colors to simulate the palette of the original image...
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 29, 2018, 04:16:09 PM
EDITED: Turns out the problem with crystals/waterfall, etc. that have two-sided polygons was Blender's OBJ format import script, which apparently can't handle basic functionality (unsurprising, lamentably.) So now I get to go back and redo these things to make sure they are correct. Savepoint looks wonderful though.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 30, 2018, 12:39:06 PM
More hopefully tantalizing screens. I'm updating the light configuration attachment from the other day's post to reflect more discoveries.

I'm sharing this image mainly just because it's a pretty cool iconic scene from KF2. After I set up the terminal (I'm not sure what they will be called, but unlikely Guidepost) there were two big problems: 1) the two upfacing surfaces that have the mechanism inserted into them were somehow considerably darker than the base ambient light level in the original, however the working light set up could not account for this, and so it clearly illustrated that the ambient level was much darker, and the southwest had to have light shining on it from somewhere. I had to think out of the box to account for this, and at times I could not convince myself it was not a 4-point light scheme. 2) its color was an unsatisfying yellow, similar to the green tunnels, and so I had to try different color transformation parameters to match the color...

The color problem seemed to go away by itself after the ambient level was adjusted. I'm not sure why, but I think it's because that got closer to what the natural level of the textures are. The real color is very, very dark and dull gray. It only comes to life when transformed. I don't know what the mechanism actually is, but that doesn't stop me from tinkering at it, which is very addictive because with every tinker it gets closer and closer to the spitting image of KF2, which for me is oddly exhilarating.

Since I had to back to the drawing board, I took the opportunity to switch the emulator into a simplest possible mode, that should be closest to what the PlayStation internals produce. That is why it looks very different from the other color matching shots. I'm thinking that it's best to match the low-level color, and from there user preferences can take over; kind of like how people tweak their emulators to look more like retro televisions. In truth, the games are tailored to technology of their day. But for this exercise, it's best to keep the raw outputted color... which may or may not look anything like a television playing KF2.

P.S. I stuck the picture from SOM_PRM in the bottom right corner just because it looks cool! It actually looks like the polygons are a different configuration, which kind of looks cool in itself. Also on display is the save-point. It's almost as tall as a man, even though it looks like a small thing hung on the wall, for some reason. KF2 never lets you get close to anything, its radius is much fatter than SOM's, which is doubled (recommended) by SomEx to a half meter radius. I don't know what KF2's is, but with the PlayStation's unfiltered output you would not want to get too close, and I'm sure that's why the distance is so great. The high/distorted FOV also adds to the sense of everything being small and far away.

I left the comparison image in full color to aid with comparison. It's not perfect, but is very close, and close enough, whether it gets better from here on out or not. With the new ambient level I tried and tried to make the picture less smokey/dull but could not. The input is so narrow/limited that it may not be possible to make the color more dynamic. Fortunately the high color mode is good at making pictures appear much more dynamic. That's why I prefer it, and true color is very often washed out anyway. Even under ideal circumstances.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 02, 2018, 02:34:26 PM
As of yesterday the color situation is a lot better, since I just happened to chance on a setting that looked really really close, and made all the lighting come together, and that spurred me to do another round of obsessive tweaking... which I should be doing with color software or something, but I'm just plugging in new numbers, start game, compare, stop game, repeat!

What I've had little success with of late is getting the colors to "pop" like they do in the emulator's raw output, somewhat or at least better than my color did. What changed this finally, is the terminal was more yellow than it should be, and that got me to try completely new values with a slightly modified transformation function, that could increase whiteness without increasing colorfulness. Eventually, with somewhat different numbers, I got an even closer approximation, which is frankly, good enough, for all future purposes, and does "pop" sufficiently. I wish I could get it to pop more, because the colors are a little drab, but I think it's very delicate, and more of a white-balancing problem, and the only way to go beyond the best approximation is to implement something like a saturation or contrast function on top of the color-space transformation function, which is something outside the scope of King's Field II. (The PSVR pathway does some color transformations like this, which I could leverage with some new extensions.)

I also took time to nail down the FOV setting. Which I've determined to be between 62 and 63, closer to 62. The INI file uses whole numbers for this, so that's as close as it can get. I think the real value is a little more than 62. But I was able to convince myself that there is nothing else funny going on, and that anything that seemed funny was just that the initial guess of 60 was just not quite enough. Not sure why the value is not a round number.


I've taken to disabling do_mipmaps and do_anisotropy so that the old point filter (nearest neighbor) can be used. It looks fine, because I've left do_smooth and do_dither on, so you can see pixels but the edges are softened. It's more colorful this way, and closer to the original for comparison sake, because the linear filter tends to dull/blur the colors in color comparisons. There are some issues with this that I need to look into first, but I may leave it like this (when I replace the project file here) for the foreseeable future.

I want to update the ZIP file before too long, to show off the accuracy of the port more than anything else. I'm trying to include all of the non NPC/monster elements of the first zone in the next upload. I'm not being careful enough about back ups, and so would prefer to not take too long between uploads, so that they can serve as short term back ups.

Below is the color transformation in use as of now.

Code: (old) [Select]
Out.col.rgb = pow(Out.col.rgb*1.6+0.3,1.6)-0.14;
Code: (new) [Select]
Out.col.rgb = pow(Out.col.rgb*1.55+0.325,1.55)-0.155;
Code: (final (with darker textures)) [Select]
Out.col.rgb = pow(Out.col.rgb*1.5+0.5,1.5)-0.3525;
It seems to retain the 1.6 value, which is mysteriously linked, and adds brightness after the multiplication, instead of before. Because of this the final correction is more severe. This looks so good that I deleted all past notes, on previous functions, and kept only a few that worked well last night, leading up to this one, only to demonstrate the process, in the hopes of one day making some sense of it all.

The color after all of this is not normal in the slightest. The dynamic range is actually fairly narrow. Anything that is remotely bright becomes absolutely white when not in fog or in one of the directions that don't receive light.

The menus are super bright, and so must be darkened to match the transformation. In truth, if the texture files are ever going to be mingled with SOM's they probably require rebalancing or something, but it's too early to make decisions like this for this project. It has its own color space for the time being.


EDITED: New picture added/attached.


EDITED: New formula above, is finally as pleasant to look at as the original, and a near perfect match. It has a little more color, which is not necessarily a bad thing. It can be seen in the yellow terminals, but not really anywhere else. More color is generally more attractive. I really had difficulty pulling brown out of the sand. This finally gets it.


UPDATE: Finally pinned down a formula with round numbers. This version came to pass after I decided to favor black over white when converting the 5:5:5 PlayStation textures to 8:8:8 BMP files for working SOM's TXR tools. That's probably better practice, it just interacts oddly with SOM's colorkey system. (Like, 0,0,0 must be 8,8,8 or it is subject to colorkey. But 0,0,8 is fine. The sky needed to be pure blue to work. The added red and green corrupts the color. But for the sky it introduced banding; banding is always a finicky thing with sky models.)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 05, 2018, 10:18:53 PM
Good news... this color work stuff is finally over! But one more post :rainbow:

I don't mean to keep returning to the subject, stuff just keeps coming up. 2 or 3 days ago I realized that the 5bit color textures would need to be converted to 8bit color (per component) differently. The result would darken the textures, and that meant back to the drawing board.

Fortunately, this proved very helpful in finding round numbers that point at a real function. And since I've all but perfected the color, and the lighting too, for the most part.

For a moment I had really punchy color that looked better than the original, that I liked a lot. But today I went back to more conservative values. I thought I found a closer white balance than the original color, maybe because the PlayStation balancing knob so-to-speak only has 32 settings. But I noticed it looking washed out in dark colors, and thought that the old light setting, might be superior, and so returned to it.

The setting I was using was haphazardly adjusted to allow for a higher ambient light setting, which was enabling the nice color. But today I darkened the color, and basically ended up at the original light parameters.

It now looks identical, just about, to the the original. And I'm happy with the color. By happy, I mean, it doesn't look dingy or anything.

More background is here (http://www.swordofmoonlight.com/bbs/index.php?topic=1129.msg13625#msg13625)

I'm confident the lighting is basically correct. By which I mean, it can only be improved by minor adjustments. It's very close to the last one I posted. I may or may not update it. The image is in the project folder.

I've finally added an extension for this. I should've done this a long time ago. (I've been doing adjustments by compiling SomEx.dll. It takes a little work to set up an extension.)

Code: (Detail) [Select]
;shader code (e.g. HLSL)
gamma_y = pow(y*1.5+0.5,1.5)-0.3525

This works with the do_gamma extension, which had never been supported by shaders. It is supposed to emulate SOM's fullscreen gamma ramp, but I lost interest in it. It does work without shaders, but is inefficient, since it emulates the gamma table with textures. I meant to find time to approximate the table, but never did. With this new extension you can try to do that yourself, and I may at some point try to set up a default power function.

The gamma_y code goes directly into the shader.

I'm pretty confident about the formula. The final term, I based on the sky. It needs to be enough to remove red and green from the sky that is added by the first term. I think that probably if it removes it from the sky, then it removes it from everything, lighting or not.

The terminal is much less yellow now, but still a little yellow. I don't know if somehow it can be made to work. Nothing else is like that. I suppose it's possible the game modifies the terminal somehow. The broken sword has a very bright highlight, that suggests to me that the function, or part of it, is applied directly to the palettes in the video memory. That's the only way I can understand the white highlight. And if the sword is brightened that way, then it may be that the terminal is less yellow for the same reason.

In some sense, this function is probably not identical to what the game does. If it is, then the game probably applies this function directly to the frame buffer (or back buffer) in VRAM. Still, it looks virtually identical.

There's not much reason to post a comparison, since identical is identical. I may be posting something to the front page when I update the ZIP file next time. It's very exciting to see KF2 in SOM, looking just like the real deal.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 06, 2018, 05:41:28 AM
The piece de resistance :smug:

Again, the sky tipped me off to this. Trouble with my efforts to match the color until now is I had been rather naively doing the gamma like adjustment in the effects pass phase... which might not be the best place to do it for other reasons, however, I noticed the sky had fewer gradiations than the original's, because it wasn't transitioning one shade at a time.

That's obviously because the image if you go by the textures as normal, is limited to a small band of the full color space, and so if you stretch it out, there's not enough information to fill in the in between shades.

I tried doing it to the texture, and also to the pixel. Actually I set up an extension called gamma_y_stage to let you chose between 3 places to perform it. I guess it should be used only to try to match a game's color.

I realized that in order to get the yellow out of the terminal, it would have to be done to the texture though. I just wanted to see the other ways because doing it to the texture was a little weird at first.

I came up with this:

Update: The new formula that removes the yellow from the terminal is "(pow(y*0.9+0.5,1.5)-0.345)*1.5"  and not the code quoted below. The change is described in a later posting. It looks really, really nice, and I think it's the real deal, and cannot be improved upon further.

Code: (Detail) [Select]
gamma_y_stage = 1
gamma_y = saturate(pow(y+0.5,1.5)-0.325)*1.5

The final 1.5 is not part of the texture. I assume it's 1.5 because it's close, and that's a round number, so I stuck with it, and adjusted lights around it. The "saturate" step clamps the value to 0,1 or as if storing it in a pixel... the texture's pixel. Values that don't fit into 1 are discarded, and that's how the terminal is drained of its yellow color.

I could not get all of the yellow out. The -0.325 part is calibrated so that the save-point doesn't lose any of its gradient to the clamping step. If the value could go lower then there would be less yellow. There may be other textures that would lose information. It's especially bad for the save point because it's texture is white, so if it loses anything that part is made invisible, merging into another shade of white.

It wouldn't matter, except the shades are visible in the emulator. It's hard to say how the terminal is still yellow, unless the textures have individual calibrations. The knight's sword on the ground still has that bright white section that I could not replicate.

The terminal's texture can always be adjusted to match.

The formula is different, in that it isn't multiplied by 1.5 inside the power function. But then it is, again on the end, as post brightening step. All of this is before lighting. I guess they are related, and look different as a result.

I kept trying to come up with a way to include the extra brightness in the texture, but it wasn't going to work. I realized that there was a secondary brightening happening, independent of the texture. This could be done by the ambient light level in theory, except it can only multiply up to 1.

I really had everything perfected :dazed:

Now once again, I'm technically back to the drawing board. But truth be told, it looks better than ever. It's just a never ending project. Of course, now there are more more shades possible. And the color draining effect works, even though it's really kind of a glitch in the game. It still determines the final color of things.

I think I'm calling the terminal thing a "terminal dock." I don't know. It's like a kiosk, or terminal, but the real terminal is the piece that is left in it. It docks there. And it's kind of like a dock, in that you arrive there.

I've switched the terminology so that the portal openers are called keys, because they open a door. And the things called keys, I just call them Moon, Star, and Sun. Because I am not calling things like the dragon replica thing, anything except a dragon. Since you know what it means. I am calling the skull key a "Sea Creature" because it doesn't look like a skull at all. There's no need to elaborate on the fact that it's not an actual creature! because that's obvious. I'm trying to be literate about the phrasing. And avoiding purple prose. At least in the English text I'm developing.

P.S. The do_smooth extension in disabled in this image, so that there is no filter at any point, like the PlayStation.

EDITED: I don't know why sections on the door and around the base are blurry. I should probably double check that nothing is wrong with SomEx.dll. It doesn't really support the point filter any longer. But it seems like probably it's only using it for magnification... funny thing though is the texture isn't supposed to have any mipmaps, so that's on Intel...

EDITED: So, looks like Intel doesn't implement a point-filter. I used the tex2lod instruction to fake it for this screenshot. And replaced it. I may try to make an extension for forcing a point minification filter.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 07, 2018, 11:55:44 AM
So this is not really progress, but it's something I found myself doing tonight, long into the night. It's definitely progress for SOM. I'm about to include it in a patch (http://www.swordofmoonlight.net/bbs2/index.php?topic=288.msg2658#msg2660)

I was going to say something about it in the patch's announcement post, but I changed my mind and moved the description back to here. "It," is a custom menu job, including some effects I had to program, like transparent borders, and better looking up/down arrows...

It has a new translucent border feature, and I made the arrows to display at their full size, so they look nice. I also noticed in the process that the icons needed to be offset a half pixel to get them to display correctly. Pixel perfect. It makes the inventory icons look better also. Come to think of it, there is already a setting for moving menu, that can possibly just be move over, if it's just an oversight. I'm making a note to investigate it.

I've tried my hand at this feature before, but never had the motivation to go the whole nine yards. It's been called paneling_frame_translucency and I guess that will stick.

How I did it is to have the borders and text fill out the z-buffer, so that the parts that overlap don't get drawn on top of, and double blended.

The back panels overlap with the border also. I don't know if this design just happens to work out. Or if there is bleeding there. It looks okay if so. I made the back panels a little wider because the border is thinner. (EDITED: I think I can see overlap of a pixel or so. It works well with borders of this width. Other size borders will need some way to control the margins of the back panel. If I cooked something up to postpone the back panels until after the frames, they can be subject to the z-buffer, and so work with frames that are not square. Even though you can't get too crazy with borders that are just extruded.)

The border texture comes from the HP/MP display in the game. It's different from the menu borders. I saw it out of the corner of my eye in a screenshot and thought that it could work as a border. I copied it from a screenshot with the sky behind it. I suppose there is a texture somewhere in the files, but I didn't go looking for it, since accurately reconstructing the menus and onscreen elements is not part of the mission. SOM will definitely get a KF2 style compass, but I will make the model from scratch, so it's better suited to the time, and other games can use it... although it will just be a MDO file you can make from scratch also.

I made the up/down arrows myself. It was harder to do than I thought. I think maybe it would be good to use the font to draw the arrows instead, since it's better quality. But those came out okay.

It uses extensions to tweak a lot of things. It has the same opacity as the original's. The text is white instead of golden/textured. I think maybe it's more like KF3. I'm going to update the project file again before too long.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 08, 2018, 06:21:37 AM
Disclaimer: I posted this here (http://www.swordofmoonlight.com/bbs/index.php?topic=1129.msg13629#msg13629) first. Word for word.

Code: (UPDATED) [Select]
[Detail]
;70,110,120,65
;gamma_y = (pow(y*0.9+0.5,1.5)-0.345)*1.5
;white light values: 75,160,160,80
gamma_y = (pow(y*0.75+0.5,1.5)-0.35)*1.5
;decent light values: 75,125,136,70
gamma_y = (pow(y*0.5+0.5,1.5)-0.35)*2.5


The four numbers are light values.

I finally figured out the saturation problem. In the quoted link I described cropping the color because the 1.5 power function produces colors brighter than can be stored in a pixel. I thought that this was the source of the desaturated elements, since they seemed pretty rare.

Trouble with that was the water fountain had tan streaks in it (its water is actually a little purplish if you look closely) as a result. So I knew that the cropping was too severe. I came up with a theory that because the PlayStation stored textures with 5bit shades, but had color/lighting parameters that were 8bit, that maybe the desaturation effect was a result of this mismatch, since there is left of shades after uniform mapping between these representations. I thought that the 5bit values would have to be converted into 8bit at some stage, but the requirement here was to go the other way, possibly as if the 8bit values were compressed to fit into the framebuffer.

However, I'm not necessarily convinced this is the case, but that was my plan. After I tried it, the color on the terminal was still too yellow, but other colors, like the starman's hair were too desaturated. So I chose a medium between them. But later I went back and asked what would be required to get the terminal to where it needed to be, and I also drug out its texture, surprised to see that it would not even be subject to cropping under the new formula. That is a little weird, because I really thought it was helping.

It's not real desaturation, but is the result of darkening, which brings it closer to gray. The value 0.9 was close enough to the terminal. And since it didn't require cropping, I removed that. To my surprise, after brightening the map to make up for the difference, the color is really nice, better than ever. Instead of desaturation, it had the opposite effect, so I think it means it's closer to the natural center of the power formula, however it's balanced against the textures.

It's kind of a funny system. I'm sure artists probably don't want to work in terms of a power formula, which might produce weird looking textures. Except the actual texture images are not really very natural looking either. I'm inclined to think maybe the textures (palettes) are processed after the artists finished them.

It's all very elaborate. I don't know if there was a big color lab involved or what. A lot of the 3D work is pretty slap-dashed, so it's hard to imagine the color work was an elaborate technical process. I'm inclined to think there must be a method to the madness though, because it looks really nice.


UPDATE: Dissatisfied after a while, I pushed the new approach further (see code above.) 0.345 is more accurate, but I chose 0.35 because it brings out more color and darkens the picture, which I feel helps, since the original's is a little washed out... which is not to say it's incorrect, because it's just raw output prior to signal encoding/decoding, and subject to television technology of its era. But it could also just be that PlayStation frame buffer is limited to 5 bits per shade. Although I think it could do more perhaps... most games, including KF2 did not take advantage of it for one reason or another. One obvious reason is it leaves less memory for textures.

UPDATE: The light maxima wasn't bright enough after that change, so the final value had to be increased to 2, and so I realized the relationship between it and the first value, and ended up with 0.5 and 2.5 for the two values. This perfectly replicates the color of the terminal. What all of this shows is you can arrive at ALMOST the same place from many different combinations. What matters is I got there, whether I could've saved myself a lot of time approaching the problem more methodically than trial-and-error or not :tongue:
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 14, 2018, 03:36:02 AM
For SOM more generally I made some unexpected progress with using the point filter yesterday, that turns out, for more than one reason these neglected filter modes have been using mipmaps. And it also looks like SOM uses point mipmapping in all three modes... which took me by surprise. It could be wrong... but it does look like it sets it that way, but it might unset it also.

KF2's textures are pretty basic by today's standards, and so the point filter mode can be a viable alternative for them. I'm actually preferring it for the time being.

The problems I discovered came down to the minification filter being set to "ANISOTROPIC" when there was not anisotropic filtering happening, and also Direct3D 9 changed the values used for mipmapping codes, that I didn't notice, and so they needed to be translated into the new codes.

These things have always vexed me, but with the default settings, it hasn't been a problem, since they use standard filtering settings.

I'm thinking about reviving the mipmapping facilities of the TXR format. I don't want to do it without doing a full job on som_db.exe's texture loading code though. I want to try to combine mipmapping with point filter. I think they can look better maybe if generated offline, but this is something I don't know very much about. It would help with load times, and I'm pretty unsatisfied with standard mipmaps, so I'm hoping there is room for improvement here. Ultimately for KF2 I plan to use SVG textures, and generate each level from the SVG, so that there is not downsampling per se. But that will come later.

P.S. I've found some kind of bug in the script editor after I tried changing the "MAIN MENU" label to say Alef, which I thought might be cute. I found out that it cannot be reverted back to its original state, without a script entry. The script editor is a beast. I have to set aside a day to dig into it before long...

Ultimately I wasn't satisfied with using the character's name that way. It was an interesting idea though. I guess you never know what something will be like until it's on the page.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 14, 2018, 04:13:32 PM
I had a long day redoing the glass on these lamps, and setting up those eternal flames! I replaced the old image on the first page with this one, since it's easier on the eyes, having everything finished.

(http://www.swordofmoonlight.net/bbs2/index.php?action=dlattach;topic=286.0;attach=962;image)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 15, 2018, 07:26:30 AM
I realized the lamp glass could be coaxed out of x2mdo because of how it works. I realized when I set up yesterdays screenshot that the glass was not right. I faked it by making it a little blue, but it still darkened the white plate inside, and the flame also, instead of lightening it.

To be honest, I think I prefer that version. But this new screenshot is close or exact to how it is in the original. It also illustrates that the ABR mode in the PlayStation model files aren't filled out, which is something I've been suspecting for a while now.

I made this image by setting the color to 25% and adding a very small amount to the emission color that x2mdo interprets as a flame, and so enables additive color based blending. Even though that's not what emission really is. This simulates the 100%+25% blending mode.

Maybe it's appropriate, I guess the idea is the light from the flame is trapped by the glass, and so bounces around inside of it.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 19, 2018, 12:46:36 AM
 :evil: This is the last of these, I swear!

After I had all but perfected the color, I realized that that last part of the transformation function that I fudged to be 2.9 but thought should be 3, just because 3 is a round number, might now work with 3.

The lights were much closer now, and I could immediately see that the individual colors tended to cluster to much more correct values, and so I went in and adjusted the ambient levels down to account for the higher outputs.

After this, I felt like I had a much better grasp on micro-tweaking the lights.

I took it as far as I could working with increments of 5 in the map editor. I just don't see a point in getting more exact than that.

I took this image just because I noticed the cameras were lined up really close. It's kind of a boring scene. But you see that they are indistinguishable down to very close color values.

Effects are all turned off so that they are both displaying triangles in the same way.


I think the up pointing lights are much more correct. I think I understand the broken sword now. I think it looks bright because it's really buried in the sand, except that the PlayStation doesn't have a depth buffer, so you can see the part that should be under the sand.

There are differences in saturation. I don't know if it's as simple as using a smaller correction. I am using a larger one because it seems less washed out, and it allows for the brightness to be cranked up higher without getting banding in the sky. I think that the correction is not quite enough to eliminate added white, and that is why it looks somewhat washed out.

They are both a little washed out. Thought it can depend a lot on your display. My monitor that I use for a television looks super dramatic, kind of like the screenshots on the back of the box and in the manual. It looks more cinematic that way. But it's pretty lossy also.

Still, whenever I get it closer to the original, it always looks better than worse, so I gotta hand it to its art director.

EDITED: For what it's worth, I only adjust to match the L part of HSL values. That's the luminance I think, or lightness. There's no way to account for the others, which are probably mostly noise, that is a side effect of the luminance values. When I say a pixel is nearly perfect, I mean that most samples will have matching luminance values. It's probably not possible to get them all to be identical, since there are slight differences in calculations (I actually have no idea how the PlayStation's lighting calculations work) and values must be rounded to the nearest shade, so being off by 1 is to be expected for some colors (given a triangle comprised of up to 16 different colors.)

EDITED: After this adjust the sky actually had banding, so I had to take the corrective further... maybe I never had it far enough to begin with. I think I may have noticed this sooner, except for some code that prevents pixel values from being 0, which I've disabled with a new extension called do_black. I don't recommend this extension by default, since many monitors treat black as completely off, which tends to have a lot of contrast with the next shade up, unless you've a monitor designed to go very black... which I find tends to just make many shades of black nearly indiscernible. Pick your poison I guess.

Code: [Select]
;light white levels: 75,105,120,55
gamma_y = (pow(y*0.5+0.5,1.5)-0.355)*3

FWIW I think the saturation differences are pretty much gone away with this change. I need to post new light directions to go with it.

EDITED: I had another horrid night fussing with the lights yet again, because of an effect on the south walls in the caves that I could not reproduce with the existing lights. Eventually I realized the ambient level needed to be higher (not lower) in order to do something else. I was able to reproduce that effect, but not without losing other lighting features in the process. I hope this means the ambient light level is determined to be within a slim margin of error of this setting. It's higher than I thought possible, so it's probably well confined. I will go ahead an repost the light positions as an attachment, to this post. And edit it into the other tomorrow. I will sleep better with a backup :goodnight:
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 22, 2018, 06:30:12 AM
Last night I ended up tinkering with the item screen, to make it more like KF2...

SOM's item screens have some issues. I think the most unsatisfying part of them, is that the items are actually too small. They are displayed in some undefined space, that is roughly where an item might be out in front of you. But I think that the placement of the item has more to do with fitting the full body armor on the screen.

The problem with this, is it means items are really small. And it feels really weird when you press a button to take an item out in front of you, and the menu pops up with the item smaller than it was in front of you. That goes against the expectation that you are going to pull the item toward you as you take it, in which case it should get larger, and appear closer to you, and in general, it should take up more space on the screen, so you can better see it.

The items are displayed noticeably larger in KF2. Although, there are actually two versions of each item, and the version you see when you pick them up is the same as the versions you see place among the level geometry, etc.

In fact, the Dagger item has a different texture mapped to its crossbar, that is like a rainbow. If you look close, a lot of the armors have rainbow coloring, so it's not surprising. The breastplate has a rainbow pattern, like the "starman." (Dead Verdite clutching the Star transporter device.)

Maybe these items are not shown much larger than how you see them, lying waiting for the taking. But they are certainly not smaller. They actually spin in the opposite direction as in the menus, and are not displayed tilted to the side.

Unfortunately, for now, SOM games only have one mode. I think I've decided to reverse the spin direction in the menu, to match KF2. My reason is, just to match this game, but also because ItemEdit's spin is reversed, and I don't know how to fix ItemEdit right now, and it so it just solves two problems.

It was pretty easy to enlarge the items. I found only 1.5x to be sufficient. This pretty much fills the screen, so that larger items need to be tilted to use more horizontal space. Before too long I will go further in, and figure out some custom manipulation system. I think I'm going to change the option setting concerning items to just determining if the items should spin on their own or not. I think that probably doesn't even require a rewording.

Enlarging them is a little funky for the Equip screen, since it puts the item off to the side. I had to play around with fudge factors to get the items to be better centered on the two screen types, to make better use of the space. I think I've come upon a pretty good system.

It gets complicated by the PRF files. Because they don't really have enough settings to manage everything. And they don't have any room for more settings either.

KF2 actually tilts its items differently. SOM tilts items around the X axis. But KF2 tends to do so around the Z axis. KF2 has separate models for this, a lot like how SOM has an extra model for weapons and gloves. KF2 actually has a separate model for the entire arm and weapon, as one unit. It seems to not have a model for gloves. So there are 3 models all told, for weapons. 2 for the rest.

I feel like I need to come up with a better system for this. However, I think the Z axis is a much better axis for tilting. Since typically it's weapons that require it, and swords tilted around the X axis are not interesting to look at.

In my experimentation I change it so the tilt is done like KF2. It looks better most of the time. But it means weird things for items like the Star device, since it's symmetric, and so a Z tilt means its design appears sideways, when you really want it to sit at a 45 angle, so you can see its design from the top.

To work around this problem, I changed its model, so that its default is like it appears in the menu, and it is tilted to lay flat on the ground.

Unfortunately, I don't have a good notion of how to institute such a change to SOM entirely, since while it seems like an improvement, it would definitely bork old games. But they could just use an update. Alternatively I could toss in some opt-in or opt-out extensions, but it's not obvious how to word it. There aren't a lot of old games, and the PRF files can be updated. But I would rather not change the orientation of the models themselves if possible.

I think that a better system can come about by extending the model formats. This way the orientation can be replaced with a simple animation to bring them into position. That's even less work than a whole other model. But that could be another option also.

There is some wiggle room to encode a Z axis tilt into the PRF files. There are so many options it's hard to settle on any in particular.

I just want to share, that I think these changes really improve the experience. And I am also going to be adding a pick-up system like KF2's to the mix shortly. I am thinking along the lines of a pseudo-extension called do_kf2 that will just be a hint, until I can figure out something else.




Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 24, 2018, 06:52:24 AM
So... it turned out that enlarging the items was the wrong idea... for VR. Instead of enlarging them, they need to be placed closer... which also makes them larger.

In VR if they get bigger, they get stuck in the wall, and play funny optical illusions. The original distance is 2 meters. So I changed it to 1. This looks good in VR, but it kind of depends on how close to the item you are when you pick it up. But it feels best all around.

1 meter is even larger than scaling up 1.5x. Though it looked good, in a chunky way. Bigger is better... until it cuts something off. To make it a little smaller, I changed the FOV for items to 62, instead of 50. Since that makes things appear more distant, and smaller. This doesn't effect VR. 62 is what KF2 uses, and honestly, it feels better than 50 to me, if you are going with a high FOV.

I noticed when picking up items, the item starts turning from the center, instead of in the menu, it starts turning from the right. The menu way looks better. The code that manages them is different. I still have to make the pick-up menu tilt on the Z axis. Tilted items, like ones that lay down on the ground, actually don't work so well, because there is no PRF setting to raise them up off the ground. That's not so bad for SOM_MAP, but for items that fall off monsters, I expect that means they get halfway stuck in the ground. Unless they are raised up by a fixed amount somehow. I haven't investigated this (okay, I just did, and it's just as suspected...)

The solution I have in mind, is to set up a drop animation system, so that the end of the animation can leave the item above ground.

Strikeout: Actually I had the angle set wrong... funnily ItemEdit seems to want angles that count down from 360, which is counterintuitive. That said, it does look better for the item to start sweeping in from the side instead of sweeping back from the center. So I intend to change it, from KF2's pattern.

P.S. Speaking of looking funny in VR... the Fire Crystal is weird in VR. It looks totally flat, like a piece of paper, or like it is steamrolled over. I tried to reshape it, just to see if I could get some intuition about why it looks flat. VR has a lot of optical illusions, because of the fake stereo picture. I notice this flattening elsewhere, like in the triangular ceilings in the cave. I don't know what causes it. Things don't generally look flattened. The rounder items look perfectly round. I wonder if I'm doing it wrong, or if it can be helped by figuring out a distance to focus on...

The secondary depth buffer that the shadow and sky blending effects use should be perfect for figuring out the distance to focus on. I just have to make an afternoon of setting up that system sometime.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 25, 2018, 04:50:14 AM
It turns out, in order to sweep Z tilted weapons from right to left (which looks best, plus an extra 10 degrees) asymmetrical weapons have to have their blade face right, and the upside of this is ItemEdit really only should use angles less than 90 degrees. That's more intuitive that using angles counting down from 360...

So that's good. The problem with that is it reverses the starting angle, so that the items appears to be on the other side of the imaginary turntable.

The downside of this, is I think the weapons that come with SOM face the left. And also, I kind of prefer facing the left. But there isn't a whole lot that can be done about it, other than going back to turning left to right. I think right to left if nothing else looks more appropriate on the main equip screen, because otherwise the item turns away...

Turning away is how it's always been, but if you think about it, it's as if you turned to face someone and instead of turning to you, they turned away from you. So I think that's not really the best.


EDITED/P.S. Funny story. The stations by the save points it turns out, are place on the map so that they float 0.125 meters off of the floor. The level designer probably sent a memo to the 3D artist to make them taller! You don't really notice it. Except in VR you see these things. Because it really looks like it's floating. I thought it was another VR optical illusion, until I checked more things, and so flew down to ground level once I began to suspect it was not flush to the ground.

The easiest way to compensate for this right now was to extend the bottom down to -0.125 meters. Since editing the maps is impractical at this stage. However, they will probably just end up left that way.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 25, 2018, 11:11:28 AM
 :ssh: I think tomorrow (Sunday) will finally be the day of the new demo. I'm going to take a break from KF2 after this! The part that I'm most pleased with is the work on the menus and item presentation changes. Mostly because I didn't plan to do either.

Everything is finished, except tonight I started looking into a weird, VR calibration feature, that looks promising, but hard to use in practice. The idea is to apply a fixed amount of rotation to the picture in the head set. The reason is while drift is pretty manageable, it seems like the picture tends to favor one side or the other. This is especially annoying for the Z axis, or roll, because it makes it feel like your head is not upright. I don't know what is the source of this.

I don't know if this can be automated reliably. And it needs to be fine tuned to several decimal places, or it can be. What makes it particularly vexing, is you cannot just recenter the picture, and go on what you see... but you must give it time to drift where it will drift, and then chose a correction that kind of splits the difference between one way or the other... on all 3 axes/dimensions in theory.


P.S. Since Sony returned my PSVR (which looks like it's probably a replacement) the home-theater mode is not really able to be used, because it now wants to reset itself if I look far in any direction. I think the firmware was upgraded. And how to disable this for PC is not well known. I haven't really used it much ever since the VR mode became pretty good.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 26, 2018, 12:04:10 PM
DEMO

I've (finally) updated the demo/copy of my project files here (http://www.swordofmoonlight.net/holy/KING'S%20FIELD%20II.zip) for the first time.

Update: I've uploaded a new 1.2.2.9.zip with an icon fix, and some other fixes for remembering window position. Both of these problems were because of recent Windows bugs. In the first case Windows simply couldn't find the icon in the running EXE file... god knows why... in the latter resizing the window inside of the main window was causing the main window to be moved to a default position... god knows why. I call this stuff WINSANITY. I also made it to retain the window position when leaving fullscreen mode with F11 (or Alt+F11 since the demo uses the function overlay system.)

The SomEx.dll file corresponds to this (http://csv.swordofmoonlight.net/SomEx.dll/1.2.2.9.zip) binary, that is an odd (demo) release, and not an official release (yet.) I don't have an idea about what the next release will be about, if anything, but this one (1.2.2.9) changes how items appear in menus, and it makes transparent map geometry flow in the direction of KF2's water/waterfall. It's just a hack to make the water move, until I can complete that feature. The waterfall is too slow, since the speed is the same.

The item appearance change is not compatible with existing item models and profiles. I haven't been able to decide on what to about it. I want to provide a build alongside the demo, so it can be patched.


The new things in the update are "items" and "objects" and the color/lighting is really close to the PlayStation's. The menus are pretty nice. The items are a mix of the models seen in the menus and the models that appear outside of the menus. Problems about because SOM doesn't differentiate the models.


On the PlayStation VR side, I've only had a little time to work with it. I've disabled the online calibration code that was inherited from the PSVRFramework code. I think I figured out what the gravity code was meant to do, and decided it seems more likely to cause problems than help anything. And I disabled the gyroscope code at the same time, just in case. Calibration is meant to determine if there is bias in the sensor, that causes it to always spin, or appear to be moving away. By not calibrating, you won't mess anything up if you manhandle your PSVR while the game is starting, or it is connecting. But if your set does require calibration, it might be worse off. I'm guessing most don't, but will work on a different, offline calibration feature if necessary.

I've added some [Stereo] extensions, and even have used some in the Ex.ini file.

Code: [Select]
[Stereo]

;WARNING! WARNING! WARNING!
;WARNING! WARNING! WARNING!
;WARNING! WARNING! WARNING!
;This setting moves the picture in the VR
;set. it MAY NOT BE RIGHT for you, but to
;tell you must center by pausing/unpausing
;and after, look back and forth, left and
;right, to see if gradually the picture is
;made to be more centered. The best way to
;test left/right is on the Use Item screen.
;The last value is roll, and most important
;since a bad roll feel is hard on your neck.
;to test it, roll your head, back-and-forth.
;find a vertical line, and open up the menu
;so the line is between the two main panels.
;to set these yourself, use F12 and look for
;"setcoords" when VR tracking is working, to
;determine how much of an offset is required.
;hopefully all PSVR units are pretty similar.   
head = 0 -0.055 0.0128

;94 looks solid, but looks foreshortened
;and feels wrong when moving/jumping
;94 was determined by looks, 110 by feel
;changing may require adjusting the pupil
;separation setting
zoom = 105

;turn off if you don't want dither in stereo
do_not_force_full_color_depth

I think I've had 3 PSVR sets in my possession now, and they all seem identical to me. That said, the "head" extension is pretty hocus-pocus. So if you try VR, be aware of it. The anti-drift system I've pioneered seems to enable prolonged play without a camera based tracking system, although I don't really recommend prolong VR sessions. It's meant to not have constantly reset the picture while testing out the VR mode. I don't know what to think about the VR mode myself. In many ways it's quite good, but it also manages to feel like a pipe dream at the same time. It mostly just demos competence with VR technology.

The "zoom" setting lets you override the fixed FOV setting of the set. I thought I determined a value. But for some reason gravity feels wrong with it, and I don't know if the FOV is wrong, or if there just needs to be more walking speed, or if there is something more fundamentally amiss. But I am feeling like higher FOV settings feel better, if they do not look better. By look better, I mean when you look around, it should not feel like the world is swimming. It may be that the FOV should be asymmetric, or the viewport is slightly off. There's a lot of possibilities.

I think the color is too saturated in VR mode, but I opted to not mess with it. There is code that increases the saturation because the PSVR tends to look very pale. But there are so many problems with the PSVR display, that might have a straightforward explanation, but that tend to just be at odds with each other. If I could crack its color like I did KF2's that would be spectacular.... but I'm sure if it could have better color than it does, Sony would've made it look right in the first place.

It may look over saturated because KF2 is actually pretty interesting, because it modifies its color so that it's not quite like specular highlights, but neither is it limited to just modulating a texture. You can really see the highlight effect in the moonstone and dragon fruit items.

For the most part the PSVR looks like KF2, but it's very fruity because by itself the PSVR looks like a hot green mess, so to counteract that it has to be purpled, but the discrepancy seems to be uneven, so that dark colors are more green, and so you end up with funny purple and green gradients. The terminals look like yellow pickles. And that's not even the saturation. I think it's just part of the PSVR's color...

I'm beginning to think that the terminals have a strange material property applied to them, that makes them look different color-wise than most everything else. Last second I modified their texture to try to tone down their yellow. But it didn't really make a difference for PSVR. But it did get much closer to the PlayStation. It's weird, because basically everything looks identical to the PlayStation except for the terminal's sandstone like texture. It seems to have modified contrast, after lighting, as if has a subtle polished sheen effect applied to it. Or maybe the lighting has more room for improvement. I think not though.


EDITED: Hmm, the icon is not working. I don't know if that was the case before. I don't think so. It can be fixed I think, by adding the following line to the SOM file:

Code: [Select]
ICON=KING'S FIELD II.exe

This just uses the launcher as an icon. I don't want to upload the whole ZIP again to fix this :redface:
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 27, 2018, 12:10:24 PM

I looked into the icon thing. I think it is a Windows bug. It will probably get fixed, but I programmed a fix, not patched...

What I think is new, is Windows is using the launcher for the taskbar instead of the launched program. That's actually a good thing in this case. It means it works to launch new instances if it is pinned (or even if not pinned, but how often do you open two games.)

I think it's a case of Windows getting smarter... but still Windows being Windows having unwelcome side effects.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 30, 2018, 06:06:04 AM
Patch

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

I've updated the DLL file (EX/SYSTEM) since I won't get another chance to, because I'm trying to add a feature to the PRF files so to control how items appear in the menus. I've already modified the PRF editor, and I'm not sure if I can modify the player easily or not, but I'm going to try. If the operation is a success the demo's PRF files won't look right in the future.

THERE ARE NOTES in Reply #34. Nothing major. Just icon and window position/full screen toggle fixes/changes.

The options I've added to ItemEdit are: Turn 90° Turn 180° and Tilt To Side. The goal is to not change the appearance of existing PRF files. At least not with respect to their tilt axis. The options are in the window's menu because there isn't room for anything more in the layout.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on December 04, 2018, 11:35:37 AM
Ever since I first uploaded the new demonstration I've been taking it very easy. Instead of jumping onto a new project, I've just been picking at some of the leftover parts in order to eventually be able to include the features in a release.

I did finish the item menu stuff, and even got ItemEdit to tilt the item sideways.

Because I've been using the PMincho font instead of Mincho I ran into some trouble the other day with the spacing on the back side of the lowercase letter f that is just atrocious...

I don't understand how a font can be released so bad, even if Japanese don't need f as much as English publishers. If fi is written, the dot of the i runs into the f. And frankly the font I'm typing this in does the same thing, though not so severely. Likewise fa puts top serif of the f over the a. It looks really bad with PMincho. Because nothing else is spaced like that, and it has big round serifs. It runs into letters so it looks like that combined "ae" pseudo letter.

So because of this, I used the synthetic font extension to do this:

Code: [Select]
[Script]
system_fonts_to_use = 1000 "MS PMincho" U+0000-0065 U+0067-007F

This is not a fix I can recommend, but in this case, it goes to great length to make f use Mincho instead of PMincho. And it looks close enough. All letters in Mincho have equal space.

But it turned out this extension still needed a lot of work. In one case, there was a bug because I'd never tried to use it with more than one range per font...

But after that there are layout issues with multi-line and right-aligned text. Right-aligned was never implemented, but multi-line, maybe I broke it somehow.

Anyway, I worked with the text stuff for about a day all told, spread over a few days. So now it works, but right-aligned is limited to single lines. Sometimes I cheat and put extra lines into single line text. That's how the built-in English menus look better in many ways. But right-aligned text is pretty rare, and limited to setting values and numbers for the most part.

I want to replace all of this stuff with "Rich Text" at some point. That's just a decent size job. The script system uses Rich Text. I have to revisit it to fix a bug sometime in the coming weeks. I might take another look at it. It's quite a beast.

I first noticed the problem with f after I tried changing the name of the healing water item to Elfin Water. I really struggle with what to call items in games. I want them to be more like literature, but games can be so abstract, it's not always practical. I was calling the item Arid Water to communicate that there is something about the water that is not normal. The fisherman says as much. But I think I decided that did not line up with how I was thinking about the names presently, and didn't fit with the other kinds of colored water.

The original name for this item is probably blue healing water, or something like this. That might sound natural in Japanese (I wouldn't know) but it doesn't flow in English, and neither does it have any literary quality.

I would be tempted to call it Blue Water, if water were not really blue, or if it was not too simplistic. The English games call it Blue Potion if I'm not mistaken. Anyway, it may not seem important. I'm trying to establish a feel for a new translation, but while I will put this feel in the demo, it will be moved over to a separate English script file before the project is completed. The final project file will use literal English translations, and possibly Japanese first, with English in parentheses. A Japanese script will convert these names to their original text.

My rationale for how to name items is that they would be called what Alef would call them to himself. He is a highly educated prince, and so would know all about Melanat that is known. Some things deeper into the island my be unknown to travelers, but many things like the nature of the island's water would be well known to all. In that case "Arid Water" while mysterious to the audience is not in keeping with Alef's internal voice.

Likewise I have to answer questions like, what would locals call a Dragon Fruit? I thought dragon fruit too prosaic. I did not feel that's what it would be called. There is a fruit called "dragon fruit" in real life, but other than grapefruit there are not many fruits with the actual word "fruit" in their name. And this fruit is the fruit of the Dragon Tree, which must be a very important tree (it's actually a "clonal colony") to the people of Elegria. I don't know if they would eat as food or not. So I changed it to Dragon Seed, since it looks much like a seed, and is a seed, and technically that still meets the definition of a literal translation, even though seed is a secondary meaning. But then I thought more, that this does not seem natural either. Right now I have called it Dragon Eye, because it looks like an eye. Like a cat's eye marble. It seems to me closer to what a people would call such a thing. To go further might be to construct a name from Latin or something, but that is too far in my opinion, because I want to keep King's Field language matter-of-fact.

I'm trying to come up with suitable names for the items. Sometimes it's torture. For the waterfall cave mechanism, I ended up calling it a Fire Mask instead of a Skull Key. Skull key is a literal translation. But it isn't a skull, and I am avoiding using the word "key" for these items that are really just shapes. The word key appears in too many item names, and I would prefer to limit it to actual keys. It is a carving of a kraken maybe, but an abstract one if so. It looks more like Cthulhu...

I was calling it Sea Monster. But felt that that name no longer felt up to snuff. Sometimes I decorate the item names, with an adjective. But I wanted some to be more straightforward. Like instead of calling the dragon shape, simply Dragon I opted to call it Marble Dragon. I felt it worked better, and it's not easy to tell what it is made of. The fountain room seems cut from special blue marble, so I felt it fitting. The texture is actually identical to that of the waterfall cave mechanism, and also the iron mask, and treasure chests' locks. I guess it's iron then, but on the dragon it's stretched out and smudgy so that it doesn't really look like metal.

I couldn't think of a name for the "sea monster" and so I turned it into a mysterious name that is really an inside joke, because if you look at the monster its jeweled eyes are made of the Fire Crystal's texture/material, and the rest of it is the same as the Iron Mask. So I called it the Fire Mask because it's also like a mask, although not one that could be worn. Just a decorative face. I liked this name. It's not at all a literal translation, but it seems to suit it better than the all of the alternatives...

I worry about what game guides will do with different names from the original game's. But the problem is unavoidable I guess, since an independent translation is necessary. Games present so many challenges like this. They are truly the enemy of the verbal.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on December 04, 2018, 05:15:54 PM
UPDATE (VR mainly)

FWIW I just reuploaded the demo ZIP file (again) after luckily noticing that somehow the code for selecting tiles when looking up and down was using the wrong axes for PlayStation VR. I don't know how it ever seemed to work before! I thought there was just a problem with looking straight up and down since it's kind of north/south pole kind of deal then... where there is no real sense of what direction you are facing on the compass. But somehow other than that it seemed to work before...

But now I don't see any problems with looking totally up or down. I got a hint something was wrong because titles started disappearing without VR, and I couldn't reproduce the problem. It's funny how things like this aren't immediately obvious, and can go unnoticed for months.

http://www.swordofmoonlight.net/holy/KING'S%20FIELD%20II.zip

I also determined that the FOV really should be 94 instead of higher. I don't know why, but 94 doesn't feel right for jumping or falling. There must be another explanation. But I was able to determine higher values did not scan right when looking at the Magician Lamps up close. So I'm undone that in the INI, and have added the font fix for the letter f also. The Mincho f looks perfect with PMincho. I don't know how that got bumbled in the font... I wonder if the current version of PMincho still has that crappiness factor. Something will have to be done about it. The fix in the demo is just a bandaid.

Also, the tile selection is now updated in the menus. With VR you can look around the room in the menus. The tiles were not updating. Sometimes it seemed like they didn't need to be updated.... most of the time in fact. It probably had something to do with the up/down bug. Without it the problem was very evident.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on February 19, 2019, 11:12:47 AM
 :coffee: I'm back on this job. It's been a while. Right now I'm deciphering the animation information. I think I have a strong grasp of its structure, and will figure it out shortly. The fields I still have to work out.

I'm less confident about what to do with the data. There's no way to get it into Blender. It can be converted to SOM's proprietary animation format. In that case I might opt to implement my plan to separate the MDL files into MDO+MDL which would be helpful, because MDO can be managed in Blender... but it would be a problem if the files got out of sync; like if the vertices were to change their ordering, it would fall apart. One approach might be to store reference vertices in the MDL file. But I want to use its vertices for clipping anyway. I suppose KF2 is low-poly enough that they could be used for both... only as a stop-gap, until something better comes along.

Ultimately I can't see a way around developing an all new modeling software. That's how far the modeling world has strayed since King's Field days. From Software must have had its own modeling software, or at least something not based on any popular exchange formats.

I think Quake's MDL format may be the only viable exchange format. But I've doubts, but will definitely investigate. Long story short, animation is going to be lost in the wilderness for a while. So far I've been able to just eek by with Blender. But I think I've gone about as far as I can get away with that.


P.S. I have a feeling I'm going to go the MDO+MDL route, and just do whatever it takes to keep the models synchronized. That would not work with a normal project. But it will be expedient here. Having a working version of KF2 will make it all the more enticing to eventually take SOM to the next level in the art dept.

Strikeout: It occurred to me that this problem exists either way because MDO files duplicate vertices where the texture/lighting requirements diverge. There's also a problem in SOM_MAP needing to display MDL files. I don't want to generate full MDL files, and so I expect I will just use untextured MDL files for the time being, and displaying the corresponding MDO files in the game/demo is going to be among the first rendering tasks. But not the-first, because that was displaying transparent level geometry, which is already in the demo. (Although, technically displaying the maps was the first novel rendering accomplishment.)

I don't know what the future of SOM holds for animation. Part of me wants to stick it out with MDO+MDL because they have their roots in the original product. Converting any animation to MDL is not actually as trivial as I've been thinking about it, because how MDL works is actually very hand-tweaked animation. It blends between two frames. I would prefer myself if it didn't work like that, and simply sampled at 60 fps. I think the key-frames are hand-made. But it's possible they are just sampled at a lower frame-rate. I don't know that the bloat would be so great if sampled at 60 fps or not. But in VR the frame-rate can go much higher, so maybe keeping with blending should just be accepted. I worry that converting such high-frequency animations to a Javascript format for WWW browsers will be unacceptable. Maybe it will be necessary to figure out a more binary-friendly way to do it.

I'm wondering if it's possible to animate a simplified hit-model mesh, and use that to drive the visible mesh. If not, there will have to be two meshes in the future MDL files.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on February 21, 2019, 10:16:08 AM
I had a hellish couple nights because I wracked my brain to come up with the shortest path to converting KF2's animations into something that can be used... without making it a major project. Especially because I still have some questions about the file format that I'm hoping having a hands on visual will help to figure out:

http://www.swordofmoonlight.com/bbs/index.php?topic=1129.msg13658#msg13658

Unfortunately, the process did not go well. I gave myself a headache last night, and felt like a fool... who wanted to skate by and so was willing to go to the ends of the earth.

But luckily, I woke up today with a feasible solution, but still can't shake the feeling that I wasted two days of work, just to cut corners.

The problem is I only have one TMD file loader which I know of. That is the old "Somimp" project that x2mdl and mdl2x use that is based off Assimp. Unfortunately Assimp has serious limitations, which have made me to go so far as to rewrite the entire library, so I can effectively "fork" it into a new library.

But even though I've already done that, it's coupled too tightly to the Daedalus code (I'm seriously thinking about decoupling it, just on principle) that seeks to use COLLADA as a middle-format. Ideally the conversion process would first go to COLLADA, and then to MDL/MDO. But I haven't yet ported the TMD loader to this code, and that would be a big job. That would require really getting back into the swing of that library, which I haven't worked with in quite a while.

The problem with Assimp is it doesn't have any facilities for the kind of animation KF2 uses, and what's worse is it has a nasty habit of exploding all models into polygon soup... which is very bad, and throws out connectivity data. The problem for working with the KF2 animated models is they need to keep the polygons in order, so that the stop-motion versions line up. When Assimp converts them into soup, and then reconstitutes them, all of that is lost.

So I had to figure out a way to retain the connectivity data. And I didn't want to cheat by trying to compare the positions... especially because they get transformed in and out of different coordinate systems, and I didn't want to deal with the stress of just hoping everything would line up.

After two days, I've got that much solved. The solution (that worked) was to store the old vertex indices into a secondary UV map. One thing I added to Assimp (that its authors wouldn't accept into the project) is a free-form model format that is much easier (more flexible) for loaders to map files to. I implemented it just because it would've been a foolish amount of work to do it any other way. And Assimp is very foolish and buggy in many ways because its authors actually write all of their loaders so they have to manually convert everything to their internal format, and they soupify the models at the same time... whereas all of the loaders I've written have to soupify as a post process, just to meet its post-processing pipelines requirements that it wants to eat soup...

Anyway, because the TMD loader uses this flexible-format, it was possible to add to the code the simplifies the complex-format into Assimp's an extra step to record the original vertices in said UV-map. Unfortunately I could not use the complex-format to add a UV channel, because it wasn't designed to have separate UV indexes... but now I'm wondering if it should (probably it should.) I'm pretty sure COLLADA supports separate UV indexes. So I honestly just got lucky. Any other solution would have been much less elegant.

Assimp is one (of the few) better 3D processing tools that is noncommercial, but (like all) open-source projects, it's very limited, buggy, badly designed, and saddled by cantankerous maintainers that act more like trolls under a bridge than developers invested in a field/career. Another problem that plagues open-source code, other than ossification-by-talk-talk-talk, is the punk ethos that pervades it. I don't know if commercial developers are more professional and good-natured or not, but punk attitude and general disregard for order is the last thing you want in a software developer/maintainer. (I mean you wouldn't want a punk carpenter! would you?)

If only open-source communities were professional and fastidious I think they could've taken the commercial software world by storm 20yrs ago.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on February 24, 2019, 11:36:28 AM
Weirdly, the variable length fields in the "MO" files (that don't have terminators or specified size... the ends are implicit) follow the following pattern, which I'm documenting here, because it looks a lot like junk:

0-0
1-1-0
2-2-0-1
3-3-0-1-2
4-4-0-1-2-3
5-5-0-1-2-3-4

These look like indices into the data block. But if you played the animation like 0-1-0-2-0-1-3-0-1-2 it's pretty obvious that can't be coherent. The pattern becomes pretty obvious arranged in a matrix. But it doesn't strictly follow this pattern. The first swing animation seems to start with 1-1-0 for example.

I've already guessed the double starts are not part of the animation. Although it's hard to say what is what. I'm just going to tinker until something does the trick. Just as a reminder, there isn't always a double start. But it seems like when not, the starting number will usually, if not always, appear later in the sequence. It's not a size, not even counting from the third number. (It might be a global identifier unrelated to the frame index... in a 3 animation monster, the counters go up across the first two animations, but the third starts back at the same as second.)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on February 27, 2019, 03:59:38 PM
It's not much to look at, but I've more or less figured out the animation format. I'm moving onto other work, since I did this mainly to assuage my own fears about having to solve this at some point. Plus it's taken up more time than I'd wanted it to.

Because my recent 2 month line of work set me back at least a month more than I wanted to, I have many things to attend to I'd set aside then. I did this animation project as almost a recreational activity after 2 months of grueling work.

P.S. The x2mdl project is maturing. I don't know if it will ever be an ideal way to get art into SOM; but now it does have code for writing soft-animation. That's good, because I haven't documented soft-animation anywhere so far, and the code that exists for working with it doesn't shed a lot of light on how it works under the hood. It was actually difficult for me to go into that code and try to figure out what the file format is from it. Because I didn't leave any notes on it while I was developing it. (File format code typically needs to read or write a format, and these processes can be very different. Typically reading is straightforward, whereas writing can be a very involved process, since it's never simply about copying a file; i.e. "copy/paste.")

EDITED: I had to use Google Chrome because Firefox is currently broken for files on your own computer. I mean it's crazy. It doesn't associate MIME-type with file-extensions, and its JavaScript implementation fails if it doesn't know the MIME-type. I don't know how something can be more broken than that. (Typically an HTTP server does MIME-type association, but your hard-drive is not a server! and so it's the browser's job to do that. It's truly bizarre that Firefox is broken in this way. It doesn't even have any business parsing files in the first place. That's just burning your CPU time. It shouldn't even care what the MIME-type is. It's baffling.)

According to this (https://stackoverflow.com/questions/2618959/not-well-formed-warning-when-loading-client-side-json-in-firefox-via-jquery-aj) it's been this way for 8yrs. But I'm pretty sure it hasn't always been. It's probably been an off/on problem.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 05, 2019, 08:11:48 PM

EDITED: http://www.swordofmoonlight.net/canvas.php?demo=head-eater :cool:
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on April 08, 2019, 09:58:22 PM
Here is the first screen of a new volume-texture feature I'm developing that fits perfectly into the existing do_alphafog extension.

In this screen it's designed to fade out Melanat's shoreline underwater. The water needs to be darkened to better match the game, since it's being shown at full opacity, which normally would get 50% blended into the black background.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 01, 2019, 08:10:34 AM
I've not said much here in the past months, so I'm just going to write something now.

This (https://www.reddit.com/r/KingsField/comments/dniw8b/death_mechanics/) Reddit post prompted me to return to agonizing on how to translate the "Dragon Fruit" item yesterday.

I'm doing a new translation of KF2. I think it's a serious game, so I want to give it a serious treatment. Writing for video games is actually quite difficult, because they are abstract entities, even when they pretend not to be. You encounter in them abstractions left and right. Because they don't exist in a real world language often does not apply.

Naming "items" can be very trying. Ideally you don't want the wording to feel forced. Putting a name on an item can be difficult because outside of things you would put on a grocery list we don't really speak about day to day objects as if they are "items". And when it comes to fantasy elements, if you just label them based on their parts, that doesn't work on the page either. Or at least not in English. Some languages (perhaps Japanese is one) do name things like this. They put together concepts, and sometimes have variable readings for those concepts. If you speak those concepts aloud it can feel like baby-speak in English. If you read Japanese like that, it does feel like baby-speak. But to a Japanese ear it probably doesn't seem that way. Plus Japanese is much denser than English. Video game adaptations of Japanese material often run out of room for their translation, and so must improvise.

So anyway, yes you can do a clunky literal translation of King's Field... but let me just say 1) That's not difficult to do in short order, so it's not worth losing sleep over nor praise, and 2) I don't personally see any value in it. So, anybody can do it if they want to. I probably won't do it myself.

As such, I truly agonize over how to label the objects in KF2's inventory. In the genre these things tend to look like "purple prose" which is something I'm very sensitive to. I think this quality overshadows the genre, makes it hard to take in and embarrassing too. At the same time, fans seem to almost relish this quality, or can't see why it's a problem for literary works. It comes off to me as second-rate media.

But KF2 is very much a beast of its day. Its "Dragon Fruit" item very much functions as an "extra life" and that is I think its essential quality. The game is not ashamed of this. It's an old-fashioned game. That can't be changed. If I can revive KF for SOM I would definitely implement this item differently, but that's another matter entirely.

Anyway, what it does is not actually of concern to me. If "Dragon Fruit" felt like an acceptable translation I would breath a sigh of relief and move on. Unfortunately that's not the case.

Likewise it took me a very long time to settle on how to refer to the "Healing Water" item. I think the English games call it BLUE WATER and DRAGON CRYSTAL. I like the simplicity of these game's translation, but I want to elevate the work more than it does. Its translation fits the context well. But today is a new context. You can see how its translation doesn't literally translate the Japanese either. And neither is "Dragon Fruit" a literal translation. Don't deceive yourself. In Japanese the concept is both more dense and more ambiguous.

In any case, I'm surprised I haven't written on the "water" items here yet. In the demo I put up I reluctantly called it something like Elf Water. I had to use something. But I've since changed it.

I'm confident these water items relate to a concept in alchemy (https://en.wikipedia.org/wiki/Magnum_opus_(alchemy) (https://en.wikipedia.org/wiki/Magnum_opus_(alchemy))) and so had settled on naming the colored water that way. The "colors" are Pale, Dark, and Gold. There is a hidden color that is red, or I call it Ruby. I think that is not in the game. But it's in the item table on the disc. The basic water item acts as an introduction to these. I settled on calling it Life Water. That is closer to Healing Water, and I felt relates to the esoteric concept of the water-of-life that seems to relate to King's Field's fountain network too. But it has a video game quality fitting the context also.

Although it often doesn't actually apply, my approach to naming things in King's Field is to assume the protagonist's knowledge of their world, and work out from there. Instead of assuming the player's knowledge, which, at the outset is presumably none.

But the game is very simplistic, so it often feels more natural to steer into simplifications or very prosaic applications of language. You can ask for example, how would someone describe something to another, versus what is their internalized representation of the same concept. Or what is a more technical label versus a more intimate or informal label.

If the Dragon Tree (not actually a tree, nor is "Tree" in the Japanese) fruit is actually a fruit (the character for this in Japanese is more open-ended) then Aleph (the protagonist) would probably know it by the name of a fruit. The closest thing to that would probably be a made up word in a made up language. It's not helpful to do that in this instance. But you see that some "items" work well like this. E.g. Verdite is easily recognizable as the name of a gemstone, and feels like it could be one, and we know what the root Verd- means naturally, and that is reflected in the color of the stone. Believe or not King's Field in many places makes creative use of language. It doesn't always translate from Japanese.

But Aleph is a prince, surely highly educated, and the dragon-tree phenomenon is something that must be well known to people of his day. He would recognize these things for what they are in other words. So I tried many permutations without success. I'm not sure what the demo calls it. Something I landed on temporarily (much like Elf Water) was "Dragon Eye". It was the least bad I could come up with at the time. I find myself wanting to use apostrophes, but the kerning on the fonts is often that they serve to introduce an additional space into the concept that I don't like. I may try to devise a technical fix for that later.

Anyway, I did a deeper dive into the subject matter. My instinct was if nothing else, the best would be to just call it "Fruit".

Part of the problem is I don't believe the object can literally be a fruit. Even though it looks like an odd drupe... it's transparent, and seems large, but I don't know if the scale is exactly accurate. Not a fruit in the sense that the thing in its middle is a seed that could be planted to grow a "Dragon Tree". Edited: I think this has implications (and flavors the narrative) but to be clear, I just don't like how it looks on the page. Or especially in the menu system. I hope this doesn't become a problem since KF has a lot of "dragon things". I feel like the emphasis is not appropriate here, and the phrasing is too unnatural. (It doesn't change what Meryl or the manual might say on the subject.)

The dragon tree doesn't seem to work like that. It's more like a vine network that grows up through the ground from the underworld. That is to say, you can't plant it on the top of the soil, or it seems that would be unbefitting its function. In KF3 the tree is set up to be intelligent, and I don't know, possibly an aspect of the earth god Valad if not Valad themselves.

And the "fruit" obviously has a weird quality of resetting a person's world. It's not even clear the fruit is consumed. Aleph would know about this. Unless when you reset via the fruit you reset into a world that is cut off from all others. I think that's overcomplicating it. Others must know of this experience. And so would many. In this quality we can understand that KF's setting is much more trippy than our own. This kind of thing is just part of life in its world.

Anyway, though I don't want to deconstruct King's Field within the games themselves, and I can't as long as the project is merely a translation, my sense of the dragon tree is at minimum its structure is a clonal colony's, that is not like a regular tree's, but closer to a fungus or parasite. So it doesn't work like a simple seed bearing tree. It reproduces asexually more or less, and if these fruit things have a purpose, it's not its own reproduction.

I settled on calling it a Fruit Body taking inspiration from this (https://en.wikipedia.org/wiki/Sporocarp_(fungi) (https://en.wikipedia.org/wiki/Sporocarp_(fungi))) anatomy of fungi. It's a kind of organ that spreads spores. I want to hint at that, but I like the quality of the double-entendre here that suggests it's a new body, or extra-life. In its odd choice of words is the hint of something less conventional, that contributes to an overall air of things not being what they seem.

When/if I get to reviving King's Field my extended concept for this is that the dragon tree functions as a factory for making the monster population. Its offspring is the monsters. And maybe like a fungus it sustains itself on the dead that seep down through the earth into the underworld where it lives.

In the revived/revised series (not this series) I think that it will be called Dragon Fruit, but I will also have the opportunity to recontextualize it and change how it functions within the game world at the same time. In that case it may serve more like mana for the monster population, or have dual roles, but as a consumable object it will work more like a straightforward healing item. (It will make an earth "field" identical to how the Earth magic would. So it amounts to just a way to use the Earth magic without consuming MP, or without being able to otherwise.)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on December 16, 2019, 05:53:47 AM
Here is a teaser of getting the animation out of KF2. I'm trying to boost my excitement levels by way of having some personally meaningful model files at my disposal.

I don't think this software can work with sparse animations where not every single frame is represented by a snapshot of the mesh. In that case I will have to add something like that somehow.

EDITED: https://github.com/zturtleman/mm3d/issues/106

Conveying 3D model data is a real bane of these projects. It's never straightforward. I've written so many 3D model transformation programs in the past years since working on SOM and it feels like they never really get you very far.

I'm doing this with x2mdl by letting it do the heavy lifting and instead of outputting a MDL file convert the would-be MDL prepared data into this MM3D format. I'm working on developing it, so it puts me in a much better position than using any old software.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on December 31, 2019, 11:09:18 AM
I've progressed with improving the animation code to be able to work with the animation data. I quickly added some textures to the headeater just for this screenshot. I will have to do it again correctly later, after I have a more correct way to do this.

I had to play with the screenshot because KFII's textuers are super dark and low contrast. I tried to make it look more like it does within the game. I think they are that way to squeeze more dynamic color out of the PlayStation, after lighting calculations.

Even though this animation goes for about a second (I think) at 30fps (MDL/SOM default... I think) it's only made out of 3 or 4 frames. I think. I have to work on locking the time slider into the actual data frames yet. The first section of this animation is left blank because the unanimated coordinates are used instead. It took me quite a bit of work to make the code I had from the MM3D project more sophisticated. It really wasn't set up to do actual work with animation data. I think it was mainly used to visualize Id Software's file formats.

I guess I've been taking it slow and easy lately also. So I've been drifting through my days more than usual... usually I'm pretty much a workaholic, so I don't know if it's right to say "usual" but I don't know... I've been without direction a lot lately. I hate these weeks around Christmas when everyone kind of retreats and the world stops turning. It plays with my mood. Plus I'm a bit burned out.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on January 02, 2020, 11:14:26 AM
This version is cleaned up with no "photoshopping" but is still nothing like in the game. It's hard to describe what the game does to transform the color. I would be curious to know how it does it... like if all PlayStation games work like that, or if it has a few modes to pick from, or if it is able to do custom modifications on the pixels before they're committed to the frame buffer.

I know PlayStation games can read from the frame buffer, but I've read they can't directly modify it. Maybe they can "blit" to it to modify it. The end effect is it's a little like a custom "shader" compared to any built in graphics modes supported by the likes of OpenGL or Direct X prior to shaders. I.e. GPU micro programs.

FWIW I added anisotropic filtering to fix the blurriness, and the enhanced OpenGL specular model (KFII doesn't do specular calculations but kind of looks like it does) and tweaked the smoothing groups and brightened and added contrast to the textures. I don't do that with the real models used by the game, though that's kind of problem because SOM's stock models don't work like this, so you can't mix them.

EDITED: This gives me an idea to work on an animated GIF feature. There's already a (frankly odd) feature to make PNG or JPG slideshows. There is a way to make a GIF with wxWidgets that I think would be nice for sharing animations online.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on January 03, 2020, 07:13:21 PM
This (sorry for headaches induced or difficulty reading this page) is the result of working on a GIF creation feature.

It's interesting to note that the mouth never actually closes. I guess when you see this in first-person (from the direction of the mouth chomping down on you) it's impossible to notice, or might've even looked weird. Another possibility is this way there's less frame data, though I'm unsure about that myself. It's certainly less work for who animated it.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on April 23, 2020, 01:37:36 PM
Update on progress with animation editing/import :sweatdrop:

Note, I just noticed while comparing this to screenshots from KF2 there are blue colors in the headeater's body. That explains why it's on a different texture page. I will have to hunt down the alternative texture.

This is just a test mockup. Work on this is going slow. I'm going to have be very thorough about details every step of the way, and some questions I can only answer by locating/examining the animation code.

This image is of an animated model converted to an editing format (MM3D) and cleaned up and cross-referenced to its textures and then exported/imported into the runtime format (MDL) and displayed in the profile editor. The animation data is in there too, although KF2's animations are somewhat simplified compared to SOM and I'm not yet sure what to do about it. KF2 combines the idling and walking animations into one, or just maybe always is on the move instead of standing still. And its animations just walk where they stand from what I can tell. At least this one does.

I'm thinking of adding some custom code for an alternative center (cyan) CP that moves independently of the model data. If so its red component would be 1 instead of 0 maybe.

Something else I'm planning to do is to try to somehow mark new MDL files to use millimeters (1000) instead of binary (1024) to represent 1. It will make it more practical to be able to line up the animated coordinates. I'm somehow still planning on using a MDO+MDL system. A problem with MDL is it has very low precision texture coordinates that don't wrap/repeat, and it isn't an indexed format. It's just complicated to combine that with MDO. I believe they will have to be tightly married to each other. MDL has unused data among its vertex data, that is where a fourth component would go. Vertices are 3D, but there is room for a fourth. I think my plan is to store in there how many MDO vertices overlap that MDL vertex. (Alternatively it could be more complicated by storing an index into some other part of the MDL file that's not needed, since it wouldn't require lighting information for example. But that wouldn't mean it would be less coupled to its MDO file.)

I think generating new MDO files will help because x2mdo seems to break its MDO files up into chunks in a way that probably slows things down.

In theory chunks could be helpful for transparency sorting but I'm pretty sure it doesn't do that with the chunks. I want to implement a full BSP system to get perfect transparency ordering in the next year or two at some point. The MM3D code has a BSP system for this, so maybe I can just copy it. I haven't tested it, though I will find out if it does a good job when I get to the slime monster in not too long. I know SOM doesn't already have a system for this because the crystals and things in my demo currently cause weird optical illusions when they spin around because they do things the brain isn't able to make sense of. I think staying with low-poly gives us the benefit of being able to do things on the CPU that would be impractical otherwise. That means we actually are better quality, just less quantity.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on May 02, 2020, 03:04:42 AM
Lately I've been trying to transfer the NPCs and monsters from the disc data to SOM.

I've run into a problem because there are more than will fit. Part of this is because there are two layers and I made SOM to not put map elements in the layers, which I think is the right decision, but now I can't think of a path forward other than than to attempt to increase the limit.

There's no telling how difficult it can become. There's a small chance MapComp and som_db will just work. SOM_MAP has to be reprogrammed.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on May 03, 2020, 08:36:54 PM
I don't want to make a series of updates on this speed bump, just for the record, I worked all day yesterday on increasing the enemy limit, and how that shook out was I started testing MapComp and the player because if they didn't work out there would be no point in doing SOM_MAP (I brainstormed some other strategies too) and MapComp presented no problem, so I could test the map with the player (I hand edited the MAP file bypassing SOM_MAP) and that went about as well as I was expecting, meaning that it would require some of the most extensive "reprogramming" I've ever done for SOM.

Normally I wouldn't touch something so extensive, except KFII is a special case. At some point the original EXE files will be abandoned, simply because SOM should be cross-platform someday after it's established, which is why I don't think it's worthwhile to solve all problems with this version of SOM, because that's harder to do with a program you don't have source code for.

Plus, as seismic changes go, increasing the limits of map placements isn't so integral to be a major disruption, but it is something that touches so many places in the program that means to change it all references to these lists must be reprogrammed, which amounts to a lot of changes in the program.

To deal with the bulk challenge I added the ability to scan for a range of values inside the program instead of single values, which I'm surprised it took me so long to do this. Then I just went through them one-by-one taking down the addresses and making the necessary changes.

I think it's good to increase these limits now that there is a layer system, meaning that there's potentially a lot more real-estate to fill, and I think 128 was a very tight limit in the first place, going by how dense the spawn point placements in KFII actually are. (I sometimes wonder if From Software issued a directive to hamper SOM just in case it spawned a community that made From Software obsolete.)

At this point there are two things left to do. The next problem is SOM_MAP obviously, which I worry won't be as easy because the tools tend to use C++ style design, whereas the player uses C style. It's generally more difficult to make sense of the C++ style code. Normally I manage to do what I need to with the tools, but if the scope of this change proves to be an order of magnitude more great than the average change it can end up being a real slog.

Finally, I have a feeling the save file system will have to be altered somehow to accommodate the added enemies.

I've used a fixed buffer that can go up to 512 enemies, but the MPX files have a counter for this, but they tend to set the counter to 128 instead of the actual number of enemies present in the MAP files. I'll have to work out the details later.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on May 09, 2020, 05:17:41 AM
Update

So, it turned out SOM_MAP proved very difficult, but I've finally finished the last of it today. I had two or three days that I was unable to work or was in town. It was a solid 3 or 4 day job.

There is a map_enemies_limit extension that can go up to 4096 but is 512 by default. The player is unlimited. SOM_MAP can go up to 65536 but I chose to artificially limit it.

I still have to look at the save file. I don't know if anyone else has a use for this but I plan to make a release out of it in the next week since it represents a body of work. I may make it a demo release since I feel like maybe it should be tested more longer.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on May 10, 2020, 05:00:40 AM
As for save files there isn't flexibility there, which is pretty much as I expected.

My plan is to replace the fixed size map records with variable size chunks and to replace the BGM field with the map's file name in order to gradually open up the possibility to use more than numeric map names and more than 64 maps and potentially different file types from MPX.

These new save files won't work without SomEx. That goes without saying. But they will cause a problem too because som_db.exe doesn't check that the map number value is less than 64, and if not it overwrites program memory that is beyond the map data.

I'm thinking about calling them SOM files instead of DAT files so that if they are opened with SOM_EX they will start the game with that save file loaded. This will keep them from possibly being used with the old GAME.exe file...

There will have to be some metadata in the save files to locate the game they belong to since it's not necessary to keep the save folder in the game files, since the game files may even be on a CD-ROM although I think those days are practically long gone.

Note, there are already SOM files that are project files, which can be more than one in the project, however it's not difficult to tell these apart. Or at least in theory it isn't. SOM_EX can also technically open up PRF and PRT files but that's more of an unofficial thing. By "open" I mean you can associate the file format so when you double click on a SOM file it opens SOM To that project. With this new plan you can start save games this way too. It's not really meant for regular players since SOM files are more for developers. Developers have more use for managing multiple save files that jump into the project at different save points.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on May 12, 2020, 01:49:50 AM
Off the technical subjects, I finally found a word for the "dragon grass" for my translation. It's a botany term called Turion that I feel captures its more peculiar qualities.

I think that since it's a "grass" it must be just the tip of the iceberg of a connected underworld root system that I call the "dragon tree". Maybe KF3 translates it as a tree? I don't know. I'm not sure myself if I ever "spoke" to the tree in the elf temple in KF2. I mean, there are numerous trees before that one and I assume they don't speak, so I'm not sure it would've occurred to me to speak to it. I have no memory of it being called a "grass" in the English game.

But I've long known the Japanese name is grass.

A Turion (as best as I understand it) is possibly a separate plant or at least a structure that has all of the morphology of a plant, which grows from a bud. I imagine the dragon tree is underground and it kisses the surface making a kind of bud there that sprouts these surface structures.

I think keeping to the literal representation that this bud produces only a single fruiting spur that dispenses their magic fruit. I don't like the crystal structures from KF3. I imagine the golden structures from KF2 are mostly hollow inside and very light, like a dried gourd. That you could easily knock them down, they are delicate, not wooden, like weeds.

I think I will just call them Turion but explain their connection to the dragon tree. I'm not doing a literal (word for word) translation, but I'm not going off script either. The English game is pretty literal except where it spices things up or dumbs things down.

I'm not doing all this work to make something dull or droll.

As a recap I'm calling the "dragon fruit" (DRAGON CRYSTAL) a Fruit Body and the healing water I'm calling Life Water that is an allusion to the "water of life" but I don't want to use "of" and that's too on the nose and "life" just sounds like old school video game lingo. The "fruit" is literally an "extra life" but it can't be called that.

The water is actually very much like the "spice" in Dune that's called the "water of life". It's actually a bodily fluid of the worms in Dune. The spice like KF2's water causes death upon withdrawal. Arguably this element of KF2 could have come from Dune's spice. But too there is "alchemy" symbolism in KF2 and I know that the "water of life" concept is in alchemy too. I think that the trees in the villas are almost definitely a replica of the "tree of life" in the form of the sefirot, in which case the "water of life" is a natural pairing.

What I'm very wary of in my effort to translate KF2 is anything that "sounds like a video game" in its text. I want it to seem literary so it can be played without these kinds of distractions.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on May 14, 2020, 10:33:33 AM
Follow-up

The new save files are finally working... all that's left is renaming them and loading the game automatically at start up.

I'll likely publish a release tomorrow with details. There is an extension for setting the file extension so you can associate save files with your game when it's not running through SOM. And there's even an extension if you want to keep the old save file format. It won't work unless your game fits into that format.

The extension will be "som" when using SOM and this means you won't be able to see those save slots if not using SOM, which might be welcomed so you don't mix your development saves up with regular games you're playing. The extension is called "player_file_extension" and it defaults to "som" so there is no differentiation by default. The reason it's good to have is because you can't assume players have SOM installed. Plus the DLL versions can differ, and there are some slight differences with the taskbar and the splash screen.

The auto-load system uses a new LOAD variable in the SOM file that you can theoretically manually set to a save game you want to load at start up.  After I figure this out I may add something to control what happens when you "die" so not to waste precious electricity loading the starting area.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on May 19, 2020, 11:58:50 AM
Today I looked at the monster data. It's pretty weird.

Some of the monsters appear to be ill-placed on the map. It's possible they are bumped into place by the clipping system. I can't see that they are rotated on the map. It's possible they always start out oriented toward the player character.

Strikeout: While it's true that "Jose" the fisherman seems to be underground so that the floor must lift him up, the prime offenders for misplacement seemed to have been the krackens. I figured out that either I mixed up their body parts or their parts are placed on the map in the opposite order of the mosquitoes'. Another weird thing I've noticed is the rotation for NPCs seems to be reversed than what objects and items use. Anyway, that's the only way to make Jose face SW. Like I say later I think most monsters aren't rotated. But I know that some must be, like stonefaces.

There are 40 large records that are kind of like SOM's profiles (PRF files) but I kind of suspect it's more like there is one for every monster you can see, like if there are two mosquitoes on screen there is a record for both. That would mean they have to be strategically placed to avoid overlap. The other obvious difference is SOM_PRM covers the entire project, whereas these are unique to every map. I'm not sure exactly how I intend to deal with that difference. Right now I just have one profile per model. But at some point it will have to be specialized, at least on a case by case basis.

The double body monsters (e.g. mosquitoes and krackens) are actually two monsters apiece. There is no way to figure out which monsters are paired together that I can see. What I suspect happens is they just behave identically except the accessory part has a smallerlarger clipping shape. I think that likely an event is linked to the main part so upon its death it takes out the other, and the dropped item is in the other part. That way it never drops two items.

Strikeout: I want to chop this up to my seeming dyslexia. I remember vacillate back-and-forth in my head about which was which. I regret writing wrong information.

It's possible they are linked by an event that fires when they spawn, but it seems like it'd be unnecessary. I guess technically for that to work they'd have to have the same chances of spawning.

This seems like a very crude system. It may be that there is something like SOM's MAP and MPX files so that the map editor didn't have to work with such a crude strategy.

I'm intending to add a body part system to SOM.

KFII's monsters behave completely differently from SOM's. That's obvious with the flyers, that will require custom AI routines, but I think all of the monsters move laterally and rotate independently more like how you can control the player character. It might look a little cheesy but I think it probably works better overall. I don't know if it will be practical to try to make it look less cheesy anytime soon. But I think the headeater should move this way since it doesn't have a lateral body plan. So I will probably make the others use the same system.

They also seem to move more sporadically but that could be the irregular frame rate on the PlayStation and emulators. I can't tell if it's an intentional effect or not, but it feels less robotic than SOM.

I have a feeling a lot KFII's charms are just accidental stuff that would be hard to replicate with SOM. It's more of a worry. Like, I'm afraid I'll get everything in place and it still won't feel right.

I think in those 40 records there may be more positional data, and they may even have patrol routines in there. It's hard to tell. There is variable-length data that looks like it must be either 32-bit pointers (offsets) or 16-bit offsets that happen to come in pairs for which the other is almost always 0.

It's hard to think what that could be other than sound effects and particle effects data, but there is too much for that, so I wonder if it's event data or patrol data. I think it may be all of those things piped through a more low-level event system than SOM uses.

I really don't intend to investigate that stuff. Tomorrow I'm going to see if any of it makes sense for improving the map positions and I have to get scaling information too.

Speaking of scale, the kracken model is actually the same size as the giant one. So all of the smaller ones are technically scaled down, which is kind of weird. It means it must have started out as a "boss" monster. I have a feeling either the giant's pixels (texels) will be huge or the children's will be tiny compared to everything else, or a mix of both.

The texture mapping on the piers and bridges are not even square. I'm going to have to rebuild those textures somehow. I really don't like it when texture maps are rectangular or scale varies in games. It looks like very sloppy work. I see it in $60 video games all the time.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on May 21, 2020, 10:34:33 AM
So I'm at the point where the monsters/NPCs are positioned correctly on the maps.

So now I must focus on producing the animated models. As a first tonight I had an idea to use the "Merge animations" function from my modeling software to attempt to take a model that is prepared in Blender and combine it with animations that come straight from the source data, since Blender can't help with animations.

I just wanted to see if the mesh happened to be compatible. But it lost 2 vertices during conversion, so there wasn't a chance, and I reckoned it would probably be way off because I started with the kracken that has hard lighting facets on its lower body, so this means many vertices would be generated to produce that lighting, so what I ended up doing instead is something like what I'd considered doing to merge MDO and MDL files except I decided to do it in the "Merge animations" function in the modeling software instead.

What got me thinking this way is I'm going to have to merge the kracken and mosquito body parts anyway to produce a demo since I'd rather put the multiple body part thing off, possibly even until after my deadline, since it seems pretty nonessential.

I also am going to put off combining MDO and MDL if I can, just in case I run out of time, since the limits of MDL are the limits of the PlayStation and KF2's data is coming from PlayStation data, so the limits don't really come into play.

It's good to be able to use Blender also, since I can work faster with it, and some things I have to do to make the do_aa extension work are very hard to do without much better modeling tools than my custom software can do so far. It's also not as accurate as Blender, so I don't want to risk losing information, mostly around texture maps.

A big difficulty for do_aa is how x2msm slices up the models. That's a long term problem that I'm not sure how it will be addressed, but it will be after a much more mature art tool chain appears.

Especially with the secrets and traps that embed into the map geometry, that are animated, it is a problem, but this new "Merge animations" strategy will help with it a lot. I can chop up the object parts in Blender and then it's easier to fix their animations after than to do the chopping in the custom software.

The "Merge animations" function didn't support soft animations, so I had to implement it tonight, and that meant I could implement it how I needed it, which is to compare the positions of the vertices in the merged models and apply the animations from the animated set to the overlapping vertices in the unanimated data.

Tomorrow I'm going to see about merging the two halves of the kracken into one model, so that's out of the way, and from here on out I will mostly be working with the model data until everything is in place. If it gets tedious I'll switch over to a programming project.

For the next demo I want to publish, I want to get the way KFII's tiles have different ambient light levels working, and I want to get the weapon/arm animations working. It won't likely have sound effects, and the monsters will probably not walk around. I might try to get a simple idle sound effect working for each monster. And I think I want to get the compass in there and matching HUD display. Doors, etc. should be working.

Since you can see every single monster I think it would be too crazy to have them walking around at the same time. There aren't as many monsters as I originally thought because the double body-part monsters were two monsters before I knew what they were. Also for some reason there were some monsters that look like they're probably junk spawn points. There model IDs were assigned to 254, which doesn't look like it could be a real number. It could mean they were deleted. I might think there is something to it, except they were all clustered around one room, which I don't remember being anything special in the game. So maybe they were a removed enemy type.

After removing the body doubles and these dummies and Jose the NPC, there are only 131 enemies on the map. It's possible there are more on the other maps, but had I known the number would be so close to 128 I might have held off on doing that two week job of increasing the enemy limit!
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on May 22, 2020, 03:03:08 AM
The kracken behavior is pretty unorthodox compared to SOM.

To begin, the mantle part model isn't elevated to sit on top of the body part, so it must snap on according to some system, but I don't see that information in the data. I haven't seen records for the equivalent of SOM's "profiles" so it could be in there conceivably, but that could be hardwired into the program.

Its walking animation runs one frame longer than the body animation. I can't tell if it's designed to be out of sync, but 1 frame isn't a lot.

But the kracken AI actually switches the mantle between the walking animation and the attack animation, which kind of looks like breathing.

I think maybe it stops moving when playing the attack animation (when not actually attacking) to create the illusion of catching its breath.

Needless to say SOM's facilities are quite robotic compared to this. I'm not sure how to go about replicating this behavior, since it requires a quite complicated description of how to behave.

Also, I still haven't fully understood the animation format. For the kracken its walk/idle and hit animations weren't coming out right. I figured out a heuristic to detect the difference in its case, but it could just be nonsense that won't hold for other models. There's a lot of extra data I can't make heads or tails of. It's seemingly nonsensical. The only thing I can think of that it could relate to is if the animations are really softer than what I have, but I can't see that visually. The Sony system uses a much more CPU intensive blending of multiple frames, which could account for this extra data, but it doesn't look like that.

Edited: One time a kracken appeared without its mantle. I don't think it was defeated earlier, I think that sometimes they just spawn without one. In theory the mosquito may too.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on May 24, 2020, 05:52:55 AM
 :eek:

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.


(http://www.swordofmoonlight.net/bbs2/index.php?action=dlattach;topic=286.0;attach=1029;image)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.

(http://www.swordofmoonlight.net/bbs2/index.php?action=dlattach;topic=286.0;attach=1033;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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.

Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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 :sweatdrop:

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 :cool:
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on August 09, 2020, 11:47:51 PM
 :eek:
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on September 09, 2020, 03:04:37 PM
On a roll :bowl:

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.

(http://www.swordofmoonlight.net/bbs2/index.php?action=dlattach;topic=286.0;attach=1211;image)

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 :cool:

EDITED: Show don't tell (screenshot incoming) :eek:
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on September 09, 2020, 06:54:35 PM
A familiar scene :hearton:
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on September 18, 2020, 05:36:17 AM
:ssh:
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley 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.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on September 30, 2020, 08:44:20 PM
Some interesting things happened today, and my UPS battery died so I have to make an emergency trip into town tonight.

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

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

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

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

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

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

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

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

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

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

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

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

In this case doing the tap/hold wouldn't crouch/squat but would instead do a squat dash/doge on tap or reenter stealth or run on hold... at least as long as you're moving. If stationary it will crouch. Which is useful in fighting too. But you can also do a standing up maneuver (exit squat mode) by doing the equivalent of a stationary jump, which is like crouching but letting go. Because of this you can't do a vertical jump in squat-walk mode. (It's mostly a curiosity... maybe could jump over some attacks. Though you can crouch first and then jump up. Same as a super standing jump.) Running leaves squat mode too, except in tight spaces. It's all very baroque TBH. It's a wonder it feels as natural as it does, at least once you get the hang of it. Kinesthetic controls are much better than push button controls. I can never remember what button does what when everything is just a push of a button.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 02, 2020, 02:11:12 AM
Update: I tested both the idea of not squatting/crouching when not running (or jogging) and to squat simply when releasing the action button when not running.

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

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

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

Because the dash modes are so complex it's shifted my thinking about them to not be about 1-to-1 controls like in traditional games. I think that they serve a few different roles. One is to encourage body awareness that I think is important to a game like King's Field, to its mood. One is to just make the movements more complicated. I've been bothered for a while that the movement is too simple to seem robotic. It works fine in the original KF with its course digital controls, but it just doesn't suit analog controls. I wonder if From Software tried analog with its later games and decided against it for these same reasons. My personal preference in games (everyone's different) is for heroes who aren't exactly competent and proficient. The Ico and SOTC games have very awkward and clumsy heroes that seems to me to make more sense. So I think of making the movement controls convoluted as a way to introduce a challenge of just having your body get in your way like in real life. In "survival horror" games clumsy controls are often prized for causing suspense and terror of failure. King's Field is not so far away from that mode of game. For me personally my primary objective is to make an ultimate kind of VR experience that is very fixated on bodily movement, so it's a natural outcome of this I think to have many movement options on the table. As many as possible. And of course if you're really deeply attuned with the game you will want the character to carry out the movements you imagine for yourself, so it's good to be able to approximate that. If you're really absorbed you may find yourself learning to be proficient like a camera man. My biggest reservation is my lack of confidence in the DualShock style controller. I think it's not ideal or what I would prefer. It's very imprecise and noisy. I wonder sometimes if a traditional joystick would be better or if it's even possible to make a better controller in this style. For the dashing modes I wish I could reliably push the stick to get the mode I want but I find it's almost a crap shoot if I press it, will I be in the bottom third, middle, or max press, I really don't know. It feels different every time and the more strung out I am the more finicky it becomes. My fingers aren't very reliable devices either for that matter.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 05, 2020, 05:13:51 PM
Here is a first image of a new system to manage KF2's variable lighting needs. If you pay attention in the game these stairs are darker than normal. The color accuracy isn't quite to the level of the rest (and I'm not sure yet if I may need to take this into account for the rest--the baseline--since virtually all cells have lighting values but you can't really see the ones in the higher ranges and that may be because they're washed out or the values are really a lookup table that isn't a proper ramp function.)

(http://www.swordofmoonlight.net/bbs2/index.php?action=dlattach;topic=286.0;attach=1393;image)

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

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

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

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

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

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

---------

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

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

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

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

The speed between dashing and walking still doesn't quite mesh but I feel like it's on the right track and it will inform decisions about speed later. When everything is self-reinforcing until there's no other way it can possibly be then you feel like you have a very refined and maybe even fateful design.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 07, 2020, 01:33:47 AM
Luckily I've discovered a way to vastly improve the "feel" of fighting monsters today and it could help smooth over the new problem when transitioning between stealth and squat modes some.

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

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

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

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

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

EDITED: BTW it seems silly but I've planned for a long time to add a fast-walking gesture for when you're just feeling a little impatient. It will be inputted by twiddling the analog stick when walking forward. I think it will use whatever parameters this fast-walk system uses, it will just be inputted directionally instead of being a side effect of dashing. Having this variable in the system makes it a lot more likely I will add that feature. It will only work while moving forward, and I think really anything that adds motion can be welcome to make for a more organic experience.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 08, 2020, 03:52:06 AM
I'm down to 2 small things then I will try to package my work so far as a new demo. I'm going to strip all of my work files out of the demo, or at least to make it smaller this time. I'm not against providing a package with all of my work if anyone wants it. I will replace the old download with it I guess.

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

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

In any event I think this will only take me two or three days. Tomorrow I may only get a half day to do my regular work.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 08, 2020, 09:06:36 PM
Sidetracked

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

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

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

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

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

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

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

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

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

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

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

P.S. I was really admiring the control system this morning. I'm beginning to feel like it's really arrived to be what I wanted it to be always. It's been a very long journey.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 09, 2020, 03:32:21 AM
Follow-up

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

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

This is done with a new, undocumented do_srgb extension. It definitely helps with these sharp aliased PlayStation style textures. It probably helps in general and isn't costly. I kind of wish many of the [Option] extensions could be turned on by default. Maybe it needs something like "do_all_recommended", I don't know?
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 11, 2020, 02:45:53 AM
Following up, I did complete the work on the do_srgb stuff that night. Funnily it transformed the sky map's stars from little points of light to bright colorful balls! The stars are lots of colors so they almost look more like planets.

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

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

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

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

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

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

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

Since I have a lot more on my plate I wonder if I should tackle the Fireball magic or not. I may go for Windcutter instead if it looks easier. The fireball magic in KF2 is just a sprite. I assume Windcutter is 3D like SOM's fireball, but I'm not positive. Windcutter is the more classic magic when I think of KF. When I get to expand on the series (assuming I do) I think of Aleph as using Wind magic. In my plans only two games will have heroes who use more than one magic type. Aleph will use wind.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 13, 2020, 05:05:33 AM
In the past few days I've found myself on a roll improving niggling glitches in the movement controls and fixing hard cases where level geometry can be clipped through. I pushed back the "camera" plane an order of magnitude for basic clipping issues, that also added 25mm (1") (not much) to the space you can lean out, out of about 350mm (14") by default.

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

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

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

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

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

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

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

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

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

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

The reason I'm going to such lengths is I'm getting self-conscious about putting out a flawless demo. Especially in the movement controls area. It's what I take the most pride in, and spend the most time on. And have the most interest in. And I worry it will be criticized if it doesn't feel like the most natural thing in the world. It's also the thing I think might bring attention to SOM since I really think it may be far more innovative than anything else that exists. Right now it's feeling very good. I'm sure it will be the center peice of the new release I'm angling for.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 16, 2020, 08:35:03 AM
I've successfully made a windcutter magic for the demo (coming soon) that continues through monsters so it can hit more than one. I'm pretty sure none of the SFX types are able to do that by themselves. It also turned up a bug where when the SFX data is deleted SOM would try to delete an SFX instead of a SND (via its SND number) but I think that the SFX records aren't deleted until the end (it's not even necessary to delete things at the end of a program but most programs still do it dutifully, even though it makes it take longer for programs to close out.)

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

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

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

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

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

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

It may take me a few days to package a demo after I'm finished with the work. I think I'm going to put it on a site like itch.io instead of self hosting it. That will save me from using up space and get some metrics going and a way for feedback.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 19, 2020, 01:07:29 AM
Almost there, I've identified a problem with jumping off the edge of platforms that happens maybe 1/20 times but it's really annoying since it short-circuits the jump at the worst possible time so I devoted a lot of time to it yesterday and intend to drill down it again today. It's not fun stuff but it will feel good to get past it.

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

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

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

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

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

I did fix a bug that has been leaking the cancel button from the menus to the regular game context where it must be mapped to one of the movement controls. I'm not sure if this has never been fully addressed or if it started again because of some changes in past year or two.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 21, 2020, 07:43:17 AM
I've not been having a great time. I did get the jumping problem straightened out pretty easily. I've been trying to get so many things in order. Tweaking everything. When I start doing that you I find more and more little glitches in the control system.

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

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

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

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

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

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

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

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

It's almost the end of October, so I don't see any way to do anything in 2020 after this demo. I could crunch on more level geometry but I don't see the point if the monsters don't have their AI in place, and I don't see myself being able to do both the AI and level design in two months. If it was one or the other I could probably manage something. 60 days can be a long time but it can go very fast too, and I tend to work slow. As usual I want to highlight the control system in the new demo. I've done a lot of work on it in recent months that I hadn't anticipated at all. And it's really come together.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 24, 2020, 12:24:08 PM
Okay, I'm at a stopping point work wise. It's really good. Tomorrow I will start packaging the files and trying to prepare a statement and make a home to publish it at.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 26, 2020, 09:01:30 AM
Okay, I'm at a stopping point work wise. It's really good. Tomorrow I will start packaging the files and trying to prepare a statement and make a home to publish it at.

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

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

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

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

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

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

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

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

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

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

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

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

They will get upgraded when it's convenient.

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

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

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

Now I just have to get this damn VR helmet on my head tomorrow. I'm not trying to demo VR this time around. But I don't want to have it broken compared to the earlier demo either.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on October 29, 2020, 10:00:50 PM



DEMO: https://swordofmoonlight.itch.io/k



(https://img.itch.zone/aW1nLzQ1MDUzNzcucG5n/original/NpCHB5.png)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on November 01, 2020, 12:18:05 AM
I've uploaded http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip and supporting files. I'm going to write a blog post for the demo and new release. It's not happening tonight though, and I'm not sure I'll be up to it by tomorrow either.

I'm definitely decompressing after publishing my demo. So far the response has been the usual deafening silence that I've come to expect from the world. I guess me and King's Field have bad karma. It's good company at least :evil:

*Whether or not "me and King's Field" is ideal grammar my intention is to put the emphasis on myself :updown:
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on January 06, 2021, 06:22:35 AM
In the past 2 days I've been obsessing over the spear trap and one of the trap doors that have bad cracks sometimes that give them away. It's been making me very unhappy. I also noticed the itch.io demo doesn't apply the scaling extensions to the second arm with the Bastard Sword item. I missed a debug check for holding off on experimental tests.

It looks like I haven't mentioned that the baby monsters are set up now, and I've boosted the color a little. I feel like I've written about that somewhere but I don't see it here. I think it helps with filtering but a little bit of color goes a long way. KFII is particularly drab/gray among the trilogy even on the PlayStation.

I've been noticing turning is a little jerky lately sometimes. (Edited: I've uploaded a patch for this.)

Back to those cracks, I really don't want to have to make a special animation for secrets. KFII actually swaps out the animated models with map pieces. SOM can't do that. There's a fundamental problem because the depth buffer lets pixels overwrite each other, so in theory the last polygon wins the so-called depth fight.

At first I thought this was the problem, but now I'm leaning toward it's more to do with precision of the MDL files not having the same exact coordinates. I rewrote two pretty intense subroutines to see if sloppy code was responsible for the imprecision without success. I'm feeling defeated. I tried reversing the part order for hard body animations. That probably helps because the MDL files put the "children" body parts earlier in the list and that seems to be the order they're displayed, but it's a problem for secrets and traps because that would display the motionless part last making it to win the depth fight, which is probably not good.

It's pretty complicated. I don't see a way to change the overwrite issue because typically the map geometry is displayed first and then any secrets or traps clearly have to overwrite it to conceal themselves. (Basically the motionless parts are equivalent to map geometry in this regard.)

Then from there which polygon goes last depends on (I assume) which part it belongs to, and which texture it uses, and then what order the polygons are in. You want the concealer parts to be last in the list, unless it goes in reverse order and I don't know it. (Either texture or polygons.)

So when I started I added some tools to my modeling software to be able to control polygon order before I realized the problem was more complicated. But it can be helpful for transparency to reverse polygons (if you don't have depth sorting/splitting.) I had to do that with Blender to make many of the transparent items to look right when spinning. And there's still sometimes an optical illusion where you convince your eyes they're going backward. (I have to work on full sorting/splitting.)

But I'm almost out of ideas for the cracks. I think either the object positions calculated by SOM_MAP and MapComp are a little off, or the 1/1024 MDL scale factor is somehow a source of problems. In theory the data needs to be perfectly matched. Even then floating-point hardware can be finicky.

The geometric problem arises from things like KFII's secret compartments because they form a perfect polygon mating. I honestly can't tell if depth buffer technology somehow can deal with that, if so my chip sometimes fails to. But surprising it generally looks good. I think it may be based on rules about shifting pixels over depending on if edges are going up or down or left or right.

It looks markedly worse with the do_aa extension, that's my baby. I feel nauseous that it's not working for me. But it sometimes glitches without it too. And I can't find any geometric explanations. Sometimes even vanilla walls (built from objects) glitch.

I think I should do a test with a MDO model to see if it has issues. It may be time to work on using MDO in place of MDL for display purposes. If so that would mean the culprit is likely either its fixed precision (not all coordinates fall on a millimeter but I think the cuts x2msm makes do) or scale matrix.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on January 07, 2021, 09:00:04 AM
For the record, I tripled down on this today. I woke up with an idea that I'd overlooked something but it didn't pan out, so I started the day feeling like reality had kicked my butt. So I kicked back. I convinced myself the numbers were exact and even reproduced the artifacts with nothing but map tiles.

I got lucky when I made a test project, it just happened to be positioned to produce the bad effect on starting the play test, so that saved me from having to wiggle around to draw it out.

It seems like this is just an intractable problem. I guess SOM needs a system comparable to KF2's. Everything seems to be pointing me to work on integrating MDO files and MHM files too are a big priority, and my working idea for fixing this problem is to let objects also have a matching MSM file that will be used until their animation is triggered, just like KF2. Except it won't live on the map, it will just occupy the same coordinates as the object.

I'm also planning to work on making the MPX compiler automatically satisfy the do_aa requirements. It needs to be automatic and I know now it shouldn't be a problem for the MPX file format.

Exploring this problem hasn't been fun but it's at least helping me to see what near term projects I should be thinking about. It's also kind of weird that this problem is unsolved for graphics, I don't know if many are conscious of it. The basic problem is if you have a perfectly carved out piece of a 3D model that fits together, like all of King's Field secret compartments do, because it fits perfectly (at least as good as the resolution of the depth buffer at any given distance) you just can't do it without faking it. I've kind of thought through it and I can see why. If there was a BSP system for transparency layering I wonder if it could be applied to this problem to make it less complicated. People might want to embed tiles into one another for other reasons. It seems like it should just work, kind of like do_aa should just work.

Edited: BTW speaking of do_aa I think it used to have issues with my Samsung monitors' "response time" setting. Now it seems to not be an issue. I don't know if that was the change I made for sharpness or the sRGB extension, but it's a good development that players don't have to adjust their damn monitors. Also I guess it feels good that I was able to determine do_aa wasn't the issue with this depth buffer artifact problem.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on January 21, 2021, 08:56:54 PM
Today I added headeaters sounds that vary pitch based on their size (which KF2 does) and recently have added lateral movement. I actually can't tell if KF2 really has lateral movement or if monsters are just rubbing against invisible barriers. It's really hard to reason about how KF2 behaves. It seems random.

I think I want to add the rest of the sounds ASAP.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on January 23, 2021, 10:31:53 PM
Three monsters down so far. Tomorrow I think I'm going to try to find a new mipmap generation filter. The cave texture still turns into a kind of white fog in the distance, which runs counter to the black fog. It doesn't look sufficiently like the emulator.

The filters in general turn everything to mush. I think in the early 2000s when everyone said games looked like brown mush, that mostly to blame for this is mipmaps and filtering. I don't know that SOM is capable of going beyond that phase in general. I think the only thing that changed that perception was games switching over to very high fidelity techniques and maybe some post-processing.

Once I get the monsters in an acceptable state for early demos (I'm going to be polishing this forever I'm afraid) the next task is a huge overhaul of clipping code for NPCs. They're mostly in the same state as vanilla SOM left them. It will be a pretty big project. I'm going to try to give them all the same benefits the PC model currently enjoys and try to put that code under the same roof to the degree I can. So it's a big reorganization project. (The NPCs--monsters included--have lots of issues, it really feels like SOM was left in an unfinished state.)

I'm also going to fix the problem where you can fall between the slats in the bridge (the bridge isn't the problem) I've put that off too long. And the "checkpoint" system needs work, especially for layers, and I want to try to keep monsters from trying to attack the PC from different layers (you can hear them trying to bite you from above or below the ceiling or floor.) And everything else can be interacted with from the wrong level, irrespective of vertical distance. I have my work cut out for me. At some point I hope I can squeeze in time to work on the art side of it again.

I'm going to upload a new demo with mobile monsters, and I want to include better mipmaps in it, assuming they can be improved... I'm hopeful they can.

For some reasons the monster sound effects seem too quiet. I'm not sure what to do about it. I've turned the volume up to max and reduced the volume of everything to compensate. The only other option is to edit their waveforms in their files. That would make them impure, so I'm trying to avoid it. I wonder if the PlayStation amplifies them. Or it seems likely too that 3D attenuation is to blame. I may have to set something up for the giant kraken to make sure its cries carry far enough to be heard beyond its grasp.

So far only the slimes seem to have an idling sound effect. I can hear the occasional cries from other animals and I wonder if those are ambient or are actually monsters. I really thought attaching the idling sound to the slimes would make them play incessantly in SOM but for whatever reason they're not overwhelming. They're probably less frequent than in the original, so far.

I've set up a trick system for slimes so they can move without rotating. To do it I let them move normally but don't assign their rotation to their model data structure. Right now I'm using the #3 slot in the new turn table system for this, but I feel like it's probably not a long term way to mark the behavior, but I don't know yet. #3 shares the #1 slot since it's fused together for diagonal movement, so it doesn't need its own. I just feel like it's too obscure to be used for this purpose.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on January 26, 2021, 03:01:53 PM
Today I'm going to finally break ground on that mipmap project. It's hard to find good information on the subject but there does seem to be a general consensus that it's helpful, or can be.

I'm going to adapt this (https://github.com/dwilliamson/GDMagArchive/blob/master/dec01/blow/gdmag_mipmap_1/main.cpp) code that comes from here (http://number-none.com/product/Mipmapping,%20Part%201/index.html) that may be an excerpt from an old magazine called gdmag (maybe it was in physical print, maybe not) (GD stands for game-development but I don't know if the intention was to hear "goddamn" mag or not.) (Edited: https://en.wikipedia.org/wiki/Game_Developer_(magazine) (https://en.wikipedia.org/wiki/Game_Developer_(magazine)))

EDITED: Specifically the build_mipmaps_wide routine with the Kaiser filter.

I worry about the "rings" problem it describes, but this looks like still the state of the art approach. Luckily I've done the bulk of the work already when adding the do_srgb extension a little while back.

Making these mipmaps is pretty compute intensive, so I don't think it's going to be advised to do this at runtime for a normal game, however KF2's textures are pretty small, so I see it as a way to do a test to see if it helps (I hope it helps) with the foggy mipmaps problem, which I'm not necessarily sure that it will. Most mipmaps probably look okay, so if successful, in the future I think what will be called for is a combination of singling out problem textures and computing the mipmaps offline (technically TXR files can store mipmaps, but do_mipmaps ignores them if present and I think even though SOM doesn't directly support full alpha channels that using TXR to store mipmaps wouldn't work well because the alpha channel needs to be full alpha in the mipmaps.)

I think I want to switch to using any image format for textures, and building a cache for mipmaps and alpha masks. The only thing standing in the way of that is time and the hundred or so other projects to prioritize.

EDITED: I should note that this effort to achieve high fidelity isn't for its own sake, it's to try to approximate what the PlayStation looks like completely unfiltered. Ironically it takes extreme high fidelity to replicate extreme low fidelity with high fidelity.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on January 27, 2021, 08:45:54 PM
Man I had a pretty bad time with this. The programming went alright, and I thought it would be a good opportunity to experiment with different parameters, but everything I tried essentially is indistinguishable from regular mipmaps.

And to make matters worse I hadn't really considered that I was using an extension that generates a double-wide pixel art texture, so that the first mipmap level was really the real texture.

And actually for the problem I'm trying to solve it mainly just shows the first mipmap. And it wasn't really interesting in this case. I wish I'd realized that from the start. It would've changed my strategy entirely.

At some point I realized what I really wanted was just a point (nearest neighbor) sampled mipmap, and that this new code can't deliver that. But it's actually simple to make a "point" mipmap and it doesn't shimmer like doing point sampling on the GPU does because it's really a mipmap, so it's stable.

Unfortunately it wasn't a eureka moment exactly, since by now I realized the problem wasn't really the mipmap so much as mipmaps/anisotropic filtering may be inadequate... this could even depend on your chipset. I think there is a little bit of the second mipmap blended in... so I switched over to using this point filter strategy, plus it's just as good really (for KF2 at least) and doesn't even require sRGB transformation.

I think it looks slightly better. A box filtered mipmap is naturally duller because it mixes the colors together until likely you get some kind of gray mush. So it helps that problem some to just keep the original colors intact. But it's not by much.

I wish I could think of something clever. I will probably try to increase the relative contrast some on them, I don't know. On the headeater monsters a problem with point-filter showed up, that is it can make stripes. So I added some bare minimum logic to jitter which pixels are chosen so you just get color noise. Not great if you expect more than that.

I will make this an extension at some point, right now I've just made "mipmaps_pixel_art_power_of_two" to use this point filter mode. It may not be a great choice if game depends on very accurate pixel art. But KF is just kind of grainy in this regard, and that's probably what you want anyway. With anisotropic filtering you don't tend to see much of the second level mipmap. Anything lower is going to be viewed at a shear angle.

My problem is it can become a gray film or sheen of mush that's just not attractive. This is mainly limited to the ceilings in the caves. It probably doesn't help they're pretty bright and contrast with the black fog.

P.S. Oh well, maybe this other code will come in handy one day.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 10, 2021, 09:57:16 AM
Here are some images of KF2 with the Iron Gloves worn on the arms that appear when fighting. I swear I spent upwards of 8hrs editing the arm version of the gloves. I honestly don't know why it takes that long to adjust a 3D model. Time just seems to melt away in 3D modeling. I don't know if that's normal. It may just be a labor intensive activity. Rebuilding meshes can be difficult.

I haven't published it yet but as of today equipment is finally on the two arm setup. I didn't have to work on it because there's no arm equipment in the demo on itch.io since there's none at the start of the game. I made these gloves just so I could work on it. I'm not crazy about how they appear. They should be even whiter than they are, but I darkened the MDO materials some. I like how the gloves appear in the menus. It's weird how they don't really translate to being cool to look at on the arms.  I plan to redo the arms before I'm done with something completely different. The forearms are super long. I guess that's some trick of perspective that generally works for the weapons but not for the angle on the shield. Technically the original animations are the "soft" variety, so it may be sometimes in the game the forearms would shorten. But SOM only understands the hard variety for arms since there's a lot of special infrastructure involved for them.

The shield seen in the insert is not finished. It's very nice and a lot of work has gone into the new shield system, but there's a lot more work yet to be done for it. There's many different aspects and needs for shields.

I shared an image of shields in a dedicated topic/thread a while ago. Today I changed my shield animation to a more exaggerated or stylized one mainly for two reasons. One was these gloves are very bulky and have some teeth like appendages that project out. I made it to hold the shield so the teeth would not clip through it. The handle on the shield isn't ideal for that but it can be redesigned eventually. I don't know if this is a natural way to hold a shield. It's a little more statuesque, but is it practical I don't know. The other reason is for now I'm assuming the gloves can be used as makeshift shields to deflect attacks and I wanted the glove animation to be approximate to the shield animation. They don't have to be identical but I thought they should suggest each other at least. The other way of holding the shield just didn't look like how you'd hold up a gauntlet to protect yourself... or it didn't look right or good.

This new pose brings the shield much closer to your face, so it's larger on screen and when pulled toward you (or when pushed up against things) it now covers the entire screen, so you're forced to play blind. That really gives a suggestion of protecting your head with the shield. I thought about scaling back the distance or basing it on the hand location (which will probably happen eventually) but ultimately I feel fine with it.

Currently pressing both buttons pulls it up closer to the face. Once I get to managing the damage reduction provided by the shield this will be a little better than the regular protection. It takes two hands suggesting you're also pulling your limbs in to be behind the shield. And you can't run... well you can, but it pulls the shield down... because pressing 3 buttons is the full running mode. I'm a little concerned pressing both buttons is going to come into conflict with my eventual plan for holstering weapons that I was really happy with. I like this too (and it has other uses) so I worry what will be required to not be forced to choose between them or decide on a different inputs.

Alternative holstering inputs would have to rope in the Menu button, which I'm generally against. I've also realized that mapping the menu button to the face buttons  doesn't make sense because it ties up the thumbs which are needed to use the planned quick-select system. That tells me that the four shoulder buttons are going to be locked in for SOM. Tapping the menu button could conceivably have a different function, but the quick select is needed on the shoulders. A game like Armored Core might make tapping the Menu button rotate your "subweapons" instead of opening a menu but in King's Field menu is pretty normal to have handy.

Speaking of menus today I worked on delaying equipment changes until the arm equipment isn't visible onscreen. I was working around equipment things to manage the models for the left arm.

One last thing. Currently the arms are fused together so it's not simple to manipulate them independently (that's not implemented) but the centering changes for two arm weapons since being perfectly center generally matters a lot for a two arm animation. I was centering when the shield was up too. But since I changed the pose to move the shield even further to the right side of the screen I decided that the shield arm should be pushed a little off the side of the left screen. So I split the difference between centered and the position of single arm attacks when shields are on screen.

Currently the shoulder distance is fixed at 0.2 meters, which isn't the original SOM distance but is the KF2 distance. Eventually I'll work on extracting that distance from the ARM.MDL skeleton. The single arm distances is 0.14 meters, and for shield 0.17 meters. You'd have to match that 0.2 value to make a new arm model with two arms. I don't think it makes since to think of it as moving the head over (ouch on your neck) so instead I think of it as rotating your shoulders. But because the arms are fused they don't currently have the right depth for that. It actually wouldn't be very hard to move the shoulders independently, but "hard" is relative in writing software... it really comes down to making a day of work out of every little possible project. You have to pick your battles day by day. But anyway I think this looks better to make the shield arm less prominent and pull the weapon arm closer to the center area. I'm going to redo KF2's arm animations (and design too) but the vertical swords for example look like meat slicers, and they tend to look better closer to the center than off in the margins, and even for the knife (Dagger) it's better if the target zone is as close to center as possible.

Strikeout: Day 2 I realized I was being stupid yesterday because it doesn't make sense to push the shield to the left if the centering is supposed to represent twisting shoulders. And it even makes sense to put the shield shoulder further out as if leading with the shield... I'm going to edit a new idea I had into a new reply post...
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 10, 2021, 11:06:32 PM
EDITED: I think I made a mistake yesterday. I've realized two things: 1) the idea about centering was wrong about the shield position... it should have been moved toward the center of the screen instead of away... which might actually pose some problems because the shield is already on the opposite side of the screen. I will have to give it thought. I think it looks better slightly on the opposite side, but not too far so... 2) in the new two arm skeleton the main shoulder actually isn't the root node... this means it's possible to animate the shoulders. I keep forgetting that...

It's also very convenient to work with the shoulders because they're at the bottom of the skeleton. My first thought is to remove the lunge effect and build it into the animation instead, however I'm not sure the lunge will look good unless the animation uses a nonlinear time step (like Bezier keys or something) which I'm not currently set up for, although it's something I want to add to my MM3D project. Often linear interpolation doesn't look right, but the "hard" animations aren't really subject to this because they have deltas for every frame, so it's just a matter of the exported animation being nonlinear... but for "soft" animation it's not as clear, since those are normally spread across multiple frames... so either what's needed is a hybrid animation or some built-in  support for interpolation modes for "soft" animations. The former seems like the better option if both is not an option.

So now I'm thinking the animations should move the shoulders, but not lunge, and when there's a shield and a weapon on screen it will need to compensate by treating the shoulders like a soft seesaw so which arm is in the foreground will trade places giving priority to the weapon arm.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on April 08, 2021, 05:37:44 AM
Here (pictured) are a couple imports from King's Field III. There's a nonzero chance both of these guys will appear in this project. The Exselector may appear in the system menu. It won't be so odd because it will be technically distinct from the game itself, like a modern day game system's menu. I'm trying to adapt Aleph's model into a VR avatar (in game body double) and use him in place of the original arms, because I don't think they will fly. That said I don't intend to include Aleph's coat here. I'm not really sure what to do about clothing. I will probably use this get up until I have an idea for an original outfit, and eventually provide both options if not more. I can't not include the KFIII outfit (it honestly looks like head-to-toe denim) for old-time-sake.

I guess his red and yellow fabric could be a shirt and stalkings. His skin appears olive tone here, but I think it's very light in the game. I know KF2's textures are much darker and lower contrast than they appear in the game. I assume KF3 is identical, although I don't know what is the mechanism. The same goes for these Exselector models. I think the rainbow color would be more washed out and brighter in the game. I've actually added some fake occlusion shading to Aleph to brighten him for his picture. I think it would be really cool if a single model of the Exselector could smoothly morph between all three of its forms. That would be a really cool progress indicator :xd:

EDITED: I've attached the 3D model files... Aleph's for this (https://www.reddit.com/r/KingsField/comments/mmnlcd/calling_artistsdesigners_reddit_contest_to_design/) contest to design clothing for Aleph to wear for this King's Field II project.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on April 11, 2021, 04:30:38 AM
So this (pictured) is what I've been wasting the past couple days doing. I sometimes doubt the wisdom of my choices of activities. When I got this model into Blender I couldn't figure out what to do next. I don't do a lot of 3D modeling, and it's been years since I modeled something from scratch.

I decided the best way to start would be to make a "skeleton" for Aleph except not in the usual way, since he's seated. I had to make reverse skeleton, and then pull it back into a standing position. The results in the picture are about as far as I could take it. I used my MM3D software to do this, mainly because I've never used Blender to do animation work, and it was very simple... except for the fact that this really put it to the test, and as usual it turned up a lot of bugs that I had to stop and work on fixes for. That's how you improve new software. But that was the bulk of my time working on this.

Now I will probably shoot it back over to Blender and tweak it. One disappointing thing I found out (which should've been obvious) is my plan to be able to edit the 3D model from inside the animation mode turned out to not work when the vertices have more than one attachment to the skeleton. I may yet find a solution to that, but there's no perfect solution to it, and this will make my idea of using the soft-body mode to tweak kinks in the skeletal animation a lot less attractive if I don't find a solution. If it's not practical then what would help is two viewports showing the model in both modes at the same time, but this will probably be a hard thing to set up in UI terms. Anyway, I have to go back to the drawing board there.

As I'm working on this I'm very seriously considering adding this soft skeleton facility to SOM before I'm done with it, because to dismember this model would be a lot of work and might not look right, even though at a minimum the arms probably need to be separated at the shoulder since SOM only shows the arms. Secondly soft body animation doesn't work for the arms. And third the arms are unique in that they're the only model (besides the gold coin and shadows) that never appears in the editing tools. That means I can add the facility without having to overhaul all of the tools to work with it immediately. Generally I'm adverse to doing work I know I'll have to just discard later. In my mind that's wasted time that's easily avoided. For that reason I see this as a real possibility. If I do this a side-effect will also be finally combining MDO and MDL files because there's no other way to do it. So that will be a big milestone. And I see this as an approachable way to break these tasks up into smaller more manageable tasks over time. (Edited: It will also require a new way to attach equipment to the arms... they'll have to be full arm models just like the arms but without animations. I've been wanting to do this because I feel like the current way involves way too many files and too much coordination.)

Note, on Aleph here his coat is probably down too low on him. It's stretched out in a way that's unavoidable. But it's sill neat to see his character model standing up. No doubt many sitting character models will have undergo this process in the future to bring all of this gold into SOM's treasure trove.

Edited: Just a fun fact. That asymmetry below his belt is because there's a strip of polygons that was clearly meant to be a second strap for his sword to hang on. In the final model it was textured over instead, but the polygons weren't removed. In this image it's stretched out like everything else. Maybe I should have pulled it up around his belt instead. FWIW this MM3D software doesn't have great facilities for working with vertex weights. It's something that needs attention.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on May 28, 2021, 05:04:55 PM
In the past couple days I had some success with VR stuff: 2) in reverse order, I got 2.25x supersampling (1.5 times each dimension resolution wise) to make a nice looking picture (attached, left eye only) by adjusting the mipmap sample point down to 50%. I could write a long post about my thoughts on this but I'm going to assume anyone reading this just wants to hear the news and not the technical breakdown. (In the picture notice that the lettering is smooth, especially on the diagonals on M. I assume if they're smooth the rest must appear smooth too.)

1) in reverse order, yesterday something on my mind made me to revisit how the eyes (twin pictures) are accomplished since a little while back I figured out, inadvertently (I'll spare you the details, I wrote them somewhere around here a while back) clipping pixels in the pixel shader is pretty costly, and I reckoned it would be much better to clip before the pixel phase. I first tried a "user clip plane" because the plane was down the middle of the screen, and it seemed to work but didn't quite, and I'm not sure why (without going into details) but generally it's advised to not use this, and especially on Intel, which my PC is/was. At some point I (stupidly) realized the 2D "scissor" clip option was what should be used since it's just a simple 2D clip, and I'd already used it for text at one point because the text is done by D3DX which doesn't let you use shaders at all. This helped with the frame rate significantly (anything around 10% is pretty significant) mainly because it does a better job of eliminating pixels from up close map geometry that's just on the other side of your nose.

EDITED: I realize I should've gone more "in depth" to explain the reason clipping was done in the pixel shader before is I originally set up stereo (two eyes) to use "instancing" so that both eyes are drawn at the same time. That sounds great, but I think at that point the data was still being uploaded to the GPU so instancing would cut the memory bus burden in half. But shortly after I set up a system that juggles temporary buffers in video memory that helped SOM with performance a lot. So at that point instancing wasn't a matter of uploading since only one copy of the data would be uploaded either way. So this new way just draws everything twice and switches the "scissor" clip from eye to eye for every little thing SOM displays, i.e. a skeleton's femur, etc. It would probably be better to do all the bones at once and do the animation on the CPU but that's another story.

So (1) helped with frame rates, and that got me wondering if I could figure out (2) to make the picture look good and hit a stable 60hz. And it did, on my system at least. But I still have to hook it up to the PlayStation VR since I recall sometimes the frame rate is affected by having to take in the input from its USB that's pretty intense, although in theory if the GPU is the limiting factor that shouldn't matter. In practice on this system the CPU and GPU share memory, so that might be why, or heat.

That costly clipping thing is still done for every pixel to poke holes in the textures (like for grass and things) so I know I could rollup my sleeves and add a system to make a twin for every shader so that that clipping could be eliminated when textures don't have holes, and that would make a comfy cushion to guarantee no frame rate blips. (Edited: A big reason I wanted to eliminate the eye clipping is this kind of VR would not benefit from eliminating the texture clipping if it was doing eye clipping, since it's the simple act of clipping that causes the GPU to perform badly, unfortunately. It has to do with the GPU not being able to make assumptions about where live pixels will end up in the depth-buffer.)

Anyway, the main story here is the supersampling, since that makes it actually look better. But it's good to get the frame rate down further to eventually be able to use a PSVR with very inexpensive computers. And hopefully once I get my new computer set up with a new high end head set I can just keep the PSVR plugged into this smaller computer. Actually my current computer is like cube that fits in the palm of your hand...whereas my new computer is enormous: https://www.amazon.com/Empowered-Grandia-GeForce-Workstation-Computer/dp/B08MQM8TXP/ref=sr_1_3 (NOTE: I paid well south of $1000 for mine, most of the price on that is inflated for the RTX graphics card, which I was able to swap out for a Vega APU. I'd like an RTX card for it but they're only supposed to cost $600 except you can't buy them for less than twice or thrice the MSRP right now because of demand for transistors. I'm thinking about going ahead and getting a head set since I think maybe the APU can handle it for SOM except I'm kind of bummed that VR controllers don't have enough index finger buttons to play SOM games, so I don't like the idea of buying controllers I'll likely never use... I like the announced PS5 VR controllers, but I think they won't come out until a head set appears which seems unlikely to happen anytime soon.)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on June 04, 2021, 02:41:24 PM
Edited: Before I kind of meant to say (I did in an early draft) that the reason I didn't try "50%" before was I'd tried 0% and it looked splotchy, and "75%" looked splotchy too, so I didn't think anything in between would help it. But I found out today working on this (http://www.swordofmoonlight.net/bbs2/index.php?topic=316.msg3177#msg3177) that "0%" actually looked fine, it was just switching to a different sampling mode in the shader (since 0 disables it) and that mode was the new contrast reduction sampling mode that shouldn't had been used with the PSVR. (Although at some point I may try to set that up. I'd need to actually spend some time on it with the PSVR.)

Also of note is that link improves this VR mode a lot more, so it's kind of on-topic. I came back here to retract that 0% claim but found I didn't mention it in the post like I thought I had.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on January 06, 2022, 02:43:57 AM
2022 translation note

It's been a while since I last posted in this topic/thread. I wonder if the most recent VR post is even best categorized into this dev-log.

I'm trying to frame new programming projects in terms of SOM itself, so that I will reserve this dev-log for only things very specific to this project, like how its art is progressing mainly.

Before too long I intend to break ground on the second map, and I will share some shots of it I'm sure. I'm also working (right now) on connecting maps without load screens.

But now I want to log a recent idea I had. One of the more daunting tasks for this project is translating KFII from Japanese into English without reference to the PlayStation translation. A hard to translate piece of this is how it refers to Dias Basil[1] to hide his identity or possibly an in-universe means of hiding his true identity, i.e. a secret identity. The original translation invents Necron for this purpose. I can't use that for legal reasons, but I want to be closer to the original text, but I don't want it to be clunky.

So I've not been sure how to thread this needle. The original text uses a kanji phrase that is often translated as "pope" (i.e. it would apply to the Catholic office of pope, or Pope?) That was the only translation I could find for many years, but I have seen at least one alternative translation, although I think it may not have been a natural English word or phrase... as in it might fit for a foreign title, or it might've been more of something you'd expect to find in a fantasy story. I don't necessarily want to deploy fantasy terms for KF, even though it is fantasy, I want to give it a patina of something deeper than mere fantasy.

The other day I think I found a solution, when I saw for a moment what was I think an online moniker of someone's pop up in a video on YouTube, maybe a streaming something. It was just the word Pope. It made me think maybe some people have Pope as their name. It sounds like it could be a name, or a surname even if not. I'm not sure. So I thought, what if instead of Necron as proper name the name Pope as proper name was used instead. This seems like it works to me. To explain the difference, upon reading Pope in some places, you might think that it means a pontiff. But in other cases if used as a regular proper name (depending on articles... or lack thereof) then you can begin to pick up that it's being used just like a name and not like a title.

I'm not sure how it will manifest in the translation, but you can see the difference if you imagined we just referred to the pope as Pope, as if using their first name, then that would change its reading. You'd never have to use "The Pope" in the text, which would be awkward I think. And Pope seems like a cool name or nickname to me. Anyway, this is how the sausage is made. One by one these conundrums have to be solved. I'm not going to fly by the seat of my pants like how games were quickly "localized" in PlayStation days. I think more care is given to localization these days even for commercial games, but I'm not sure how illiterate video game texts tends to be ATM. I'm definitely going to shoot for a hyper-literate feeling. Hyper here means I might even stretch it just to underscore this as intent. That said I'm going to shoot for something as natural as possible too, but not unmemorable.

Edited: [1] I just noticed now (same day) on this (http://en.swordofmoonlight.org/wiki/King%27s_Field_II/list_of_in_game_bios) page Dias's surname is given as Bagil. But I checked the Japanese, and it seems I was correct to say Basil. Just for the record.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on February 05, 2022, 10:03:44 AM
2022

I've got my work cut out for me :goodnight:
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on February 22, 2022, 10:20:39 AM
update

BTW, from my previous post (image of the fountain room) if you like a little piece of trivia, the little white cut in the channel on the left is actually a piece of the small mine, a room where you collect an Earth Crystal from a treasure chest. It's really crazy how compact the layouts are on the vertical plane. Luckily it's not generally a huge problem, but I suppose it could have been very worse. Usually the lower ceiling is only inches below the higher floor. In this case I will have to replace some flat tunnels with descending tunnels so that the small mine won't abut up into the fountain room. In the PlayStation version the separate levels are usually not loaded into memory simultaneously in order to meet the PlayStation's limited requirements. I don't think SOM will have any way to express this level of control, although I could add something in the form of an advanced extension to hide layers via events. (Which is how it would've been done most likely in the original.) Still I think that the overlap is undesirable, even in the level editor. I don't think it would be a good idea to do more than disable drawing on the other layer, so most likely sound effects would bleed in, which may or may not happen in KF2. Reproducing its sound landscape is something that concerns me, especially because it's largely an X factor that's opaque to my knowledge so far.

progress

As of a couple days ago I've begun to really hit my stride with much better development process at my disposal that allows me to work at a fast pace without any encumbrances. It's beginning to feel very exhilarating. I can set up tiles often in seconds. Everything is very streamlined and accurate. I will probably have to redo the first zone at some point.

SOM is at the beginning of feeling like an optimized development experience. It wasn't designed for building whole games from scratch with original art work, so it had not had facilities to integrate art development into its workflow... until now.

Since I've been using my own 3D modeling software to do this, I've been more inclined to work on improving its experience lately, since that pays dividends. I don't know how much I will spend time working on it now, it will depend on what feels like good tradeoffs. It certainly needs some work in areas. One thing I know I need to work on is nonlinear animation key frames. I think it's impossible to make high quality animations with linear interpolation, and if I'd had another option I think when I worked on adding animations for the shield and other things I probably wouldn't have struggled so much since I probably would've been happier with the results if they were more fluid. I'm surprised 3D graphics software often only deals with linear animation, since I think nonlinear is essential for good results, and allows for fewer key frames, less fuss.

I've had a very long journey to get this far. But it's starting to pay off. Finally.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on February 28, 2022, 11:57:32 PM
status update

On the second map, all of the tiles are now texture mapped, including palette swaps (there are a more than just the first map's Harvine room, which I also finally finished yesterday.)

It's pretty short work, but it's a mountain of work. It's definitely going much faster than before, but I'm not sure the quality of the texture mapping is as good. I intend to go back and tweak the maps after most everything is finished, some along the way. There's probably no perfect mapping because the PlayStation address model is so different, and the tiles have a like a cm of extra space that overlaps, that makes it hard to say what's correct.

(Edited: FWIW, for the most part, especially for tiles, I'm not having to make any adjustments to the UVs this time around. I added some simple shortcuts to my MM3D software, but I realized after a few tiles I was doing the same thing, and so I should just put that in the TMD conversion code as my starting point.)

There are some "objects" that need to be converted to tiles. I actually thought the game had a sophisticated system here it would plug in static tile models until things like secrets (and traps) are engaged, and only then replace them with the animated models, in order to hide their internals from the PlayStation's no depth-buffer approach... except yesterday I was in the Harvine castle area and every single secret there was obvious because the walls would glitch around them. I'm starting to wonder if the false walls in this area were just not given the full treatment. I don't remember the secrets being so obvious as these. I suppose secret panels are somewhat different on the PlayStation if they give multiple tells through various glitches. All it takes is a keen eye then.

I haven't noticed that many new items on this map. Hopefully I won't have to work on any more weapon animations.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 06, 2022, 07:25:01 AM
story time (j/k)

Today was a town/groceries day, but I managed to squeeze in a project to work on programming KF2's drawbridges. It was somewhat eventful (no pun intended.)

How SOM uses switches you could accomplish this a few ways. However in practice it probably wouldn't work for a number of reasons. How I wanted to make it simple, so I set up a global event that is constantly updating. It just checks the state for both drawbridge systems and updates them. Alternatively the event could be triggered by a button press, for each bridge.

The latter approach might require a timer, however the switch animation seems to be synchronized with the drawbridge's, and it seems like SOM doesn't let you flip the switch back until it finishes. Although I haven't looked at the code for this.

Edited: Actually the PlayStation game doesn't work like this. In it the bridges don't begin moving until the switch is fully transitioned, and the bridges move more slowly (and creakily) than the switches do. (I wonder if SOM should work like this... the way it works is more like an analog--1-to-1---switch, whereas the way KF2 works is like a digital switch... both have merit.)

For the approach I chose it wouldn't work because every event frame the animation would reset. So I worked on the object engage (animation) instruction to make sure it finishes playing the animation unless the state is flipped (I should probably add some protection to make sure the animation completes while I'm at it.)

But then it turned out there was another problem, because after the animation plays, the "object" automatically switches over to its resetting animation. For doors that means it closes itself.

This applies to either approach. So in some ways it probably turns out that to have the object remain open that the global event approach is the only way that can work. Of course I had to modify the programming, essentially to have the animation reset the wait timer, which for doors is set to 120. I think at the old 30 fps this holds the doors open for 4 seconds. However a while back I modified doors to behave like KF2's. That's better because they don't close on your face, and the timing is moot because they now will close at an opportune time.

This was a little confusing at first until I figured out that while waiting, it's actually displaying the first frame of the closing animation. I had programmed a strategy when I realized this, and so I knew I should work with the given system and take that into account, and take a new tack.

Then I noticed something, that wasn't a fluke. The drawbridge wouldn't quite open up fully after closing. This was a hint of something I've kind of suspected but never quite understood. It turns out (it seems) that som_db.exe will pretty much ignore the final frame in animations. I never could quite confirm it because usually for a door like animation the final frame isn't that important in the scheme of things... however, for the drawbridge it needed to be level in the final configuration.

This was kind of annoying, since I had to factor all of this into x2mdl. And while I was in the process I found a lot of other recent problems with it... as you do. I'll have to patch it, etc. again tomorrow.

It's actually nice to have the player (som_db) ignore the final frame, because the hard animations use "step" sampling, which is in a way ambiguous on the final frame, and I realized it was causing a problem with "round-tripping" animations between art and runtime files. I figured it was doing the best it could, but I was missing this important piece.

The existing animations will all have to be patched/revised, at least for the hard animations. I'll have to regenerate them. I looked at the player, and it's a little confusing because when the animation advances, it sets it to plus 1... which is what you'd expect. And it rejects it if that value is less than the length of the animation. But what I expect is that "plus 1" is really amounting to rejecting if less than the runtime minus 1, in a roundabout way. For the soft animations the subroutine that gets the runtime actually adds 1 to their length, which is I think a way of bringing both systems into alignment. Soft animations don't use "step" sampling.

If I wasn't clear, this is actually a good development for art work because it ensures the end of the animations are the same. It's a little confusing though because in the player the final frame never appears. It's more or less assumed either it matches the first for looping, or the closing animation will reproduce it.

Another interesting note is SOM doesn't really have a system for KF2's drawbridges and trap doors. What I've used is the double-door model. It doesn't actually capture the incline of these, since it's still working as if it's an upright door. However it pretty much captures everything, except that really you're walking on top of the door, which is assumed to be flat. I could try to improve it some time by factoring in an incline formed by the control-points. But I'm planning to add an even more flexible system, simply by enabling objects to use an MHM like clipping model before very long. I'm thinking this is something I'd like to get into this next demo. A good way to exhibit it would be to be able to climb inside the fountain I think.

I've been able to convert the new map's objects and characters fairly briskly (still very much in progress) but I keep finding myself midday in the middle of fixing some bug or programing this or that, often into the night right up until bedtime. One interesting moment came up last night. I'd been kind of unhappy with how the new map looked for some reason I couldn't place. I thought maybe its per tile ambient lighting isn't set up yet. Then last night I realized there was something wrong with the texture upscaling system (set up because KF2's textures are pretty small by modern standards.) It turned out for some reason (I forget) I'd set it to ignore the sky model's textures (maybe because they're always at a fixed distance that might not qualify, I don't know) and so now that the art system I just set up was sourcing its textures out of the same folder they were having the effect disabled. It looks so much better restored that I felt really good that it was back on track again.

It sounds very simple, but whenever something breaks, and it's for some left field reason, it's kind of stressful for programmers. We have to think on our toes, or dread that wait until every logical possibility is exhausted, and you've been there before, you know it's going to be some curve ball... you just don't know how long until it will reveal itself. Lately I've been having a problem that seemed to creep up when I worked on the MPX preloading system (I'm not sure what to call it) that I thought was a side effect of switching D3D over to multi-thread (which I've recently disabled in the latest patches, it seems to be working now without it.) but it turns out not. What's happening is it's crashing at start up every now and then, always inside an Intel driver. I've been watching it but I haven't got any leads on it. I'm a little worried about it. It's not good. I haven't figured out if it's isolated to my KF2 project. In theory it could be an Intel bug, but anyway, it is something that's bothering me lately. I just don't have any way to approach it. I worry it could be worse (always crash) on other drivers.

Update: I think I figured out the crash, or the basic reason for why crashes started with the introduction of the new background loading system. I wasn't open minded enough to realize some other subsystems could be split across multiple "threads" that aren't designed for that. (The first major such find was the [Number] system that enables some functional programming in the Ex.ini files. I just got lucky that eventually the CPU state post-crash made some sense... or at least gave me an idea.)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 09, 2022, 03:28:00 AM
Here's a screen from what I'm working on. I disabled the dither in this screenshot... I wanted to get more detail into the icon in the back of the room. I scooted it over 0.25 meters in order for it to be centered. I always wonder if its art direction is meant to be askew or not whenever I think I'm correcting something like that. I mean, it gets to your head, in a perfectly symmetrical room, is there a reason the icon is askew? Or were artists working overtime? The latter certainly seems to be the case.

Another thing you may not notice in this room is these braziers actually have some lava flows in their basins. You can't see it in this screen, but it's very easy to walk up to them and see it in this version... whereas in the original you really have to work to get the (very exaggerated) walking effect to peek over the lip of the basins, usually for only a brief moment... however somehow I was able to get it to perch, but still it's only possible to see just the tip of the molten lava.

These flames are all synchronized in this screen. I think there's supposed to be some randomness to them, although it's probably synced to the spawn frame, which in this case is identical since I started the level in this room, via the level editor.

I can't fathom how long it took the artists to imagine all of these set pieces. It takes me what seems like a long time just to set them back up. I'm learning partially how much work it would take to mount a new KF production. The answer is a lot. It's a lot of coordination and task management. I think it would be really hard to involve other team members, but necessary. At least by doing a first outing with this project a lot of the difficult programming challenges can be met in advance.

P.S. I also finished the Harvine room in the first zone today, and rebuilt the magic crystals, thinking my new set up is better at accurately capturing their double (and asymmetrical) sided texture map and that I may have made a mistake on the fire and water ones before. I did the wind, earth, and holy (light?) ones today. I'm not 100% positive this rendition of this crystal is accurate because I plundered the one in my emulator game.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 14, 2022, 02:51:03 AM
dragon doors

I've been having an interesting time with the heavy french doors outside the fountain room. One surreal experience I had last night was realizing there is a huge snafu in them when the frame rate plummeted. I'd already seen some phantom polygons in them, but it turned out there are 3 copies of the doors stacked on top of each other!! Some poor artist was working overtime that day (Edited: I've fixed up the frames too in order to mesh with the walls.)

That led me down a pretty strange hour or so of peeling off polygons from the doors, almost physically. It was the most tactile experience I've ever had with a 3D model, an odd feeling, so I just kept at it for the unique experience of it. I thought for a second about programming a solution to tease the copies apart, and then this morning I realized I could've worked a lot faster by pulling out a vertex, and then using a function that selects all of the connected polygons, and their connections, and so on... but that would've ruined my fun. Bu I did do that to confirm I didn't miss anything, comparing the vertex and polygon counts to the real model's.

Then I got swept up today working on a scheme to hide the interior sections of the door while they're closed, because if not they appear as shimmering cracks in the walls, which is something all our 3D technology can't solve it seems, since the edges coincide perfectly. It's a unique challenge of low-poly animations I suppose, although I imagine it probably does come up in high-poly scenarios as well. I found a sign extension bug in doing this that was causing Y scaling to make the MDL file appear to have X scaling (and so corrupting the decoding) (this is in my rewritten animation routines) and, unrelated, I had to disable the 60 fps upscaling when scale values on either side of the interpolated frames are set to 0, to prevent artifacts when using scaling to hide polygons.

Lastly I just added a fix to reset objects with closing animations to the first frame of their opening animation, or else I'd have to also put this scaling trick into the closing animation, and I reckon that's busy work and a source of mistakes, better to have the player behave consistently. (It shows the first frame of the opening animation when the door, etc. hasn't yet been opened, so I reckon it should show that after closing as well.)

Another problem arises with these doors that also affects the wooden doors. That is it's really not possible for a pair of doors to not have any space between them, at least if they're flat. And you can see this in the animation, it's quite clear the polygons clip into each other.

With the wooden doors it seemed sensible to put a notch in them. With these doors I'm less inclined to do that because they're more impressive in design. I figure that I'll have to invent some solution by remodeling them. I wonder if simply having a crescent (inner) contour would be sufficient. That might keep with the moon theme of this area. Although "dragon doors" appear in KF games often. I think that there should be sensible design that's also functional while maintaining their mystique. It'll be interesting to see what I can come up with.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 15, 2022, 09:25:59 AM
Ever wondered what the fountain looks like from underneath? Well I'm kidding of course, there's nothing there, but I had to improvise this. Both because you can actually stand on the bottom of the sluice gate canal (in the original the standing elevation hardly changes) and you can crouch down quite far with SOM. Lately I've also designed a lip inside the dragon doors to make their ability to open without jamming/breaking passably believable (one door must begin opening a little sooner--really faster--than the other) and I just extended the mouth of the canals. I'm not sure I like how that turned out, I'll probably go back and redesign it. It seems more distracting than I expected. I put a slope in there so the water wouldn't crash down. The lighting draws a bit too much attention. It has to be extended (somehow) for the same reason as the bottom side of the fountain.

Yes the yellow water is flowing, even though the canals are empty. There's actually an animation that just pulls the water up like with a crane. I guess the game short-circuited it, or didn't use it, or something. When the yellow water appears it just fades in. I'm thinking about making it possible to remove the dragon statues just for the heck of it, and making an animation where the water comes out as a thin thread and then expands out. Likewise the canals would become shallow as the closing animation recedes.

Edited: I worked on the obelisks yesterday... I did some tricks to help it look better by extending the texture map on the base and mirroring the sides so the squares appear level. I think the reason the base is how it is is the artist might not have tried turning the quad faces into 4 triangles instead of 2. It sounds really basic, but it does always surprise me when I try to map a trapezoid and it comes out completely distorted. I guess that's just how barycentric coordinates work, which I think is what's used to interpolate triangles.

If I spend even a little bit of time in this chamber, I start seeing everything as yellowed. Even the moon becomes bright yellow, because it's not blue. It's an odd feeling. After leaving the room the regular (not blue) walls are all very ripe yellow. It's a funny thing, the color schemes for the regular marble/stone walls is somewhat yellow. However textbook saturation enhancement formulas assign weights to red, green, and blue. I've always wondered what justifies these weights (I mean you can read up on it) but it's odd that red and green (especially) are weighted much harder than blue. As a result applying a saturation function beyond a very little tends to turn things yellow... unless I suppose the scene is predominantly green, in which case it may become ultra green because green's contribution to this yellowing is significantly more than red's. It's I guess a pure function of our physiology. I wonder if it applies though to everyone equally. I'm sure studies have been done, but I'm sure also it's just a compromise. But I sometimes wonder what if those weights were different, if it would allow for saturation to be pushed further before it breaks or not. Anyway... I wonder if it's somewhat linked to this color compensation/exposure our eyes play on us, since it looks very similar.

[Edited: I guess this pic has come some way since Reply #120 at the top of this page! BTW, I believe the fountain was the last "object" on this map. Next is NPCs, and then comes monsters/monks.]
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 19, 2022, 07:07:09 PM
new pic

https://swordofmoonlight.itch.io/k has a new picture of Al Hunt (I'm thinking of naming of him Al Hundt, I dunno) up, and I've remade the older image, mainly because the gauge and compass has changed some since then, and it was too noticeable it didn't match. But I wanted to match the contrast levels too, and the new pic was pretty accurate to the background so I made the other more accurate to match... just now I wondered if I should've matched the HP and MP on the gauges, but it's too late for that now.

It takes a lot of fussing to make thumbnails. You have to play around with sharpening and contrast filters, and so on, to get them to look right. I think today's monitors dynamic change their contrast levels, and even at different places on their screens. But eyes do funny things too. It's kind of annoying that what looks best on a full screen display can look very different (usually lower contrast and dimmer) on a desktop background.

I guess this is a teaser for the new demo I'm preparing. It's progressing, but I don't expect to have it ready before sometime in April. If it's anything like how things usually go, probably late April. It will probably be rushed, and I will then for the next two or three months try to polish it up more. I honestly don't know how long it will take before I can piece together a more or less complete version of the game... I know even after that I'll be trying to polish it for the next few years, hopefully while working on other projects. I consider KF2 one of the very few (if only) games worthy of this level of attention. Someone has to give it the attention it deserves.

Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 23, 2022, 07:44:36 PM
update

You'll notice in that screenshot of Al his skin isn't lit so bright like the original. This also matters in Nola's area where the sky is actually blue (Al's house is in the dark.)

What that meant is the lighting I've been using up to now was inadequate because Nola's area must push the light up higher than what I assumed would be its maximum.

This was a real headache for me, but I sat down today just to take a look at it.

What I seem to have ended up doing was taking all of my careful lighting calibration function, and what seemed to work was to pull it all out (including the power function) and just multiply by 2 instead.

What this tells me is the tile based lighting function I originally went with must actually be very close to the real function, and that this 2 is probably part of that function. IOW, what I was doing before was reproducing this function without realizing the default lighting was somewhere in the middle. This is understandable since I set out to reproduce the generic lighting long before I ventured into this per tile customization business.

I'm hoping that this answers most of the question about why the color is calibrated the way it is. I still wonder how this works on the PlayStation, as it seems kind of unusual. I assumed the color grading was more down to some kind of gamma ramp. I could still be wrong here, but it really looks pretty accurate. I still have no idea what the actual tile lighting values are, so it's really surprising it would be accurate. I just chose some arbitrary values. (I usually get lucky at this.)

From what I can see the lighting stored in the map data is not a gradient, but just hand adjusted values.

I was really thinking I'd probably have to adjust the lighting in the MAP files, but it seems to look okay so far.

The NPCs seem to usually have some kind of fake light source nearby. It's pretty easy to see there's some kind of big lamp in front of Al. And Nola's dress is lit near her feet. This explains why I couldn't match the fisherman's color. I really struggled with that. I gave up, but it's hard to tell he has a light in front of him, but now it looks obvious knowing what's up. I'm not sure how that's implemented. Most monsters (except Slimes) have their own light that follows them, and it doesn't change when they turn. I actually think this seems to work better than basing lights off the environment. It gives a consistent presentation. But the NPCs so far use the environment's lights except for these spotlights) ... and I guess that's down to their being immobile most of the time. Many "objects" appear to have custom lights too, and often it looks like they're just roughly mimicking the environment lighting. It's possible every one of them is custom lit somehow. I don't know if I plan to reproduce that.

EDITED: To some extent the fake lighting is produced by "surface normals" that are either manipulated, or just smooth normals (Gouraud shaded) where they shouldn't be so, but I still feel like there's an extra light source, or a custom light setup that just happens to be close to the environment's light. I may try to do this later once I have a custom system for lighting monsters. They don't approximate the environment at all, except for slimes.

I'm glad to be getting a handle on this, and surprised that the formula I used for the tile lighting effect would be accurate. I really just whipped it up as an approximation.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 24, 2022, 10:20:49 PM
Have to improvise for some of these NPCs who hide behind counters. Of course there's nothing back there in the PS game, legs and all. In SOM you can't get behind this counter, but you can lean around it and see most everything except the hollow space. You can climb over the counter, with some effort. I'm thinking of calling this NPC Wazoo Shoe. That's a kind of comedic interpretation of his name, but it's completely accurate.

Edited: I imagine the space behind the counter would be hung with several keys, but I don't think I'm going to go that far for something only visible by climbing over the top of it. It's not to save effort, but there's a certain amount of minimalism to KF's design which I appreciate very much.

Edited: Oh yes, you can see Woz's glasses are (now) two-sided, and I've made them a little bit transparent to boot!
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 28, 2022, 03:19:47 AM
good news

I finished the last NPC 2 or 3 days ago. I'm about to move onto monsters. I've been polishing up many models, odd jobs, like for instance I just worked on making the dragon doors invisible against the level geometry. That's actually pretty complicated because of how the do_aa extension works. Before even that (I've talked about this before) the inner walls of the doors have to be hidden in the animation by scaling them until they disappear. Then for do_aa the exterior vertices have to match the surrounding level geometry's precisely, or there will be visible tells there's a door there, and it will just look a little glitched otherwise. The supersampling option makes these glitches almost invisible to the naked eye. To accomplish this the object model has to be run through the level geometry converter, because it gets subdivided, which adds extra vertices. These are for points where lamps can cast light onto vertices, because the lighting model is vertex based. Used to unlit level geometry would not be subdivided in the game, however for do_aa to work, for a long time I've made it to subdivide everything. In theory the map compiler could be made to fill in gaps between different levels of subdivision, however realistically, in order for objects to be embedded into the level geometry, at least for this to work, there would need to be a way to tell the compiler to divide sections, other than placing a lamp on the map nearby. (Maybe even a false lamp would do, but I think this would be a hack... maybe it could detect objects that have Phantom Rod status and interpret them as requiring subdivision... actually that would be a pretty solid strategy.)

Good news wise, I'm very happy with where the color is at now. This really helps me to get excited to work because there's so much work that has to be done. Really the team that developed KF2 deserves so much credit, but the way I look at it is they made a really good prototype which posterity now has to polish into a gem, which is easier said than done. Not discounting the degree of work required to produce a product like this, which isn't even paralleled today. Those days really were a unique time for video games, which are now gone like the dinosaurs. We have to be the paleontologists of these dinosaurs in the meantime; Pay our dues.

The PlayStation game, at least on emulators, always has a washed out feeling that I really dislike. Sometimes I can't see it, but sometimes it comes on very strong. I don't fully understand how the PlayStation architecture would have supported how KF2's colors/lighting seems to work, but that's probably just because I don't know enough about it. It seems like the textures have their colors multiplied by 2 at some stage. All of KF2's textures are very dim, so it's possible this is done when they're loaded into VRAM, if not somewhere in the graphics stack. The textures are 15 bit color, so I could see why they might get upgraded into higher resolution data at some stage. If not, then KF2 only uses half of the 15 bit color range, which would be like using 4 bits instead of 5 bits for each color channel. It's pretty hard to work with these dim textures because they're hard to see, but it can be even harder to work with really bright textures, especially if you're editing them, and generally how graphics worked in those days (and still probably) textures would need to be exaggerated in terms of their brightness because typically materials and lighting could only make them dimmer than the texture, never brighter, so the texture would need to be as bright as it will ever appear... and that's still how SOM works. So that's one reason why the team could've chosen to brighten them at "runtime" when the game loads up.

Anyway, there also seems to be a creative dynamic contrast system, which is combined with darkening, to create dark environments which have reduced contrast. Unless I'm mistaken this is pretty clever because I think how SOM and other games work, lighting doesn't impact contrast. But how we see IRL definitely does seem to work like this, and it feels pretty interesting in the game. But the default contrast level isn't maximum contrast, so maybe this can contribute to why KF2 feels (looks) dull in this area, i.e. like it has reduced contrast. But that doesn't fully explain why it looks "washed out". It's possible the mix is just wrong, however it could be a choice based on how televisions worked in those days. I don't know, but it doesn't transfer well to modern day displays. As soon as I started to unravel some of the mysteries around the color lately, my project's color started to take on these same low contrast and washed out effects. That meant it was actually reproducing KF2's color. I'm actually surprised I haven't needed to tweak it that much. But I've been spending a lot of time in the past few days tweaking color, more than anything. Also remapping some textures.

I noticed that dropping the color down like 12 values (I think) helped to remove the washed out appearance. That's easy to understand I guess because what makes it seem so is because it's too bright... washed out basically means everything is too white. But I wasn't smart enough until a few days later, I realized the commonsense thing to then do is to just remap the color to full brightness. This sacrifices those 12 values at the bottom, but then pulls everything else back into full brightness. I had been using SOM's brightness setting to compensate some. I don't know why it didn't occur to me to just do that in the color function. This looks really good. And I've been tweaking the lighting too. This is possible now that it's really accurate. Although I wish one of the KF2 hackers would just cough up the real lighting values, because there's 3 lights, and they're all at oblique angles, so it really hurts my skull to reason about them. I know someday someone will find them. I assume there's also a baseline ambient light level. This is exactly how SOM works fortunately.

Just to reiterate, the color is really popping. I think the new demo will be very attractive. It feels closer to an ideal mix.

I also had a funny thing happen yesterday. What happened is I was just poking around as normal, and I went into the fountain room and found all the channels full of their water. I hadn't set it up to do that, so it was a little surprising. Of course there's an explanation. What happened is I usually use the first register in the event system as a temporary variable, and this is also what the objects default to, so it's kind of surprising this didn't happen sooner. Something had just left a nonzero value in that register, and that turned them on. It was still fun to see. Even though the channel's water isn't moving yet. That requires a texture animation, and SOM doesn't support that on animated objects, so it's something I have to work on. And I have to upgrade how "pedestals" work too. SOM puts fake versions of the items that fit the pedestals into their animated model. I have to build a better system that uses real items instead. Even if the dragon pedestals could work this way, it's not a very flexible system, and the save room pedestals can't work like this since they accept more than one item.

aside

Speaking of that, a while ago I decided on what to call those items when I translate KF2. I don't think I'm going to call them gates and keys, even though this is the literal words used in katakana in the original. I want to do the translation from Aleph's perspective. I assume Aleph knows about this system. Plus the "gates" function like keys really, since they open a door. Even though I admit, looking like compacts they're not evocative of keys. I still think the generic suffix of "key" works since their are already so many keys. So I think I'm calling the portable items keys. But I couldn't figure out what to call their counterparts in English. Oftentimes English seems very impoverished when you go to find a word for a concept... especially abstract concepts with no modern precedent, as you so often find in games and software. But without further ado, I found the word "pendant", which also has a meaning that means a counterpart or pairing, and the shape of these things does evoke a pendant in some usages. They're actually very hard to categorize things in terms of their shape and action. English doesn't even really have a generic word for a thing that inserts into another thing. Like a plug? I don't know. English seems very ad hoc in design... as in words only appear when there is very strict need for one, which allows it to catch on. Anything else, sorry Charlie/Chuck, you're out of luck. I wonder if Japanese is like this or not. It seems very abstract to me, like baby speak sometimes. English seems overly/obsessively concrete/specific by comparison. But I think that can be interesting for game translations, because it forces you to try to be concrete in your words, or else the script comes across as unnatural or not literary, more like a low piece of cultural ephemera than art. 
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on March 31, 2022, 08:57:50 AM
Woap :geno:

EDITED: For the record this is using the Volume system. It occurs to me that surface normals might look very similar to this if fixed how KF2 does it and with just so lighting. It's possible that's exactly what it does. I might try to do it that way later. This system would work even when the ghost flies through things. There are places where the ghost intersects itself. It might be worth trying to make him/her/it more convex because it breaks the illusion by introducing creases... edited: or it might be possible to solve this after I work on sorting/splitting every triangle for correct transparency. Slimes will probably get this treatment soon. I'm going to work on UV animating MDL files very soon, for the fountain room. The green slimes should be able to use that to do their flowing animation. (It took most of my day to redesign the texture work on the ghost. It wouldn't work how it is. I had to put the mouth and eyes onto a full body texture. In KF2 they're just kind of patches. That doesn't blend smoothly with filtered textures. There's not enough degrees of freedom in the model to match the oriignal eyes and mouth exactly.)
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on April 04, 2022, 12:43:02 PM


Oh Ramona, if there was only some kind of future
And these cerulean skies
Something in our skies, something in our skies
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on April 04, 2022, 12:46:01 PM
[For the record, this sky background didn't look like this at all at first. I worked with it all through the night. I think I pulled out all the stops, trying everything.]
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on April 06, 2022, 01:40:21 PM
black hole of despair

Today I set out to switch between this blue sky and the dark sky. Somehow it spiraled into a recurring nightmare so that I couldn't seem to tear myself away from it all day.

The tricky thing is loading the sky without hitting a hiccup. I couldn't get it to work so I ended up tearing through and double checking all of my code around this sort of thing. I found a lot of problem areas in the process. Some may be bugs in the current patch. I kept going through moments where it seemed to be working, only to later have it regress back to not working.

Even the map transitions I set up were stalling. But I think I've got a handle on all of it now.

On the sky changes front, I started out by looking at the event trip zones as a possibility, however they're really pretty badly designed. I thought about how they could be improved. But for this leg of my project I decided it would do to add a formula to my INI file that looks like sky[1] = if(neg(70-2_,12-3_,40-1_,1_-56,0),4,1) and just cuts out the relevant section of map.

I've made the 2 old "alphafog" Detail extensions that serve to blend the sky into the ground plane of fog communicate the sky model number to specialize accordingly, but I'm not certain if this is best for the other ones that control the fog effects mainly. These 2 are very much tailored to the model itself and isolated, so it seems fine to work like this.

Next I have to work on the UV animation. In order to make this blue sky I had to disable it. I could write a long paragraph about what the options are how to do this. I'm not sure yet what I intend to do. I'll have to figure out something.

trip zone thoughts

Trip zones definitely need to be improved. The main problem is there's no way to pick up on leaving the zone, so it makes event setup really tedious and unreliable. Unfortunately there isn't a very obvious way to incorporate this into SOM_MAP's existing framework. I would start by adding a system number to the INI file for testing the trip zones, which can help some, but can't inform events, so they would need there own way to do this, that I think could be done with the Counter loading module, but isn't very straightforward. It would be better if the trip zone events had a direct way. I thought about letting the "always on" events define an optional trip zone. The only real problem there is how to choose if the zone is square or circular. Being "always on" could process coming or going or staying in or out. But how? The Counter way seems most practical. Its only drawback is obtuseness and requiring dummy trip zones. But the master event could consolidate all trip zones. The approach I took probably isn't practical for a real project, and isn't user-friendly at all, so I'm certain this trip-zone approach will be realized down the road.

Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on April 11, 2022, 06:02:04 AM
pics

In the 2020 demo (very late months) I did a bit of butcher job on the green stone tunnels to try to make them work. Something has to be done because they just can't translate to filtered textures and IMO they only half work because they're not filtered, otherwise the design is really questionable.

Today I woke up with the intention of finally rebuilding these from the ground up. A better 3D artist could probably do something a little more creative to capture the spirit of the originals, and they're welcome to, but I knew I had to fix this for the next/upcoming demo. I'm pleased with the results. It can use some polish, and hopefully there will be time for some, but at least I can check it off my list like this.

Another reason these need work, beside the design, is the texture maps on them are way too low resolution. The brick size I ended up with was based on the arches, which have much smaller bricks for some reason. (They don't match up at all.) But ended up being made a little smaller to match the stair steps height. It takes a little getting used to but is not so bad. It definitely has a different feeling.

EDITED: For the record, the 3D polygons are unchanged. Also the surface lighting is hard. It can be hard to tell with this texture. It looks smooth either way really with all the confusion and polygons falling on the texture lines.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on April 23, 2022, 04:39:42 AM
Here's a GIF of a slime made with an animation movie export system I cooked up quite a while back. It gets the job done. I think this is probably accurate to the game but I've not sat down to scrutinize it just yet.

It certainly looks different to me... almost like stained glass because the edges of the triangles don't (all) hold together. I made some slight adjustments to help the dark edges line up where they didn't quite meet sub-pixel accuracy. That's the only part that holds throughout the animation.

P.S. If anyone's reading this, I'm still trying to publish a demo by the end of the month, but this is likely to take up all my time until then. I'll just have a few days to try to do a little bit to add some missing item models and patch up some animations. It's going to be really rough. I have a feeling the new monsters will just be walking in place without sounds unfortunately. I just have to publish what I have. Their textures aren't cleaned up enough to give them a good show, so I feel even a little better if they're more like placeholders. There will be a follow-up in the coming months with everything touched up. There probably won't be another big demo this year after that.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on April 26, 2022, 06:37:58 AM
home stretch

I'm going to upload a new demo before the month ends. I'm making a list of last things to include (it's going to have to leave out a lot that I'm not sure I could do right now if I had the time to anyway... I'm getting very near maximum burnout.)

1) Finish channels in fountain room.
2) Some clipping obstacles in the village areas, raised entryways, Nola's fountain.
3) Make the windows on houses see-through, remake their super low-res texture.
4) Try to improve tree fuzz on the blue sky model's skyline.
5) Many item models. Try to get all of them... as quick I can work.

Things that won't be in the April demo are, any new sound effects, any new moving/fighting monsters (they're walking in place), any AI improvements or fixes for flying/swimming monsters.

Things that will be are, cross into zone #2 without loading pause (if your PC is at least as good as my very low-end work PC), all of zone 2 visuals wise, except the dark village area is using the same textures as the regular villages, and significantly improved color.

Most of my work since I set out to do this has been on the 3D model editor side. I've done everything this time around without Blender or anything else. Just SOM and my MM3D editor. It's been very pleasurable. A fully streamlined experience.
Title: Re: STICKY: 2020 King's Field II port progress report
Post by: Holey Moley on April 30, 2022, 08:31:45 PM
Yesterday I worked on the remaining "item" models and went down a particularly absorbing rabbit hole with this model (pictured) because of troubles with the design on the stomach.

I actually started on it the day before (lately I've been in town and had a tire explode on me) and got derailed because of upscaling artifacts on the same design. As a result I decided the upscaling system I'm using has to deemphasize diagonal pixels, and this is a significant improvement, although it makes it more generic looking perhaps. There were noticeable unsightly artifacts in some of the textures, like the cliffside beach walls' one, that are eliminated now.

Still, after making this fix, how the design on the armor (pictured) is executed seemed not good enough for this project. So last night I did the best I could on short notice to try to remake the stomach area. In the original the gray gradient on the stomach is part of the design's texture. This looked too bad, much like the ghost, so I tried to remake the stomach to use the same gradient pattern as the rest of the armor, and change the design to a decal.

I couldn't get the colors I wanted, so it's quite a compromise. This is because it had to be an additive transparent decal. This can be improved later when I plan to switch the art system over to outputting a texture format that can enable alpha data alongside the RGB color. As for the decal itself, I've just upscaled it, blurred it and resharpened, and made a few hand tweaks. It will all have to be redone (hopefully better) when the rest of the set is done. In theory it wouldn't be that difficult to remake the design(s) from scratch. I'm sure it would look better. It definitely requires more resolution. I want to be proficient with SVG at some point. Surprisingly tools like GIMP don't offer any good automatic solutions for upscaling. I looked into some of the recently popularized solutions for upscaling old games and media but found nothing of use.

I think I'll be done with my plans for the new demo by the end of my day today. I don't know if I'll get to generating the final game files, I'll find out. I think I've settled on names for all of the "items". (Edited: Not just those in the new demo.) For this armor set I've decided against calling it "Merrel Ur's Armor" etc. That's what the Japanese says, except for the gloves and boots it calls Ruinas. I looked up the katakana for those two, I think it probably means something like "ruinous" as related to ruins, but most common associations online relate "Ruinas" which sounds like a proper noun. It might be related to something in Spain, I can't remember what I found. Sometimes Japanese loan words come from older pan-European sources. I was thinking of calling them Ruinas, but I've decided it's too quirky and "Ruined Armor" etc. probably scans better in English. The word "ruinous" I consider too baroque, or even too on the nose if it's meant to portend  tragedy. In English "ruinous" is more like cursed, and I think the meaning in Japanese is closer to ruined, as in both archaic and dilapidated. I guess those two pieces of the set are named differently because they've somehow become separated from the others and handed down as heirlooms. As for "Merrel Ur" I just find it too clunky. I think I'm going to call the arm band piece Merrel Ur (Something) since I think it's said to be inscribed with a message from the artisan who made it. The artisan's name is given. (Sorry, I can't recall it now.) Because its design matches the rest of the pieces from this it can be concluded they once belonged to "Merrel Ur".

Note, the pieces are covered with "runes" (of sorts) however the Japanese does insert an "i" sound after the "u"'s that suggests it's not meant to be read as "rune armor". Currently I have the arm band called Merrel Ur Pass, suggesting it's a badge conferring a title which allows "passage". This is from my future plans for a KF project, which I don't mean to tie into this project necessarily. But there is a problem that this item needs a name that works in English which this overcomes. It suggests the arm band is more than just a decorative flourish, and that perhaps Merrel Ur is a title instead of a man. although the name is used to denote the last man (or high elf) who held this title. (I think maybe the "'" (apostrophe) doesn't render so well in the Japanese font SOM uses, so I'm leaning toward avoiding it in names. It's a little too wonky for video games anyway. (If this is its name it might be worth adding some kind of bonus section that's only accessed by wearing this arm band.)

[Edited: I think I meant to also say here that I'm seriously considering calling one of the rings Lulufon's Ring, drawing a connection to the Shadow Tower series, so I'm not taking this extremely seriously. This ring is really called the chirei ring, which if you know from playing Megaten for example, chirei are spirits of the earth. But the only real use of this word in Japanese is for a semi-famous play called Earth Spirit about a wild woman of the new century named Lulu, and anyway, it looks like something she'd wear, and I can't think of an English translation that scans, so I'm thinking about using this just as a pun. Lou Reed--a hero of mine--wanted to raise a production of this play, Lulu, and named his last major album done with Metallica Lulu. This is moreso me leaving my own (esoteric) mark on this project as an Easter egg. (Ascribing to it some literary pretensions for good luck.) (https://en.wikipedia.org/wiki/Earth_Spirit_(play) (https://en.wikipedia.org/wiki/Earth_Spirit_(play)))]

Anyway, this isn't exactly how it looks in the SOM game. This screenshot is out of SOM_PRM (actually ItemEdit) which has different lighting. The original game has false lighting when picking up items and in the menus. SOM uses the environment lighting, although I suppose I should offer an alternative. Or it could be the item itself has false lighting. To fake this I turned down the "diffuse" component and turned up the "emissive" component.