simple machines forum

home stretch

I'm going to upload a new demo before the month ends. I'm making a list of last things to include (it's going to have to leave out a lot that I'm not sure I could do right now if I had the time to anyway... I'm getting very near maximum burnout.)

1) Finish channels in fountain room.
2) Some clipping obstacles in the village areas, raised entryways, Nola's fountain.
3) Make the windows on houses see-through, remake their super low-res texture.
4) Try to improve tree fuzz on the blue sky model's skyline.
5) Many item models. Try to get all of them... as quick I can work.

Things that won't be in the April demo are, any new sound effects, any new moving/fighting monsters (they're walking in place), any AI improvements or fixes for flying/swimming monsters.

Things that will be are, cross into zone #2 without loading pause (if your PC is at least as good as my very low-end work PC), all of zone 2 visuals wise, except the dark village area is using the same textures as the regular villages, and significantly improved color.

Most of my work since I set out to do this has been on the 3D model editor side. I've done everything this time around without Blender or anything else. Just SOM and my MM3D editor. It's been very pleasurable. A fully streamlined experience.

Attachments

 Slime.gif 

Here's a GIF of a slime made with an animation movie export system I cooked up quite a while back. It gets the job done. I think this is probably accurate to the game but I've not sat down to scrutinize it just yet.

It certainly looks different to me... almost like stained glass because the edges of the triangles don't (all) hold together. I made some slight adjustments to help the dark edges line up where they didn't quite meet sub-pixel accuracy. That's the only part that holds throughout the animation.

P.S. If anyone's reading this, I'm still trying to publish a demo by the end of the month, but this is likely to take up all my time until then. I'll just have a few days to try to do a little bit to add some missing item models and patch up some animations. It's going to be really rough. I have a feeling the new monsters will just be walking in place without sounds unfortunately. I just have to publish what I have. Their textures aren't cleaned up enough to give them a good show, so I feel even a little better if they're more like placeholders. There will be a follow-up in the coming months with everything touched up. There probably won't be another big demo this year after that.

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.

Attachments

 MM3D utilities.png 

checking in

In the past 2 or 3 days I've been taking on SOM's UV animation problems. There are 3 problems I hope to tackle. The first is control over sky animations. The second is animating NPCs and monsters. The third is animating MDL files in general, which includes NPCs and monsters, but the real problem is just the inability to mix regular animations with UV animations. A fourth is animating level geometry. Unfortunately that one's going to have to wait. There is a solution for that already, but it's not ideal.

Unfortunately I expect this to be a week long project, if not 2 weeks, since it will also include realizing the animations in the modeling software, in the player, and converting the art data into runtime data. It's not exactly what I expected to be working on right this moment, but it seems to be the right time to do this.

The first problem I faced was how to wedge this into the modeling software UI. UV animation like this is pretty obscure, and the software already has virtually every key on the keyboard mapped to hotkey shortcuts. So it didn't make sense to make a dedicated facility for it, and I didn't want to tack it onto the animation facilities either.

Animating a UV map is already pretty odd since there's not really anything to grab onto. You could cook something up, but it would feel a little pointless and frictionless. I wanted to add a new category for more obscure video game like needs. I.e. stuff 3D modelers don't usually think about, but games need. The more low-fi the game, the more obscure the need. I had to brainstorm what to call it. I started out with something like Effects, but it didn't map nicely to a shortcut. Then I thought maybe Qualities, but I didn't like using Q as a shortcut... that area on the keyboard already has a certain character that didn't quite fit for opening a window up, lest you do so by mistake. Then I hit on Utilities, that was just perfect. That made me excited for the project. The U key was wide open (being quite out of reach) and "utility" exactly captures the meaning I'm going for. I'm surprised I didn't have to resort to a thesaurus. It did take me a few days to come up with that.

It's good for work when everything seems to click into place like destiny. Also there's an existing "Meta Data" system that didn't have a good shortcut assignment. But I changed the wording to User Data (better IMO) and that was perfect as a double (Ctrl+U) for the U key. Especially because this new Utilities layout is identical to the User Data window's, even going so far as to reuse the same code and source file.

The first day of real work was a hurricane of just laying down infrastructure. Because of the extra level of indirection caused by establishing a category (Utilities) there was extra work and abstract things to consider. It's a modular system, ideally it would be nice to integrate plugins into it. It's like meta data, only more than just little textual notes. (Sometimes games can get some mileage from such notes, but SOM doesn't. It can also be nice for adding contact information if you want.)

I think somewhere down the road will be some "utilities" for fine-grain manipulation of lighting "surface normals". That's something you can't always get out of 3D editors which low-poly games can really benefit from. I already have a problem with lighting on KF2's dead soldier (I call him star man) because this software calculates soft normals differently from KF2's. It's more correct, but the slight difference on low-poly models makes the soldier's face look pretty bad in some locations. That could be fixed by having any of a number of facilities, including storing imported normals, alternative ways of calculating them, or full customization... as in directly specifying normals. Anyway, the thinking is if you keep adding obscure possibilities like this in a disorganized way then the software's high traffic interface would be compromised.

How the Utility system differs is it pulls out a side panel that's tailored to the utility type itself. When I was done working yesterday I wasn't too happy with the layout. But I had some ideas this morning and now it's all come out quite nice by the end of the day. Sometimes doing layouts with C++ seems to go slow. Plus I've been improving the UI software itself somewhat today. One day I'd like to apply it to SOM... like for Apple or Linux systems, where Windows won't fly. The right panel is still a little incomplete. It's going to have full key-frames for a texture matrix... but I don't expect I will initially enable all of that for SOM's MDO file format. I'll leave it open for expansion if not. For modeling software it would be too odd to restrict it to SOM's use case.

In the screenshot the Detach button lets the right panel come off in order to be able to work with the main window at the same time. This changes the undo/redo model somewhat since every change then becomes an undo sequence point, and there's no Cancel button. But really there just needs to be a way to get to its panel in the first place. Programming UI stuff for editors takes days too. It looks simple but it may be more complicated than the actual animation logic... especially if it's approached as an art form in its own right.

Repatch (EDITED)

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.

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.

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.