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

Holey Moley · « **Reply #30 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.

Holey Moley · « **Reply #31 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.

Holey Moley · « **Reply #32 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.

Holey Moley · « **Reply #33 on:** November 25, 2018, 11:11:28 AM »

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.

Holey Moley · « **Reply #34 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

Holey Moley · « **Reply #35 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.

Holey Moley · « **Reply #36 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.

Holey Moley · « **Reply #37 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.

Holey Moley · « **Reply #38 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.

Holey Moley · « **Reply #39 on:** February 19, 2019, 11:12:47 AM »

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.

Holey Moley · « **Reply #40 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.

Holey Moley · « **Reply #41 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.)

Holey Moley · « **Reply #42 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.

Holey Moley · « **Reply #43 on:** March 05, 2019, 08:11:48 PM »

EDITED: http://www.swordofmoonlight.net/canvas.php?demo=head-eater

Holey Moley · « **Reply #44 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.

simple machines forum

News:

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

STICKY: 2020 King's Field II port progress report

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

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

simple machines forum

News:

Sword of Moonlight| Archive (pre 2023)| Projects, demos, and games Information| STICKY: 2020 King's Field II port progress report

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

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

STICKY: 2020 King's Field II port progress report