simple machines forum

Please login or register.

Login with username, password and session length
 

News:

Remember to make your own backup of posts before submitting.

 
 

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Holey Moley

Pages: 1 ... 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 ... 58
301
Beginner and other Nonsense / Re: STICKY: Random News
« on: June 13, 2020, 05:57:36 AM »
I haven't had an excuse to use this topic/thread in a while, but just for the record, today I found myself working on a new extension feature to add black masks around the game view, probably limited to full screen mode.

The rationale for it has to do with something called "back-light bleed" that isn't always visible on monitors but tends to be very visible on first person video games like anything that just kind of sticks to the screen when you move around.

I probably should've just figured out a way to augment the resolution (not being able to directly control the resolution menu is kind of anachronism to begin with) and use the black backing "window" to fill in the space, but instead so not disturb that I went ahead and used an existing system that originally was mainly only used to enlarge SOM's title screens that are stuck in 640 x 480 normally.

I think the system is used in dedicated full screen mode also but that's pretty well a thing of the past today.

One side effect of doing this way is the "function overlay" stuff can actually exist in the mask area. I will probably add an option to keep it out of the mask area too in case it's unwanted there. That is to say the mask area is actually part of the allocated resolution. Though by default it will be traded off with the black backing window margin.

My use case for it is the 1050 resolutions have 15 pixels on the top and bottom on a 1080 screen but my back light is still visible on the bottom half, so I notice it, and the next available resolution is 900, which sacrifices 180 pixels, which seems excessive. I could use a custom resolution in the INI file, but that's only temporary if you change resolutions, and it would be symmetrical, whereas my issue is on the bottom only.

With this system you can just tell it to make room for your crappy back-light. I wonder how many games support this kind of thing?

