simple machines forum

I've added a not about fixing trip zones for this old project with the current patch explained here (
http://www.swordofmoonlight.net/bbs2/index.php?topic=330.msg3335#msg3335) and I think I'll upload my Ex.ini file to the OP in case it's any help.

Significant patch

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

I think this patch is a pretty stable representation of the map transfer and load balancing work I've been wrestling with of late. I'd also (for some reason) been plagued lately by a random crash/corruption type bug that I think I've figured out (knock on wood) which seems to have been related to a long problem around map geometry vertex buffers. For some reason the multi-thread scenario seemed to cause it to manifest, however the root cause was (if correct) two-fold, first in some transparent map geometry code of my own, and second in that MapComp doesn't decompose the MSM geometry to fit into som_db.exe's buffers, so they can overflow and produce similar effects. I've observe this in the Moratheia 2.1 demo, and I've added temporary code to som_db.exe to excise the offending geometry until I can try to extend these buffers.

FWIW the limit on MSM geometry is 896 vertices, and 896 triangles on a per texture basis. In Moratheia 2.1 the naked trees seem to go over this limit, even though they certainly don't look like 896 vertices to me. I'm not sure what that could mean, but some of their polygons are lost with the patch I've applied. (It could be that every triangle has different normals and UVs for every vertex, requiring duplications.)

The Moratheia 2.1 demo is a big help to me because it always has unique problems to solve whenever I work on something, that would otherwise go unnoticed most likely.

Both of these problems have been around for a long time, so I really don't understand why the addition of background loading agitates them. For the MPX geometry (MSM) index buffer, following it is a huge gulf in the data section of the player's EXE image. I'm beginning to wonder why it exists. Any buffer overruns would corrupt this memory. I wonder if it's a default heap chunk or something. The vertex data goes into a D3D vertex-buffer. If it overruns it overwrites internal D3D memory.

I've checked in my source code for safe keeping. This is the first patch that can do seamless map transfers. It's probably more stable than some of the recent patches.

It adds a do_fix_trip_zone_range=no [Bugfix] extension that the Morathaeia 2.1 demo depends on because it sets its trip zones underground for some reason, and their bound object height doesn't reach to the surface. The alphafog_skyflood_constant [Detail] extension default is changed to 1.5 from 8 because I had to remove some code that capped it to 1 in the vertex shader because it made the math depend on the sky model's geometry.

Attachments

 KF2 tunnels.png 

pics

In the 2020 demo (very late months) I did a bit of butcher job on the green stone tunnels to try to make them work. Something has to be done because they just can't translate to filtered textures and IMO they only half work because they're not filtered, otherwise the design is really questionable.

Today I woke up with the intention of finally rebuilding these from the ground up. A better 3D artist could probably do something a little more creative to capture the spirit of the originals, and they're welcome to, but I knew I had to fix this for the next/upcoming demo. I'm pleased with the results. It can use some polish, and hopefully there will be time for some, but at least I can check it off my list like this.

Another reason these need work, beside the design, is the texture maps on them are way too low resolution. The brick size I ended up with was based on the arches, which have much smaller bricks for some reason. (They don't match up at all.) But ended up being made a little smaller to match the stair steps height. It takes a little getting used to but is not so bad. It definitely has a different feeling.

EDITED: For the record, the 3D polygons are unchanged. Also the surface lighting is hard. It can be hard to tell with this texture. It looks smooth either way really with all the confusion and polygons falling on the texture lines.

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.

[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.]

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

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.

Attachments

 KF2 ectoplasm.png 

Woap

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.)

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.