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
 61 
 on: April 06, 2022, 01:40:21 PM 
Started by Holey Moley - Last post by Holey Moley
black hole of despair

Today I set out to switch between this blue sky and the dark sky. Somehow it spiraled into a recurring nightmare so that I couldn't seem to tear myself away from it all day.

The tricky thing is loading the sky without hitting a hiccup. I couldn't get it to work so I ended up tearing through and double checking all of my code around this sort of thing. I found a lot of problem areas in the process. Some may be bugs in the current patch. I kept going through moments where it seemed to be working, only to later have it regress back to not working.

Even the map transitions I set up were stalling. But I think I've got a handle on all of it now.

On the sky changes front, I started out by looking at the event trip zones as a possibility, however they're really pretty badly designed. I thought about how they could be improved. But for this leg of my project I decided it would do to add a formula to my INI file that looks like sky[1] = if(neg(70-2_,12-3_,40-1_,1_-56,0),4,1) and just cuts out the relevant section of map.

I've made the 2 old "alphafog" Detail extensions that serve to blend the sky into the ground plane of fog communicate the sky model number to specialize accordingly, but I'm not certain if this is best for the other ones that control the fog effects mainly. These 2 are very much tailored to the model itself and isolated, so it seems fine to work like this.

Next I have to work on the UV animation. In order to make this blue sky I had to disable it. I could write a long paragraph about what the options are how to do this. I'm not sure yet what I intend to do. I'll have to figure out something.

trip zone thoughts

Trip zones definitely need to be improved. The main problem is there's no way to pick up on leaving the zone, so it makes event setup really tedious and unreliable. Unfortunately there isn't a very obvious way to incorporate this into SOM_MAP's existing framework. I would start by adding a system number to the INI file for testing the trip zones, which can help some, but can't inform events, so they would need there own way to do this, that I think could be done with the Counter loading module, but isn't very straightforward. It would be better if the trip zone events had a direct way. I thought about letting the "always on" events define an optional trip zone. The only real problem there is how to choose if the zone is square or circular. Being "always on" could process coming or going or staying in or out. But how? The Counter way seems most practical. Its only drawback is obtuseness and requiring dummy trip zones. But the master event could consolidate all trip zones. The approach I took probably isn't practical for a real project, and isn't user-friendly at all, so I'm certain this trip-zone approach will be realized down the road.


 62 
 on: April 04, 2022, 12:46:01 PM 
