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

Holey Moley · « **Reply #105 on:** October 29, 2020, 10:00:50 PM »

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

Holey Moley · « **Reply #106 on:** November 01, 2020, 12:18:05 AM »

I've uploaded http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip and supporting files. I'm going to write a blog post for the demo and new release. It's not happening tonight though, and I'm not sure I'll be up to it by tomorrow either.

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

*Whether or not "me and King's Field" is ideal grammar my intention is to put the emphasis on myself

Holey Moley · « **Reply #107 on:** January 06, 2021, 06:22:35 AM »

In the past 2 days I've been obsessing over the spear trap and one of the trap doors that have bad cracks sometimes that give them away. It's been making me very unhappy. I also noticed the itch.io demo doesn't apply the scaling extensions to the second arm with the Bastard Sword item. I missed a debug check for holding off on experimental tests.

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

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

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

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

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

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

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

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

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

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

I think I should do a test with a MDO model to see if it has issues. It may be time to work on using MDO in place of MDL for display purposes. If so that would mean the culprit is likely either its fixed precision (not all coordinates fall on a millimeter but I think the cuts x2msm makes do) or scale matrix.

Holey Moley · « **Reply #108 on:** January 07, 2021, 09:00:04 AM »

For the record, I tripled down on this today. I woke up with an idea that I'd overlooked something but it didn't pan out, so I started the day feeling like reality had kicked my butt. So I kicked back. I convinced myself the numbers were exact and even reproduced the artifacts with nothing but map tiles.

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

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

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

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

Edited: BTW speaking of do_aa I think it used to have issues with my Samsung monitors' "response time" setting. Now it seems to not be an issue. I don't know if that was the change I made for sharpness or the sRGB extension, but it's a good development that players don't have to adjust their damn monitors. Also I guess it feels good that I was able to determine do_aa wasn't the issue with this depth buffer artifact problem.

Holey Moley · « **Reply #109 on:** January 21, 2021, 08:56:54 PM »

Today I added headeaters sounds that vary pitch based on their size (which KF2 does) and recently have added lateral movement. I actually can't tell if KF2 really has lateral movement or if monsters are just rubbing against invisible barriers. It's really hard to reason about how KF2 behaves. It seems random.

I think I want to add the rest of the sounds ASAP.

Holey Moley · « **Reply #110 on:** January 23, 2021, 10:31:53 PM »

Three monsters down so far. Tomorrow I think I'm going to try to find a new mipmap generation filter. The cave texture still turns into a kind of white fog in the distance, which runs counter to the black fog. It doesn't look sufficiently like the emulator.

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

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

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

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

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

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

I've set up a trick system for slimes so they can move without rotating. To do it I let them move normally but don't assign their rotation to their model data structure. Right now I'm using the #3 slot in the new turn table system for this, but I feel like it's probably not a long term way to mark the behavior, but I don't know yet. #3 shares the #1 slot since it's fused together for diagonal movement, so it doesn't need its own. I just feel like it's too obscure to be used for this purpose.

Holey Moley · « **Reply #111 on:** January 26, 2021, 03:01:53 PM »

Today I'm going to finally break ground on that mipmap project. It's hard to find good information on the subject but there does seem to be a general consensus that it's helpful, or can be.

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

EDITED: Specifically the build_mipmaps_wide routine with the Kaiser filter.

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

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

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

EDITED: I should note that this effort to achieve high fidelity isn't for its own sake, it's to try to approximate what the PlayStation looks like completely unfiltered. Ironically it takes extreme high fidelity to replicate extreme low fidelity with high fidelity.

Holey Moley · « **Reply #112 on:** January 27, 2021, 08:45:54 PM »

Man I had a pretty bad time with this. The programming went alright, and I thought it would be a good opportunity to experiment with different parameters, but everything I tried essentially is indistinguishable from regular mipmaps.

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

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

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

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

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

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

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

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

P.S. Oh well, maybe this other code will come in handy one day.

Holey Moley · « **Reply #113 on:** March 10, 2021, 09:57:16 AM »

Here are some images of KF2 with the Iron Gloves worn on the arms that appear when fighting. I swear I spent upwards of 8hrs editing the arm version of the gloves. I honestly don't know why it takes that long to adjust a 3D model. Time just seems to melt away in 3D modeling. I don't know if that's normal. It may just be a labor intensive activity. Rebuilding meshes can be difficult.

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

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

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

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

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

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

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

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

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

Strikeout: Day 2 I realized I was being stupid yesterday because it doesn't make sense to push the shield to the left if the centering is supposed to represent twisting shoulders. And it even makes sense to put the shield shoulder further out as if leading with the shield... I'm going to edit a new idea I had into a new reply post...

Holey Moley · « **Reply #114 on:** March 10, 2021, 11:06:32 PM »

EDITED: I think I made a mistake yesterday. I've realized two things: 1) the idea about centering was wrong about the shield position... it should have been moved toward the center of the screen instead of away... which might actually pose some problems because the shield is already on the opposite side of the screen. I will have to give it thought. I think it looks better slightly on the opposite side, but not too far so... 2) in the new two arm skeleton the main shoulder actually isn't the root node... this means it's possible to animate the shoulders. I keep forgetting that...

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

