Topic: EXIT: 25th Anniversary Project (Read 22807 times)

Holey Moley · « **Reply #15 on:** February 03, 2021, 12:55:59 AM »

Patch (2)

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

I noticed jumping sideways was badly affected by the change I made to improve drifting after circling, so this patch tries to claw that back.

I've also disabled the new gaits system for walking (not turning) because it's a bit floaty, especially after jumping, so I have to make time to reevaluate it. I think it is a better experience but walking has never been an issue before. (Don't fix it if it's not broken.) You just don't notice it like turning. Plus the turning system is nonlinear and so goes very very slow to very fast.

Holey Moley · « **Reply #16 on:** February 04, 2021, 08:54:45 AM »

Patch (3)

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

Today I found a major glitch in the new AA effect. It was a good find because the code came from VR code. Fixing it may help with some bad vibes I was getting from VR that turned me off or made me feel something was wrong. I wrote about it in the thread/topic about the AA effect. I've also expressed some doubts, but I'm trying to keep a positive attitude about it so I don't go into a spiral of despair

I've tried to reevaluate the effect after finding/correcting the glitch. ~~Also I think lately some bad frame rate timing (spasms) crept into recent releases/patches, that hopefully this patch will eliminate.~~

Strikeout: Nope, it's choppy without the change I made too... I guess I prefer spasms in the meantime (reuploaded 30min later)

P.S. I really love how great the control system has become. But I swear tomorrow I'm moving onto something new for a while. Something to add to and complement the budding control system.

Holey Moley · « **Reply #17 on:** February 05, 2021, 06:01:45 AM »

SVN Update (minor)

FWIW I've bumped the Sompaste.dll component up to 1.0.2.6 in order to add Windows/DOS "glob" pattern matching (FindFirstFile family) to its SET file parser.

This makes managing temporary SET files easier for projects in development. I probably need to give this area more thought. Especially for PRT files I can see having to edit each one into a SET file just to include them in the project would be a chore. Which is why I had to add this ability.

The only reason I set up sets at this stage is I'm adding some pseudo PRF files to a DATA/MY/ARM folder to do initial experiments for new arm facilities, and they get picked up as item profiles in SOM_PRM. I didn't want that so I made a meta.set file for them, but I (http://en.swordofmoonlight.org/wiki/SOM_file/list_of_environment_variables#DATASET) haven't provided a way to do a true blacklist style DATASET set at this time, so I actually just need to not include them. But to do that I needed to be able to (somehow) include everything else in my project, and around the time I got to PRT files I knew I needed to find a better way, and adding wildcards was obvious.

P.S. As a reminder, TOOL/SetComp.exe can generate SET files by dropping a directory on it. It's not very user-friendly in that regard, but you just have to make a temp directory and copy/paste the PRF/PRT files you want in your set into it. Then you can start using sets and categorizing your profiles.

Holey Moley · « **Reply #18 on:** February 06, 2021, 04:55:58 AM »

Patch + SVN Update

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

Today I changed the TXR colorkey to 0,0,0 for everything except SOM_MAP. I think the main thing that had held back this change was being able to distinguish between MDL and MDO textures in the player. I realized that was no longer an issue and the various bad TXR files would need to be fixed either way, and possibly they're not even bad with this change. (So this may fix them en masse, fingers crossed.)

I've spent some time doctoring the two magic circle objects since my reason for making this change is to provide a way to use color based blending (similar to having a full alpha channel) without the cutout effect interfering with soft images.

To do that (although this is probably not strictly necessary) what you want to do is create a 1 pixel wide buffer around your image and set those pixels equal to 1,1,1 (as black as possible) and set the rest to 0,0,0. This will probably be completely invisible, and it will push the cutout system out to this 1px fringe so you can't see it.

Before making this change (historically) the darkest black was 8,8,8 and although I haven't tested it, my guess is that would've been too visible.

Every since I added a much improved cutout effect (it's still possible to improve it a lot but I haven't been able to find better mask antialiasing code) these magic circle objects got the raw end of the deal. But honestly they're much too low resolution, so they look pretty crummy either way, so I didn't consider it a major loss at the time.

Sometimes flames looks better cutout. KFII's flames look better without the cutout, at least if I don't edit them.

Holey Moley · « **Reply #19 on:** February 09, 2021, 09:28:47 AM »

Improvement Patch

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

I could only work a half day today so I set about to try to enable the better gait smoothing code for directional movement and in the process I was able to solve some other things.

One big surprise that makes me feel dumber than usual is I realized the problem with the turning drift effect was really that the movement drift affect needed to track with turning. This is like your momentum transfers as you turn because of friction. I'm really surprised it took me like 10 years to realize this. It helps a lot with the bad feeling I was getting fighting monsters.

It still behaves the old way when jumping or falling, i.e. not having a footing. I think the way I was trying solve the problem wouldn't even work. I began to realize that it was just matching the angular and linear momentum but the direction was still incorrect.

I may have found the "wobble" I've been posting about. A while back I noticed when turning in one direction (or holding down the look/up down input) my code would still turn in the other direction even with no input. So I tried to make a change to fix that. I think I've found a better way to fix it. And the other way had issues as I suspected it might. I just forgot about it. It's really hard to implement joint rotation because you have to snap it when you get down to a certain point, but if you snap just one of one or more dependent axes it can feel like someone's grabbing the steering wheel. In my system there's some auto-centering logic but the stiffness for it in the middle is 0 so it offers no resistance in the beginning. The problem is the system is quantized so anything below 1 (which is also the dead-zone threshold) is 0 and so by right has/had no power to pull it in until the snap kicks in, which is suppressed while the other axis is engaged. Thinking aloud this makes me think I should at least try to tie the axes together with respect to this figure. (To see if it's an improvement.) Although what stiffness I can detect in the PS4 controller doesn't feel like this.

