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: Unleashing monsters  (Read 31020 times)

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« on: May 16, 2020, 10:57:40 AM »

It turns out King’s Field II monsters exceed the limit Sword of Moonlight imposes. I feel like the limit doesn’t make much sense, but From Software saw fit to limit it to 128 so-called enemies for a given level in your project’s video game. KFII treats its characters and monsters identically, and caps them at 200 on each of its two-story zones. SOM had a layer system that was disabled before it was published. I’ve since restored it, some time last year I think. It would have allowed each layer to have 128 more monsters, in which case its limit may have been 256 for a two-story level, which would have exceeded KFII’s limit.

When I restored the new layer system I decided to limit it to level geometry, so that layers don’t bring in new elements like monsters. That’s a better system because I imagined layers can be used to tackle the artistic limits of SOM’s grid based level design. I suspect not many game systems use grids any longer, but it’s something I feel is a great strength for SOM. I think there is lost wisdom in many of its anachronisms. By putting monsters on layers it isn’t clear what happens when they cross between layers or if that would even have been possible in the original system that got disabled. By artistic limits, I mean things like, you might want a layer to just be a ceiling for example, so you can have a lower ceiling on some section, or just have the elevation of the ceiling be independent of the floor. If you can’t do that you have great limits in design possibilities since the only other way to do this is to make new tile models for every combination of floor and ceiling. The new layer system can represent many things like a plane of water or mist or fog or just plug holes in the existing tile configuration. Anybody who’s ever worked with SOM runs into these limits.

But even on a single layer 128 seems like a very tight budget for video games. Monsters are seen as the sole purpose of video games, so it’s kind of bizarre that From Software set the so-called NPC limit equal to 128 also. Your average King’s Field game has many monsters and very few NPCs. And KFII’s maps are only 80×80 tiles as compared to SOM’s 100×100. In KFII’s levels the first thing you notice is how dense they are with monsters. These are really so-called spawn-points, which means that you never see this density in the game because they don’t all spawn at the same time.

I have all of these numbers handy because I’m working on porting KFII to SOM, and I could not make progress on that as long as this 128 limit remained, so two weeks ago I steeled myself to do whatever it took to overcome it. It was a grueling task as I knew it would be because monsters are a systemic aspect of SOM’s programs. Normally I wouldn’t work on this problem. I would wait until SOM is mature and I inevitably make a next-gen version of it, or write a specification for an interoperable media standard based on it. Luckily if you were to draw a diagram of SOM’s structure spawn-points would be out on the edge of the structure, meaning that they are self-contained and independent of its infrastructure, like leaves on trees. Because of this, even though they are referenced in a great number of places inside the program, they’re more like an ends than a means, or not foundational in other words.

Despite this, it still took me a long time to complete work on this. It’s a bit absurd because how normal software development proceeds if you do have fixed numeric limits imposed, it’s normally as simple as pressing the delete key on the number and inputting a new upper limit. But SOM isn’t like that, it’s like hacking a video game without source code. It isn’t always, but it is for anything like this. But since I’ve done it once, if there was cause to I could increase the limit for the other map elements. It would still take a lot of work, but less since it’s been done before.

Another aspect of this task is the so-called save file has to track spawning figures for the additional monsters. Enhancing the save data has never been done before now. I had to plan for future compatibility in addition to adding the new data, and because the new flexible save files can’t be used by old versions of SOM I’ve changed the file extension from “dat” to “som”. The “som” extension is also used by project files, which can be associated with the SOM_EX program to open them in Windows Explorer. Likewise the new save files can open the player component directly into the save game, bypassing all of the starting screens and menus.

