Sword of Moonlight > Devs

Exit: Passing between worlds

(1/4) > >>

Holey Moley:

--- Quote from: http://www.swordofmoonlight.net/archives/sword-of-moonlight/2022/02/passing-between-worlds/ ---An important milestone has (finally) been reached by Sword of Moonlight by realizing the original King’s Field single environment experience of no “loading screens” after hopping into the game. This is something King’s Field fans always gloat about since it was pretty novel back in the day, and even to this day lately I’ve played a little bit of some PlayStation 4 games and am finding myself shocked how much of the time is really just spent on minutes long loading screens. In my opinion I would happily remove the high fidelity visuals in these games for practical seconds long loading screens. Of course, no load screens would be ideal.

I believe From Software published Sword of Moonlight so that it would be carried away by its public. This is a crucial facility no King’s Field Making Tool is complete without. I believe Sword of Moonlight would not have been published in this form except as a challenge to take it up. We should not forget that Sword of Moonlight is modeled on a sword after all.
--- End quote ---

I wasn't sure whether to make this a release or a demo because I still need to battle test it by building out a full 2 map system using my KF2 project (it's long over due for another map to be added to its demo on itch.io and I've been postponing that until it could properly replicate KF2's no hiccups experience.) Both because I was thinking of making it a demo and I kept shooting myself in the foot with patches to the current release, all the way up to today, I've decided to just write this blog post and refer it to the current patch, which I hope is finally stable. Below are links to the patch files. I'm also going to be posting any future patches to this topic/thread to mark a point of departure.

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.6.zip
http://www.swordofmoonlight.net/text/日本語/最新.zip (Japanese)
http://www.swordofmoonlight.net/text/English/Neutral.zip

I've been working on this since the last weeks of December, last year. Although in that month I mainly did preliminary work (some studying/planning) by adding layer elements to events that take map coordinates. Technically I think it was possible to just refer to the base layer and set its elevation setting to coincide with a desired layer's elevation. I've tried to cover layers fully in the event system in this patch/quasi-release/project/task. This also includes new elevation limits and a rotation option for action based events and trip zone events. Note, I think in terms of activating things everything is now covered so that activation doesn't span "infinitely" above and below. IOW the default range is now limited to the object or character model bound to the event. (Also there's a "breaking-change" for the circle trip zone which had added its radius to said object's radius, which is no longer done. I've added an option to re-enable this, however I have a feeling the restriction to the object's base/height is more likely to break old games. I had a thought today to roll all of that together.)

One new event "module" (I think I'm calling these modules now, even though I have another plan for literal C# modules for SOM, but that will offer a plugin system for events too, so they will technically be modules too) was added, filling out the last remaining slot in the list (before it requires a scroll-bar) as if fated to fill in this slot (why was a slot left unfilled?) much like the layer system filled in the spaces left by the layer system From Software ripped out prior to publishing. Anyway, this event module/command/operation/instruction (call it what you want) sets a secondary map to start loading in the background. This requires a multi-core CPU. They've been standard for many years now and current Windows systems require them to function, so unless there is demand it will just be a minimum requirement from now on to use this. I did some timing tests and I think that a single-core CPU just won't be practical given how slow Windows is to access files (I'm a little surprised it can stream the BGM file, and this may be a bottleneck) at 60+ frames per second, so if demand arises the only likely thing I can do is add a way to disable this so that loading screens come back.

As a starting point this system functions just like the King's Field games would have functioned (I think all of them do so this way anyway) by connecting two maps at a time. Technically more than two "maps" (i.e. levels) will stay in memory for a few minutes, but two maps will remain in memory. Memory just means they're not on your disk drive. I'm pretty sure from what I've seen online that KF2 duplicates parts of its maps that intersect on the threshold. Currently this duplication is required with this existing system. I am interested in pushing it further down the road to actually display the other map against the current map. Logistically there is only one active map. Things like events only run on one map's events at a time. Under the current system the maps switch out instantaneously. If a more literal stitching system combined their images however, there would still just be one set of events. I do plan to try to carryover monsters, however presently, any monsters visible on map change will just blink out. This version isn't fully complete. To avoid that you can set up doorways (gates) like you will find in most KF games' inter-map corridors.

