Sword of Moonlight > Devs

Exit: Passing between worlds

<< < (3/4) > >>

Holey Moley:
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.

Holey Moley:
emergency patch-patch

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

Yesterday's patch is still having thread synchronization issues I hoped had gone away with that overrun bug fix. A real problem is changing the resolution, etc. in Moratheia would lose mipmaps and sometimes freeze. I'm not sure why this doesn't happen in my KF2 project... maybe because Moratheia has some really big monster textures that take a while to process.

I hope this patch solves these problems, but it does so bluntly by wrapping the whole mipmap/colorkey/upload subroutine in a global "critical section" object (thread synchronization) which isn't ideal. But this should stop the bleeding until I can think of something else.

It also removes a "critical section" object that was kind of superstitiously preventing some routines that seemed to lock up from coinciding with the screen buffer present/flip step. I really want these problems to just go away since they stand to make using background loading a nonstarter if they don't. (At least not without further work to decouple texture loading from Direct3D.)

blue is the new black

Without writing too much about this, this patch is trying a new strategy for lighting up black pixels so they don't look like holes in the monitor. There's a do_black extension if you believe your monitor can do black gracefully. Anyway, looking at the blue night sky in my KF2 project I decided the 1,1,1 black pixels were a kind of haze and so I tried different strategies and settled on just adding 1 blue pixel value to every pixel. This has upsides and downsides. One is blue is the dimmest component and so guarantees black is the darkest color and so brightness gradients should be preserved. But also it seems to me to have some visual effects if I'm not just imagining it. I think in theory if pixels are pure red/green then just turning on 1 blue has a similar impact on the character of those pixels as filling in pure black pixels does. But it's really hard to describe... Mortheia's final dark area seems to be the most dramatic difference I've seen, where somehow it seems much darker. It's a strange effect to me because I don't really see any pixels in Moratheia that are completely lacking in blue. Although its entire game has a very green/yellow/red palette. You wouldn't think one blue would make a difference. I suppose the darker the pixel the bigger difference relative to the other components adding a blue will produce.

In my KF2 project I can't see a difference, other than desired effect. I think I'm going to add a little blue tint to its fog to help things blend a little better. It seems to help with its water horizon regardless of the black strategy.

Holey Moley:
Repatch (EDITED) :censored:

EDITED: Okay, I think I had a miserable/crisis morning of this. I neglected to see if the fix from a couple hours ago still worked to remove loading hiccups as advertised and it did not.

So I had to just try everything I could think of to figure why the critical-section set up I had wasn't working. The first thing I found was a typo I made and I really thought that explained it all, but there were still strange further troubles to work through. It seems I needed to extend the guard region and what I had written wasn't exactly a correct double-locking pattern. I should've just relented and looked at some old code of mine. I've done this before.

It wasn't fun but I'm glad for the Moratheia project as ever for helping me discover unique problems.

EDITED: I really hope this stuff is finally out of the woods... knock on wood. This work can be great fun but it can be frustrating too. This latest around of work has been beset with bugs (many seemingly unrelated) and I've been constantly on edge about whether it's going to work out in the end or not.

Holey Moley:
Replatch/Reupload (upload failure) patch

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

For the record, I just found out (by chance) I must have (somehow) botched the last patch (7 days ago) most likely by forgetting to replace the DLL file inside the ZIP file before uploading, I'm not sure??? Maybe I imagined I uploaded the patch files because the dates on my host were the same as the ones in my TOOL folder. Maybe Windows failed to update the DLL file in the ZIP file, I don't know.

while I'm here posting (off-topic news)

The UV animation project I'm doing these days is coming along as fast as it can. It just takes a long time. I wonder sometimes if I'm going about things the wrong way when something takes too long. I found out I messed up this patch (human fallibility still gets to me in this area) because of a problem in the saved (Slime) model file... something I forgot needed to be updated with the addition of new features (I've stuck a note in the source code for future features.) Hopefully I'll have a render in the modeling software going before day's end. That will mark the end of work on the editor side.

Holey Moley:
Important Patch

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

[SVN Update is required for new sky model animations.]

EDITED: For the record, I had to make one more fix shortly after writing this post (I should've test it) so if the sky is stuck, please try to redownload/reapply the SomEx.dll patch.

This patch fixes a problem that writes corrupted item data to save files. What happened is some code that tries to eliminate removed items that were edited so the save file doesn't crash ended up running before the save file is loaded (I probably misplaced it when reorganizing code for changing maps in this release.)

Somehow another problem slipped through that fails to play sound effects when using the new "standby" preloading system. This was owing to some checks that ensured some mmio APIs (Win32 multimedia subsystem) were running on the main thread, which is not the case when preloading. I honestly don't know how this didn't raise its head months ago.

As for x2mdl, it has a new system for directly specifying texture map animations in the MDO format. The only way to use this is with the MM3D editor (https://github.com/mick-p1982/mm3d/releases/tag/win32-dec-2021) (see Model->Utilities) and is limited to 1 key-frame of "translation" data only. This isn't limited to one texture or even specified on a per-texture basis. It uses groups of triangles instead, which can all be animated independently. Items can now be animated like this, as can NPCs, including monsters.

This reminds me, I have to now quickly update the SVN repository (SVN Update) because with this change sky models will no longer be animated so artists can manually control this. I almost forget, since I was putting fixes ahead of features. Give me a few minutes to do this.

Note, if a project loads an old MDO file the old sky animation system will kick in, however there isn't an opt out option for this, so if using the new art system it's required to specify the sky animation with the art file. The reason for this is not specifying an animation is meaningful since it tells the player a stationary sky is wanted.

Animation info: For those curious, to reproduce SOM's sky animations, set V to -0.025 (40 seconds) for a 1 frame animation at 1 FPS. For objects, set V to -1 (1 second) I believe. Of course you can set these to any values you please now. These values are negative because OpenGL and Direct3D differ on this. Note, the editor plays back these animations when playing animations (via a toggle) but the skies don't have animations, so to see it in action it might be necessary to make a dummy animation.

I'm going to enable using MDL files for skies sometime. If so it will just loop like a looping object until something can be done to control it (MDL animations move the geometry, whereas texture animations just move/cycle the texture map.) I'd like to explore more animation options in the future, however I chose to keep with tradition for the moment.

Navigation

[0] Message Index

[#] Next page

[*] Previous page