I’m releasing this work and writing about it to mark the occasion even though most can’t see the benefit of relaxing the monster cap. The save file system is also included in this new release, but I caution to use it with care because it’s new, so I don’t recommend using it to play games. There is a way to disable it. I was going to put this release forward as a demo but I don’t think the extra work entailed warrants it. I just recommend maybe skipping it or waiting for patches. I have increased the minor version number since I think this version is going to new and exciting places, and I think there will be patches to this release for some time since there are some loose ends in the layer system that I intend to iron out with my KFII project very shortly. The new feature doesn’t require patching, but I think that I will just be slipping in little things here and there that will help fill out this important milestone release.

I'm penning this blog post at the end of a long day and it occurs to me I likely need to go over it again, but I don't have the energy or presence of mind to do it right now. But I want to go ahead and put this release out. Mostly these blog posts are just a formality. I do my best.

The new release is here (http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip) although I recommend updating with Subversion and using the updater software. I recently updated some of SOM's art files that isn't part of any release, just spur of the moment touch ups.

Other than the save system changes there isn't a lot to gain from this release, but I will probably patch it later with some new unrelated developments. This is kind of a trial release but I don't feel like putting it out as a demo.

I'm releasing it and writing about it because it constitutes a body of work that I want to document and it's a big development too I think, but unless you're working on a game project that stands to benefit from more monsters per map, it's not something you can do much with except to read all about it!

I'm filling tired right now... I hope it doesn't come through in my writing, but I can't wait to wake up tomorrow refreshed and finally not have to stare down the barrel of this unexpected hiccup any longer.

It represents one more step closer to realizing KFII via SOM. I really want to get to a point with my project before the end of the year that is semi-complete and worthy of sharing. I really hope there's enough time. I want to at a minimum have all of the content in the game and get to the point where it's in a playable state even if there's still room for improvement before December. I want to use December to promote it and not to work on it. But I have no idea if there's enough time or not. I'm not good with time estimates. And even when I can estimate time reasonably I'm always off by a factor of two or more.
« Last Edit: May 17, 2020, 09:32:43 AM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #1 on: May 17, 2020, 04:18:56 AM »

Update

I completely scrapped what I wrote yesterday for the blog post, and did it from scratch. I've also patched the DLL to make it refuse to load newer save files than it's designed to.

I'm going to come back later today or tomorrow and write down the details.
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #2 on: May 17, 2020, 07:54:30 AM »

Patch

It turns out this release didn't work for me with the "release mode" build, but the problem had to do with command-line arguments (to the launcher) so it's not something you're likely to notice, but this patch fixes it so it works with arguments.

Almost everything I do uses arguments, except I tested it before publishing through the new save file system, which doesn't have any arguments. With arguments you can make Windows shortcuts to everything in your project, so I don't go through SOM_MAIN or SOM_EDIT to do things. Because I'm always working on features that would be a nightmare, since I often have to rebuild the SomEx.dll file, which you can't do while SOM programs or games are using it.
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #3 on: May 19, 2020, 01:10:41 AM »

Details

Sorry, I almost forgot to share some specifics.

The SOM_MAP enemy limit now defaults to 512 and can be increased up to 4096 with map_enemies_limit in the [Editor] section of the config file.

Technically this maximum can be 65535 but I soft limited it to 4096. It has to fit into a 16-bit CPU instruction, so it can't go higher. I don't think games need this to go higher on a 100x100 map. 65536 would be the more natural limit here, but it won't fit. Usually the limits are powers of two, but not always, like the item limit is 250.

The player doesn't actually have a limit, so if you could make your MAP file without SOM_MAP you could go until the game grinds to a halt or runs out of 32-bit address space.

The save file extension can be changed for standalone games (playing games without SOM) with player_file_extension in the [Player] section of the config file. This is limited to 15 characters. Extensions are usually 3 characters. The reason this exists is so you can "associate" your save files with the game and not have conflicts. I think if SOM is installed the difference between using it and not is negligible to nonexistent, but it may not be installed, so a properly published game would want to provide a default setting for this extension. It's in the Player section since ultimately end users are encouraged to change it.

