simple machines forum

Some interesting things happened today, and my UPS battery died so I have to make an emergency trip into town tonight.

From yesterday I had an idea that the events that do the trap doors where monsters fall out of the ceiling (maybe these are always pirate skeletons) I'd reasoned it makes more sense to attach the event to the monster so that the door wouldn't open after it's defeated. But because of this the door opens when approaching the monster, even after they've fallen through the door.

So yesterday I made the event to progress to the next stage that would be its terminal stage. That way the door only opens once. Except in that case there is more than one skeleton in the hiding places, so the encounter could only happen once.

So this morning I tested this theory and added some new logic to SOM to reset monster attached events when a monster spawns. That way every instance of the monster can use the event. I limited this to multi-spawn monsters that are driven by chance encounter, and not the other modes. So if there is a single instance monster the event just has to do itself manually even though the monster technically can spawn many times if bypassed. I could reverse this choice but I felt like the spirit of this change is to deal with multi-instance events, not multi-spawn events. Come to think of it's possible that instances don't respawn because the value SOM uses to test this is a "floating-point" value that is loaded from the save file as a "boolean" byte. So it's possible that once an instance spawns it roams forever, and is retained by the save file. (The "float" value may be its opacity when it fades in.)

I've noticed Aleph is a little taller than SOM's default hero so I've been adjusting his measurements. It got me scrutinizing the "bob" effect, and one thing led to another. So I got an idea to increase the threshold for using the Action button to move stealthily, deemphasizing the jogging ability. I'd even like to make jogging only work when holding down all three buttons, but I'm not sure if acceleration would feel right in that case since you need to run some to get to a full run, and jogging handles that transition okay. (Note this change is just changing the default value of the dash_jogging_gait extension from 3 to 4.)

My idea really was to try to incorporate this into the swordplay element. But also too lately with my PS4 controller it seems like the stealth region is too small to be used easily, and it was always kind of touchy, which is not so bad for stealth since there's an element of taking care...

But I really wanted to instead be able to use it kind of like an alternative stance for fighting the monsters. Even expanded like I said to cover normal movement up to a full sprint/run. But I think the jogging ability still has a use here too. The stealth mode drains the gauges whereas the jogging mode restores them. In that case you can combine them by approaching monster cautiously in stealth mode. You have to do that slowly or else you sprint because the first few moments of running are a fast sprint, acceleration to full speed.

But if you want to move in on the monster then you can kick the gear up to jogging and restore your gauge that way before striking. And the stealth mode actually moves faster than walking when moving sideways, so circle strafing is actually beneficial there. It's a little bit like lock-on in the Souls games play style (that I don't like.)

I think this is a good direction. I think it will be built on. Right now I can't really see a path to transition literal jogging to the 3 button combo but I think that's the eventuality. But then the jogging will have to be replaced with some kind of generic fight mode that also looks like running somehow and that doesn't drain your gauge, so just like jogging mode without literal jogging. When jogging was added the 3-button mode didn't exist at the time. I might have made it use that then if it'd came about in the other order. At the time I just wanted a less intense style of movement that's faster than walking.

For KF2 I'm trying to exaggerate the bobbing effect a little just as homage to the original, but you really can't turn that up high without it becoming a distraction. Analog is really different from digital input and it was always pretty goofy, but there's something about bounding around that does feel pleasant compared to being stiff as board. And I haven't figured out how to cross that gap yet. You really notice it with the monsters so maybe having an alternative stance will be helpful.

In the stealth mode you duck down some always, so that makes it feel more dynamic. And it's probably better to be able to use it more easily just for role-playing scenarios, although someday monsters might be sensitive to stealth. In fact I could program that easily soon since SOM_PRM does have some settings for how alert monsters are that can be dialed down when using stealth movements without doing anything overly sophisticated.

EDITED: As much as I hate to complicate things further, it seems like the way of pressing/holding the action button when exiting dash mode to either crouch or transition to a squat-walk seamlessly is at odds with using the stealth mode because it is technically dashing mode and so does these things that feel natural when running but not if you're trying to circle a monster.