EDITED: There's also some code that suppresses the texture AA effect when the the screen is moving. It removes what can be pretty serious/unpleasant strobe patterns that can occur on bright, high contrast surfaces. (Edited: Right now it doesn't kick in for the the bounce and ducking effects. I'll have to reorganize it.)

Holey Moley · « **Reply #20 on:** February 10, 2021, 10:37:30 AM »

A Feature Patch (mainly)

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

There's now (finally) some code to limit event/object activation to 1 meter above/below the PC's feet/height.

This is for layers mainly, although keeping monsters at bay is not so simple unless their ability to recognize the PC across elevations would be hampered. I still have to do a major round of work on this area.

I also noticed a problem with money pickup. Its timing was broken, too fast, but also it was switching to a new alternative subtitle height for crouch pickups. Since it would take a lot of work to treat it differently I've adjusted its timing so the subtitle appears as soon as possible after the crouch height kicks in. So its timing is the same crouching or not for now. On the plus side, I don't think crouching to pickup money had ever worked before. (Edited: I think I need to work on delaying item/event activation now, finally.)

Elsewhere today I announced a fix for NPC title animations WRT the new 60 fps system. And (no one cares) the new smaller VR menu is fixed for aspect ratios different from the PlayStation VR set's.

P.S. Except for the money glitch/fix these were all ideas that came to me as I was coming to (waking up) today. I'm impressed I was able to cover them all in one day (and I do a lot with NpcEdit too.)

Holey Moley · « **Reply #21 on:** February 12, 2021, 11:46:19 AM »

Improvement Patch?

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

This patch switches over to a fixed frame rate. I don't know if it's best for everyone, but it certainly helps my system. I think Windows is just an unstable environment for games. But it could depend on hardware. I really don't think there's anything SOM can do to help this.

What I was using until now (since recently really) is average time over 20 or 30 frames. Not doing this caused smoothness to tank. Lately I've been having bad feedback in the control system intermittently and I took it to be frame rate irregularities most likely.

Edited: Note, my main motivation was to determine if the new much improved gait system had math issues or if the troubles with it lied elsewhere. So far it seems the frame rate mainly was at issue, which at least for the gait system is good news.