Edited: To get this new style transition working the new "relative" setting has to be checked on the map change event module. Technically this makes it so the "event" can cover every tile inside its trip zone, but it's also doubling as a "new mode" switch, since the old mode is limited to a single tile, almost like a teleportation booth. (I've thought about upgrading the old mode but it's not clear-cut that the new semantics can work with it without losing something in the process.) One other small thing is you need to rebuild the MPX file (compile/prepare it) since MapComp needs  to add some new information to it. (What tile/layer things belong too. This is information it used to emit but was disabled.) Note, it now defaults to "relative" mode.

The fog and sky and BGM is smoothly transitioned, however there's a larger flaw in this version than monsters blinking out, that is there's no provision for transitioning lighting. I have a plan for this, but it's going to have to wait until later this year, and will be a big project. In the meantime there are some creative workarounds for this if someone is really keen on using this in the next few months. What can be done is map geometry can have its diffuse lighting component overpowered either by maximizing the "emissive" component or using the new per-tile ambient system my KF2 demo is using to overpower the ambient component. At that point you will be stuck with having to fake lights by baking any lighting into your textures. But this approach can create a liminal corridor which both maps (with different global lighting) can agree on.

The solution I have planned involves more per-tile settings for most of SOM_MAP's settings. Even ones you wouldn't expect like the fog and names and music. This system should allow for little pocket regions within the maps themselves. (Edited: There will be an option to set the sky model on a per-tile basis, but it will most likely only apply to the current tile/layer and so anytime the sky is swapped out will have to be obscured from view somehow. The sky transition system blends two skies, and if it were possible to blend per-tile skies there would be a "combinatorial explosion" and tiles are square, so it would be tricky to smooth out jagged diagonals between tiles. That said I won't completely rule out tackling this one day.)

Oh, one more small limitation is you should stick to WAV files for music. The transcoding system I set up a while back isn't super efficient, but it will no doubt incur a hiccup if you try to mix it with a new nonstop map transfer. I need to roll that into the new art system cache x2mdl.dll is using so that the conversion to WAV is done one time and saved until the cache is emptied. I will do that when I add sound effects to the art system.

Another little something worth mentioning is I've tweaked the opening movies to load the first map in the background so that the game will load faster, even if players just try to cancel it ASAP... it only needs a second or two, which it can take to do the fade out effect. I'm also going to add this to the Continue screen, but I haven't yet. It will need to start loading while its Yes/No menu is shown. Also if you use do_start/start_mode=1 ("KF1" style) it will load the first map as soon as the title screens begin. Ideally SOM can be a no loading experience like the old 16-bit consoles which used ROM cartridges :713:

Edited: For the record, I want to take some time off to work on art for my KF2 project. So I'm not going to be working on SOM features for a while, and when I return to it I plan to focus on a few things that will make a new KF2 demo shine. One other odd thing that made it into this patch is a new way to turn off the menu system on the item pickup screen. This is how most of From Software's games actually work. SOM works differently IOW. But this new system still feels a little bit unfinished. Obviously it needs animation, but I wonder if it needs something else. (A sound perhaps?) Anyway, you can try it by setting it to Off in the Options menu, or pressing one of the auxiliary face buttons on the pickup screen. Even in an unfinished state it's actually good to get rid of the old Options setting, since it was totally nonsensical (and implemented completely wrong I found out) and so would otherwise be interpreted as the mark of unprofessional product.

https://www.youtube.com/watch?v=TgQUZcwd-JQ

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

This patches a serious SOM_MAP bug that might be in the current build/patch which will fail to save your MAP file if encountered. It's down to random chance, so you want to update this to not lose work.

I'm not 100% certain this needs patching, but I can't test it because my map that encountered the bug depends on the new art system, which isn't available in the current build/patch. (The bug happens when the buffer happens to end at the last tile in a string of blank tiles at just the right spot... probably because of a sanity check I recently added.)

Another thing I happened to notice today is bugs in a few places around the vertical limits I added to event triggers/activation a while ago. (I really messed up in multiple places here: 1) was a rounding mistake with negative values; 2) monsters were checking an NPC parameter to determine if they're alive or not; 3) square triggers were using the round trigger's parameters.)

