Topic: EXIT: Layer feature unearthed, now restored (Read 29162 times)

Holey Moley · « **Reply #15 on:** October 16, 2018, 11:34:00 PM »

ObjEdit patch

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

A bug in Windows's CheckRadioButton API makes some of ObjEdit's boxes not get checked off on when opened in maximized picture mode as SOM_PRM does.

(It unchecks "buttons" that aren't actually radio buttons.)

Holey Moley · « **Reply #16 on:** October 19, 2018, 03:47:06 AM »

Critical SOM_MAP patch

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

Turns out SOM_MAP's Save function has been broken since the beginning of this release. I didn't notice it because only the "Release" mode "build" was affected.

What happened is I transcribed an 8B to B8 and a 89 to B9. Something about 8 and B looking pretty close. The cardinal sin is that I neglected to test the code, made worse by the fact that I kept using the old code I dictated from in the "Debug" mode "build" which I tend to favor because I'm always doing work on SOM.

FWIW this has to do with the last minute work I did to use objects' first field in the MAP files to denote the layer that they belong to. For some reason the code was using the field to record the objects' type. But none of the programs actually used this type information, and the way the type information goes into the field makes it hard to tell if it wasn't just an accident that it ended up there, or if it was at one point used to do something. I have noticed lately that if the profiles change or are reassigned that the MAP files must be saved, or else MapComp will not succeed.

Holey Moley · « **Reply #17 on:** October 20, 2018, 10:00:45 AM »

For the record Patch

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

I'd been messing around with the defaults for the bob effect, not liking the feel of late. Some of the changes I made found their way into the patch yesterday. I didn't have enough time to evaluate the changes.

So I went in and tried to scale things back, because they felt a little weird. What I ended up with is just instead of doubling the effect (by default) according to the dash speed (ramping up with acceleration) is go from 0.3 to 1 instead of 0.5 to 1. If that makes sense. IOW the effect is lessened when walking/now more than doubled when dashing.

In addition, I noticed that because as the gauge drains the running speed is lessened (unless you hold down both both attack buttons, kind of like pumping your arms) that the stepping frequency was not maxing out, so I boosted it artificially, as if the endurance speed change is not in effect. This is fine because running speed is more a function of power than stepping frequency, and if anything the step rate doesn't acknowledge this, and feels like you should be moving faster... but I don't know how much of that is because of field-of-view effects.

I momentarily played with longer steps also, since walking felt too fast to me, but I worry that's because I've long legs, and scaled back to 1 because it's a round number. I kind of like that full speed feels unnatural so that middle speed feels natural.

Again, I don't know how much of this is field of view. I'm more and more thinking that these effects should be in terms of FOV, even though it's not realistic to do that. Especially for the rotation effects, I feel like it really should be a fraction of the FOV instead of an absolute angle. FOV is just a limitation of what displays can fit on the screen, and how it feels I think is more important than a mathematically correct simulation of a camera.

Part of the problem is it's impossible to choose ideal settings since they are different depending on the FOV setting. You just have to split the difference. I know this will have to change sooner or later. I just don't know if it will be limited to rotation effects, or if it will extend to movement effects and speed. It can't change the actual speed, but it can play with cues that we use to judge our speed.

Holey Moley · « **Reply #18 on:** October 22, 2018, 07:30:50 AM »

ItemEdit/ObjEdit patch

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

This fixes 2 problems: 1) Setting the menu/drop pose for items had been failing to refresh the picture of the 3D model. 2) ItemEdit's Save function would be disabled if not in the 3D model mode...

I believe (2) is oddly, because the button number I chose for the new 3D model mode (1000) may have just happened to have been a Save Lock feature that enabled/disabled the Save function. If so, this Lock button must have been removed prior to publication. Without it it seems to require the Save-As function to be used exclusively.

After I learned about this, it became more difficult to control the enabling of the Save function. Note, the reason to do so is if you make a New profile from scratch, it doesn't have a file to save to. Maybe there will be a policy for protecting public profiles in the future, but there isn't now, nor any time soon.

Compounding the problem is Ctrl+S doesn't work when the menu is disabled. Windows must perform this check automatically. So, I had worked on a number of profiles, using Ctrl+S only to find that they had not saved. (This was because I was editing drop poses, and so was in that mode instead.)

Holey Moley · « **Reply #19 on:** October 24, 2018, 07:52:11 AM »