What I tried today was to fix the frame rate to the closest standard frame rate. That seemed to remove it, although it changes the experience a little bit. Ultimately I decided to defer to the display adapter's reported frame rate where available.

I also added a [Window] extension called "seconds_per_frame" (not fps since this doesn't change the frame rate) that sets the length of the fixed time step. It's not really meant to be used normally, but it can speed up and slow down the game effectively by covering more time. It can be used to speed up the game like people usually play KF2 on emulator.

But what I wanted to see was if the control system held up at different time steps. It's a little hard to judge because it's unnatural to play in slow-motion or sped up speed, but it doesn't appear to have any issues. It seems that the problems arise due to irregular timing. In that case they're probably purely down to human perception and not really errors.

I think this will be the best experience when hiccups occur, but more importantly it seems to eliminate turbulence from the control system. It seems to make jumping last longer or be more full. I might even reduce the jump height. I'm also thinking of reducing the do_lap extension when turning to see if it can make it a little less blurry. (In theory giving more weight to the more recent frame would give the blur some directionality, more like afterimages probably are IRL. Unfortunately this would degrade the do_aa effect. I wonder if the new contrast detection system can help to reason about if things are moving, then give a slight weight to the current frame if so. In that case the do_aa effect can't do its magic anyway, but I don't know if every pixel having a different weight would be odd or if small weights would be noticeable. It's possible even a slight weight could aid the brain to isolate the real image. Edited: in the debug mode build I can hit the grave/tilde key to turn off the effects pass. In that case the blur is not majorly reduced, so I think the improvement will be nice but not night and day.)

Holey Moley · « **Reply #22 on:** February 14, 2021, 02:05:04 PM »

Patch (SOM_PRM profile update misbehavior)

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

This patch fixes a long standing SOM_PRM misbehavior so PRF files can be edited while using it and and shared profiles can be updated at all.

Also there's a fix for a glitch related to the new gauge hit effect that got stuck if hit while jogging.

I'm trying not to make a patch for everything I do lately but this is a bug I want to write something to let people know it's solved. Note, more than once I've had my profiles get all mismatched. Whatever that is I don't believe it's solved by this.

Holey Moley · « **Reply #23 on:** February 20, 2021, 11:10:57 AM »

Patch (same link as above)

There's a new supersampling mode in this patch that's entered by pressing F1 or Alt+F1. It takes a toll on your PC so if it makes the frame rate irregular (feel bad) you have to decide if you'd rather reduce the resolution or switch out. I recommend it over widescreen if you have to choose. Also, you can ignore the "Anisotropy" feature in this mode because I've made it to always use 4x for the time being. This helps it perform better and I can't personally see any difference when I increase it.

This is an official style announcement, I've already written about this everywhere. But I have since updated the DLL with a fix for some menu text layouts, mainly in weapon damage rating text.

Holey Moley · « **Reply #24 on:** February 21, 2021, 03:20:05 PM »

Important Improvement Patch

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

Since working on the supersampling feature (F1 or Alt+F1) I've been trying to work lumps out of the movement system. This also started with the edge "defocusing" technique a little while ago. Today I tried to get a handle on the frame rate and I've been able to come up with a much better FPS readout on the F5 overlay, and rule out frame rate in the lumpiness dept.

The main remaining source of it I found was actually in the change I made to rotate the linear momentum when turning. Luckily what helps with it was to remove some ratcheting logic from the drift system ("pedals") gaits. The ratchet keeps them from bouncing between gaits but with this change it's much better without it and I really don't want to give up that change. I'm hoping the new much smoother gait transitions (gear shifting) will make any bouncing go unnoticed.

There's still some jerkiness if you quickly change from circling one way to the other but this is actually how it's supposed to behave, but I think in this case it's not ideal, but to solve it will take some special logic later.

Holey Moley · « **Reply #25 on:** February 28, 2021, 11:39:33 AM »

Last patch for a while

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

I uploaded a patch yesterday because the code was at a stable place and I expect to be venturing into unstable territory for the next so many days, or weeks perhaps...

It has new code that draws the arm animation before everything else. This helps to keep performance more even when the arm/arms is/are taking up a lot of pixels on screen.

