simple machines forum

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. 

Attachments

 KF2 Woz exposed.png 

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!

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.

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.

MM3D upgrade

First, off-topic, I've uploaded a minor SomEx.dll patch just now that fixes a problem with scaling animations. I'm not going to announce it as usual.

The past few days I've been working upgrading MM3D's modeling capabilities by addressing several of its tools that original author neglected to add texture map support to. That made these tools pretty much useless since texture mapping is the most difficult thing, and it's not worth ruining your texture map to edit a model.

I've mostly been using it for animation, but lately I've not used Blender since I started the new round of work on my KF2 project. I have been making some edits, but I'd hit enough walls that I decided it was time to roll up my sleeves and do something about this. The demo and source code for this is on Github.com. I really enjoy working on MM3D this way. I've been pleased with my decision to take it under my wing.

Anyway, this is just my activities of late. Hopefully I will be back to working on KF2's NPCs by this time tomorrow.

Attachments

 KF2 underbelly.png 

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.]

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.

Optional x2mdl (dll) patch (#2)

http://csv.swordofmoonlight.net/x2mdl.dll/1.0.0.2.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.6.zip (maybe slightly improved)

I got lucky with an accident that helped me to identify a pretty wild bug in x2mdl when converting the MM3D files (that format specifically) into SOM's files. It will likely crash if the MM3D file doesn't assign all of the model parts to groups (i.e. materials/smoothing groups) (which is how I found it, by accidentally not doing so with a portion of model) but the real kicker is a "loop" I wrote was using the wrong "variable" to track its progress, which could potentially be slow things down.

(I've never made a bug like this before, but basically in one standard kind of loop you have a number that is incremented until it gets to another higher number. What I did is mistype the "variables" holding the numbers so that the higher number is incremented and the other retains the value of the first item that is looped over. In that case the CPU just keeps hitting that item until the higher number "wraps around" in memory so that it becomes lower, and that can take billions of instructions (probably around 1B in this case) which is in theory a gigahertz if an instruction is one cycle. In practice though there's probably several instructions involved, although this loop was very simple.)

I'm just glad I found it. I'm sure it would turn up eventually, but I actually neglected last night to investigate it since I forgot to make a note, but luckily I remembered and went back and reproduced the crash (in SOM_MAP) to figure out what happened.

x2mdl (dll) patch

http://csv.swordofmoonlight.net/x2mdl.dll/1.0.0.2.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.6.zip (maybe unnecessary, can't remember)

I'm still patching this leaky raft... namely I didn't test the texture downsizing path (to fit MDL's 256x256 limit) and some other nontrivial stuff I won't go into details about. One serious problem led SOM_MAP to convert non level geometry models into level geometry. (A new time optimization is it no longer generates MDL textures when there aren't animations, since it won't be outputting a MDL file. Eventually I want to omit textures from MDL files altogether since they're not shown in the game. But for now--transitioning time--the files still have textures so they can be opened up and looked at.)

Attachments

 KF2 shrine.png 

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.