IMPORTANT PATCH + CLASSIC BUG FIX

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

1) I discovered an original (From Software) bug where projectiles (e.g. fireball) hit cylindrical type objects, wherein the object's radius and height are swapped. I think there are larger problems with this interaction, that seem to cause the impact point (point of explosion) to be funny and also, cylinders that are wider than they are all tall seem to behave strangely, so I plan to investigate this further.

I ran into the problem making new objects like KF2's Magician's Lamp, which would not interact at all with a fireball (not good since part of the games has you shooting them with fireballs) and generally could not get any cylinders to interact! I wonder if the reason that so many cylinder objects from the KF sample project are shorter than their models... I thought this was just laziness, but if wide cylinders have problems, and originally the height/width were swapped, then making them square might have been a harebrained way to deal with the problem. If so, the art team and programming team must not have been talking to one another.

2) Projectile interaction with layers was disabled by another "Debug build" check.

3) Reading the MAP files can still fail because one of the checks I added a while back to prevent peeking (looking ahead in the file buffer) was written wrong (like *rd-- instead of --*rd) so that it fails to remove the carriage-return.

Funny I've worked with SOM all this time not noticing the cylinder problem... I really have a feeling the funky cylinders are an artist hack to workaround the problem.

Holey Moley · « **Reply #20 on:** October 24, 2018, 11:59:31 AM »

EDIT

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

I thought to get rid of the funky impact points it would help to set the vertical coordinate back to the projectile's position, but ultimately I simply copied over the original position, since it seems pretty harmless and eliminates some horizontal funkiness. I mean, generally the projectiles explode on impact, so I don't see any reason to reflect them off of the target. They shouldn't be going so fast as to penetrate too deeply...

And even if they do, I tried offsetting the impact point along the PC's view vector (the "camera") to try to make the ugly sheering go away.

This worked so well, I bit the bullet and tracked down all of the subroutines/calls for boxes, NPCs, MHM geometry, etc. so that fireballs look good exploding off every kind of thing.

I don't know if this is a good fit for every SFX but it seems to me like it should not be too bad. I will address problems as they arise.

EDITED: I was worried about the Moonlight Sword's 3 stage sword magic. And similar effects. I put a limit on the offset, since it's just meant to get the explosion away from the walls, etc. But did not update the download. Since the second splash explosion is at its center. I didn't want it to be too far away. However, the additional explosions, would have been a larger problem, since their locations are not based on the center of the splash. The splash is subject to the offset, although considerably smaller since it's limited. However, it doesn't seem like the hit site is used for this effect, so it seems to be fine. Instead of using the hit site, just the center of the NPC is used (feet level) for the stage 3 explosions.

The initial fireball has a 0.75 radius, and the limit I set was to 0.5, based on the small fireball's radius. So the difference is not enough to warrant a patch. The splash had a 4.5 radius. But it doesn't seem to matter.

EDITED: For the record, I wrote a replacement for the cylinder/sphere clipping procedure from scratch (it's very simple) in order to make fat (more disc shaped) cylinders work. It's hard to imagine why they don't. The subroutines seem overly complex for what they accomplish, and don't seem to be used elsewhere. It suggests that they are part of general purpose "library" code. The fix will be in the next patch/demo/release. I've also made the fireball's clipping radius smaller so that it doesn't explode so easily when grazing things. It's still no smaller than the 3D model I think. It's probably time to start correcting the clip shapes of SOM's built-in components. Before long I'm going to begin extending clipping to MHM like polygons. Speaking of which, there's definitely something wrong with MHM clipping, since the fireball often goes through walls. It may help to simplify the clip models, or may not.

Holey Moley · « **Reply #21 on:** November 06, 2018, 09:20:07 PM »

Hell yeah!

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

FINALLY FOUND A WORKAROUND for the most obnoxious Windows bug in the world!

This patch is to fix the problem with exiting F11 mode (fullscreen) wherein a few years ago Windows 10 (8 too I think) started making the title bar part of the window disabled, so that it cannot be clicked, and disables the window when clicked!

I've tried and tried to find a fix for this problem, and also to bring it to Microsoft's attention.... unfortunately they have an army of employees that ensure that bugs are never fixed... that's literally their job from what I can tell. (The only time I've had success fixing Windows bugs is when I can find the blogs of the employees who are responsible for the module and contact them directly.)