enhancements

Everything seems pretty stable right now, so also in this patch is support for the last two model formats under the new art system, which I've been using lately and it's really a vast improvement for building maps with custom art.

I haven't yet added some new advanced features to these formats, but they're as good (better) than the existing x2msm/x2mhm option. One thing to look out for is untextured models are still treated as wall-to-wall CPs, except for when converting to MM3D, which I've added some code to its path to tease them apart in order to be able to convert MHM files. If you put x2mdl into MHM mode it won't do this, but the art system doesn't do that, so models either need to be textured, or make the MHM geometry slightly transparent to defeat the CP detectors. (I don't know if I can fix this really, the best that can be done is to only treat lone triangles as CPs, but sometimes low-poly art might have long triangles too... luckily MSM files should be texture mapped because they don't have materials even if you wanted to do something more like the original KF.)

Another thing it doesn't do (yet) is split models up into MSM and MHM parts. IOW the art system will just output both an MSM and an MHM file, so you don't just use one of them if you just need it for MSM or MHM for time being.

Edited: Another secret I added today (I guess SOM can hold secrets if KF does) is holding the Alt key when clicking in the workshop tools (PrtsEdit, ItemEdit, etc.) will open up the model in your 3D editing software associated with your art file's file format. I intend to make this available from outside the workshop tools too. (I also had a good idea to make A and S and E set elevation values in SOM_MAP. A for add, S for subtract, and E for equal/elevation. That way you can do it left handed! Unfortunately I still have to work on this...)

Holey Moley:
EDITED: For 1hr the following patch was bad (I hate when this happens) because I forgot I disabled the fix to try to test it before realizing it wouldn't work with the art system absent.

Patch Part 2

http://csv.swordofmoonlight.net/x2mdl.dll/1.0.0.2.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.6.zip (see EDITED in bold)

The SomEx.dll link is because I botched the earlier patch, and I'm merging the warning I posted into this post.

As for x2mdl, I noticed a problem with my wall writing decals in my KF2 project and was convinced x2mdl was outputting bad colors in the textures somehow, and so I finally did something I've been meaning to do to optimize how x2mdl outputs textures from back in the day when they needed to be downscaled to 256x256 in 16-bit color for MDL files. (Originally it was actually using D3D to do this color conversion, but it failed once on a GPU or device that didn't support it.)

Well, it turned out at some point when I had lost the original texture, and only the TXR file was correct. After I started using the new art system that TXR was no longer used. So IOW my scramble to fix x2mdl was for nought there. However, I also realized it was still downscaling to 256x256 and MDO files actually support much larger textures than this. I'm not sure how many mipmap levels som_db allocates, but with do_mipmaps it doesn't even matter. Moratheia has 2048x2048 textures that I know of, so at least that big (which is too big) probably works without SomEx.dll.

So I've fixed that problem. The only textures in SOM's larger than this is 3 of its 4 sky textures I enlarged to 512x512 in the original release for this release. I didn't realize they were getting hacked back down to 256x256. To see that benefit it's necessary to clear out the shortcut/lnk files in the map/model folder for sky files (called sky) or delete that folder from the temporary cache.

I've also updated these files in the TOOL folder. I meant to do that earlier, but I'm glad I forgot to now.

