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

Holey Moley · « **Reply #15 on:** October 27, 2018, 01:43:32 PM »

EDITED

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

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

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

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

The lighting is accomplished with 3 directional light sources, which seems like a lot. But it's exactly what SOM affords.

Holey Moley · « **Reply #16 on:** October 28, 2018, 09:11:41 AM »

UPDATE: Final colors, accurate to within a infinitesimally small threshold using the following color transformation function:

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

Code: [Select]

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

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

EDITED: Better colors

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

Holey Moley · « **Reply #17 on:** October 28, 2018, 03:59:14 PM »

Here (pictured) are two unique challenges of late: crystal flasks and wall scrawls.

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

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

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

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

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

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

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

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

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

EDITED: The cliffs' skin isn't much to look at from that distance. Ultimately there will be a new skin pack with high resolution SVG versions of the same images. SOM displays item menus too small I think. I don't know if it should be larger or if it would be better to work on a way to scale up/down with the controller, and remember the settings. (I sometimes think looking at items would be a good use for a SIXAXIS style motion control function.)

Holey Moley · « **Reply #18 on:** October 29, 2018, 12:55:04 PM »

EDITED! I realized (maybe after noticing the scrawl text is actually the same as the text/skin on the gravestones) that the black highlights must be part of the TIM images, and I'd just neglected to handle the extra see-through bit part of the the 5:5:5:1 pixels.

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

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

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

I don't know how much the between color looking purple is from the original image or from the background being basically purple. I did add a little purple and tan to the diffuse colors to simulate the palette of the original image...

Holey Moley · « **Reply #19 on:** October 29, 2018, 04:16:09 PM »

EDITED: Turns out the problem with crystals/waterfall, etc. that have two-sided polygons was Blender's OBJ format import script, which apparently can't handle basic functionality (unsurprising, lamentably.) So now I get to go back and redo these things to make sure they are correct. Savepoint looks wonderful though.

Holey Moley · « **Reply #20 on:** October 30, 2018, 12:39:06 PM »

More hopefully tantalizing screens. I'm updating the light configuration attachment from the other day's post to reflect more discoveries.

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

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

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

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

I left the comparison image in full color to aid with comparison. It's not perfect, but is very close, and close enough, whether it gets better from here on out or not. With the new ambient level I tried and tried to make the picture less smokey/dull but could not. The input is so narrow/limited that it may not be possible to make the color more dynamic. Fortunately the high color mode is good at making pictures appear much more dynamic. That's why I prefer it, and true color is very often washed out anyway. Even under ideal circumstances.

Holey Moley · « **Reply #21 on:** November 02, 2018, 02:34:26 PM »

As of yesterday the color situation is a lot better, since I just happened to chance on a setting that looked really really close, and made all the lighting come together, and that spurred me to do another round of obsessive tweaking... which I should be doing with color software or something, but I'm just plugging in new numbers, start game, compare, stop game, repeat!

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

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

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

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

Below is the color transformation in use as of now.

Code: (old) [Select]

Out.col.rgb = pow(Out.col.rgb*1.6+0.3,1.6)-0.14;

Code: (new) [Select]

Out.col.rgb = pow(Out.col.rgb*1.55+0.325,1.55)-0.155;

Code: (final (with darker textures)) [Select]

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

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

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

EDITED: New picture added/attached.

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

UPDATE: Finally pinned down a formula with round numbers. This version came to pass after I decided to favor black over white when converting the 5:5:5 PlayStation textures to 8:8:8 BMP files for working SOM's TXR tools. That's probably better practice, it just interacts oddly with SOM's colorkey system. (Like, 0,0,0 must be 8,8,8 or it is subject to colorkey. But 0,0,8 is fine. The sky needed to be pure blue to work. The added red and green corrupts the color. But for the sky it introduced banding; banding is always a finicky thing with sky models.)

Holey Moley · « **Reply #22 on:** November 05, 2018, 10:18:53 PM »

Good news... this color work stuff is finally over! But one more post

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

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

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

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

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

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

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

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

Code: (Detail) [Select]

;shader code (e.g. HLSL)
gamma_y = pow(y*1.5+0.5,1.5)-0.3525

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