What I think is an interesting move is to always exit stealth mode into squat-walk mode so that you can switch between them easily, and it's a kind action button free stealth itself. In that case to go from stealth to normal walking you have to speed up a little in the transition, which also helps because that matches the walking speed better. And the squat-walk mode is actually interesting for combat so it may be nice to be able to use it in combination with this mode. I've been asked to have it be a more defensive mode or a sturdier stance.

In this case doing the tap/hold wouldn't crouch/squat but would instead do a squat dash/doge on tap or reenter stealth or run on hold... at least as long as you're moving. If stationary it will crouch. Which is useful in fighting too. But you can also do a standing up maneuver (exit squat mode) by doing the equivalent of a stationary jump, which is like crouching but letting go. Because of this you can't do a vertical jump in squat-walk mode. (It's mostly a curiosity... maybe could jump over some attacks. Though you can crouch first and then jump up. Same as a super standing jump.) Running leaves squat mode too, except in tight spaces. It's all very baroque TBH. It's a wonder it feels as natural as it does, at least once you get the hang of it. Kinesthetic controls are much better than push button controls. I can never remember what button does what when everything is just a push of a button.

I've started to look at selectively darkening some groups of tiles but I'm feeling intimidated by the project, so lately I've found myself working on these trap elements instead.

The blades work pretty well. I didn't replicate having one swing as if it's broken down over time, or whatever it's doing. I think KF2's worked that way because I suspect it's responsible for the interesting grinding sound that's like sharpening knives, and I think because neither is synchronized with the sound effect that their asymmetry helps to make it less noticeable.

I made it so that the only way to pass through is to walk directly through the middle very accurately or to try to slip between at a diagonal with good timing. To do this I had to make the hit box virtually square, which is a little counterintutive. There are two CPs positioned on the mid points of either side, that SOM must treat like balls. Not a very scythe like shape but you can't exactly tell.

I manipulated the sound effect by doubling it and making it more symmetrical. It sounds alright. The animation has to make two swings in order to loop back but the sound is only one swipe. I don't think there are two swipes in the original game.

I did the trap door today. SOM isn't really designed for this I don't think, but it basically works. I haven't tested it thoroughly but I think when the trap doesn't trigger the door is slightly leaky, which I could fix if necessary, and it looks like SOM doesn't have a way to make a door that is unresponsive to the Action button. I'm not sure how to approach that, but it means you can make it say "sealed" or "locked" but it is possible to hide those messages if you don't want them, but I'd like another alternative. I think the trigger is pretty reliable. I had to convert into having an open and close animation. Hopefully it isn't glitchy. It remains open like a regular door ever since I added the logic to hold doors open. That seems fine probably.

SOM's doors aren't designed to be placed in the floor. What I did is put the CP that designates the height of the door on the lip so that it goes down as it opens. And beside that I suspect it's more like an elevator door than a trap door, but that pretty much does the job. It can always be improved.