For the record it was a good amount of work to implement since it really pushes the existing system to its limits. I had to fix a lot of things that didn't work. And those are things that probably wouldn't have worked if you tried to actually use the old dedicated full screen mode today (which I don't recommend.)

302
Projects, demos, and games Information / Re: STICKY: 2020 King's Field II port progress report
« on: June 09, 2020, 06:40:40 PM »
EDITED: I meant to post this yesterday before the previous post, but my Internet died on me.

Quote
For the record, I've now published this new dimension the do_aa extension(s). I'm only penning this addendum to say I eventually saw the value in having the effect applied in the distance (mipmap) and so changed course to a anisotropy based filter, only to find that the X and Y dimensions seemed to be linked in a way that merely canceling the effect for anisotropic surfaces was inadequate, so that the X and Y had to be independent and that maybe anisotropy is inherently ambiguous if the UV map is running in the opposite direction...

So I ended up trying to reformulate in many ways until after about 5 attempts, I tried the simplest way, and realized that I'd done the wrong thing in the very beginning in fusing the derivatives to create an X, Y area, and the key to independence was to treat them separately, and after this anisotropic filtered samples no longer degraded, so the whole problem of canceling the effect disappeared.

What I find funny is of all of the several attempts I made, they all did a good job of antialiasing, but they had undesirable edge cases. So, there was a kind of "local minima" at every turn where things basically worked, which was very misleading, so I'm very glad I was forced to stick with it. If there had been one of the solutions that worked acceptably I would have likely have settled on it and never discovered the original flaw.

303
Projects, demos, and games Information / Re: STICKY: 2020 King's Field II port progress report
« on: June 09, 2020, 03:11:30 AM »
First, don't get your hopes up!!! this is a patch to the current demo at https://www.patreon.com/posts/23273769 which I'm preparing to share the do_aa effect. It just updates the SomEx.dll file, and adds new Ex.ini settings, and adds the volume effect to the water, and adds the gauges and compass elements, and changes the names of some items.

I'm still working on a new demo, but like it says, this is just a patch to the existing demo.

It also adds files for using a Nolo set for tracking with the PlayStation VR, but I used it yesterday, and as I recall the directional tracking feels far inferior to the PSVR's internal tracking, and I think I haven't yet worked on some kind of fusion to try to get the best of both. I did a VR session last night and I still sick the next night after. I hadn't done VR in probably 10 months, so all of the tolerance I'd built up while working on VR daily has been lost. The only takeaway I got was the color looks very good, which surprised me...

Oh yeah, two days ago I tweaked the color grading formula (not in a very intelligent way) to remove the smokiness from the PlayStation accurate formula. I probably should have done that a long time ago because I think the smokiness begins to play tricks on my eyes after a little while. So it's not healthy for me to work with the accurate color, and I think the new color is better, but just a shot in the dark. I'm sure there's probably better formulations, however there isn't a lot of wiggle room. By smokiness I just mean poor (low) contrast. That sounds odd because KF2 is incredibly colorful by game standards, but there's something about the color that's off, that gives the overall impression that the contrast is incorrect, and this could be because it's on a different style display from the original NTSC television standard. I matched it to the RetroArch Beetle emulator's color but I don't actually know its stance on the RGB output, that is if it outputs the exact same pixel values as the wires on the back of the PlayStation, or if it changes it to look pleasing. Of course I disabled all filter effects.

I don't know how much the recent changes to the do_aa system effected the PSVR experience, it's hard to say, but I didn't see them as a problem, which was the main reason I dawned the set, i.e. to verify it still looked acceptable under the new do_aa regime.

I may try to do a little more with VR because I noticed an unexpected effect with Nolo that when I turned by head the world seemed to zoom out a little bit, and I can't think of an explanation for this, so I think it might be a useful way to try to calibrate it, i.e. if I can make the effect go away then it probably means the result is a more sound system. That said, the funny thing about VR is effects can be purely in your brain, and they're always fuzzy, so you always feel like very paranoid if you can believe your eyes or not. This is because brains are so good at adapting (to visual stimuli) too good even.

304
Devs / Re: EXIT: Unleashing monsters
« on: June 09, 2020, 02:54:45 AM »
For the record, earlier today I uploaded a fix for the F4 flying thing that by changing it to work with the controller, I broke it working with the Alt key, and also, to repeat some edited into yesterday's announcement, I had to reupload because I put a debug mode build up the first time.

Edited: Crap, actually I didn't upload the F4 fix because rain had knocked out my Internet access, so I thought I did, and I couldn't upload until the next morning. I have to go out and trim some tree limbs around the satellite dish. I'm pretty sure it wouldn't have been as bad without those tree limbs in the way in way. I feel dumb making these updates since unlikely anyone downloaded it. The patch to my KFII demo yesterday should include the fix.

305
Devs / Re: EXIT: Unleashing monsters
« on: June 08, 2020, 07:07:49 AM »
CRITICAL PATCH

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip

This patch fixes a bug loading save files with the new system! That was fast :doh:

There was also a problem with showing the wrong file times in the save menus. I think it got introduced in one of these patches.

I'm planning to just keep adding patches to this release for a little while if nothing comes up.

There's a lot extra in this patch...

Just last minute I added an ability to use the controller to switch to vertical movement while flying with F4. I remember ensuring this didn't happen, but I'm not sure why. I know it's annoying if you're used to running with all three buttons down, but while flying you already move super fast, so you don't really need top speed run, and I may make it always top speed. To do it you just hold both attack buttons, which is how you do alt combos, but this was previously exempt. Note, "flying" is a developer/debug/cheat thing.

Mainly this patch "antialiases" cutout (colorkey) textures, which previously didn't get the full benefits of the do_aa extension. In these screens below the tree limbs and grass are getting this new effect. The second is a closeup on a single blade, although it looks better in person than in a screenshot.




The UI elements are also party to the effect, and speaking of that, there are two new Option extensions called "do_kf2" and "do_nwse" that enable a King's Field II style compass. The latter does so, whereas the former automatically enables the latter and also adds a KF2 style HP/MP display.

I'm more impressed by the compass than the display, which just uses the menu system, like KF2 does. But I wonder if there's a way to improve it, so it better complements the new compass. I think VR may require 3D menus, which is my first instinct on how to improve it.

To see the compass you'll have to SVN Update your data/menu folder to get the MDO and TXR file. Actually these displays are the first time I've added both menu and MDO elements to SOM. Slowly but surely I'm inching closer to more sexy extensions. I don't know why it's taken so long to get to model extensions, it just has. Ultimately it's not as high priority as it seems.

The compass is kind of cute. It tracks your movement in a lot of ways, not just to indicate where you're facing, but it acts like a little bobble head that's on your person. It doesn't really look up and down like in KF2 so that instead it stays readable. It's also angled down so it feels like you're looking up at it, which you are since it's on the the top edge of the screen.

The lettering on the compass is what inspired the new extension to do_aa. Technically I renamed the old extension to do_aa2, in a bit of an odd choice. It's relegated to being used to manually control effects, whereas the new do_aa automatically turns on its accessory effects that it requires to look nice, which includes do_aa2, do_smooth, and do_lap. Those all get packaged into do_aa now. But how this works is if you turn off do_aa they all remain on, so turning it on and off (weirdly) is what you might do to have everything except the new texture effect.

In theory these do_aa effects might be unpleasant for some, or not work with monitor settings or be incompatible with a monitor altogether. I haven't had enough feedback to know how many can use them happily. My monitor has a "Response Time" setting, which if I turn it on it makes motion in movies choppy (which is what it's for) and shows heavy black bands in games. So I'm thinking this option (it inserts black frames between real frames) is for people who see very differently from how I do. I think my eyes or brain are different in this regard.