Finally do_2000_compatible_player_file ([Player]) is an opt out just in case there's any reason to do so. It doesn't work unless the game can fit into the original save game format, and it forces the "dat" extension and removes extra information in the file name.
« Last Edit: May 19, 2020, 03:40:06 AM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #4 on: May 20, 2020, 12:24:43 PM »

Patch

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

This is a fix for a loop that was still counting up to 128 enemies when loading layers in SOM_MAP.
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #5 on: May 25, 2020, 09:32:45 AM »

Feature

Strikeout: as fate would have it like one day after this patch I stumbled upon a mistake in the original do_aa formulation that made "do_sharp" immediately obsolete, so it's removed in future patches, and this patch is no longer available, so this post just serves (I guess) to document the course of events.

I've added a new extension (do_sharp) to a patch:

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

I think this is a groundbreaking development, I describe it in detail in a comment here  (https://www.reddit.com/r/KingsField/comments/gpkou9/early_image_of_kings_field_ii_converted_to_sword/) but the basic idea is by leveraging the do_aa and do_lap extensions it's possible to make the do_smooth extension only apply to the after-image composite of do_lap.

The do_smooth extension is nice, but it's a little too smooth. For my King's Field project I didn't like that it didn't feel sharp like a PlayStation game. Plus it's always kind of made things overly blurry.

But it always looked better and the do_aa/do_lap extensions don't really work without it.

What do_smooth does is it makes a half-tone image by sampling between pixels in the effects compositing stage. This is functionally no-cost effect.

I tend to only use no-cost effects. So I had an idea this morning how to sharpen the picture at no-cost. At first I thought of something elaborate to retain as much as the do_aa extension as I could.

But I decided that the results of just going half-and-half was good enough and that the potential side-effects of the more complicated approach were too risky.

I may experiment with adding a third composite image to do_lap, which could stabilize the bad side-effects, but each image is like an after-image and I have a feeling 3 will be too many when moving/turning, so it could get quite complicated if it were necessary to weight the dissolve according to movement to minimize blurring.

That's an interesting area of study, and could help make the images in the tools look nicer (I would rather wait until SOM_MAP has better visuals) but I think I'm happy with this result for now and won't spend time taking this further.

The default Ex.ini file in the /data/my/prof folder has been updated, but that's Japanese, so I recommend getting the latest English data pack (Default.zip) at http://www.swordofmoonlight.net/swordofmoonlight.com/text/English/ or redownloading it via your updater's translation settings.

This change just adds do_sharp to it like this (http://svn.swordofmoonlight.net/data/my/prof/Ex.ini) file's.

I need to add some extensions to the documentation, but for how do_sharp works, it enables do_smooth, do_aa, and do_lap in addition to itself, so going forward it may be thought of as a basket way to dispense with all of these extensions, but it can be confusing if you don't understand how it works.

The effect itself looks a lot like classic SOM, just with anti-aliasing, and no circa 2000 defects. Which is nice.

Edited: My favorite thing about this other than the sharper image is the stars in King's Field II tend to be only a pixel onscreen, so in the half-tone image they're dimmed by being blended into the sky. Now they're restored to their full brilliance. I think that the animated sky effect SOM has actually suits KFII and I will leave it alone. It looks like a kaleidoscope of spirits ascending and they appear to ascend more slowly the closer they're to the ground. It looks like motes of dust near the ground...

It's not how SOM's sky effect is intended to be used because the UV map for its sky dome is different from SOM's own sky domes. I think when you can see the stars indoors it's easier to see they're part of the sky if they're drifting upward, and it feels more magical. I'm feeling more confident for this project now. I could fix the indoor stars too, even without programming anything new, but I intend to leave them in as well.
« Last Edit: June 15, 2020, 10:05:38 AM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #6 on: May 25, 2020, 11:16:06 AM »

Patch

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

I noticed when poisoned by a headeater bite the do_hit effect was getting stuck and preventing dashing.

I'm not sure why, but I've relaxed the condition that prevented it from going back to normal, that's based on how far you're ducking. It was set to recover as soon as you stop ducking, but it was stuck at like 96% ducking, so I made it stop at 95%.

Note, this isn't a part of SOM originally, it's a stagger effect for the PC like monsters have, and it actually makes poison a more interesting status because it causes you to stagger as the poison bites. I think this stagger is enforced even with do_red that makes it so staggering works like in KFIII, which is a much better system, but I think I made poison exempt to this, so even if it only hits for 1HP it is debilitating physically.

I think there is a way to adjust the poison HP loss too, but that it might be nice too to make the stagger more infrequent or irregular so it'd be unpredictable.

Edited: For the record, I'm going to leave the KFIII system in for my KFII project. I'm not overly fastidious about reproducing anything other than its audiovisual style and story. The rest, I'm just going to do whatever is expedient or seems for best. If anybody wants a completely faithful reproduction they have everything they need to make one.
« Last Edit: May 25, 2020, 11:22:14 AM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #7 on: May 27, 2020, 06:43:27 PM »

CRITICAL PATCH

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

I think this is last layer system patch dealing with SOM_MAP integrity (knock on wood) that corrects a problem with the base layer elevations so that some things on layers would end up at the wrong elevation.

I think this release is the first official release that layers actually work in. After patching some other things, like the "checkpoint" system of course.

What happened in this case is I used the line number in the file to fill out the base layer, but didn't realize the number was only incremented when the line-ending was present, so when the line was partially buffered it put them in the previous tile row. It's a wonder something like this wasn't immediately apparent, but such is the nature of all bugs.

I couldn't have seen it unless it had hit some of my tests, which I guess it didn't. It took me a long time working with a map with a lot of monsters on the second layer to notice it. But I've only been doing that since this release was published 10 days ago. I've been looking over every single monster to try to understand some data on the discs as it relates to them, and I think I only found one monster with this problem in the whole time. Anyway, I'm glad I did!

I remember thinking I was clever to change the code to use the line number, since it's a much simpler calculation, just for readability sake, and to remove the dependency on the map height/width, which is historically fixed to 100x100 but may not always be the case.
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #8 on: May 30, 2020, 11:51:31 AM »

MONUMENTAL PATCH

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

I knew I felt something special about this release. I had an accidental breakthrough yesterday described below that unleashed the true power of the "do_aa" extension. I describe it in the post quoted below, over on Reddit.

The power basically doubled overnight and now the visual fidelity is perfection. It just happened to come at the same time as the new "do_sharp" extension, but there is no relationship. The old way without do_sharp (strikeout: "do_sharp" was subsequently patched out) is now also perfectly sharp, without objection, and you might even prefer it less sharp since it's by no means smudgy and there are reasons it might be superior.

This is actually a big deal and it couldn't have come at a better time (before publishing by KFII project) even though it's a funny story that it was 5 years working with an inferior effect.

It would've been 5 more years, or who knows how long, except for the scenario I relate that allowed me to discover the error that made the difference. And it's very strange now that SOM is unique in the world for having this technique at its disposal, since it works absolutely flawlessly.

Anyway, I encourage you to see for yourself. This patch updates the fix.

It also includes (for the record) an obscure fix for the script editor that could ruin your day. I think last time I worked on it I broke the "meta" message ("" msgid) that isn't normally edited, but it would fail to save/read your script (and give you a 0 sized file) if you do edit it, without this fix.

I wish that I could patent and communicate this technique to people, but alas I'm not really up to the task and nobody listens. I think I would have to go on a big quest, like try to speak at conferences, to even get anyone to listen. And the whole patent thing, while it could be a solid foundation for making money for SOM and art, I'm afraid I'm not up to it, and I tried to approach Khronos to patent it for hardware, and got the webmaster to send a few letters to the president, but I never received a reply.

Many years ago while I was working on SOM trying to make a system that works on every computer with a GPU I wanted to have clean lines because I feel geometry is essential to King's Field style and it's my personal preference, I like computerized images, but I don't like pixelated artifacts, though sometimes they have their charms (https://twitter.com/cuddigan/status/1068230670097338368/photo/1)

I had pretty good images but they weren't good enough in the hardest cases, so I had a eureka moment that actually worked, like in 2015, and I think I made the first synthetic images that don't have "aliasing" in them. Technically the process graphics companies call "antialiasing" and have been in an arms race over forever is a post-process that steals a lot of power and compute time from your games, and so can't work on affordable systems, and is fundamentally flawed because it's trying to clean up a mess that ideally shouldn't exist in the first place, and you can't clean it up perfectly, since information is lost that can't be reconstructed.

I think I discovered/invented a novel way to make images that don't have aliasing in the first place, and I started with a germ of an idea, and kept massaging the techniques that feed into that technique until I produced a working system.

At the time I couldn't give away or popularize that idea, I tried, and I probably can't now either. I think the only way to make people listen is to produce a game with SOM that gains attention. People are just stupid, pigheaded, like that. It's why this technique (and many others I'm certain) are never discovered in the first place. Because this technique is no-cost (computationally) I'm certain that it could have been deployed on the PlayStation had it been discovered earlier. And the history of video games would've been very different.

Well, lately, I have been worrying because part of the basket of techniques I used produced a kind of smudgy half-tone image, and I'm working on converting KFII to SOM and this isn't consonant with the PlayStation's hard-edge style. So in the last week I started to think about how I could sharpen it, and I came up with a way, that was very simple.

But yesterday, just by happenstance, I was working on adding KF style onscreen elements to SOM, and so I was testing if they would survive destroying the device context, and you do that by changing the resolution in the Options. So I was just changing to the next resolution, and I ended up on a very weird resolution that is 1152 x 864.

This resolution had anomalies in the frames around the menu elements using the technique that eliminates aliasing. I spent the back-half of my day trying to understand why, and I finally determined it was because of the colorkey system that clips out black pixels, because it's all or nothing, at a threshold, and that threshold just happened to be crossed.

That made me to think about how the technique works, and I realized that it's actually very good for this colorkey system too, because it locks the 3D points (vertices) onto pixels, which should mean the threshold can't be arbitrarily crossed like this, and should improve (optimize) that. That made me to question if so, why on earth was this resolution doing this. And then I realized maybe it wasn't on the pixel center, all of these years.

So I shifted it over by half a pixel, which never occurred to me to do, I guess because I assumed it was already so, and it's more instructions in the GPU shader program.

But this fixed the problem with the 1152 x 864 mode, and I knew I was onto something. And it turned out the image after this was better than ever, and now even the half-tone smudgy image was super sharp. So, now the removal of aliasing seems absolutely perfect.

And an extremely sharp option I tried the other day that flickered no longer flickers, so there are three degrees of sharpness, starting with the original "smooth" mode, that's now very sharp, so no complaints about being smudgy, and there is sharper still using the new technique, and there is extra sharp using an unpublished experimental technique.

In short, the image quality doubled overnight because I'm just muddling through this shit, and made a slight error 5 years ago that halved the quality even though it was still very good. It was just dumb luck (or timely miracle) that this odd resolution setting revealed my mistake. It makes me even more to question how nobody has ever discovered this, since it works quite literally perfectly. There's no downside. It's just something everyone who claims to be committed to showstopping visuals overlooked because they're really just following each other's leads.
« Last Edit: June 15, 2020, 10:07:14 AM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #9 on: June 08, 2020, 07:07:49 AM »

CRITICAL PATCH

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

This patch fixes a bug loading save files with the new system! That was fast :doh:

There was also a problem with showing the wrong file times in the save menus. I think it got introduced in one of these patches.

I'm planning to just keep adding patches to this release for a little while if nothing comes up.

There's a lot extra in this patch...

Just last minute I added an ability to use the controller to switch to vertical movement while flying with F4. I remember ensuring this didn't happen, but I'm not sure why. I know it's annoying if you're used to running with all three buttons down, but while flying you already move super fast, so you don't really need top speed run, and I may make it always top speed. To do it you just hold both attack buttons, which is how you do alt combos, but this was previously exempt. Note, "flying" is a developer/debug/cheat thing.

Mainly this patch "antialiases" cutout (colorkey) textures, which previously didn't get the full benefits of the do_aa extension. In these screens below the tree limbs and grass are getting this new effect. The second is a closeup on a single blade, although it looks better in person than in a screenshot.




The UI elements are also party to the effect, and speaking of that, there are two new Option extensions called "do_kf2" and "do_nwse" that enable a King's Field II style compass. The latter does so, whereas the former automatically enables the latter and also adds a KF2 style HP/MP display.

I'm more impressed by the compass than the display, which just uses the menu system, like KF2 does. But I wonder if there's a way to improve it, so it better complements the new compass. I think VR may require 3D menus, which is my first instinct on how to improve it.

To see the compass you'll have to SVN Update your data/menu folder to get the MDO and TXR file. Actually these displays are the first time I've added both menu and MDO elements to SOM. Slowly but surely I'm inching closer to more sexy extensions. I don't know why it's taken so long to get to model extensions, it just has. Ultimately it's not as high priority as it seems.

The compass is kind of cute. It tracks your movement in a lot of ways, not just to indicate where you're facing, but it acts like a little bobble head that's on your person. It doesn't really look up and down like in KF2 so that instead it stays readable. It's also angled down so it feels like you're looking up at it, which you are since it's on the the top edge of the screen.

The lettering on the compass is what inspired the new extension to do_aa. Technically I renamed the old extension to do_aa2, in a bit of an odd choice. It's relegated to being used to manually control effects, whereas the new do_aa automatically turns on its accessory effects that it requires to look nice, which includes do_aa2, do_smooth, and do_lap. Those all get packaged into do_aa now. But how this works is if you turn off do_aa they all remain on, so turning it on and off (weirdly) is what you might do to have everything except the new texture effect.

In theory these do_aa effects might be unpleasant for some, or not work with monitor settings or be incompatible with a monitor altogether. I haven't had enough feedback to know how many can use them happily. My monitor has a "Response Time" setting, which if I turn it on it makes motion in movies choppy (which is what it's for) and shows heavy black bands in games. So I'm thinking this option (it inserts black frames between real frames) is for people who see very differently from how I do. I think my eyes or brain are different in this regard.