(EDITED: I'm thinking maybe the messages can be hidden if objects react to the phantom rod, since that ought to imply they're invisible secrets assuming games use that in the traditional way. It'd still be nice to add an inert option to SOM_MAP someday.)

P.S. I took some time off to play Moss on my PSVR yesterday. I can't believe sometimes I can't tell I'm looking at a display. I don't know what makes the difference but sometimes many things in the PSVR look like they're fully native vision without any pixel artifacts, it's really spooky when the simulation of materials is very realistic, it's like the thing is really there.

I seem to be progressing very slowly, in the past few days I've worked on issues around MDL models, to make them precise for hiding secret doors and compartments, including adding an extension to the MDL format so the texture can cover the last pixel on the end opposite of the 0,0 origin. The extension works by setting 6 bits is the back of the TSB field that are ignored (not allocated) by the PlayStation and MDL code. The bits are interpreted as meaning the UV coordinate is 1.0. The PlayStation doesn't need this because it doesn't filter its textures. SOM sorely needs it, although I intend to phase out using MDL for texture coordinates.

Yesterday I began work on the spear traps that spring out of the walls from secret compartments. SOM has some spear traps but I've long suspected they don't actually work. That appears to be the case. Today I will probably be investigating the code responsible for traps. It should be fun, but its continuing the trend of piling on delays.

I haven't decided if I will try to do something about KF2's trap doors at this stage. It seems like the something I'd like to include in a new demo, but it's a technical challenge.

P.S. I bought $40 of PSVR games the other day in a digital sale, including From Software's game, that cost $7. I don't know if I have time to actually play them, I'm sure I'll try, but I'd really like to play more games with a PSVR.

I may have spent the entire day working on the first secret door model and frame.

I had a couple good ideas. One was to pump the door model through x2msm so it is subdivided as necessary to match the MSM geometry for do_aa to work. I don't know why, but I don't think it's ever occurred to me to do that. Maybe it's because I have a lot more flexibility now with the new MDL<->MM3D tools. I had to add a backdoor way to tell x2mdl to output the fully subdivided MSM model. It doesn't currently have a proper command-line options system.

The other good idea was to truncate the vertex coordinates in the vertex shader so small numerical differences between the walls and secrets don't become visible. There might not have been another way to do it since even after I got the seams to go away from far away they tended to open up.

The tile system doesn't do anything that can corrupt the MSM coordinates since it just swaps the XY coordinates or negates them as necessary, whch isn't destructive to floating-point data. However the objects and character models undergo extensive 3D transformations that are probably way more involved than is necessary and prone to inaccuracies. (Maybe the do_aa system requires more precision than normal, I'm not sure. I could try without it and see.)

Just because the art data already exists doesn't make it a breezy job. It takes me (maybe I work slow) a lot of time to do every little thing. But it's nowhere near as much work or pressure as making art for a game all by yourself like Moratheia did. I still can't really wrap my head around making a game with original art work, but converting KF2 is a test of my ability (and a display of SOM's ability too.)

Here are some more images. In the second I've tried to show off a change I made to the mipmaps_pixel_art_power_of_two extension to accept a fractional value to be used to soften the 2x2 pixels by applying a hand written filter to the blown up mipmap.

My goal is to make them vaguely unrecognizable as pixels so your brain doesn't shoot off "those are pixels!" some level of plausible deniability so you can see what you want to see in them. At the distance in the screenshot it shows off well how much closer you can get without seeing pixels, but it's not as close as you can go, since I wanted to have a nice photograph too, with the subject in frame.

I'm pretty happy with these results. It's very close to a successful upscaling of the textures, and certainly good enough at this stage, and I think it gels well, and is true to the spirit of the original.

EDITED: In case anyone is interested, the filter works differently from a regular linear filter, and it makes new pixels, that the regular linear magnification filter will sample between. Since there are are 4 times as many pixels instead of having them be the exact same color in blocks of four, what it does is to look at the corner of each block and blend it with the value sampled in the very corner of that quadrant. So the structure is still in 2x2 blocks, but the corners are softened, but they're not truly corners because there's only 4 pixels there, so really each one is a quadrant in the multipixel. So there's an organization to it. The pixel's own value is one of the four in the sample, since that's simplest, and the weight itself is quite small, like less than 20%, but very noticeable. You wouldn't want much more of a weight than that. It also wraps around as if the texture is repeating. In theory that can cause problems, but it's better than the alternative. I think even when the maps aren't designed to wrap around it kind of helps to soften the edges subtly, like in the lines in the ceiling.

NOTE: The aliasing is less in the moving picture than in screenshots, because of its temporal nature. I think the chunky dither pattern helps to lend it a film grain kind of quality that can feel a little like CGI. But that depends a lot on if there are any crummy looking elements in the picture. When it comes time to polish it up I want to eliminate any crummy elements.

A familiar scene