I think x2mdl should run a little faster now when converting models. It actually was pretty optimal already when updating textures by themselves, and didn't have this 256x256 problem then (actually that's probably why I missed the sky kneecapping come to think of it) however, in practice it still generates the textures when converting the models, and usually that comes first unless the model's texture(s) already exist with shortcuts. Anyway, now it's almost as good, but still allocates a texture in video memory in case it needs to be downscaled for the MDL file... although I can fix that too come to think of it (next patch.)

Holey Moley:
off-topic


--- Quote ---(I also had a good idea to make A and S and E set elevation values in SOM_MAP. A for add, S for subtract, and E for equal/elevation. That way you can do it left handed! Unfortunately I still have to work on this...)
--- End quote ---

Sorry this really isn't on-topic, but just as a note... I worked on this this morning, which will be in the next patch, whenever that is.

I first looked at SOM_MAP's hotkeys. They're a little unusual, but they all work. I've never learned them I guess because they're not intuitive. I remember seeing them in the manual. Here are some of the more odd ones...

Ctrl+1 through Ctrl+3 choose between the 3 different views or tabs. This also works in SOM_PRM.

Ctrl+I opens the events menu. This one seems odd, so does putting hotkeys on the right side of the keyboard. I wonder why I of all letters? Maybe I should add a Ctrl+E option come to think of it. Maybe I is for Japanese something?

Ctrl+T opens a game (a test).

Ctrl+W opens the MPX compiler menu, but doesn't compile it.

Ctrl+P is the same as Ctrl+Click used to be, which copies the tile into the current "pen" and syncs the palette viewer.

Ctrl+Left (and Right) does horizontal paging. Up/Down don't, but I think PageUp/Down does. I guess I should add those come to think of it.

new SOM_MAP hotkeys

New ones I've added (mainly oriented to using a mouse with left hand on keyboard) are A to add 0.5 to elevation, S to subtract. E to assign elevation. Note, these 3 don't currently work with Undo, but I will probably fix that if it ever starts to annoy me...

C does same as Ctrl+P. V does same as Enter/Space but doesn't depend on the Ctrl key or CtrlLock button. I recommend using V now, but I also made Ctrl+Enter/Space work with CtrlLock off, which it hadn't previously.

Ctrl+D now deletes tiles. F and G flip the tile, equivalent to 2 turns. They're the same actually, except you can press Shift to make them do 1 turn, like Z and X. Useful to avoid moving your finger between them. Plus F and G are closer to V.

Holey Moley:
Important Patch (Critical)

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

Late last night I ran into yet another problem saving layer MAP files. I can't ever seem to complete that project... I really feel like at some point I need to rewrite the MAP file input/output code from scratch, but maybe this is the last time... knock on wood. (What was happening was some code I wrote that juggles some data between the files failed to give READ permissions to the file in question... which explained why some junk would appear at the end of layer MAP files... but the real problem I suppose is I added some error handling code that reported errors, and I thought it would catch my attention in debug modes, but it was incomplete. I think this was the same problem the last time I published a patch the other week... i.e. new error code causing the load/save operation to give up where previously it would've carried on.)

What's a wonder is how this didn't become a problem sooner. (This is a common refrain for bugs... really the problem bugs are the ones that get masked by shear chance instead of backfiring immediately.)

Last night I also found numerous new problems I introduced to x2mdl around textures mainly... and I chanced upon a realization that som_db.exe ignores the last frame in hard (skeletal) animations, and so I've adapted x2mdl to reflect this behavior by clipping the final frame down to 0 time... this means the last frame is shown at the end of the animation but for 0 amount of time. I.e. you won't see it unless you freeze the animation (or set the cursor) on the end. This is actually how animators usually work, so this is a benefit. The only problem is now I have to go back and regenerate all of the hard animation MM3D files from the last release a while ago. (Note, technically this topic/thread is still maintaining that release.)

Navigation

[0] Message Index

[#] Next page