simple machines forum

Please login or register.

Login with username, password and session length
 

News:

Remember to make your own backup of posts before submitting.

 
 
Pages: [1] 2

Author Topic: EXIT: Long time no update! (Sorry about that)  (Read 984 times)

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« on: December 14, 2021, 03:57:22 AM »

I’m pleased to announce I’ve completed the most grueling round of work I’ve ever done on Sword of Moonlight and all the new files are online for the taking.

I did two long release cycles back-to-back except the first was not published because it didn’t have anything to offer to the general public. What it was instead was a big task to bolt on an OpenGL based alternative mode for SOM because new VR peripherals for PC don’t work with Direct3D 9. I chose OpenGL because I’ve used it plenty in the past and the newer systems like Vulkan and Direct3D 11 or 12 are completely different in terms of their design and are much more complicated, so it would be an even bigger effort to write code for those and it would be very alien to my past experience.

Once I completed that task the OpenGL performance wasn’t good enough, so I wanted to experiment with the dynamic vertex buffers, since SOM only uses dynamic buffers, which OpenGL is not good for. But to do that it’s necessary to rebuild all of the model files, like the MDO files, and remove the MDL files, so I realized that the time had finally come to do a project I’ve long been considering to unify SOM’s model files and build an art system into SOM to make it aware of the art development process.

SOM’s animated model files inherited a lot of quirks from the PlayStation’s design and the model format used by Sony’s SDK. These were unsuited for PC. SOM has a better format called MDO but it’s not animated, so you can say that its team were relying on this Sony style format as a crutch that shouldn’t have been published to an unsuited system. As a result this format has to be converted into a MDO like layout when the game loads, which is bad for performance, and both formats had used very small vertex chunks, which seem to be almost a clerical error, that would make them 32 times smaller than the target vertex buffer, which always remained until now only 1/32nd full, the rest going to disuse.

Working on this ended up being the culmination of all of my time working on the model conversion tools since I originally started working on SOM. These tools were the first things users at the time asked for, however I developed them and their reception was lukewarm at best, so don’t give people what they ask for I guess is the moral of this story, or don’t expect them to be grateful. I never know what to expect in terms of details when I start a programming task, it’s hard to predict, but this project turned into a never-ending slog very fast, to the point for the first time in my career I did what video game developers call “crunch” for weeks on end. I didn’t do this because I had to hit a deadline. I did it because if I hadn’t I would grow crazy forever pushing this rock up a proverbial Sisyphean ramp… and at least if you focus singularly on a task it tends to help to distract from the difficulty and monotony of the task. That was my thinking anyway. In the end it took hundreds of hours and add that to the hundreds of hours that I’ve already poured into the conversion tools, which had to be entirely battle tested for this effort, which itself proved to be a big part of the work.

In practical terms how to think about this development is SOM now will act as if it works directly with your art files, but in fact what it does is monitor changes to your art files and when they change it rebuilds its proprietary runtime files to reflect your changes. This can take a little bit of time, so it will be experienced as a pause with a busy cursor, or the splash screen taking longer to lower.

To make all of SOM’s components comply with this change it was necessary to upgrade its level editor. I had to rewrite all of that tool’s graphics from scratch. But this is good because it finally brought it up to the same standard as the rest of SOM, where before it had been noticeably lacking; another thing I long wanted to address. Its mouse input model has also been upgraded, and the screens that use gray and white squares has been upgraded to show an impression of the tiles underneath them so that they’re not so disorienting as before.

In addition I had to do forensics on all of SOM’s built-in models to reverse them back to the state of art files and archive them in an MM3D format I’m using for my King’s Field II project. You can download pretty competent 3D modeling software from my Github to work with them. I made some corrections to them where I found major non-cosmetic issues, however I haven’t yet made the effort to fix their many blemishes, although this work has moved that goal within reach. I will try to speak to more details in the forum post attached to this blog post.

Note, for this update it's very important to use SVN Update to refresh all of your files because that's the main part of the change. I usually post a link to a new SomEx.dll file like this (http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.6.zip) one, but this file will be updated with the rest (although you'll still be prompted to upgrade it, which you should in case it's patched.)