The brilliant fix I came up with, was to try to make it so the window doesn't look like a fullscreen window, and so to avoid the idiotic bug altogether.

The only fix to get the window to work normally is to minimize it and restore it via the task manager menu. That's been something I've had to deal with for years ever since. There was also a graphical glitch in the top-left corner when this bug was in effect. But that went away about a year or so ago.

I'm convinced the bug is due to bad programmers hacking the window manager to try to give special affordances to fullscreen windows. They think they solved the problem, but something about SOM is broken by the feature.

Good news is that what I did is put a frame around the window, which is not even visible, at least not on Windows 10. I think maybe it's on the outside of the screen, off screen. So it looks no different.

Bad news is, maybe there is a performance loss, but F11 is not for performance, so I could care less.

Holey Moley · « **Reply #22 on:** November 07, 2018, 12:17:40 PM »

EDITED: I'm putting up another patch because I think I may have left something that might be messed up in it, to do with better handling the mouse takeover behavior when multitasking with outside windows. I think it was made to put the mouse in an Alt/F10 mode, which was not really correct, since it floats the mouse and requires 2 clicks to begin interacting.

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

P.S. I got carried away tonight working on a custom menu for my King's Field II project. Consequently it's part of this patch, though by accidental (http://www.swordofmoonlight.net/bbs2/index.php?topic=286.15)

EDITED: I had a change of heart and moved the description of this image to my KF2 "devlog" thread.

Holey Moley · « **Reply #23 on:** November 09, 2018, 02:58:16 AM »

Patch

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

The up/down arrows I modified yesterday have a problem because of the VR feature that changes the size of the menu area. It doesn't just do this in F2 mode.

Also, yesterday it seems like my hard drive or something related to it has began to occasionally take long pauses. Every now and then it would take a long time to start a game test session, from running it to the window appearing. I thought it was just this hard drive thing, and once SOM_MAP took forever to load the files at the start. But after a while, I began to look into the program to see where it was when it was stuck, and it consistently came up to some code I added to detect XInput controllers...

So it turns out the code can be very unfriendly for real-time applications. Probably it's acting up because of the strange behavior I'm experiencing, but my impression is that it can take a long time even under normal circumstances, and so it's very possible it can be a large part of delay before the window appears. So I've done some work to mitigate this likelihood, by moving the routine to the secondary "thread," that does time keeping, and mouse tracking, pausing, etc. And it doesn't begin until SOM starts polling for input, which should be after the window appears.

The problem is described by this (https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/improving-enumeration-performance) document, and I don't know why this is the recommended way to determine that a DirectInput controller is an XInput controller. I'm going to look into it some more. I've made some of the changes that are recommended, but it still takes more than a quarter second sometimes. And there appears to be a possibility that it can fail to work, or give up after taking too long.

Holey Moley · « **Reply #24 on:** November 11, 2018, 06:31:26 AM »

EDITED:

I've reuploaded a patch because the game window is getting stuck in a state where it cannot be clicked on! I think it is a bug in Windows, but related to the change I made to try to make the mouse pointer behave better when switching between other windows and the taskbar. I haven't got stuck since.

I've changed it to a different behavior, and am hoping for the best. (My disk or disk-controller seems to be malfunctioning, so it's really hard to tell what isn't a side effect of that. I don't know what I'm going to do. I should probably start looking at a new workstation, instead of trying to replace the drive just to find out that it's the motherboard acting up.)

P.S. I've added Shift support to the Esc and F3 functions. I could say more on the subject, but it's probably not worth anyone's time. EDITED: So it turns out I had a lot more to say (http://www.swordofmoonlight.net/bbs2/index.php?topic=290.0) on the subject, but just didn't realize it.

Holey Moley · « **Reply #25 on:** November 12, 2018, 01:33:51 AM »

Patch

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

I discovered the MP3 pathway I implemented has been converting regular WAV files, redundantly. I know I remember checking this code, but I basically had botched the code that determines if a WAV file is compatible with SOM or not. I probably only checked it for the converse.