EDITED: Ooh! I just spotted the compass in the second screenshot, so it's technically included. I wasn't going to include it. It's still early. Part of the problem it has right now is it's subject to the level's lighting. In Moratheia, and most games, it's not enough to light it properly. I have to add some extensions too to control its colors and opacity. In the final version (not seen here) I have colored each letter to be very white, but still technically different complementary colors. N is green, W is yellow/peach/tan color, and S is purple/pinkish, and E is bluish/greenish. There actually weren't more distinct hues than this. Luckily they bleed nicely into one another forming a kind of rainbow spectra, albeit not ROYGBIV. They are more like off-white.

Edited: For 2.5hrs I'd uploaded a debug build instead. I really doubt anyone downloaded, but just in case, maybe you will or won't see this.

306
Demos / Re: Moratheia
« on: June 08, 2020, 06:11:03 AM »
These are new screens I'm attaching in order to be able to link to elsewhere. They actually have a better version of "do_aa" than in the previous post because I inexplicably found out the very next day that the old effect was actually hobbled by not being shifted over by half a pixel (https://www.reddit.com/r/KingsField/comments/gtcp6t/more_good_news_for_sword_of_moonlight_visuals/) so I've reverted back to the old effect, and have added a complementary effect that works on the textures, which is what these images are really meant to showcase.



This new effect came about because I wanted to use cutouts (colorkey) for the letters on the King's Field II style 3D compass, however the text wasn't good enough, forcing me to consider options.

In these screens the trees and grasses are cutouts, except for the tree trunks, and the new sharper formulation is on display. The closeup on a single blade of grass is actually stronger than the final setting I went with, that had to be more conservative if it was going to be used in the menus. I think I will probably change the blit and/or sprite shaders to lessen the effect so it can be stronger. The idea just occurred to me.

I only just enabled it for UI elements today. You can see that in the screenshot too. I didn't want it to be visually detectable in the UI elements so I scaled it back. But these screens are already taken. You don't get the full effect in a screenshot anyway, and the texture effect as-is is less attractive in screenshots because I made it to spread over an equilateral triangle so that every side is as diagonal as possible.

I've written about it elsewhere already, and I'm about to publish a patch with links to these images. And I'm going to share them with a CMAA author who I've contacted to try to help me to replace the MLAA system with CMAA since it's so much better now. These are algorithms for converting the 1bit cutout mask to an antialiased mask. If I'm really lucky they may even take on this novel technique to give it a technical paper like they have for Intel.

307
Projects, demos, and games Information / Re: STICKY: 2020 King's Field II port progress report
« on: June 04, 2020, 07:28:50 PM »
I was in town yesterday but before that I got sucked into my world of computer watching the clock all the while, by the end of the day I found the time to further revise this new technique to claw back the lost fidelity in anisotropic filtered samples so that it wouldn't make things any more "smudgy" through its addition.

The modified effect is scaled by the square root of the UV derivative so that large deltas are less effected. Large deltas can occur for more than one reason, but anisotropic filtering is the desired reason. It applies to distance texture triangles, but I don't know if that's acceptable since by then you're down to smudgy, tiny mipmaps anyway. Another case is perhaps UV mappings that are highly distorted, which ideally artists should avoid. It could be further refined by determining how distorted the mapping is, which applies to anisotropic filtering, and might even be a better formulation than the current, that uses distance as a metric. It didn't occur to me to consider distortion until just a while ago. A benefit of using distortion is it would not penalize distant triangles, but perhaps it's right to do so too.

With this augmentation there is no visible strobe to speak of, which is good for stability sake. The new code takes into consideration the dimensions of the textures since smaller textures need to reach further to find their neighbor pixels. I first found good settings for 512 x 512 textures, and then tried to work out how to adjust it to smaller or larger textures. I wasn't certain how too, so I just tried different ways, and ultimately I think what I ended up with works since it demonstrates the desired characteristics without ill effect.

I also took this opportunity to play around with mipmaps more, specifically in the Moratheia demo I tried to improve the spindly grasses armed with this new technique, which in theory should benefit them. This is an intrinsically fraught problem because there always comes a point where the width of the blades of grass becomes thinner than a single pixel on screen and suddenly they just pop in or out of thin air.

