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

Holey Moley · « **Reply #120 on:** February 05, 2022, 10:03:44 AM »

2022

I've got my work cut out for me

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

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

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

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

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

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

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

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

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

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

Holey Moley · « **Reply #131 on:** March 31, 2022, 08:57:50 AM »

Woap

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

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

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

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

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

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

STICKY: 2020 King's Field II port progress report