EDITED: Ooh! I just spotted the compass in the second screenshot, so it's technically included. I wasn't going to include it. It's still early. Part of the problem it has right now is it's subject to the level's lighting. In Moratheia, and most games, it's not enough to light it properly. I have to add some extensions too to control its colors and opacity. In the final version (not seen here) I have colored each letter to be very white, but still technically different complementary colors. N is green, W is yellow/peach/tan color, and S is purple/pinkish, and E is bluish/greenish. There actually weren't more distinct hues than this. Luckily they bleed nicely into one another forming a kind of rainbow spectra, albeit not ROYGBIV. They are more like off-white.

Edited: For 2.5hrs I'd uploaded a debug build instead. I really doubt anyone downloaded, but just in case, maybe you will or won't see this.
« Last Edit: June 08, 2020, 08:32:03 AM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #10 on: June 09, 2020, 02:54:45 AM »

For the record, earlier today I uploaded a fix for the F4 flying thing that by changing it to work with the controller, I broke it working with the Alt key, and also, to repeat some edited into yesterday's announcement, I had to reupload because I put a debug mode build up the first time.

Edited: Crap, actually I didn't upload the F4 fix because rain had knocked out my Internet access, so I thought I did, and I couldn't upload until the next morning. I have to go out and trim some tree limbs around the satellite dish. I'm pretty sure it wouldn't have been as bad without those tree limbs in the way in way. I feel dumb making these updates since unlikely anyone downloaded it. The patch to my KFII demo yesterday should include the fix.
« Last Edit: June 09, 2020, 05:34:06 PM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #11 on: June 26, 2020, 06:50:16 AM »