I don't think there is a perfect solution to this problem short of playing around with completely models that work differently or trying to blend them together somehow. I'm resistant to add alpha channel textures to SOM mainly because I think it brings with it all manner of complications. What I did was to boost the alpha in the mipmaps so that the grass has more body, since mipmaps tend to blur alpha, which is bad for cutout scenarios since it tends to make the mipmaps disappear into thin air more so than the higher levels in the texture. I boosted the alpha by a fourth, and that is folded back into the lower level mipmaps. Then I boosted mipmap sampling bias by about a third. That delays mipmapping effects until triangles are further in the distance. It's normally undesirable but it's been a common solution for grasses. But in the recent past I've not felt it had good enough effects to justify it. I don't know if it's actually helping now, but I read yesterday that companies are doing this when they are using "temporal antialiasing" which do_aa kind of is, by a loose definition. It kind of fulfills the same purposes, and anyway, there is a basket of techniques working in unison that ought to be able to counteract the side effects in theory. It's a common feeling that unbiased mipmapping is more smudgy than it ought to be, and it's part of the reason SOM looks more smudgy than the PlayStation, so I felt scaling back on mipmapping might help with sharpness.

But I can't say definitively at this point if it's a wise trade off. The only thing I can say is that for once the grasses in Moratheia seem to retain their same size and density on approach. And up close thanks to this new effect their edges could not be more perfect.

In fact, I'm now wondering if it's time to try to find a better algorithm than MLAA to generate the cutouts. What I liked about Intel's MLAA is that I could easily implement it using their source code attached to their research paper. I don't understand why exactly, but there is virtually no public code available for taking a simple 1 bit black and white image and generating a grayscale antialiased image from it. That's all we really need. Not a basic kernel based AA algorithm but a perfect one that at least does its best to do what an art program would if it had created the black and white image out of primitives. I know it's possible to do a lot better than MLAA. All of the code I could find to do better were giant projects that were as big as SOM and no way to simply copy/paste and rework the code into SOM. That doesn't seem necessary to me. I even wonder if there is something like neural-network code for doing this kind of AA today. I think it is a complicated problem, but it seems also like there might be a simple algorithm for converting a mask to grayscale that's just under lock and key somewhere and just obscure enough to not be public. It's certainly not something that's easy to think about and program. It risks getting sucked into a proverbial rabbit hole to try to do it from scratch.

Speaking of which, I wonder if I'm making good progress on KFII or not. I worry all of these weeks devoted to seemingly minor little micro projects are going to ultimately prevent me from doing the basic work of just getting all of the game's elements in place. I want to think I can just knuckle down on that once everything is in order.

308
Projects, demos, and games Information / Re: STICKY: 2020 King's Field II port progress report
« on: June 03, 2020, 01:06:01 AM »
Before bed last night I had an idea to improve the new "do_aa2" effect especially because I worried it's too visible in the bright ceilings in KF2. I usually have ideas when waking up. The do_aa effect works in an abstract subpixel space that is invisible, however this new effect is visible in the texture UV space, so instead of doing it by slashing across the pixel I fitted an equilateral triangle as best as can be and used its corners for the effect. The fit is weird since it's very asymmetric and the X/Y bias is variable, but because the effect is geometric it benefits from a 3 point system. The center isn't in the center of the pixel, but it needs to move equal distances I suspect, which is why I chose the triangle, and most importantly in the do_aa system when going from 0.5 to -0.5 that's a big jump that is theoretically a source of strobe effects in the new technique.

As a result I can't see anything happening in the bright ceilings and I've turned the effect up as high as possible to get the best result even in the bright white compass.

Speaking of the compass, today I played with adding effects to it. The overshot effect in the game proved hard to do without writing a full on inertial simulation, mainly I think because the inputs are analog and even in a simulation they'd need to be more digital to get the same behavior.

As a result I settled on just doing the overshot effect when canceling fast turns where it seems appropriate. It wobbles back and forth a little, and I couldn't get the wobble out. Mainly because I had to exaggerate it to get any overshot at all to occur.

Beyond this I had first put in a simple delay so that it doesn't exactly follow your movement, which is how it is in the original game.

But then I took it a step forward and started to have the compass mimic some of your bodily movements. These effects aren't on a delay since they kind of represent the compass housing bobbing around instead of orienting itself internally.

I felt that it was too stiff to not do something like this. And I think it admirably does a good job of acting like a player character avatar that helps illustrate how your body is moving.

I programmed it to lean forward as if transferring momentum and this is counteracted by footsteps. When you hit the ground it acts like you're looking down unless you're moving fast enough forward then it looks in the opposite direction (as if looking upward) as if you're falling forward.

Lately I made it less sensitive to looking up and down so that in the middle region the lettering remains visible so it can be used as a compass. I tend to not look straight ahead when I play so this way I can still read it.