(Edited: I think possibly this has been exacerbating the trouble I've been having with my disk/disk-controller/something. If so it chokes up when simultaneously reading/writing to the disk. This procedure seems to be especially prone to choking: https://docs.microsoft.com/en-us/windows/desktop/xinput/xinput-and-directinput)

P.S. I've enabled transparent text, which was actually super simple. I thought the the SetTextColor API would surely discard the "alpha" component, but it doesn't...

I've done this because I'm using it with KF2 to make text appear smoother when using the do_stipple extension. I prefer to use it with dithering, in high color, but I found that it is so noticeable on the text that it was making me to prefer the true color mode (which admittedly looks quite good itself nowadays running at a steady 60fps.) With transparent text the edge is less crisp, and so it looks smoother under do_stipple.

On my previous monitor I cannot see do_stipple, but my latest monitor is slightly larger. And individual pixels are visible. I think probably monitors shouldn't be so large, that you can see pixels, but I didn't now this when I placed the order. It's not generally a problem. (Except funny story, the Samsung monitor kind of malfunctions with dithering turned on, depending on its Gamma Mode. I can't fathom why. I thought it was limited to Mode 2, since there is a place you can stand in Moratheia's demo that causes it to malfunction. You can take a screenshot, and look at the picture normally, and it still malfunctions... that was an interesting day. Well, it turns out Mode 1 malfunctions when sweeping over KF2's water. And so I put it into Mode 2 again... which I actually prefer, since it's a darker gamma setting.)

Holey Moley · « **Reply #26 on:** November 12, 2018, 06:50:01 AM »

EDITED: I've reuploaded a fix for the Pause+S or Pause+Select screenshot feature, which had stopped working with the addition of D3DSWAPEFFECT_FLIPEX mode. It can be useful feature, but I mainly wanted to not have anything broken.

In the FLIPEX mode you can't get a picture from the window. Last night I tried many Direct3D ways to, and they all failed. I realized the way to do it was to use the desktop, and just clip the window out of the desktop, which is the same thing, no better no worse... just a counterintuitive approach.

Holey Moley · « **Reply #27 on:** November 13, 2018, 06:59:23 AM »

Patch

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

I found a much less stinky way to detect the XInput controllers. Some accounts online suggest the documentation's way can take up to a minute. I don't understand where Microsoft is going with some of its COM based APIs, but this is useless, and certainly cannot be used at start up.

http://lists.libsdl.org/pipermail/commits-libsdl.org/2013-August/007312.html
http://hg.libsdl.org/SDL/file/8cc29a668223/src/joystick/windows/SDL_dxjoystick.c

I think I began to have problems with this because my computer may be dying, which is not good if it up and dies while I'm working on a KF2 project and lose a day or so of work. I actually think I may have indirectly hurt it by accidentally hitting a shutdown button while some files were transferring to an external drive... but it would be really stupid if that job did not keep the system from shutting down. I just don't know if a shortcut to a direct shutdown command goes through the same kinds of checks. Anyway, the problem began the next morning after having shut it down. It could be a cosmic blessing to get this egregious code out of the start up sequence.

I thought maybe my SSD disk is working in a bad section, and so I copied my KF2 project, and deleted the old files. It's only been an evening since I did that, but before I did it SOM_PRM couldn't switch tabs without getting stuck for a minute (which prompted me to try this) and after, so far so good.

P.S. This "build" has a new feature where the Attack/Magic buttons don't fire until they are released. It's actually better than before, because it removes 150ms delay, if you can just press faster than that. It's now easier to press all three buttons to run fast without accidentally lashing out. It opens up using the Shift key as a modifier, without dorky side effects. The Menu button will also work this way at some stage, but doesn't just yet.

Holey Moley · « **Reply #28 on:** November 16, 2018, 10:56:48 PM »

Patch Patch

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

This patch fixes depth buffer issue for items in a menu with a picture background, instead of transparent effect, caused by the new transparent frame feature.

It also uses the linear filter for 2D elements, with the point filter option. I can't think of a single reason to use a point filter for these things. There's no reason wanting the point filter option ought to degrade the menu system.

simple machines forum

News:

Sword of Moonlight|

Devs|

EXIT: Layer feature unearthed, now restored

Author Topic: EXIT: Layer feature unearthed, now restored (Read 29162 times)

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

simple machines forum

News:

Sword of Moonlight| Devs| EXIT: Layer feature unearthed, now restored

Author Topic: EXIT: Layer feature unearthed, now restored (Read 29162 times)

Sword of Moonlight|

Devs|

EXIT: Layer feature unearthed, now restored