Neato Patch (some under the radar fixes)

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

This patch holds a bevvy of quality upgrades for the movement system.

I got sucked into working more on trying to minimize false positives in the jumping system yesterday and began to notice the jumps were sometimes a bit halted in their movement, so I really dug into what the problem could be, investigating everything. The old jump system was designed to cancel out some assumptions based on how SOM's pseudo (flying squirrel) gravity works that seem to no longer hold.

I guess at some point one of the (many) changes to the clipping system changed this behavior. So the extra oomph it was programmed to give on the first frame of the jump was adding to it instead of canceling out and throwing off the descent as well. So I just removed that and some other stuff and tried to figure out why the jump was underpowered, which related to some new changes in this patch that smooths out the frame rate (I was keeping the fractional part of the smoothed frame rate for some stuff and not others and the difference in rounding was enough to reduce the jump height/impact.)

So, this fix is the biggest non-feature part of this patch. The jump arc is smoother than ever and very fluid.

This fix also solved some ceiling interaction issues I was having with my KF2 demo.

I've done so many upgrades to the movement system this week I probably can't recount them all. One of the biggest is there is now a tentative system for making the bounce effect depend on the field-of-view so I was really able to push it to the limit instead of trying to find a one-size-fits-all compromise.

Climbing now has a bounce like effect, but just the head tilt and not the knee bend part. Landing a jump without stopping feels a lot better now. There are two ways to land a jump, one (stopping) is a deep knee bend, while the other is just kind of hits the ground running. This one is far more dramatic now but somehow less noticeable.