Started by Holey Moley - Last post by Holey Moley
[For the record, this sky background didn't look like this at all at first. I worked with it all through the night. I think I pulled out all the stops, trying everything.]

 63 
 on: April 04, 2022, 12:43:02 PM 
Started by Holey Moley - Last post by Holey Moley
Attachments * KF2 cerulean skies.png 


Oh Ramona, if there was only some kind of future
And these cerulean skies
Something in our skies, something in our skies

 64 
 on: April 02, 2022, 12:12:09 AM 
Started by Holey Moley - Last post by Holey Moley
MM3D upgrade

I've been working on the UV editor part of the MM3D editor a lot in the past few days... all day yesterday. I've published the work on its Github site. It includes snapping and other new editing commands and buttons. I have to work on a pivot system like Blender's "3D cursor" to make it a little better, but it's pretty competent at this point. I had to add a vertex (UV) snapping system to edit KF2's ghost the other day. Yesterday I worked on snapping to pixels and polish. There's considerable hotkey remapping, so always delete your key binding config file to restore to the latest default.

 65 
 on: March 31, 2022, 08:57:50 AM 
Started by Holey Moley - Last post by Holey Moley
Attachments * KF2 ectoplasm.png 
Woap :geno:

EDITED: For the record this is using the Volume system. It occurs to me that surface normals might look very similar to this if fixed how KF2 does it and with just so lighting. It's possible that's exactly what it does. I might try to do it that way later. This system would work even when the ghost flies through things. There are places where the ghost intersects itself. It might be worth trying to make him/her/it more convex because it breaks the illusion by introducing creases... edited: or it might be possible to solve this after I work on sorting/splitting every triangle for correct transparency. Slimes will probably get this treatment soon. I'm going to work on UV animating MDL files very soon, for the fountain room. The green slimes should be able to use that to do their flowing animation. (It took most of my day to redesign the texture work on the ghost. It wouldn't work how it is. I had to put the mouth and eyes onto a full body texture. In KF2 they're just kind of patches. That doesn't blend smoothly with filtered textures. There's not enough degrees of freedom in the model to match the oriignal eyes and mouth exactly.)

 66 
 on: March 29, 2022, 07:40:59 PM 
Started by Holey Moley - Last post by Holey Moley
Routine patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.6.zip
http://csv.swordofmoonlight.net/x2mdl.dll/1.0.0.2.zip (minor)

The x2mdl.dll patch just adds some hints to error popups and an option to subdivide MSM input. The latter is is needed to make object models that blend into the level geometry, a/k/a secret doors.

The past few days I've been trying to crack down on a bunch of recent bugs I've been neglecting debugging. That's what this patch is. I'm not going to lie, here lately it's been crashing for me a lot, usually at the start, in ways that seem random. I'm hoping all the problems are covered by this patch. I haven't had any this morning. A lot of them were really weird, and I've only recently hit upon a few reproducible cases for a few of them.

I'm pretty sure there are still unsolved problems. It's always demoralizing when a problem keeps raising its head. Most of these crashes are around new features. There was a constellation of bugs that all kind of seemed related but were not. I've fixed a least 3 like this, so at least they're being teased apart. Divide and conquer. At least this patch addresses several of them, which is better than nothing. It also fixes a number of places where recent patches broke new features. I have to be bug free before I can release a demo later in April. I'm going to have to work like a demon if that demo is going to not have a bunch of loose ends, but I intend to publish it in April, however far I get.

 67 
 on: March 28, 2022, 03:19:47 AM 
Started by Holey Moley - Last post by Holey Moley
good news

I finished the last NPC 2 or 3 days ago. I'm about to move onto monsters. I've been polishing up many models, odd jobs, like for instance I just worked on making the dragon doors invisible against the level geometry. That's actually pretty complicated because of how the do_aa extension works. Before even that (I've talked about this before) the inner walls of the doors have to be hidden in the animation by scaling them until they disappear. Then for do_aa the exterior vertices have to match the surrounding level geometry's precisely, or there will be visible tells there's a door there, and it will just look a little glitched otherwise. The supersampling option makes these glitches almost invisible to the naked eye. To accomplish this the object model has to be run through the level geometry converter, because it gets subdivided, which adds extra vertices. These are for points where lamps can cast light onto vertices, because the lighting model is vertex based. Used to unlit level geometry would not be subdivided in the game, however for do_aa to work, for a long time I've made it to subdivide everything. In theory the map compiler could be made to fill in gaps between different levels of subdivision, however realistically, in order for objects to be embedded into the level geometry, at least for this to work, there would need to be a way to tell the compiler to divide sections, other than placing a lamp on the map nearby. (Maybe even a false lamp would do, but I think this would be a hack... maybe it could detect objects that have Phantom Rod status and interpret them as requiring subdivision... actually that would be a pretty solid strategy.)

Good news wise, I'm very happy with where the color is at now. This really helps me to get excited to work because there's so much work that has to be done. Really the team that developed KF2 deserves so much credit, but the way I look at it is they made a really good prototype which posterity now has to polish into a gem, which is easier said than done. Not discounting the degree of work required to produce a product like this, which isn't even paralleled today. Those days really were a unique time for video games, which are now gone like the dinosaurs. We have to be the paleontologists of these dinosaurs in the meantime; Pay our dues.

The PlayStation game, at least on emulators, always has a washed out feeling that I really dislike. Sometimes I can't see it, but sometimes it comes on very strong. I don't fully understand how the PlayStation architecture would have supported how KF2's colors/lighting seems to work, but that's probably just because I don't know enough about it. It seems like the textures have their colors multiplied by 2 at some stage. All of KF2's textures are very dim, so it's possible this is done when they're loaded into VRAM, if not somewhere in the graphics stack. The textures are 15 bit color, so I could see why they might get upgraded into higher resolution data at some stage. If not, then KF2 only uses half of the 15 bit color range, which would be like using 4 bits instead of 5 bits for each color channel. It's pretty hard to work with these dim textures because they're hard to see, but it can be even harder to work with really bright textures, especially if you're editing them, and generally how graphics worked in those days (and still probably) textures would need to be exaggerated in terms of their brightness because typically materials and lighting could only make them dimmer than the texture, never brighter, so the texture would need to be as bright as it will ever appear... and that's still how SOM works. So that's one reason why the team could've chosen to brighten them at "runtime" when the game loads up.

