simple machines forum

Patch (SOM_MAP)

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

This fixes a problem with the Add button in SOM_MAP when adding monsters and NPCs on a fresh screen. I put in some new stringent error handling code fairly recently that "returned" the wrong value (0 instead of -1) and also the X and Y rotation fields needed to be initialized to 0 to pass this error checking for better or worse.

Note, this patch has the VR code for my current KF2 demo, but it doesn't have code for the normal HP gauge and compass. The KF2 demo uses an alternative HUD that's like the PlayStation trilogy's. So I still have to work on those. When I finish them there will be a new release, and it will change the default Ex.ini file to use the new OpenGL mode that the demo uses.

EDITED: Thanks to JackTheRipper for spotting this.

Fix

http://www.swordofmoonlight.net/holy/x2mdl.zip
http://csv.swordofmoonlight.net/x2mdl.dll/1.0.0.2.zip

I've updated the x2mdl.exe file in these to fix a bug when converting MDL files into MM3D files that outputs 1 pixel textures if the files already exist.

Unrelated, FWIW I've also updated https://github.com/mick-p1982/mm3d/releases to fix glitches in the scroll bar pixels, and a couple other minor bugs. I've also added a mantis-model.zip file in order to supply a test model to play with. It's the same as SOM's DATA/ENEMY/MODEL/E019.MM3D file.

MM3D upgrade

More info: https://github.com/mick-p1982/mm3d/issues/1#issuecomment-1147825671

Download: https://github.com/mick-p1982/mm3d/releases/download/win32-dec-2021/mm3d-portable.zip

Edited: A lot of hotkeys are remapped. The Help->About menu now has a "Tip" to clear out the keycfg.ini file, and the hyperlink to its URL should now open it into your text editor that's assigned to the INI extension.

This is a substantial upgrade I've been focusing on pretty much since the new KF2 demo I published on the eve of May 1. I don't like the thought that it took me a month to prepare this, but I don't know what else I've been doing.

This model editor is becoming more mature. I'm happy with how the menus and hotkeys have turned out. The main focus of this update is a graph based animation editor, but it's really pretty basic. Maybe the extras are more impressive, but it was the editor that took up the bulk of my time preparing this. There's just so many little details involved that you wouldn't think of.

VR update

RE the last post, in the past 2 days I had to stop using my old work PC because I'm hoping its little CR2032 watch battery died. So I finally had to get set up with the new PC since it's going to take some soldering to replace that battery. I'll be sad if that doesn't fix that PC up, but I'm pretty well situated with the new PC now.

I've been trying to finish up a project that's turned into quite a slog, to add some animation enhancements to the software I use to work with animation models. I think I'll have it finished and published tomorrow. I didn't get as far as I wanted with it. Instead I had to stick with it as long as it took to get to an initial stopping point. I'm planning to switch gears to VR work immediately after I'm done with that. It should be interesting.

I may also be playing some VR, I'm not sure. I got a game for cheap off the PS4 that is Doom 3 in VR. It looks like the whole game plus some expansion campaigns. I did own and play Doom 3. I remember the last boss was a big disappointment. But that means I did finish it. I wonder if I'll still enjoy it or not. In theory I could even get some VR games for the PC now. I'm not sure what's out there.

SVN Update

I've updated the hard animation type MM3D models to remove the last frame and remove redundant key frames. The latter point is nice because it makes it practical to edit the animations or reuse them as a starting point for making new or customized models.

I had to leave most of the SFX models alone apart from the final frame because they weren't coming out right. Probably because they turn a full 360 degrees. I have to look into it but I'm burnt out on this for now. I couldn't bring myself to go through and check every animation for correctness, and I know there are still some redundant key frames in there that could probably be verified/removed manually. I figure if there are any problems (I saw none) they'll just have to be stumbled over over time as usual.

In order to do this I had to recalculate the lighting surface normals, and I'm not sure what the MM3D software generates is an improvement. It has to use its normals if the file is saved. If it had occurred to me before I'd done most of the data entry I may have had set up a new "utility" that could have preserved the original normals. But I don't think it's that big of deal, and really the models need manual work to add smoothing groups to them. Low-poly models are hard to use any kind of automatic normal generation system with. I'd even like to add facilities for hand tweaking normals, to make this editor a beast for low-poly work.

The MM3D software is becoming pretty mature. I've been sitting on what would be a new release for a while. I also found a bug in x2mdl.exe for making MM3D files that overwrites existing textures with a 1x1 image. I have to publish a patch ASAP but I don't believe anyone is using it for this. Mostly this is for converting SOM's proprietary file formats into MM3D files.

EDITED: Just for whom it concerns I think I've decided what I want to do next is to take some time to add some nonlinear animation and animation curve fitting facilities to the MM3D model editor. This is something that's been weighing on me for a while, and I still need to update some of the animated models to shave 1 frame worth of time off the end of their run-times, so if I do this project first I can also rebuild their animations with real keyframes (currently they have a keyframe for every frame that makes any movement, which you can't realistically make edits to) so that that can be rolled into the same SVN Update. I.e. "2 birds 1 stone" (the 1 frame of extra time thing doesn't really impact the existing animations that much, so it can wait a little while longer.)