There's a friction system that ties into grabbing the wall. It slows you down when you rub harder and harder against the wall. I added it just so it feels less slippery (don't slide off things when pushing against them) and it's very subtle by design, so you might not even notice it.

It's now possible to look all the way down while crouching and even while leaning out. You can even look the furthest down I think by crouching and leaning out. I guess that feels about right if you wanted to look down the side of a cliff. This may tie into a system for climbing down off ledges at some point. All the way down now means like 110 degrees or more.

Like I said, there's a new system for eliminating false positives so you jump by accident less. But I ran into some problems with my controller momentarily crossing over to the opposite side of the sticks when releasing it, instead of stopping in the center. This is what got me looking at it again yesterday. I made a lot of other changes and by the end the problem wasn't occurring for me, but it could just be my stick was having a good day. But I just left it alone for now. (One fix could be just one frame of smoothing the input data would probably prevent it from going that far, but I know I'm using a much smaller dead-zone than PS4 games do, so the obvious fix would be to increase the dead-zone, but I'm hesitant to do that. But too I worry other peoples controllers aren't going to work if I don't increase the default anyway.)

In short, I want to push this patch out since it presents a more competent movement system.
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #12 on: June 27, 2020, 03:22:06 PM »

Patch Patch

EDITED: http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip

Unfortunately, I've had to compromise the new filter that prevents some jumps because the logic it uses is to cancel jumps that crossover the middle of the direction pad, taking that to mean it's not a jump input... but it turns out that even though you can't see it in the DualShock4 controller, it crosses over up to like 33% of its effective output, so it's really not possible to tell if the stick is let go or pushed. I mean, it'd be really hard to push it to the center without going over, and I wish that was how they worked, because then the jump could know you let the stick go and didn't just move it.