Anyway, there also seems to be a creative dynamic contrast system, which is combined with darkening, to create dark environments which have reduced contrast. Unless I'm mistaken this is pretty clever because I think how SOM and other games work, lighting doesn't impact contrast. But how we see IRL definitely does seem to work like this, and it feels pretty interesting in the game. But the default contrast level isn't maximum contrast, so maybe this can contribute to why KF2 feels (looks) dull in this area, i.e. like it has reduced contrast. But that doesn't fully explain why it looks "washed out". It's possible the mix is just wrong, however it could be a choice based on how televisions worked in those days. I don't know, but it doesn't transfer well to modern day displays. As soon as I started to unravel some of the mysteries around the color lately, my project's color started to take on these same low contrast and washed out effects. That meant it was actually reproducing KF2's color. I'm actually surprised I haven't needed to tweak it that much. But I've been spending a lot of time in the past few days tweaking color, more than anything. Also remapping some textures.

I noticed that dropping the color down like 12 values (I think) helped to remove the washed out appearance. That's easy to understand I guess because what makes it seem so is because it's too bright... washed out basically means everything is too white. But I wasn't smart enough until a few days later, I realized the commonsense thing to then do is to just remap the color to full brightness. This sacrifices those 12 values at the bottom, but then pulls everything else back into full brightness. I had been using SOM's brightness setting to compensate some. I don't know why it didn't occur to me to just do that in the color function. This looks really good. And I've been tweaking the lighting too. This is possible now that it's really accurate. Although I wish one of the KF2 hackers would just cough up the real lighting values, because there's 3 lights, and they're all at oblique angles, so it really hurts my skull to reason about them. I know someday someone will find them. I assume there's also a baseline ambient light level. This is exactly how SOM works fortunately.

Just to reiterate, the color is really popping. I think the new demo will be very attractive. It feels closer to an ideal mix.

I also had a funny thing happen yesterday. What happened is I was just poking around as normal, and I went into the fountain room and found all the channels full of their water. I hadn't set it up to do that, so it was a little surprising. Of course there's an explanation. What happened is I usually use the first register in the event system as a temporary variable, and this is also what the objects default to, so it's kind of surprising this didn't happen sooner. Something had just left a nonzero value in that register, and that turned them on. It was still fun to see. Even though the channel's water isn't moving yet. That requires a texture animation, and SOM doesn't support that on animated objects, so it's something I have to work on. And I have to upgrade how "pedestals" work too. SOM puts fake versions of the items that fit the pedestals into their animated model. I have to build a better system that uses real items instead. Even if the dragon pedestals could work this way, it's not a very flexible system, and the save room pedestals can't work like this since they accept more than one item.

aside

Speaking of that, a while ago I decided on what to call those items when I translate KF2. I don't think I'm going to call them gates and keys, even though this is the literal words used in katakana in the original. I want to do the translation from Aleph's perspective. I assume Aleph knows about this system. Plus the "gates" function like keys really, since they open a door. Even though I admit, looking like compacts they're not evocative of keys. I still think the generic suffix of "key" works since their are already so many keys. So I think I'm calling the portable items keys. But I couldn't figure out what to call their counterparts in English. Oftentimes English seems very impoverished when you go to find a word for a concept... especially abstract concepts with no modern precedent, as you so often find in games and software. But without further ado, I found the word "pendant", which also has a meaning that means a counterpart or pairing, and the shape of these things does evoke a pendant in some usages. They're actually very hard to categorize things in terms of their shape and action. English doesn't even really have a generic word for a thing that inserts into another thing. Like a plug? I don't know. English seems very ad hoc in design... as in words only appear when there is very strict need for one, which allows it to catch on. Anything else, sorry Charlie/Chuck, you're out of luck. I wonder if Japanese is like this or not. It seems very abstract to me, like baby speak sometimes. English seems overly/obsessively concrete/specific by comparison. But I think that can be interesting for game translations, because it forces you to try to be concrete in your words, or else the script comes across as unnatural or not literary, more like a low piece of cultural ephemera than art. 

 68 
 on: March 24, 2022, 10:20:49 PM 
Started by Holey Moley - Last post by Holey Moley
Attachments * KF2 Woz exposed.png 
Have to improvise for some of these NPCs who hide behind counters. Of course there's nothing back there in the PS game, legs and all. In SOM you can't get behind this counter, but you can lean around it and see most everything except the hollow space. You can climb over the counter, with some effort. I'm thinking of calling this NPC Wazoo Shoe. That's a kind of comedic interpretation of his name, but it's completely accurate.