I recall fixing some timing code for subtitles, and (I'm sure there are other fixes) one odd change worth mentioning somewhere is the hop input won't any longer force you to stand up, so it's possible to hop mid squatting while remaining squatting. But it does stand up if you fall further than a jump height, so it only works (currently) on level ground.

P.S. I think I'm going to start playing with this (https://github.com/jibbsmart/JoyShockLibrary) library to add advanced features for Sony's PS4 and PS5 controllers (maybe Nintendo Switch can work too) shortly. My main plan for the accelerometer is to use it to lean over while standing still and look behind your self, like a rear-view glance. I will see about other uses when moving or attacking later. Since leaning forward and backward doesn't seem incredibly useful I will see about possibly making it an alternative way to look up and down instead. This is among the things I saw myself doing at the beginning of the new year.

Holey Moley · « **Reply #26 on:** March 02, 2021, 12:08:28 AM »

EDITED: DualSense (PS5) Patch

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

This just detects a PS5 controller. It behaves identically to the PS4 controller but it has a different device ID so wasn't previously supported (BTW I got a DualSense and am looking at adding support for advanced PS4/PS5 controller features the XInput (XBox) system doesn't have analogues for.)

Holey Moley · « **Reply #27 on:** March 03, 2021, 10:04:24 PM »

Important Fix Patch

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

Somehow about half the resolutions were "cursed" by the change I made how the effects depth buffer is cleared (reset) to try to get a little bit better performance.

I still don't quite understand it, but only my KF2 project seemed to be affected, and the solution is when the "render target" changes it automatically resets the "view port" so it just needed to save/restore the view port. It looked just like the buffer wasn't getting cleared (water would disappear for one thing, sometime a pure black screen--yikes) but there must be another explanation.

Anyway this fixes it, and I hope no one had this bad experience with my demo in the past so many days since that change. The weirdest thing is it only hit some screen resolution settings, which makes absolutely no sense.

Holey Moley · « **Reply #28 on:** March 06, 2021, 10:49:15 PM »

EDITED: Just for anyone getting notifications every time I reupload my KF2 demo there's a new patch that addresses a glitch where the menus showed the arm/weapon model incorrectly and a fix for unmuting the Master Volume at full volume (16) which wasn't working, and... also using F12 to manage the volume (with ctrl/shift) now repeats when held down (the R3 button is mapped to F12). Note, you can just press +/- on the keyboard.

(The glitch was caused by a recent change to "draw" the arms first so any pixels behind it can be skipped to reduce performance hiccups as a result of a large increase in pixels when your giant arms cover the whole screen.)

Holey Moley · « **Reply #29 on:** March 14, 2021, 11:14:16 AM »

Final 1.2.3.4 Patch

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

I've decided to finally retire this version (1.2.3.4) with this patch that (1) fixes the afterimages in the arm animation that I broke in recent patches (they were drawn on top of each other) and (2) fixes phantom pause that can happen when the program in "minimized" causing the game to keep playing and using potentially high CPU/GPU resources.

I'm planning to write a blog about the recent round of developments that culminated in the new supersampling mode and in its topic/thread I'm to float an odd numbered demo version 1.2.3.5 which will include important patches and tests of the new shield system as it's mid development. Odd numbered versions aren't available to the updater menu.

This was a very fun version but a hodgepodge of patches too. It's linked to my KF2 project's initial demo and happened to be "1-2-3-4" so I've stuck with it longer than I should, especially since my work has been unfocused here lately. I've got a lot of unfinished efforts underway. I've no particular goal in mind. I think the new "arm" enhancements is a good thing to structure a release around, but it's going to be a slow build to releasing it.

simple machines forum

News:

Sword of Moonlight|

Devs|

EXIT: 25th Anniversary Project

Author Topic: EXIT: 25th Anniversary Project (Read 22807 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| Devs| EXIT: 25th Anniversary Project

Author Topic: EXIT: 25th Anniversary Project (Read 22807 times)

Sword of Moonlight|

Devs|

EXIT: 25th Anniversary Project