It's also counterintuitive that the sensors are saying the stick is at 30% (for a split second) even though the stick itself isn't. It took me a while to convince myself this was happening. Even the Control Panel calibration too doesn't seem to show the stick bouncing over.

How I've dealt with this is to make the detector less sensitive during the jump window so that when it goes up to 33% it doesn't appear to get out of the dead zone, but this also diminishes the filter's ability to detect crossover...

So, after the jump is initiated it starts returning sensitivity, with the thinking that the springs will snap into place faster than a player's finger, and so to get the desired effect you have to overcome this insensitivity and you only have one or two input frames to do so, depending on the frame rate (2 at more than 30fps.)

Because of the short window the system works best for fast movements, like sudden stops. If you're moving your thumb slowly it's going to register as a jump most likely. That's why you shouldn't make a habit of releasing the action button while moving/releasing the dpad.
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #13 on: August 02, 2020, 09:21:52 AM »

Feature/crash fix patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
http://svn.swordofmoonlight.net/data/my/model/ARM.MDL

I was about to possibly put out a new release but in the last minute I somehow crashed the program in a way that hadn't happened before, so as a result I want to patch this crash that was introduced in the previous patch, and as it just so happens the patch includes what would be in a new release, so I'm possibly just going to keep rolling things into this release via patches.