I also don't like how the shield/weapon animations I made for my demo move, and I think nonlinearity will help that and help me to simplify these new animations. Chances are the original kit that was used to develop SOM's models had nonlinear animation facility, but I won't know for certain until I can analyze their data.

I'm also going to be fussing around with VR for a while, off and on. I have a new Nvidia video card that should allow me to resume my work on that front.

P.P.S. I did some of that work on COLLADA-DOM yesterday (Reply #15) and it hit another blocker for CLANG, so I may put it back down for a while. I also had a horrible time with Microsoft's Remote Desktop because it just doesn't want to work to let my new PC connect to my old PC over my local network. Windows seems to be developing unaddressed bugs these days, like it's sliding backward into its old reputation of being an endlessly frustrating experience. For me it feels awful to spend the afternoon banging my head against an impenetrable problem. And I hate that I can't reliably access my old PC easily.

Incidentally this COLLADA project is my best reference for nonlinear animation. My main job will be to adapt its code (a lot of it written myself) to the MM3D system and figure out a suitable UI for it. For the record, I don't intend to add nonlinear animation facilities to SOM. The "hard" animations have data for every frame, so they can approximate a nonlinear animation with a high number of samples. The "soft" animations can't do this, so they would require new data in the MDL format. The real blocker however is Assimp's model representation, which can't represent nonlinear data. So for now this will be limited to the hard animations. I'll have to be rid of Assimp to progress beyond this, another day.

EDITED: Also, some might like to know that KF2 uses "soft" animation for everything, however many if not most of its animations don't really require this, and I feel they'd be improved to be converted into "hard" animations. It's one of my goals to do this. So far I've had to do it for the arm model for technical reasons. And I've done it for a number of "objects", like the drawbridges and doors for example. It  just makes them more manageable. I'd guess the original art files were not animated this way but were converted so the game could use a consistent animation system. Although some of KF2 animations (like treasures chests and some doors) are accomplished more like how SOM's events are able to move objects. In that case there's usually multiple objects, like the lids on its treasure chests are their own objects (as is their lower, box half) for example.

VR again maybe?

I've just placed an order for an Nvidia 3060 RTX video card (GPU) for my newer system, that I haven't been using for development, that I bought expressly for VR work. I had a bad turn of events with it after I signed up for Microsoft's Windows developer preview program, so I could try some WSL features. Don't ever do that, it was a horrible experience, that forced me to reinstall Windows to get out of it (after it stopped offering me updates) so that I lost all of the time I spent setting up the system for work, although I was able to salvage some of the disk contents for basic things like portable apps (like SOM is.)

After that I was really disappointed that OpenGL is unusable on AMD's GPUs. So I've been waiting for this drought on GPUs (since COVID mainly) to pass. I got a really basic GPU (OEM) from the company (Computer Upgrade King) that put the PC together. I really just hope it's not too loud and works. It's not a powerhouse, but I'm not a gamer, and I just hope it can do video well on my 4K PC VR set. And I hope it's enough for SOM work. I calculated in theory it can fill 63 times the number of pixels I need to run my VR set at 90 fps...

I just hope that's enough, plus it may take longer to compute real pixels with some additional math, but in general SOM does one texture sample per pixel, so I figure it's close to the theoretical limit, except for the effects pass. So I'm hopeful it's within margins, and may even be able to squeeze out some 4K super-sampling.

EDITED: In theory these cards can do ray-tracing. I don't know if it will be practical to test SOM with that, but in practice its graphics are really basic, so it could work. On this card it would just be enough to develop it and see. I think it would run only at 60 fps at 1080 or maybe some slightly higher super-sampling target, downsampled to a square aspect ratio on slightly less than 1080.

Patch

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

This patch fixes some (serious) problems with SOM_MAP's new Convert system. I'm glad I held back on giving this round a work a new release label, since it's still very much in progress. I used it late yesterday to prepare this (https://swordofmoonlight.itch.io/k/devlog/375925/april-2022-demo-announcement) new demo. It seems that was the first time it had been tested.

I also just fixed the magic spell icon in the Arrange Inventory screen, I'd recently broken while ripping out some code to do with the MENU/map_icon.bmp feature.

For the record, the prior patch also fixed a new screen initialization bug when opening save files from Windows Explorer.

This patch also has a fix for the three button fast-running feature that had erroneously popped up the shield when taking damage. Damage could come from falling or normal damage sources.

P.S. Publishing that demo marks the end of a period of more intense work for myself. I'm going to try to take things easy for a little while and see what happens. It's good to let your mind drift from time to time to not miss the forest for the trees in life. I think I mean to pick up the COLLADA-DOM project I've been off and on with over the years. I want to do something completely different, and that's something I've been neglecting too long. I mainly just want to build it with the CLANG compiler and see if the major compilers are getting any better at compiling C++ templates. (Microsoft's is way ahead of the pack in this area, but still I believe it could/should be much, much better.)