Edited: I imagine the space behind the counter would be hung with several keys, but I don't think I'm going to go that far for something only visible by climbing over the top of it. It's not to save effort, but there's a certain amount of minimalism to KF's design which I appreciate very much.

Edited: Oh yes, you can see Woz's glasses are (now) two-sided, and I've made them a little bit transparent to boot!

 69 
 on: March 23, 2022, 07:44:36 PM 
Started by Holey Moley - Last post by Holey Moley
update

You'll notice in that screenshot of Al his skin isn't lit so bright like the original. This also matters in Nola's area where the sky is actually blue (Al's house is in the dark.)

What that meant is the lighting I've been using up to now was inadequate because Nola's area must push the light up higher than what I assumed would be its maximum.

This was a real headache for me, but I sat down today just to take a look at it.

What I seem to have ended up doing was taking all of my careful lighting calibration function, and what seemed to work was to pull it all out (including the power function) and just multiply by 2 instead.

What this tells me is the tile based lighting function I originally went with must actually be very close to the real function, and that this 2 is probably part of that function. IOW, what I was doing before was reproducing this function without realizing the default lighting was somewhere in the middle. This is understandable since I set out to reproduce the generic lighting long before I ventured into this per tile customization business.

I'm hoping that this answers most of the question about why the color is calibrated the way it is. I still wonder how this works on the PlayStation, as it seems kind of unusual. I assumed the color grading was more down to some kind of gamma ramp. I could still be wrong here, but it really looks pretty accurate. I still have no idea what the actual tile lighting values are, so it's really surprising it would be accurate. I just chose some arbitrary values. (I usually get lucky at this.)

From what I can see the lighting stored in the map data is not a gradient, but just hand adjusted values.

I was really thinking I'd probably have to adjust the lighting in the MAP files, but it seems to look okay so far.

The NPCs seem to usually have some kind of fake light source nearby. It's pretty easy to see there's some kind of big lamp in front of Al. And Nola's dress is lit near her feet. This explains why I couldn't match the fisherman's color. I really struggled with that. I gave up, but it's hard to tell he has a light in front of him, but now it looks obvious knowing what's up. I'm not sure how that's implemented. Most monsters (except Slimes) have their own light that follows them, and it doesn't change when they turn. I actually think this seems to work better than basing lights off the environment. It gives a consistent presentation. But the NPCs so far use the environment's lights except for these spotlights) ... and I guess that's down to their being immobile most of the time. Many "objects" appear to have custom lights too, and often it looks like they're just roughly mimicking the environment lighting. It's possible every one of them is custom lit somehow. I don't know if I plan to reproduce that.

EDITED: To some extent the fake lighting is produced by "surface normals" that are either manipulated, or just smooth normals (Gouraud shaded) where they shouldn't be so, but I still feel like there's an extra light source, or a custom light setup that just happens to be close to the environment's light. I may try to do this later once I have a custom system for lighting monsters. They don't approximate the environment at all, except for slimes.

I'm glad to be getting a handle on this, and surprised that the formula I used for the tile lighting effect would be accurate. I really just whipped it up as an approximation.

 70 
 on: March 19, 2022, 07:07:09 PM 
Started by Holey Moley - Last post by Holey Moley
new pic

https://swordofmoonlight.itch.io/k has a new picture of Al Hunt (I'm thinking of naming of him Al Hundt, I dunno) up, and I've remade the older image, mainly because the gauge and compass has changed some since then, and it was too noticeable it didn't match. But I wanted to match the contrast levels too, and the new pic was pretty accurate to the background so I made the other more accurate to match... just now I wondered if I should've matched the HP and MP on the gauges, but it's too late for that now.

It takes a lot of fussing to make thumbnails. You have to play around with sharpening and contrast filters, and so on, to get them to look right. I think today's monitors dynamic change their contrast levels, and even at different places on their screens. But eyes do funny things too. It's kind of annoying that what looks best on a full screen display can look very different (usually lower contrast and dimmer) on a desktop background.

I guess this is a teaser for the new demo I'm preparing. It's progressing, but I don't expect to have it ready before sometime in April. If it's anything like how things usually go, probably late April. It will probably be rushed, and I will then for the next two or three months try to polish it up more. I honestly don't know how long it will take before I can piece together a more or less complete version of the game... I know even after that I'll be trying to polish it for the next few years, hopefully while working on other projects. I consider KF2 one of the very few (if only) games worthy of this level of attention. Someone has to give it the attention it deserves.


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