As for "do_aa2" I think my intention is to rename the current "do_aa" extension to this can change the do_aa behavior to act more like a basket of extensions. That way old config files will still work and it will be easier to set up. This new technique can be used without the others, but it's probably no recommended. So it's good to just have all of them flip on with one switch.

I'm going to remove the new "do_sharp" extension from a recent patch since it will be replaced by the new do_aa extension, and I will something like "aa_sharpness" or something to give better control. I had no idea the do_aa extension was about to get a lot better by accident when I made the patch.

309
Projects, demos, and games Information / Re: STICKY: 2020 King's Field II port progress report
« on: June 02, 2020, 03:04:45 AM »
This is a look at how the KF2 style displays are progressing.

This image also shows a promising new effect to help with the cutout (colorkey) effect since that doesn't really benefit from do_aa like the edges of triangles do.

I think this effect will be here to stay. It works similar to do_aa and it may be possible to see the pixels changing from frame to frame, but I think only because of the relatively extreme white in this compass.

The color is extreme because KF2 crushes whites since its textures are all in the middle ranges. I can't see the effect on the compass at all in regular color. The benefit of the effect is hard to see elsewhere.

When I first tried to model a compass I thought that I would not use a texture but would make the lettering out of triangles to minimize aliasing artifacts but I didn't realize how that would mess up the smoothness of the surface for lighting purposes.

After I took pains to model it with a texture I wasn't happy with the cutout effect. You can see that version on the left. I also wished that I'd used more triangles for the sphere, so I will probably go back and redo it no matter what.

But this inspired me to think about how to improve the cutout effect. This wasn't as forgiving as the do_aa effect, but one specific setting seems to be acceptable, at least for my eyes. But I don't think it can be adjusted.

The compass on the right is using the new effect, which I think will be called do_aa2. The reason to separate it is it's more likely I think to be objectionable. It looks better than in this screen in motion, but there's also a possibility that you can see it in motion and be annoyed by its alternating between frames.

The displays on the left are the same, except one is over the mountainside so you can see its transparency. I'm not attempting to replicate KF2's menus and gauges. I want to do something more generic to be useful for SOM projects and I think having modern text invites doing a more modern presentation. The whiter frames are to match the white text. I tried using duller text and decided against it.

The "do_aa2" effect works by shifting the texture map over. It doesn't do it uniformly however, although maybe it should. That requires more work since the GPU "shader" doesn't know the size of the texture, so instead I have it shift according to the derivative of the UVs from pixel to pixel, which is something that's possible to do for texture sampling. It shifts by 25% of the derivative in either direction, and that means the cutout threshold varies and so it be superimposed just like the do_aa system. In theory do_aa helps with that a little too, but it tends not to have an AA like effect. Instead the jaggies are just accentuated instead of blended.

Because of this shifting all textures for regular geometry are being shifted, and I'm not sure what the effect there is entirely, but I don't notice it. For comparison I added a patch to the bottom left corner that shows what the textures look like without the effect. They don't seem particularly more crisp to me. The effect for higher resolution textures is even less. I tend to think solving the cutout problem is more important.

I don't know if the new "do_sharp" extension is going to survive since I found out it wasn't really necessary in the first place, but for what it's worth it still looks alright with this new technique. It lessens its effect, but it doesn't flicker particularly.

Before I thought to try my hand at a new technique I'd decided that I would go back to doing the lettering with triangles and just add a per-pixel shader that just does spherical lighting to solve the problem I ran into. It might be an interesting option someday but for now I want to stick with the texture approach since it's easier to customize the texture and can work with any kind of MDO file in case you wanted to do a custom compass. The only downside is to make it work like KF2 it will need this new extension to look nice.

It could also be accomplished with a texture with an alpha channel, but those aren't officially supported yet, although there is an old system that can do it. It's possible color based blending would work too. I'll definitely have to try that as an alternative or if this new effect doesn't work out.

BTW: I couldn't find the compass model in KF2's files, but I don't know where its magic models are either, so I have to try to find them, and maybe it's wherever those are. I don't think it uses a 62 field-of-view like the game does because I found that looks extremely fish-eye on the compass and KF2's compass is actually very straight. It may even be an orthographic projection. If not I think it's probably low field-of-view or else it would require tricks of perspective on the level of Michelangelo.

BTW: Oh and too I meant to add a problem caused by the effect (like do_aa) is it can show seems in the texture even more than before, so it will require cleaning up SOM's original artwork even more and will keep artists on their toes. The reason being is it moves the UVs over a little so they can cross a seam.

EDITED: Something I worry about with these effects is that the brain can see them even if you don't know it and it's taxing the brain to NOT see them. The more you pile on the worse it may be, even though in theory it's a lot like film grain or interlacing.

EDITED: Also of note, this is the first time menu elements and MDO files have been displayed as part of "extension" work.

