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.

 
 
Pages: [1] 2 3 4 5 6 7 8 9 10
 1 
 on: Today at 07:43:17 AM 
Started by Holy Diver - Last post by Holy Diver
I've not been having a great time. I did get the jumping problem straightened out pretty easily. I've been trying to get so many things in order. Tweaking everything. When I start doing that you I find more and more little glitches in the control system.

The last thing was a real nightmare that I didn't expect to work out well. I noticed falling off the small fountain was very disjointed. I tried all kinds of things to get the bottom of it. By the end I'd just retaught myself everything about the gravity system. It's annoying to go down a rabbit hole you've been down time and again and just forgotten.

In the end I think I just got lucky (this project is really charmed I think, I'm just its "holy fool" really) and the fix I barely was able to arrive at also happens to make walking downstairs possible in the demo. So even though it feels very draining I think there's really a light at the end of the tunnel.

The problem is (in case anyone is curious) walking down stairs is hard because you can't really know what the player is doing since there is no thing called "stairs" there's just polygons. So the fountain was the right height to under certain circumstances to look like a very tall stairs. Actually everything is treated as stairs when not jumping off platforms.

Maybe this problem is because something else broke something or maybe I've just never really noticed or cared. But since I didn't want to make it into a huge project at this point I needed as simple, generic solution. And luckily now the normal stairs you can walk down at full speed, which is something I wasn't planning for the demo. And the walking is fast like when you walk down stairs in a hurry. You can still walk slow of course.

But you can't walk down the lighthouse full speed, and that's understandable I guess because it has stairs that in real life would be the death of lots of people. There's basically not room to put your feet on those stairs, so only the professional lighthouse person would dare climb those lighthouses. So yeah, it's appropriate to not be able to walk down them full speed ahead.

I've been working on everything. Footstep sounds, and all manner of climbing and squatting embellishments. Jumping is almost like a skateboarding game now. I even added something to get the slime lighting right since they differ from the other monsters. The slimes are lit like the NPCs and the rest of the environment.

I still have that one last project... maybe I've been avoiding it subconsciously... but yesterday I did study a lot of the relevant code to make sure I understand it. My goal is just to be able to open the secret compartments without taking out their contents first. I might try to do the same for things like barrels and graves but maybe not yet. Right now I'm just giving items a larger activation radius so they take priority.

It's almost the end of October, so I don't see any way to do anything in 2020 after this demo. I could crunch on more level geometry but I don't see the point if the monsters don't have their AI in place, and I don't see myself being able to do both the AI and level design in two months. If it was one or the other I could probably manage something. 60 days can be a long time but it can go very fast too, and I tend to work slow. As usual I want to highlight the control system in the new demo. I've done a lot of work on it in recent months that I hadn't anticipated at all. And it's really come together.

 2 
 on: Today at 07:12:44 AM 
Started by Holy Diver - Last post by Holy Diver
:censored: Patch

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

Great, I just found out SOM_MAIN wouldn't start since I changed something to load the Sys.dat file and it's the only tool that doesn't load a project, so it doesn't have a Sys.dat file.

Of course it crashes. Great look to have the first program that leads into SOM not start.

It's annoying to not realize something this for a while. And a reminder no one tries SOM or if they do they don't report when it doesn't work out. But I also really didn't want to patch this release again. It's going to be another deal where the last patch of the previous release is the same as the new release.

Incidentally there's a lot of cool stuff in this patch, but I can't divulge it now. I will say there's a new do_srgb extension that I've changed to always get turned on when the do_lap extension is turned on (but it can be turned off) because I think it really helps with ghost images that come from the do_lap extension. It superimposes two frames, so you always want it, but with the sRGB blending you get the proper colors for the blending and this makes it less funky and so it seems less blurry. Just some odd news. Of course the do_aa extension turns on do_lap. (I'm not crazy about the "do_lap" extension's name, but it's not one you normally turn on yourself.)

 3 
 on: October 19, 2020, 01:07:29 AM 
Started by Holy Diver - Last post by Holy Diver
Almost there, I've identified a problem with jumping off the edge of platforms that happens maybe 1/20 times but it's really annoying since it short-circuits the jump at the worst possible time so I devoted a lot of time to it yesterday and intend to drill down it again today. It's not fun stuff but it will feel good to get past it.

Scrutinizing it did make for some improvements. I've got the water/waterfall animation working properly without need to build a hack into the DLL. I recently came across the relevant code that does this kind of animation (moving texture UV coordinates uniformly) and it looks like the sky model moves at 1/40th per second, and objects move at 1 per second, and the new system I've added I left to move at 1/4th per second.

The sky doesn't seem that slow to me but I presume it must be so. Anyway, it's kind of patchy that all of these things are on different time scales and there's not a lot of control over it. At some point I will attach it to an Ex.ini extension that can change and even regulate the animation speed on a case by case basis to some extent. I don't think the slime monster will be animated in my demo, but I do intend to add support for other models besides level geometry. The obj and sky paths will probably become anachronisms at some point.

KF2 has duplicate map pieces for every direction the water flows in, but the new system I've set up has an option to rotate the UV direction to match the tiling so that duplication isn't required. And I will eventually get around to removing the duplicated pieces.

Nothing more to report except more delays. I've increased the resolution of the Sword of Moonlight splash screen stored in the EXE file. It takes up the bulk of the EXE size. And I've decided to add a title screen to the demo that I stole from online, that's just a good quality cropped shot of the Japanese cover. I guess the cropping suggests it's a sneak peek, since it's like closing your eyelids. It's just the best I can do on short notice. (NOTE: I changed the splash to the SOM_MAIN background a while back. The sword is used for SOM itself but this other splash screen is for games if they want to identify they're made with SOM. The SOM_MAIN background seems better for that purpose. It's more low key.)

I've added an interior_border extension to [Window] that enables some code I've been setting on for adding a black border to help with edge-lit monitors. I'm going to have it turned on in the demo. The Ex.ini file has a few sections moved to the top that may be of interest to players. One is this, in case it is undesired. I think probably most monitors are edge-lit, because they're cheaper but I think people don't know they're getting lemons until it's too late.

I did fix a bug that has been leaking the cancel button from the menus to the regular game context where it must be mapped to one of the movement controls. I'm not sure if this has never been fully addressed or if it started again because of some changes in past year or two.

 4 
 on: October 16, 2020, 08:35:03 AM 
Started by Holy Diver - Last post by Holy Diver
I've successfully made a windcutter magic for the demo (coming soon) that continues through monsters so it can hit more than one. I'm pretty sure none of the SFX types are able to do that by themselves. It also turned up a bug where when the SFX data is deleted SOM would try to delete an SFX instead of a SND (via its SND number) but I think that the SFX records aren't deleted until the end (it's not even necessary to delete things at the end of a program but most programs still do it dutifully, even though it makes it take longer for programs to close out.)

When I first tried to make the windcutter I had an out-of-the-box idea to make the windcutter SFX make another windcutter as its explosion SFX, that could in theory look like it went in and came out the other side. I might return to this idea in an attempt to generalize the idea to all SFX types. But instead I just ended up taking one type that happened to be #5 (that may or may not be used) and reprogrammed some stuff to treat the values -1,-1 (for the subordinate SFX and its SND) as if the SFX goes through the target (i.e. doesn't explode) and voila. I did try the other idea first, but it didn't survive. Maybe because it would hit the target again immediately over and over never coming out, I'm not sure exactly. But it crashed on program exit, but I could have fixed that, but I didn't want to go that far. It's possible that same bug made it crash in hindsight.

I couldn't find an SFX that rotated like windcutter. I didn't look that hard (it's actually really hard to make sense of the SFX system) but it doesn't seem possible to make the type that the fireball uses to rotate in a different direction. Instead I took one that doesn't rotate and made the MDL an animated MDL that rotates. Anyway, that's the extent of it. I also learned that I needed to apply the new npc_hitbox_clearance extension to projectiles, and did that. I also will need to look into if monsters are subject to traps, because if not I worry that what I did to remove the trap clipping code will make monsters walk right through traps. But the trap clipping code is bad anyway. It doesn't really work since a trap doesn't fit into a box shape. If monsters aren't subject to traps I'll have to make them to be. But this won't make it into a demo. That will at least make the trap clipping code cover the damaging parts of the traps. (Edited: I think maybe disarmed traps still clip. I guess I have to look into that too. Armed traps may still clip that way too if so.)

Finally, today I changed the new variable lighting formula to try to better match dark, unlit triangles.

I thought about it and ended up going back to a simple contrast formula and added one more simple darkening term that's just like reducing brightness by up to 25% and surprisingly it's a better and maybe even an exact match. I don't know if this formula would look good for a regular SOM project or not. I got the idea from seeing the unlit models in SOM_MAP. The dark, low contrast textures looked nearly identical to the darkened zones. So I thought in light of that idea I should give it another shot. Also things are going so well I'm making an effort to address any and all defects.

I just have two more things to do before I can start packaging a demo. I'm extremely happy with the results. They're storybook quality. I hope it has a good reaction. I realized I should work on finishing the code that makes the water flow. In the last demo I just enabled a hack for that build. I still haven't finished it. And I want to try to do something for the containers so that the items inside can't be taken until they're opened. That might sound like a weird thing to say but it's because KF2 doesn't work like SOM in this regard. Speaking of the water yesterday I did a lot of digging around in the code to confirm the new 60 fps upgrade wasn't playing the colored flashes too fast...

I think some things are too fast. It seems that the pulse in the power gauges is the same as the pulse in the blindness effect and that these will be too fast. I don't plan to fix this for the demo, and I think the menu pulse is probably too fast also. It will get fixed eventually. There are always unfinished things. (If someone hypothetically used SOM they're invited to either use it unfinished or disable each enhancement until finished. That's the way it will always be.)

It may take me a few days to package a demo after I'm finished with the work. I think I'm going to put it on a site like itch.io instead of self hosting it. That will save me from using up space and get some metrics going and a way for feedback.

 5 
 on: October 13, 2020, 05:05:33 AM 
Started by Holy Diver - Last post by Holy Diver
In the past few days I've found myself on a roll improving niggling glitches in the movement controls and fixing hard cases where level geometry can be clipped through. I pushed back the "camera" plane an order of magnitude for basic clipping issues, that also added 25mm (1") (not much) to the space you can lean out, out of about 350mm (14") by default.

Then most of today I worked on clipping caused by the new feature that can look far down, even behind yourself some. That does like leaning your upper body out some, so it's possible to really clip if you try to dash straight into a wall (or do so by accident) but after several hours I managed to crack it.

Yesterday I identified a problem with jumping because the height was prone to changing over time, since it wasn't locked in. It depended on how long you'd been dashing, so I locked it into the time of the jump. That inspired me today to try to improve the experience of crouch jumps, which I just did. Their problem is you lean out from the crouch, and let go before releasing the action button to jump, and that causes you to draw back some before jumping forward. Which is unpleasant. It's like going forth-and-back-and-forth, when you really want forth.

The trick to fix that was to abuse the drift system so it keeps pushing you in the direction you're going even after you let go. There was already some old code doing that, but not aggressively as it could. I don't think it occurred to me to make the drift stronger than the actual input! But that's what I did. I think the old code was just patching over a glitch because it had reduced "drift" when leaning out, which I think may no longer be required, and it was creating a feedback effect so I removed it anyway. The new do_u2 system shouldn't require it since it's very accurate.

I've been trying to understand the drift code (called "pedals" on the F5 overlay) better lately. I think I've got a formulation that feels much better. I had a bit a breakthrough yesterday that makes circle drifting feel much better.

The problem is there's tension between two ideal situations that can't be met.

If there's too much drift in the look/turn inputs it's too hard to control like a camera person. It drifts around too much. But if it doesn't match the drift resulting from movement then it doesn't rotate when you turn at the rate of movement and so it can't make a clean tail on the circle you're making. The positional momentum doesn't match the rotational momentum in other words.

But you can't match them because turning is looking. And part of the reason too much drift is not fun is it's too blurry on our great modern LED displays. Even if it wasn't unwieldy with our not so great DualShock style controllers. (I don't mean to "dis" Sony. I assume their controllers are state of the art, but the state is just very dismal if so.)

So the compromise I made was to match the drifts progressively when moving sideways but not when standing still or moving forward. This means you can't really play camera person when moving sideways (or circling monsters) like you can when moving forward. But on the other hand the drift feels a lot better, and there is already a problem with trying to do that because fast-turning makes trying to look around asymmetrical, and so nearly impossible.

Plus, when you're turning you really want to match your movement to try to keep the picture from losing focus. It's hard to explain, but if you get the movement and turning lined up just right the picture comes into focus when turning. This is just a video game thing. It's probably why King's Field has that particular turn speed that everyone hates for being so slow.

I guess in analog controls it's still the same, but you can choose different speeds at least. When out of focus everything gets blurry, because you're moving in two directions or more at once. I think you can buy expensive monitors to solve this problem. I've never had more than a basic monitor. But I swear next time I'm going to pay extra for one that's not backlit from the sides!

The reason I'm going to such lengths is I'm getting self-conscious about putting out a flawless demo. Especially in the movement controls area. It's what I take the most pride in, and spend the most time on. And have the most interest in. And I worry it will be criticized if it doesn't feel like the most natural thing in the world. It's also the thing I think might bring attention to SOM since I really think it may be far more innovative than anything else that exists. Right now it's feeling very good. I'm sure it will be the center peice of the new release I'm angling for.

 6 
 on: October 11, 2020, 06:47:00 PM 
Started by Holy Diver - Last post by Holy Diver
EDITED: Before bed last night it dawned on me what would be a good use of that new hole opened up in the control scheme.

I call it sliding:

I implemented it first thing in the morning after a shower. When circle-strafing you actually can't move very fast once you peak the dash. In my KF2 project it tops out at 9 km/h whereas running is 15 km/h and sprinting is 17 km/h. On a side note, yesterday I increased the speed when running slightly so that it's closer to sprinting, which is the dash speed you can set in SOM_SYS, i.e. max speed (although, for a long time I've had the default Ex.ini file override the SOM_SYS setting to encourage people to not play with this value.) For comparison walking forward is 6 km/h.

I've increased the speed and stride by a factor of 1.067 in my project. Like 1/15th. That doesn't sound like much but it's a noticeable difference. I did it because KF2 has a lot of spacious locales and I wanted it to move a little faster. The defaults are chosen because they're round numbers. They let the stride be 1. (My change is from 1.5 to 1.6 walking and from 4.5 to 4.8 dashing.)

Back to "sliding" how this new feature works is when dashing sideways you can pump the action button to slide. It pops the eye-level up about 66% and releases the slow-down effect on circle-strafing so it's kind of like another way to dodge when dashing. Note, I say "pump" instead of press only because in order to do this you're already pressing the action button, so you have to release it and press it again.

But it's more because it also lets the power gauge refill and keeps you dashing even after you let go (this is to prevent normal dashes from creating unpleasant interference) until the slide ends, so you can use this to your advantage too, like a sustained auto dash.

The refill is pegged at your strength level as is normal for SOM. I'm thinking about changing this behavior. I had to reproduce the refill formula in order to counteract it, so I'm now aware of the relevant code if I decided to change the behavior. There's a mystery factor which I guess is a function of the weapon's weight. I don't know if armor weight affects refill speed but I suspect not.

The refill is a little like how jogging refills, but there's no real downside to "sliding" ... it's just a way to move in for an attack when dash circle-strafing. You do have to be careful because you can't slide forward and the equivalent input there could make you squat or crouch depending on if you hold (holding has no benefit to sliding but it will return you to dashing after it finishes.)

Conceptually sliding is like when walking sideways/twisted you can slide your foot like almost a jump but not quite, or like taking a very long step pushing off with the back leg. Probably pretty standard swordplay stuff from movies.

EDITED: I've restricted running/jogging to about 45 degrees (or 90 rather) so that this slide maneuver can be done at up to a 45 degree angle and this makes it more clear when it can and can't be used.

EDITED: Writing this gave me the idea to enhance the player_character_stride extension to scale the walk/dash speeds in the next release. I was setting them all individually, but that seems much easier and it's not a constant value, so it can even be changed by events.

 7 
 on: October 11, 2020, 02:45:53 AM 
Started by Holy Diver - Last post by Holy Diver
Following up, I did complete the work on the do_srgb stuff that night. Funnily it transformed the sky map's stars from little points of light to bright colorful balls! The stars are lots of colors so they almost look more like planets.

And this helped me to see a glaring bug in the forthcoming mipmaps_pixel_art_power_of_two extension, thankfully before I published anything because the balls were smeared across few extra pixels. It's funny that the old sky so overpowered the stars that I didn't notice.

That means the sRGB stuff is working to show the true textures. The difference can be slight but major in textures like KF2's. And it helps with do_aa a lot if I haven't already said so. That said I can't see a big difference in the Moratheia project's demo. That doesn't mean it shouldn't be used, but the difference is dependent on the art style. If textures are already pretty well blended in then it matters less. The benefit to do_aa can be stark but it's more of a further refinement than "night and day".

After fixing the bug I had to change the weight on the mipmaps_pixel_art_power_of_two extension to get the same level of smoothness. I had to add sRGB aware code to the mipmap generation code (that this extension makes use of) to make the mipmaps not fade out. It uses lookup tables via some code I found online and I've included a copyright per its MIT license in the Ex.mipmap.cpp file (https://github.com/ncruces/go-image/blob/master/imageutil/srgb.go)

Oh yeah, I don't think the bright colored balls are acceptable in HD so I've enlarged the sky map so the stars could be made smaller, although I left them medium size and they're technically larger now, except the bulk is an antialiased halo around them.

When I used the generic upscale function in GIMP it put black halos around the stars. I guess that means that's what the sky was doing before when the stars looked like pin pricks of light. I kind of liked that look since it's probably more realistic. But like i said, I stuck with a happy medium. Note the sky isn't black, so it's strange that interpolating the colors makes a darker color, but that's exactly what happens when interpolating red and green this way, so it's not surprising. I never noticed. The green caves are "night and day" though. I'm actually glad they were so dramatic since it forced me to investigate the effect and this is one of the major developments of this project so far.

BTW: I think maybe I intend to work on a feature for the treasure chests and things that is to be able to open them and take the contents as separate actions. I have the secret compartments working but if you activate them the first thing that happens is you will take the contents instead, and only after they're cleared out of the way can you activate the doors to the compartments. The question I worry about is if I solve this then I'll be inclined to make the treasure chests work too, so I hope this doesn't become a multi day project. It's something I forgot about in a rush to publish a demo.

I have finished work on the "hop" feature I mentioned, and luckily that turned up at least two bugs in my recent changes to the movement code that I'm trying to publish as a new release soon. I will probably upload it in the next couple of days, but I don't intend to write a blog post for it until after doing the rounds with my new demo. So that will be a week or more from now. This new release will match the demo's release.

Since I have a lot more on my plate I wonder if I should tackle the Fireball magic or not. I may go for Windcutter instead if it looks easier. The fireball magic in KF2 is just a sprite. I assume Windcutter is 3D like SOM's fireball, but I'm not positive. Windcutter is the more classic magic when I think of KF. When I get to expand on the series (assuming I do) I think of Aleph as using Wind magic. In my plans only two games will have heroes who use more than one magic type. Aleph will use wind.

 8 
 on: October 11, 2020, 02:18:39 AM 
Started by Holy Diver - Last post by Holy Diver
Follow-up

(For the record,)

I've added (3mos later) an update to the http://www.swordofmoonlight.net/bbs2/index.php?topic=301.0 link about new control additions continuing in the same vein. I'm planning a new release that will highlight these additions, however I don't think I will be able to take time to do a write-up until after I can publish my new KF2 demo in the next few days.

 9 
 on: October 11, 2020, 01:45:39 AM 
Started by Holy Diver - Last post by Holy Diver
3/7mos later just when I thought nothing more could fit into the control scheme I'm poised to publish a new release with extensive addition to Action button based controls in the next day or so.

I just wanted to include a mention in this topic. I don't want to add it to the retired blog post. The short description of these new additions is all of the different modes have become interwoven so you can move in and out of them all at any point.

There's a new hop system that's just another way to jump, that only made sense after there were so many other ways to jump, it just made sense. To hop you just have to tap the direction and action button at the same time, but the catch is to tap the direction means it must be in a neutral position first, and you have to tap the action button more quickly than a normal tap. You have to press it as fast as a quick button press and not just anything shorter than the hold period.

I've also relaxed the regular jump timing so not to have to be exactly after the hold period, and the difference between these periods is really just counted in 10s of milliseconds, so it's pretty ambiguous, but maybe if you don't jump one way then you jump the other way.

The hop has to be this way so you don't do it when opening a door or picking up money. It's hard to describe but you naturally will press the button longer when bending over to pick up something off the ground or when waiting for a door to open. Plus if you're lazy the hop won't work. You don't generally aggressively pick stuff up open a door like that.

The dash->crouch/squat system described a few posts up now only works when going forward and backward, and I find this natural because you wouldn't want to crouch when circle-strafing and it doesn't make sense to crouch when walking sideways.

Now when releasing the action button in stealth mode the controls enter the squat mode. That means you don't have to crouch to do that anymore. This is like an extension of the stealth mode. I've enlarged the stealth section of the analog sticks. Moving sideways and backwards is technically stealth since the other modes are only for going forward since nobody runs or jogs sideways.

There is some complicated logic so if you're dashing at the full gait it won't enter the squat mode, and ideally if you're slowing down (i.e. releasing the stick) it won't either, but I find this depends a lot on having a well calibrated controller. My best one is still biased to one side. The Windows calibration system doesn't help it. So it seems to sometimes not reach the full gait on the left side and is inclined to squat accidentally on that side. I've worked a lot to make the system feel like magic.

Since you can't crouch/squat when moving sideways something needs to happen instead, but for now nothing happens when you pump the action button in that case. I'm not sure what it should do but I'd have to program an effect from scratch since it can't use any of the existing variables. I mention it to highlight how crazy it is to jam all of this stuff together and not collapse under its own weight. At that point it feels weird if moving the controller or pressing the button in a different way doesn't do anything.

I would say that it can go no further at this point, but I said that before, and was very wrong, so I won't say it again.

Oh, another big innovation is the walking speed now increases after dashing and swinging your weapon, and then it gradually slows down. This way when fighting monsters you will naturally have a heightened movement speed and and incentive to keep dashing to keep it up.


 10 
 on: October 09, 2020, 03:32:21 AM 
Started by Holy Diver - Last post by Holy Diver
Attachments * KF2 green (and white) caves.png 
Follow-up

I couldn't convince myself the luminance based pixel formats could survive a linear filter but I did set up the next best thing, that is to do the filter in linear color space with D3DSAMP_SRGBTEXTURE and the results shown below speak for themselves.

The texture looks identical to me close up (*) but at a distance it becomes white like the emulator and what I assume the PlayStation looks like since neither has a filter that I can tell. I did a before and after screenshot comparison but I know this scene in particular used to be very green but now the white parts of the texture are preserved. (*Based on some tests I think I might be able to fix this.)

This is done with a new, undocumented do_srgb extension. It definitely helps with these sharp aliased PlayStation style textures. It probably helps in general and isn't costly. I kind of wish many of the [Option] extensions could be turned on by default. Maybe it needs something like "do_all_recommended", I don't know?

Pages: [1] 2 3 4 5 6 7 8 9 10