So now I'm thinking the animations should move the shoulders, but not lunge, and when there's a shield and a weapon on screen it will need to compensate by treating the shoulders like a soft seesaw so which arm is in the foreground will trade places giving priority to the weapon arm.

Holey Moley · « **Reply #115 on:** April 08, 2021, 05:37:44 AM »

Here (pictured) are a couple imports from King's Field III. There's a nonzero chance both of these guys will appear in this project. The Exselector may appear in the system menu. It won't be so odd because it will be technically distinct from the game itself, like a modern day game system's menu. I'm trying to adapt Aleph's model into a VR avatar (in game body double) and use him in place of the original arms, because I don't think they will fly. That said I don't intend to include Aleph's coat here. I'm not really sure what to do about clothing. I will probably use this get up until I have an idea for an original outfit, and eventually provide both options if not more. I can't not include the KFIII outfit (it honestly looks like head-to-toe denim) for old-time-sake.

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

EDITED: I've attached the 3D model files... Aleph's for this (https://www.reddit.com/r/KingsField/comments/mmnlcd/calling_artistsdesigners_reddit_contest_to_design/) contest to design clothing for Aleph to wear for this King's Field II project.

Holey Moley · « **Reply #116 on:** April 11, 2021, 04:30:38 AM »

So this (pictured) is what I've been wasting the past couple days doing. I sometimes doubt the wisdom of my choices of activities. When I got this model into Blender I couldn't figure out what to do next. I don't do a lot of 3D modeling, and it's been years since I modeled something from scratch.

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

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

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

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

Edited: Just a fun fact. That asymmetry below his belt is because there's a strip of polygons that was clearly meant to be a second strap for his sword to hang on. In the final model it was textured over instead, but the polygons weren't removed. In this image it's stretched out like everything else. Maybe I should have pulled it up around his belt instead. FWIW this MM3D software doesn't have great facilities for working with vertex weights. It's something that needs attention.

Holey Moley · « **Reply #117 on:** May 28, 2021, 05:04:55 PM »

In the past couple days I had some success with VR stuff: 2) in reverse order, I got 2.25x supersampling (1.5 times each dimension resolution wise) to make a nice looking picture (attached, left eye only) by adjusting the mipmap sample point down to 50%. I could write a long post about my thoughts on this but I'm going to assume anyone reading this just wants to hear the news and not the technical breakdown. (In the picture notice that the lettering is smooth, especially on the diagonals on M. I assume if they're smooth the rest must appear smooth too.)

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

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

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

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

Anyway, the main story here is the supersampling, since that makes it actually look better. But it's good to get the frame rate down further to eventually be able to use a PSVR with very inexpensive computers. And hopefully once I get my new computer set up with a new high end head set I can just keep the PSVR plugged into this smaller computer. Actually my current computer is like cube that fits in the palm of your hand...whereas my new computer is enormous: https://www.amazon.com/Empowered-Grandia-GeForce-Workstation-Computer/dp/B08MQM8TXP/ref=sr_1_3 (NOTE: I paid well south of $1000 for mine, most of the price on that is inflated for the RTX graphics card, which I was able to swap out for a Vega APU. I'd like an RTX card for it but they're only supposed to cost $600 except you can't buy them for less than twice or thrice the MSRP right now because of demand for transistors. I'm thinking about going ahead and getting a head set since I think maybe the APU can handle it for SOM except I'm kind of bummed that VR controllers don't have enough index finger buttons to play SOM games, so I don't like the idea of buying controllers I'll likely never use... I like the announced PS5 VR controllers, but I think they won't come out until a head set appears which seems unlikely to happen anytime soon.)

Holey Moley · « **Reply #118 on:** June 04, 2021, 02:41:24 PM »

Edited: Before I kind of meant to say (I did in an early draft) that the reason I didn't try "50%" before was I'd tried 0% and it looked splotchy, and "75%" looked splotchy too, so I didn't think anything in between would help it. But I found out today working on this (http://www.swordofmoonlight.net/bbs2/index.php?topic=316.msg3177#msg3177) that "0%" actually looked fine, it was just switching to a different sampling mode in the shader (since 0 disables it) and that mode was the new contrast reduction sampling mode that shouldn't had been used with the PSVR. (Although at some point I may try to set that up. I'd need to actually spend some time on it with the PSVR.)

Also of note is that link improves this VR mode a lot more, so it's kind of on-topic. I came back here to retract that 0% claim but found I didn't mention it in the post like I thought I had.

Holey Moley · « **Reply #119 on:** January 06, 2022, 02:43:57 AM »

2022 translation note

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

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

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

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

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

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

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

Edited: [1] I just noticed now (same day) on this (http://en.swordofmoonlight.org/wiki/King%27s_Field_II/list_of_in_game_bios) page Dias's surname is given as Bagil. But I checked the Japanese, and it seems I was correct to say Basil. Just for the record.

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

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

STICKY: 2020 King's Field II port progress report