I may make a blog post with or without a release. I will have to see what I feel like doing.

The crash happens in the jump system because I had it to read past the end of a buffer. It's a wonder it didn't show up until weeks later, but that stuff just happens.

This patch includes the new 60fps code I've been working on for a long time, and it changes how the arm is displayed when attacking, so I've included a new-and-improved ARM.MDL file (link above) that you want to make sure is in your DATA/MY folder.

This ARM.MDL is a lot better but the animations are identical to the old one. I think that its animations should probably be changed too, eventually, but what to change them to is a major decision I can't deal with right now. I do think the chop should be centered and not twist around. The thrust seems pretty lame too.

A lot of work has gone into this upgrade to 60fps animations and effects. The attack animations now have four times as many frames, but to do that they are blurred together to form a sweep of afterimages. And the transparency effect used is not great, but it's the same as the one for fading things in.

I definitely want to program a better system for the transparent elements before long. By that I mean a full BSP triangle sorting/partitioning system.
« Last Edit: August 02, 2020, 02:48:36 PM by Holy Diver »
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts

Holey Moley

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • twitter.com/m__7761
look out honey, 'cause I'm using technology
Holey Moley says,
« Reply #14 on: August 03, 2020, 12:14:06 PM »

Patch

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

Yesterday I forgot about how the arm/hand equipment pieces have extra models that displace the ARM.MDL sections.

This patch addresses that omission and makes that system a little more flexible since before all 3 MDO files were required, but now if one is absent it will use the ARM.MDL geometry.

Most of these items have dummy models for the shoulder/bicep part of the arm so I took the drastic option of deleting those files. The problem with this approach is you need this version/patch of SomEx.dll to make it work without those models. I didn't want to upgrade the models with the new bicep/shoulder work I did.

Two items have alternative models for this section. I have to take a look at them. One seems to have a pauldron or something that is closed off, so technically it's okay I guess. The other has a hole in its shoulder like the old ARM.MDL that I have to fix when I can get around to it.

All of these models require work to switch over to soft shading to match the new ARM.MDL file and I think that this system should be more flexible, and ideally the ARM.MDL should not be displaced as long as the pieces aren't in conflict with it, so that they don't have to copy its geometry since that's error prone and inflexible. But changing how this works on a more fundamental  level will require more elaborate extensions and even more work.

Luckily unless you pause the game these arm models fly by so fast you can't see them well. But the hole in the shoulder is definitely possible to pick out. I have to fix that. Really it seems to me that the body equipment should cover the shoulder. Of course both can as long as they don't come into conflict. I actually thought maybe that's how it worked, but it turns out not to be the case. (I'm not as familiar with SOM as you might guess, yes I know more than anyone surely, but there's a lot I haven't looked at that people who've made games all have to deal with at some point. That's caused communication problems is the past. Making my own game with SOM is a big help here, although unfortunately my memory tends to slip away faster than normal.)
Formerly "Holy Diver" ("Holy") [Holy will be back as soon as I'm back to full form]

Holey Moley has 2730 posts
Pages: [1] 2