simple machines forum

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.

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.