310
Devs / Re: EXIT: Unleashing monsters
« on: May 30, 2020, 11:51:31 AM »
MONUMENTAL PATCH

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip

I knew I felt something special about this release. I had an accidental breakthrough yesterday described below that unleashed the true power of the "do_aa" extension. I describe it in the post quoted below, over on Reddit.

The power basically doubled overnight and now the visual fidelity is perfection. It just happened to come at the same time as the new "do_sharp" extension, but there is no relationship. The old way without do_sharp (strikeout: "do_sharp" was subsequently patched out) is now also perfectly sharp, without objection, and you might even prefer it less sharp since it's by no means smudgy and there are reasons it might be superior.

This is actually a big deal and it couldn't have come at a better time (before publishing by KFII project) even though it's a funny story that it was 5 years working with an inferior effect.

It would've been 5 more years, or who knows how long, except for the scenario I relate that allowed me to discover the error that made the difference. And it's very strange now that SOM is unique in the world for having this technique at its disposal, since it works absolutely flawlessly.

Anyway, I encourage you to see for yourself. This patch updates the fix.

It also includes (for the record) an obscure fix for the script editor that could ruin your day. I think last time I worked on it I broke the "meta" message ("" msgid) that isn't normally edited, but it would fail to save/read your script (and give you a 0 sized file) if you do edit it, without this fix.

I wish that I could patent and communicate this technique to people, but alas I'm not really up to the task and nobody listens. I think I would have to go on a big quest, like try to speak at conferences, to even get anyone to listen. And the whole patent thing, while it could be a solid foundation for making money for SOM and art, I'm afraid I'm not up to it, and I tried to approach Khronos to patent it for hardware, and got the webmaster to send a few letters to the president, but I never received a reply.

Quote from: https://www.reddit.com/r/KingsField/comments/gtcp6t/more_good_news_for_sword_of_moonlight_visuals/
Many years ago while I was working on SOM trying to make a system that works on every computer with a GPU I wanted to have clean lines because I feel geometry is essential to King's Field style and it's my personal preference, I like computerized images, but I don't like pixelated artifacts, though sometimes they have their charms (https://twitter.com/cuddigan/status/1068230670097338368/photo/1)

I had pretty good images but they weren't good enough in the hardest cases, so I had a eureka moment that actually worked, like in 2015, and I think I made the first synthetic images that don't have "aliasing" in them. Technically the process graphics companies call "antialiasing" and have been in an arms race over forever is a post-process that steals a lot of power and compute time from your games, and so can't work on affordable systems, and is fundamentally flawed because it's trying to clean up a mess that ideally shouldn't exist in the first place, and you can't clean it up perfectly, since information is lost that can't be reconstructed.

I think I discovered/invented a novel way to make images that don't have aliasing in the first place, and I started with a germ of an idea, and kept massaging the techniques that feed into that technique until I produced a working system.

At the time I couldn't give away or popularize that idea, I tried, and I probably can't now either. I think the only way to make people listen is to produce a game with SOM that gains attention. People are just stupid, pigheaded, like that. It's why this technique (and many others I'm certain) are never discovered in the first place. Because this technique is no-cost (computationally) I'm certain that it could have been deployed on the PlayStation had it been discovered earlier. And the history of video games would've been very different.

Well, lately, I have been worrying because part of the basket of techniques I used produced a kind of smudgy half-tone image, and I'm working on converting KFII to SOM and this isn't consonant with the PlayStation's hard-edge style. So in the last week I started to think about how I could sharpen it, and I came up with a way, that was very simple.

But yesterday, just by happenstance, I was working on adding KF style onscreen elements to SOM, and so I was testing if they would survive destroying the device context, and you do that by changing the resolution in the Options. So I was just changing to the next resolution, and I ended up on a very weird resolution that is 1152 x 864.

This resolution had anomalies in the frames around the menu elements using the technique that eliminates aliasing. I spent the back-half of my day trying to understand why, and I finally determined it was because of the colorkey system that clips out black pixels, because it's all or nothing, at a threshold, and that threshold just happened to be crossed.

That made me to think about how the technique works, and I realized that it's actually very good for this colorkey system too, because it locks the 3D points (vertices) onto pixels, which should mean the threshold can't be arbitrarily crossed like this, and should improve (optimize) that. That made me to question if so, why on earth was this resolution doing this. And then I realized maybe it wasn't on the pixel center, all of these years.

So I shifted it over by half a pixel, which never occurred to me to do, I guess because I assumed it was already so, and it's more instructions in the GPU shader program.