The gamma_y code goes directly into the shader.

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

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

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

There's not much reason to post a comparison, since identical is identical. I may be posting something to the front page when I update the ZIP file next time. It's very exciting to see KF2 in SOM, looking just like the real deal.

Holey Moley · « **Reply #23 on:** November 06, 2018, 05:41:28 AM »

The piece de resistance

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

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

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

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

I came up with this:

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

Code: (Detail) [Select]

gamma_y_stage = 1
gamma_y = saturate(pow(y+0.5,1.5)-0.325)*1.5

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

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

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

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

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

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

I really had everything perfected

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

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

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

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

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

EDITED: So, looks like Intel doesn't implement a point-filter. I used the tex2lod instruction to fake it for this screenshot. And replaced it. I may try to make an extension for forcing a point minification filter.

Holey Moley · « **Reply #24 on:** November 07, 2018, 11:55:44 AM »

So this is not really progress, but it's something I found myself doing tonight, long into the night. It's definitely progress for SOM. I'm about to include it in a patch (http://www.swordofmoonlight.net/bbs2/index.php?topic=288.msg2658#msg2660)

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

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

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

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

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

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

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

It uses extensions to tweak a lot of things. It has the same opacity as the original's. The text is white instead of golden/textured. I think maybe it's more like KF3. I'm going to update the project file again before too long.

Holey Moley · « **Reply #25 on:** November 08, 2018, 06:21:37 AM »

Disclaimer: I posted this here (http://www.swordofmoonlight.com/bbs/index.php?topic=1129.msg13629#msg13629) first. Word for word.

Code: (UPDATED) [Select]

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

The four numbers are light values.

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

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

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

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

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

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

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

UPDATE: The light maxima wasn't bright enough after that change, so the final value had to be increased to 2, and so I realized the relationship between it and the first value, and ended up with 0.5 and 2.5 for the two values. This perfectly replicates the color of the terminal. What all of this shows is you can arrive at ALMOST the same place from many different combinations. What matters is I got there, whether I could've saved myself a lot of time approaching the problem more methodically than trial-and-error or not

Holey Moley · « **Reply #26 on:** November 14, 2018, 03:36:02 AM »

For SOM more generally I made some unexpected progress with using the point filter yesterday, that turns out, for more than one reason these neglected filter modes have been using mipmaps. And it also looks like SOM uses point mipmapping in all three modes... which took me by surprise. It could be wrong... but it does look like it sets it that way, but it might unset it also.

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

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

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

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

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

Ultimately I wasn't satisfied with using the character's name that way. It was an interesting idea though. I guess you never know what something will be like until it's on the page.

Holey Moley · « **Reply #27 on:** November 14, 2018, 04:13:32 PM »

I had a long day redoing the glass on these lamps, and setting up those eternal flames! I replaced the old image on the first page with this one, since it's easier on the eyes, having everything finished.

Holey Moley · « **Reply #28 on:** November 15, 2018, 07:26:30 AM »

I realized the lamp glass could be coaxed out of x2mdo because of how it works. I realized when I set up yesterdays screenshot that the glass was not right. I faked it by making it a little blue, but it still darkened the white plate inside, and the flame also, instead of lightening it.

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

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

Maybe it's appropriate, I guess the idea is the light from the flame is trapped by the glass, and so bounces around inside of it.

Holey Moley · « **Reply #29 on:** November 19, 2018, 12:46:36 AM »

This is the last of these, I swear!

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

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

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

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

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

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

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

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

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

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

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

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

Code: [Select]

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

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

EDITED: I had another horrid night fussing with the lights yet again, because of an effect on the south walls in the caves that I could not reproduce with the existing lights. Eventually I realized the ambient level needed to be higher (not lower) in order to do something else. I was able to reproduce that effect, but not without losing other lighting features in the process. I hope this means the ambient light level is determined to be within a slim margin of error of this setting. It's higher than I thought possible, so it's probably well confined. I will go ahead an repost the light positions as an attachment, to this post. And edit it into the other tomorrow. I will sleep better with a backup

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

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

STICKY: 2020 King's Field II port progress report