Attachments

 KF2 Ruined Armor.png 

Yesterday I worked on the remaining "item" models and went down a particularly absorbing rabbit hole with this model (pictured) because of troubles with the design on the stomach.

I actually started on it the day before (lately I've been in town and had a tire explode on me) and got derailed because of upscaling artifacts on the same design. As a result I decided the upscaling system I'm using has to deemphasize diagonal pixels, and this is a significant improvement, although it makes it more generic looking perhaps. There were noticeable unsightly artifacts in some of the textures, like the cliffside beach walls' one, that are eliminated now.

Still, after making this fix, how the design on the armor (pictured) is executed seemed not good enough for this project. So last night I did the best I could on short notice to try to remake the stomach area. In the original the gray gradient on the stomach is part of the design's texture. This looked too bad, much like the ghost, so I tried to remake the stomach to use the same gradient pattern as the rest of the armor, and change the design to a decal.

I couldn't get the colors I wanted, so it's quite a compromise. This is because it had to be an additive transparent decal. This can be improved later when I plan to switch the art system over to outputting a texture format that can enable alpha data alongside the RGB color. As for the decal itself, I've just upscaled it, blurred it and resharpened, and made a few hand tweaks. It will all have to be redone (hopefully better) when the rest of the set is done. In theory it wouldn't be that difficult to remake the design(s) from scratch. I'm sure it would look better. It definitely requires more resolution. I want to be proficient with SVG at some point. Surprisingly tools like GIMP don't offer any good automatic solutions for upscaling. I looked into some of the recently popularized solutions for upscaling old games and media but found nothing of use.

I think I'll be done with my plans for the new demo by the end of my day today. I don't know if I'll get to generating the final game files, I'll find out. I think I've settled on names for all of the "items". (Edited: Not just those in the new demo.) For this armor set I've decided against calling it "Merrel Ur's Armor" etc. That's what the Japanese says, except for the gloves and boots it calls Ruinas. I looked up the katakana for those two, I think it probably means something like "ruinous" as related to ruins, but most common associations online relate "Ruinas" which sounds like a proper noun. It might be related to something in Spain, I can't remember what I found. Sometimes Japanese loan words come from older pan-European sources. I was thinking of calling them Ruinas, but I've decided it's too quirky and "Ruined Armor" etc. probably scans better in English. The word "ruinous" I consider too baroque, or even too on the nose if it's meant to portend  tragedy. In English "ruinous" is more like cursed, and I think the meaning in Japanese is closer to ruined, as in both archaic and dilapidated. I guess those two pieces of the set are named differently because they've somehow become separated from the others and handed down as heirlooms. As for "Merrel Ur" I just find it too clunky. I think I'm going to call the arm band piece Merrel Ur (Something) since I think it's said to be inscribed with a message from the artisan who made it. The artisan's name is given. (Sorry, I can't recall it now.) Because its design matches the rest of the pieces from this it can be concluded they once belonged to "Merrel Ur".

Note, the pieces are covered with "runes" (of sorts) however the Japanese does insert an "i" sound after the "u"'s that suggests it's not meant to be read as "rune armor". Currently I have the arm band called Merrel Ur Pass, suggesting it's a badge conferring a title which allows "passage". This is from my future plans for a KF project, which I don't mean to tie into this project necessarily. But there is a problem that this item needs a name that works in English which this overcomes. It suggests the arm band is more than just a decorative flourish, and that perhaps Merrel Ur is a title instead of a man. although the name is used to denote the last man (or high elf) who held this title. (I think maybe the "'" (apostrophe) doesn't render so well in the Japanese font SOM uses, so I'm leaning toward avoiding it in names. It's a little too wonky for video games anyway. (If this is its name it might be worth adding some kind of bonus section that's only accessed by wearing this arm band.)

[Edited: I think I meant to also say here that I'm seriously considering calling one of the rings Lulufon's Ring, drawing a connection to the Shadow Tower series, so I'm not taking this extremely seriously. This ring is really called the chirei ring, which if you know from playing Megaten for example, chirei are spirits of the earth. But the only real use of this word in Japanese is for a semi-famous play called Earth Spirit about a wild woman of the new century named Lulu, and anyway, it looks like something she'd wear, and I can't think of an English translation that scans, so I'm thinking about using this just as a pun. Lou Reed--a hero of mine--wanted to raise a production of this play, Lulu, and named his last major album done with Metallica Lulu. This is moreso me leaving my own (esoteric) mark on this project as an Easter egg. (Ascribing to it some literary pretensions for good luck.) (https://en.wikipedia.org/wiki/Earth_Spirit_(play))]

Anyway, this isn't exactly how it looks in the SOM game. This screenshot is out of SOM_PRM (actually ItemEdit) which has different lighting. The original game has false lighting when picking up items and in the menus. SOM uses the environment lighting, although I suppose I should offer an alternative. Or it could be the item itself has false lighting. To fake this I turned down the "diffuse" component and turned up the "emissive" component.

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.