But this fixed the problem with the 1152 x 864 mode, and I knew I was onto something. And it turned out the image after this was better than ever, and now even the half-tone smudgy image was super sharp. So, now the removal of aliasing seems absolutely perfect.

And an extremely sharp option I tried the other day that flickered no longer flickers, so there are three degrees of sharpness, starting with the original "smooth" mode, that's now very sharp, so no complaints about being smudgy, and there is sharper still using the new technique, and there is extra sharp using an unpublished experimental technique.

In short, the image quality doubled overnight because I'm just muddling through this shit, and made a slight error 5 years ago that halved the quality even though it was still very good. It was just dumb luck (or timely miracle) that this odd resolution setting revealed my mistake. It makes me even more to question how nobody has ever discovered this, since it works quite literally perfectly. There's no downside. It's just something everyone who claims to be committed to showstopping visuals overlooked because they're really just following each other's leads.

311
Devs / Re: EXIT: Unleashing monsters
« on: May 27, 2020, 06:43:27 PM »
CRITICAL PATCH

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip

I think this is last layer system patch dealing with SOM_MAP integrity (knock on wood) that corrects a problem with the base layer elevations so that some things on layers would end up at the wrong elevation.

I think this release is the first official release that layers actually work in. After patching some other things, like the "checkpoint" system of course.

What happened in this case is I used the line number in the file to fill out the base layer, but didn't realize the number was only incremented when the line-ending was present, so when the line was partially buffered it put them in the previous tile row. It's a wonder something like this wasn't immediately apparent, but such is the nature of all bugs.

I couldn't have seen it unless it had hit some of my tests, which I guess it didn't. It took me a long time working with a map with a lot of monsters on the second layer to notice it. But I've only been doing that since this release was published 10 days ago. I've been looking over every single monster to try to understand some data on the discs as it relates to them, and I think I only found one monster with this problem in the whole time. Anyway, I'm glad I did!

I remember thinking I was clever to change the code to use the line number, since it's a much simpler calculation, just for readability sake, and to remove the dependency on the map height/width, which is historically fixed to 100x100 but may not always be the case.

312
Devs / Re: EXIT: Every part of the controller
« on: May 27, 2020, 08:05:03 AM »
For the record, for future releases/patches yesterday for triggers I augmented the way to transition from running to crouching/squatting to require the trigger to be fully released  in order to avoid accidentally doing it just by trying to adjust your grip on the triggers.

I am not a fan of triggers, I wish that in order to add them to controllers we didn't have to sacrifice our digital buttons to the trigger gods. I've never once in my video game career used a trigger for anything since they were added to the PS3 generation controllers; nothing that a button isn't better suited to.

They make the jumping/squatting system unpredictable. I'm still occasionally making mistakes with them, but at least I'm aware of the problems. I pray at some point I can improve the experience somehow. In theory triggers offer more immediate, sensitive feedback that can be useful, and maybe even superior with enough innovation time.

I want to make SOM a permanent game system. You lose a lot in the ephemeral nature of games as product. Here today, gone tomorrow, in a sense you can never improve that way, or you're always pouring new foundations, and there is always a chance of back sliding.

313
Projects, demos, and games Information / Re: Modern ps1 games
« on: May 26, 2020, 03:58:04 PM »
Quote from: mosspunch on March 16, 2020, 08:44:26 PM
Projects like Back in 1995 and the Haunted PS1 Demo Disk.

I'm so self-absorbed I didn't notice these titles before. For the record I checked them out, but they're pretty emblematic of what I already had to say. It's definitely not what I'm doing in memorializing King's Field II.

314
Projects, demos, and games Information / Re: STICKY: 2020 King's Field II port progress report
« on: May 26, 2020, 03:40:49 PM »
I went nuts trying to improve on this formula.

Code: [Select]
gamma_n = normalize(pow(n,0.25)*float3(-1,sign(n.y)*0.4,-1))*1.5; Out.col.rgb-=0.25
It's the kind of thing that might never occur to someone making a game today, but the gist of it is the lighting on the monsters is pseudo-lighting that maybe helps to portray their character more than anything. You have to think of of the box to decide to throw out your established lighting scheme completely and just glue the highlights on.

Does that make KFII less than a modern 3D game? I don't know; it may be the soul of its charm. It may be something that catches on with SOM fans.

My new formula is design to capture the specific highlights on the headeaters. I'm skeptical it replicates what the game actually does, but I'm almost certain the game likely doesn't use the lighting coordinates in the model data by itself. To make pleasing pseudo-lighting you need I think to round off the sharp edges, it needs to feel evocative yet innocuous. I wonder if the NPC characters do this too, it could be key to how they come across as so organic if so. I know the secret doors at least must be lit accordingly or else you'd be able to see them, and I would have noticed if the treasure chests weren't so lit, but I might have not noticed the doors.