For English readers, there are new buttons in the language package here (http://www.swordofmoonlight.net/text/English/Neutral.zip) which aren't extremely essential, but they offer a "Convert" feature in SOM_PRM and SOM_MAP which enables you to manually convert all of your art files in bulk. In SOM_MAP this is useful for making demos since you can tell it to generate data folders with just the runtime files that you need for a set of maps and nothing more, and use that as the basis for your game demo without including art files. (Edited: There's also some new error messages in them.)

This manual conversion system is a little bit different in that it also copies over runtime files where it doesn't find art files, so it's not strictly the same as rebuilding your cache to avoid running into load hiccups/waits, but if all of your models are represented by art files then it will be the same thing. All but a few weird MDL files that my x2mdl tool couldn't faithfully recreate--because they look like solid control points to it--are converted to art files, although I've not yet gotten to the level geometry files. The game never sees level files (it sees the compiled MPX files) so technically they're not part of the runtime file set, but I only neglected them now because I couldn't take anymore (delay) before publishing, and I hope I get them done in time for the next release.

The Convert button in SOM_PRM is supposed to let you select a subset of items on each screen, however it doesn't yet have a multi-selection model, so it just has to convert everything on said screen until I can get around to it. As for SOM_MAP I think it should generate everything. At first I thought it might be lacking, but I realized it was simple to also include SOM_SYS's starting inventory in its output, and also some odd models like the arm and shadow and gold coin. So it should build out a complete demo. In SOM_MAP this button is in the compile window called Prepare in the English language package.

For the new MM3D models you can use the program here (https://github.com/mick-p1982/mm3d/releases) called portable-mm3d.zip. I updated it last night but intend to do a little more work soon to improve the appearance of the texture model mode with respect to lighting and selection because with SOM's models its lighting is overpowered to the point that it may as well not exist. I've put a lot of work into this modeling software, but I didn't develop it from scratch. The original version was called Misfit Model 3D. I found a newer version (fork) called Maverick Model 3D. I'm calling my version (fork) Multimedia 3D. The others aren't compatible with these files.

The art system can work with any format in theory, but I'm not sure if other exchange formats are able to fully represent SOM's feature set, even though it's relatively simplistic. 3D file formats are just weird and nonstandard... to this day there's no standard thinking in terms of how to encode animations. The main page to watch for these things is this (http://www.swordofmoonlight.net/bbs2/index.php?topic=319.0) one. The x2mdl tool that I've developed originally as a tool for making MDL files is based on Assimp. It's an older version of Assimp but I don't think it's changed that much in the meantime. In theory what formats it accepts should be viable art formats. At one point I spent a good amount of time rewriting Assimp from scratch. That code lives in a code/Daedalus folder in the code downloaded with SOM. Unfortunately I never switched fully over to it, but I hope to one day because the x2mdl code (code/x2mdl) is very messy even by my own standards. I just can't commit to that right now, and what I didn't port much of to the rewrite was the actual importer code. That said I don't stand by the importers other than the main ones I've worked with and developed myself. I recommend the MM3D path if you can stand it, but if someone wants to work with a different format I will do all I can to make that work. I chose MM3D for SOM because I'm fully in control of it and it's a very close fit.

Something all of Assimp's loaders lack is support for soft animations. That's one reason I forked it since there was no movement happening in that direction. I've only implemented soft animation paths for the import code I've written myself. Another reason I forked it is I strongly disagree with how its importers work since they throw away connectivity data and don't work efficiently the way most proprietary formats work. (Not only are they inefficient for performance they're not good for writing maintainable/legible/brief code reflecting the structure of a target format.)

EDITED: I'm going to take a much needed break of sorts for a while. I hoped I could do another release before New Years but this one spiraled far into December, so I'm not expecting that to happen. I really want to pick up my King's Field II project so the next goal I have in mind is to implement level streaming, a la KFII and KFIII, that is always on everyone's lips when talking about King's Field but From Software neglected to include in SOM. Their team implemented very little more than the bare necessities to make a half passable PC version of the original King's Field (1994) that they only published in Japan. I'm not sure what will be required to implement streaming, but it feels like the right time to do it. I hope it's much simpler than this project turned out to be. Because it will deal a lot with level data it should be an opportune time to try to finish this art system with respect to level geometry. Level files also include the MHM clipping format which I intend to extend to static objects at the same time, hopefully included in the next release. For animated models my plan is to put clipping data in the MDL format. BTW, I forgot to say that how the new system unifies the model format is to combine MDO and MDL so that what you get is a hybrid where everything is a MDO file except there's animation data inside the MDL file, so neither has been discarded IOW.
« Last Edit: December 15, 2021, 01:58:57 AM by Holy Diver »

Holy Diver has 2717 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #1 on: December 14, 2021, 10:31:24 AM »

patches

I noticed the new MM3D files made from MDO files had UVs that weren't on the origin (0,0 to 1,1) but offset by 1, so I've gone ahead and repaired them and x2mdl too. I almost decided to remove x2mdl.exe because it's too heavy to repair like this, however instead I've packaged it with x2mdl.dll so it will be updated at the same time. This required patching Somversion.dll because I'd never actually tested it with more than one file. Luckily I'd programmed everything this requires but just had to fix a few things since I'd not tested. (Edited: I actually did remove x2mdl.exe, so it requires updating x2mdl.dll to get it back.)

The x2mdl versions in the TOOL folder don't have this fix, although it's not likely to be a problem. The patch links follow in case anyone already downloaded these versions.

http://csv.swordofmoonlight.net/Somversion.dll/1.0.4.6.zip
http://csv.swordofmoonlight.net/x2mdl.dll/1.0.0.2.zip

SVN Update is required to fix these MM3D files, but it's justnot even a cosmetic fix unless the intent was to edit these files... as in the bad UV mapping doesn't change their appearance since they wraparound.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #2 on: December 17, 2021, 01:03:35 PM »

Again, the software for viewing/editing MM3D files like these (http://svn.swordofmoonlight.net/Sword-of-Moonlight/data/enemy/model/) can be got here (https://github.com/mick-p1982/mm3d/releases) and I've just updated it to fix an old problem where the sense of material/lighting was inverted so that there's now visible lighting in the texture mapped mode and the selection triangles are lit up red.

The old software was set up to set materials by default to 20% ambient and 80% diffuse, which is more like how you set a light, whereas a material should be 100% on both by default. Likewise it set its lights (which aren't currently customizable) up like materials to compensate. I only recently noticed it was doing that, which explained the lighting problems.

I was thinking about adding some controls to adjust its lighting and background color (bright background is not good for SOM's additive blend materials) but I've stopped at this fix for now because I'd rather be working on SOM in the next few days. I'm pretty eager to get back to work in some capacity.

Some of the new models that I edited I dropped the ambient material level down on them so I could see their lighting. It won't effect how they appear in SOM but it will make them look a little darker now until they're corrected.
« Last Edit: December 18, 2021, 09:54:05 AM by Holy Diver »

Holy Diver has 2717 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #3 on: December 18, 2021, 12:06:07 PM »

PLEASE MAKE IT STOP (PATCH)

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

x2mdl.dll is updated for SVN Update

I shot myself in the foot with one of those patches that needed different behavior for MDL output than MM3D output (control point stuff never ends) and also ran into a problem (probably related now that I think about it) that was applying a CP rotation to the whole model for soft body models like the Slime. Basically a huge class of models I didn't notice. I really should do more testing before publishing things. I never learn. I really don't like posting these notices, but it seems the correct thing to do.

I think I'll delete the earlier patch notices to save readers the trouble...

Quote from: Good info from the older patches
A problem with this new system is if a bug gets into the cache or if something goes wrong and x2mdl.dll doesn't finish then the cache has to be invalidated. The simplest way is to remove the shortcut file if you know the model name (try SOM_PRM to see the model) or delete the files from the (%TEMP%\Swordofmoonlight.net\art) cache folder. I think eventually the tools like EneEdit will have a menu option for managing this, especially if it becomes a problem.

EDITED: Some good news, the optimized release mode build of x2mdl.dll runs way faster than the debug version, so the wait isn't really noticeable on single models, and probably won't be a big deal for converting lots of models when a game loads either.
« Last Edit: December 18, 2021, 12:19:46 PM by Holy Diver »

Holy Diver has 2717 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #4 on: December 19, 2021, 03:53:57 PM »

I got my KF2 project switched over to using this system today. It was very convenient. Because with it I'm putting the MM3D extension in the profiles it required some additional work that I've quietly patched. The x2mdl program also needed some changes to support some unique things that would only be of interest to anyone wanting to make custom art with it. It's been patched too.

I'll be eager to get the MSM and MHM files working to be so convenient also.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #5 on: December 22, 2021, 06:35:52 PM »

Feature Patch

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

These are patch files for a potentially helpful commenting/annotation feature I've been working on (finishing up from when I dropped the project 3yrs ago) in the past two days. It also adds more aggressive categorization to the list on the right side of the image showing the big fat comment button below.



I've written more about this image here (http://www.swordofmoonlight.net/bbs2/index.php?topic=257.msg3255#msg3255) in this old topic/thread in case anyone's interested in it. It speaks to an eventual plan to add advanced programming to SOM's event system by tying this feature into the script/translation system, which can include normal open-ended "scripting" in the style programmer's prefer to these limited/clunky visual programming systems.

P.S. I'll probably get around to adding some balloon tips to this, and it shouldn't be hard to add a special style to the comment lines, I'm just not sure what style. Maybe they should be a little more gray? Bold? Or a certain color? I'm a little unsure.
« Last Edit: December 22, 2021, 10:02:51 PM by Holy Diver »

Holy Diver has 2717 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #6 on: December 27, 2021, 08:34:25 PM »

Yearly GameFAQs update

I don't know how many people still read GameFAQs but I've committed to posting a yearly update there since it's one of the few places that has a SOM section and it used to be a major source for game stuff when I was still into games, mainly back in the 20th century. So that link is below!

https://gamefaqs.gamespot.com/boards/958393-sword-of-moonlight-kings-field-making-tool/79828570

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #7 on: January 05, 2022, 02:24:46 AM »

load time regression patch (important)

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

Edited: I've also updated these files (and code files) in the SVN (Subversion) repository, so SVN Update is another way to update to this patch.

Since I'm working on better loading maps I lucked into noticing that the Microsoft system (IShellLink) for extracting targets from "shortcuts" was roughly tripling the amount of time it takes for a game to start up since it takes about twice as long as it does to read a file. FYI the new art system introduced by this release uses shortcuts for timestamp files.

Luckily I figured out a different way, which is not online as far as I know, however it's perhaps uncommon to use shortcuts for things like this, so that's unsurprising. I wrote about this in a recent topic about map loading. (Edited: http://www.swordofmoonlight.net/bbs2/index.php?topic=67.msg3267#msg3267)

I also added the technique to x2mdl for when it checks if it needs to extract textures from models or not, and this was another lucky find because I noticed that it was always failing this test owing to not equating slashes and backslashes in file system addresses. I chose to use slashes with the new models, however shortcuts use backslashes. I should've thought of this in the first place. This should speed up conversions when the textures are already converted. (Assuming reading a shortcut file is faster than writing a texture.)

This last bit is really questionable if I should even mention it, but last minute I also wanted to add something, to truncate the data in the MPX file to speed up load times, since normally it would have data for every entry (like all 512 objects) even if the slots aren't filled. This makes the files smaller and load faster. Another odd thing about MPX (and MSM) is the texture section isn't aligned on 32-bit addresses, and this throws off the rest of the file, so that many crucial parts are unaligned, and this isn't good for CPUs since they will run more slowly. It doesn't matter in the game because each section is copied into its own designated address in memory, however if the whole file were to be loaded into memory, these parts of the file would be unable to be used efficiently without copying them out, so it's important to align files. Most of SOM's file formats are so aligned fortunately. And not by accident. So it's odd these aren't. What I did this afternoon to fix this (going forward) is to add some blank textures to the texture section to pad out the extra space. I'm going to do the same for MSM files when I add MSM to x2mdl. I plan to do that sometime in the early parts of 2022. If I don't do it soon it's because things are dragging out... it's in the front of my immediate plans. (Edited: I just checked and found a note that SOM_MAP is sending the unaligned MSM data to Direct3D. Edited: I wouldn't be surprised if MapComp is doing unaligned reads too. If so converting the MSM files should speed it up some.)
« Last Edit: January 05, 2022, 07:16:38 PM by Holy Diver »

Holy Diver has 2717 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #8 on: January 05, 2022, 05:33:50 AM »

SOM_MAP shift+drag patch

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

I'm not sure how long Shift selection with the mouse has been broken, but I failed to include a fix in this release with some improvements to mouse input.

I should've dug into it, I couldn't think of a reason it shouldn't work, unless it had never worked. But that seemed unlikely, but there's many unlikely things in SOM. The problem turned out to be something out of left field. In inverting the sense of the Ctrl combo by default, I changed some code that used an unusual approach to calling this subroutine, via a register. I didn't think that the same register would later be used for the Shift test, but that's what was happening. I have a strong hunch this bug was only introduced in this latest release, but it's hard to go back and test this theory.

I'm trying to make this release a stable, long term release, since it jettisons all previous versions of SomEx.dll, so I've gone ahead and updated the binary once again (I wish I'd waited a few hours ago to do this, but I just found myself at the end of my day with enough time and desire to do a small task.) It would be nice to establish a long term release because this release broke from the past, so there's nothing to fall back on. However the next release--or maybe the one after--will have the same problem as this one when the MSM files are changed over like the MDO and MDL files are changed by this release.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #9 on: January 06, 2022, 07:15:54 AM »

Moratheia demo patch (and NPC skin bug)

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

Update: I remembered last night after going to bed that there was a clerical error that broke the skin system (and caused everything to go haywire) so that this fix is not strictly limited to plain/legacy MDL models, but also affects the new MDL+MDO models. IOW this patch is required for "skins" but I'm not patching the TOOL folder because this is an advanced feature that SOM's own models don't utilize.

I missed some things for old projects not using the new MDO+MDL system like this (http://www.swordofmoonlight.net/bbs2/index.php?topic=154.0) Moratheia 2.1 demo for example.

One thing is the "skin" feature of NPCs and monsters. Another problem pertains to this demo more specifically since its arm.mdl file (floating first-person arm) depends on the old behavior of ignoring "translation" movement on the root node of the arm's skeleton. To deal with this I had to tie the new behavior to the new "modern" bit setting in the MDL file. The new behavior subtracts the base CP from the node both to make it behave like the other animation type, and to be less counterintuitive. (Edited: being "intuitive" functionally means greater flexibility.)
« Last Edit: January 10, 2022, 06:46:34 AM by Holy Diver »

Holy Diver has 2717 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #10 on: January 08, 2022, 10:52:11 AM »

Important Patch

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

I'm not sure when this started, but I just noticed the Brightness option was disabled. It turned out a whole file (http://svn.swordofmoonlight.net/code/SomEx/dx.ddcaps.inl) was excluded from the build by a // programming comment, that I swear I doubt I inputted. Sometimes the editor inserts random things into text based on esoteric key combinations.

In this case it probably made the video card seem to have no functionality. Fortunately the brightness (gamma) functionality was the only thing I noticed trouble with, but it could have further reaching effects.

I've updated the TOOL folder with the previous patch. The last patch also probably breaks synchronization of the "systemwide" events on map change. (This one--hopefully--fixes it.)

I've been working furiously the past 2 days on shuffling a lot of things around to decouple loading MPX files from the global game level state so more than one map can be managed at a time. There's a good chance this will cause some fallout afterward as sometimes its hard to remember what has been manipulated to change SOM's behavior. It's dicey to publish patches with this degree of changes in play but in this case the bug is too great to ignore. That "decoupling" is done now. I still have a lot of work ahead to transition maps without being noticeable. The main things are loading files (of course) and then controls (sounds trivial but it's not) and finally the parameters of the source and destination maps has to be smoothly blended (faded) somehow. I hope to do this gradually and imperceptibly only as you move away from the spawn point, but for some things like sky models it's going to be pretty obvious without sacrificing too much performance.
« Last Edit: January 10, 2022, 06:43:44 AM by Holy Diver »

Holy Diver has 2717 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #11 on: January 13, 2022, 05:52:34 AM »

Important Patch

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

This patch fixes a new crash on leaving the Inventory screen (a minor screen for hiding items to have fewer to scroll through) AND the arm model (arm.mdl) has special needs for using the new MDL+MDO system that didn't occur to me. Namely it needs to hide its segments (i.e. the hand, forearm, etc.) selectively. The arm code needs a patch to hide the MDO elements instead of the MDL elements (which don't exist) so no the arm segments aren't going to be hidden when putting on gloves for example without this patch.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #12 on: January 14, 2022, 11:43:15 AM »

Patch

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

I found out I missed two subroutines that attach equipment graphics to the arm model. One of the annoying things about Ghidra is it tells which subroutines use which subroutines, but not how many times they do or the places that they do, so it's easy to forget to manually use F3 to search for duplicate instances. I've updated the TOOL folder to complement yesterday's arm equipment related patch. I should've put some gloves on (in the game) but I usually don't have that on in my tests.

BTW today I had to rewrite the equipment code from scratch. I figured out yesterday it had a lot of problems around ref-counting its sound-effects and SFX (special effects) references. The hacks I'd accumulated around it were getting to be too much anyway. It's a lot nicer system now. The NPCs and objects (character models) didn't have code for decrementing their ref-counts, so I had to add that, and rewrote their code too to only make references for each item in SOM_PRM instead of each in SOM_MAP. There's also numerous (fixed) bugs in the SFX and SND references code itself.

I think I'm through the woods on improving how resources are juggled. Next is (finally) loading object/character models in the background. The background loading system will also be helpful for speeding up the start of the game. I'm going to add something to the game INI file to remember the last map you played and assume it will be the one you will play next time, and go ahead and start loading it from inside the title screens.
« Last Edit: January 14, 2022, 11:51:57 AM by Holy Diver »

Holy Diver has 2717 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #13 on: January 15, 2022, 01:28:15 AM »

Patch Patch

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

Yesterday's patch had a bad number in it (offset to the PARAM/OBJ.PR2PRO index in PRM records) I'd inputted incorrectly into Ghidra. I also forgot to use the loading routine I wrote for object instances... luckily my brain told me this when I woke up this morning. I don't know what I'd do without my brain figuring this stuff out while I'm sleeping and pointing out my mistakes in the morning.

I had to update the TOOL folder (again) and I'd like to consolidate the last three posts, but I feel like there's information in them that would be collateral damage if so. Daily patches never get old. It feels like once a release is published its patching draws on until the next release. Probably a good reason to hang back one release cycle.
« Last Edit: January 20, 2022, 05:08:39 PM by Holy Diver »

Holy Diver has 2717 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #14 on: January 19, 2022, 07:59:24 PM »

Emergency Patch

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

I learned 2 days ago that I messed up again and had broken sound effects on "objects" and the magic equipment (and a few other things too) but I was too deep into debugging the new background loading system to be able to publish a patch... and a little embarrassed to be making so many patching posts.

I hoped I could iron out some troubles yesterday, but it took me 2 days of keep running into things. (Plus I figure probably next to no one is downloading these patches. I make them out of principle.)

I don't like how the work on the next release is being consumed into this release. It's about tantamount to just roll it into this release as an early demo. I will announce it since it's an interesting juncture. Technically it can be used with this patch but just requires a language pack with the extra event module for SOM_MAP. I may upload that tomorrow as a sneak preview. I still have to work on blending the fog and sky to call it good enough to officially publish it.

I won't be surprised if something breaks, but this patch/version will start loading the first map either when the New Game option is chosen, in which case an intro sequence can hide the loading, or if do_start and start_mode=1 is used it will start loading as soon as the first title screen. I also intend to work on starting the load when a save file is chosen, since it takes some time to move the button up to Yes (it defaults to No) which can be enough to load a game.

Currently it can take time to process textures, which this patch doesn't do all immediately. I've been able to improve the start of maps, especially when they fade in. The first frame will process everything that's in its scene, but after that it starts processing in the background and goes ahead and starts playing the map. This would benefit from implementing the prioritization system I've in mind even now. But I also intend to move that processing into x2mdl ASAP. Technically even x2mdl runs in the background now, so it might not even be noticed if lucky.

I've had to switch Direct3D 9 over to a "multi-threaded" mode, which is supposedly pretty flaky and naive. It might not be necessary if these textures were processed by x2mdl but it can take several milliseconds to process them at runtime, which is too much to do on the same thread as Direct3D. It seems to work, but it can't upload textures without jamming, so I've set it to upload one processed texture per frame. Of course if a model actually requires a texture it will be uploaded in addition to this, and too many can result in a hiccup. It might be nice to be able to fade things in a little late in that case to avoid frame drops. I think only NPCs and items fade in normally.

Support for NPC reskins is limited too. The model preloading system isn't fully aware of skins now, so it will apply the first skin to a model, so that model will never have a different skin if there's more than one. I will work on this. I don't know if the Moratheia 2.1 demo doubles up models with skins. Now with MDL+MDO skins aren't required but can be an optimization for "palette swapped" NPCs.

There's also the start of an alternative "item" pickup experience, but it feels a bit flat. I will have to study KFII to see if it has any sound effects involved. It can be jarring to not have the visual spin around and rise up. I have to work on that. Luckily this can be turned on and off in the Options menu. I will probably update the TOOL folder again after some sleep and more testing and confidence this time.
« Last Edit: January 20, 2022, 07:47:20 AM by Holy Diver »

Holy Diver has 2717 posts
Pages: [1] 2