Honestly, I never really noticed the lighting was fake, and I never really noticed before the environment was lit either. I think it shows how subtle KF2 is. It's subliminal.

I'm warming up to the motto that graphics are for stupids. I think graphics is the path of least resistance in video games, and focusing on graphics is really a way to divert your attention from real difficult subjects. I think if you go in for graphics that you should at least be honest with yourself.

After spending so much time at it I think the krackens must have some setting that makes them darker than they'd otherwise be. I half remember StolenBattenberg reporting that they found a byte in the game that darkened and lightened them.

In the screenshot in the earlier post the kracken is darker, but after I applied myself more and more they became lighter again. I even cheated in that "gamma_n" extension by modifying the ambient light level because I know it must be darker for the headeater than for the map geometry and other elements, and I don't believe they're darkened.

I think the monsters likely just have a wholly different light scheme, but the trick I'm using for the time being makes use of the existing light scheme. Since the lighting is symmetrical it's possible to pick a direction in the lighting to look for that seems to work. It doesn't even have to be upright, and I did that by skewing the lighting away from the vertical direction because that's where it's harshest. You'll notice the ceilings are very bright, the lighting is basically pointing up like holding a flashlight under your face.

Something else I've noticed is there aren't any light sources in most of Melanat. I don't know if its subplot about being stuck in night relates to that reality, or if it's just an oversight. Maybe in a magic world light isn't an issue...

But I wonder what that will mean for my other project to resurrect King's Field, since I have a feeling I won't be able to get away with that luxury. I think how to approach the problem will likely lean on a new system to simulate how eyes adapt to low light levels, and also casting a magical "field" will provide some light. But there will have to be more light sources in a new Melanat. Maybe part of the magic system will be making light sources. It's a tricky subject. Since KFII is Aleph's story my plan (wrong project thread I know) is for Aleph to only have Wind magic, and the rest of his magic will have to come from weapons or items. Earth magic will be present in all of the games because the healing items will all work by casting an Earth field, and that's how you heal yourself. Dias has Earth magic, which is most associated with "necromancy" and may relate to the "monks" patrolling Melanat, who I imagine are undead soldiers taken from the soldier graveyard area of Melanat. Even though we won't call Dias "Necron", it's not far off. But that's not this project. The Wind magic will make green "ghost" light. There aren't really ghosts in the new series. It will have "monsters" that means plant-based creatures born of the Dragon Tree, that mimic life. But also "elementals" are a separate kind of entity, and ghosts are really elementals that animate material things. So, technically the undead army aren't people at all, they are just Earth elementals that animate things like old dry bones or even long dead soldiers. The Earth magic can even put flesh back on their bones.

315
Demos / Re: Moratheia
« on: May 26, 2020, 03:03:49 PM »
Here's an old/new shot from the "Moratheia 2.1" demo. I think this is my favorite shot in a SOM game so far. It's very cinematic/photogenic. I usually criticize Ben's game for being too dark, because I can't see it on my monitor, but I don't know if he's intentionally aiming for these kinds of deep dark scenes or if it's just by accident this scene turns out this way. It's the first house you're likely to visit in this demo.

I'm resharing it to show off a new do_sharp effect, that adds a degree of hitherto unseen sharpness that rivals commercial games that use oppressive image-based antialiasing techniques (that kill your frame rate and won't work on budget systems.) The effect is lost more to still images than the old one. The full effect must be seen in motion.

The new technique is stupidly simple, it just replaces one of the halftone images with an unfiltered image. That's why you see halos that can be up to two pixels. But in motion they are changing every frame and your eye blends them together so you don't seem them as halos.

It looks good enough in game to be worth ditching the old double half-tone image that was too blurry. You can see it in some of the screenshots here, except many of them are dithered shots. I used to really like the dithered/stippled effect, but the new effects have come a long way, and I haven't been able to use the dither/stipple effects personally for a long time because my recent monitors are too fat in the pixel dept. Dither only looks good if you can't discern individual pixels from a distance. The market for monitors has plummeted until there are only like two bare bones monitors at the stores. Samsung doesn't even make monitors that you can plug in and configure two separate inputs for. It's weird how we are going backward with the march of time.

Edited: For the record I haven't heard from Moratheia's author in a very long time, or what seems like a long time to me anyway. He actually made a post in here a while back, in this sub-board, but he didn't hang around after, which is pretty ****ing typical of him.

Update: For the record, by crazy coincidence I overturned this effect the very next day, so this reply/image is not representative of anything. There was nothing wrong with it, but it turned out the problem it was meant to solve never should have existed. See the next reply for details.

Pages: 1 ... 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 ... 58