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.

 
 

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Holey Moley

Pages: 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 ... 58
136
In the past couple days I had some success with VR stuff: 2) in reverse order, I got 2.25x supersampling (1.5 times each dimension resolution wise) to make a nice looking picture (attached, left eye only) by adjusting the mipmap sample point down to 50%. I could write a long post about my thoughts on this but I'm going to assume anyone reading this just wants to hear the news and not the technical breakdown. (In the picture notice that the lettering is smooth, especially on the diagonals on M. I assume if they're smooth the rest must appear smooth too.)

1) in reverse order, yesterday something on my mind made me to revisit how the eyes (twin pictures) are accomplished since a little while back I figured out, inadvertently (I'll spare you the details, I wrote them somewhere around here a while back) clipping pixels in the pixel shader is pretty costly, and I reckoned it would be much better to clip before the pixel phase. I first tried a "user clip plane" because the plane was down the middle of the screen, and it seemed to work but didn't quite, and I'm not sure why (without going into details) but generally it's advised to not use this, and especially on Intel, which my PC is/was. At some point I (stupidly) realized the 2D "scissor" clip option was what should be used since it's just a simple 2D clip, and I'd already used it for text at one point because the text is done by D3DX which doesn't let you use shaders at all. This helped with the frame rate significantly (anything around 10% is pretty significant) mainly because it does a better job of eliminating pixels from up close map geometry that's just on the other side of your nose.

EDITED: I realize I should've gone more "in depth" to explain the reason clipping was done in the pixel shader before is I originally set up stereo (two eyes) to use "instancing" so that both eyes are drawn at the same time. That sounds great, but I think at that point the data was still being uploaded to the GPU so instancing would cut the memory bus burden in half. But shortly after I set up a system that juggles temporary buffers in video memory that helped SOM with performance a lot. So at that point instancing wasn't a matter of uploading since only one copy of the data would be uploaded either way. So this new way just draws everything twice and switches the "scissor" clip from eye to eye for every little thing SOM displays, i.e. a skeleton's femur, etc. It would probably be better to do all the bones at once and do the animation on the CPU but that's another story.

So (1) helped with frame rates, and that got me wondering if I could figure out (2) to make the picture look good and hit a stable 60hz. And it did, on my system at least. But I still have to hook it up to the PlayStation VR since I recall sometimes the frame rate is affected by having to take in the input from its USB that's pretty intense, although in theory if the GPU is the limiting factor that shouldn't matter. In practice on this system the CPU and GPU share memory, so that might be why, or heat.

That costly clipping thing is still done for every pixel to poke holes in the textures (like for grass and things) so I know I could rollup my sleeves and add a system to make a twin for every shader so that that clipping could be eliminated when textures don't have holes, and that would make a comfy cushion to guarantee no frame rate blips. (Edited: A big reason I wanted to eliminate the eye clipping is this kind of VR would not benefit from eliminating the texture clipping if it was doing eye clipping, since it's the simple act of clipping that causes the GPU to perform badly, unfortunately. It has to do with the GPU not being able to make assumptions about where live pixels will end up in the depth-buffer.)

Anyway, the main story here is the supersampling, since that makes it actually look better. But it's good to get the frame rate down further to eventually be able to use a PSVR with very inexpensive computers. And hopefully once I get my new computer set up with a new high end head set I can just keep the PSVR plugged into this smaller computer. Actually my current computer is like cube that fits in the palm of your hand...whereas my new computer is enormous: https://www.amazon.com/Empowered-Grandia-GeForce-Workstation-Computer/dp/B08MQM8TXP/ref=sr_1_3 (NOTE: I paid well south of $1000 for mine, most of the price on that is inflated for the RTX graphics card, which I was able to swap out for a Vega APU. I'd like an RTX card for it but they're only supposed to cost $600 except you can't buy them for less than twice or thrice the MSRP right now because of demand for transistors. I'm thinking about going ahead and getting a head set since I think maybe the APU can handle it for SOM except I'm kind of bummed that VR controllers don't have enough index finger buttons to play SOM games, so I don't like the idea of buying controllers I'll likely never use... I like the announced PS5 VR controllers, but I think they won't come out until a head set appears which seems unlikely to happen anytime soon.)

137
Help / Re: x2mdl/x2mm3d download (2021)
« on: May 22, 2021, 05:34:48 PM »
Slight fix for working backward and "Original_MDL_viewer.exe"

Verdite (Moratheia) contacted me today with a problem that (inadvertently) made me to notice a change I made a while back appeared to require a touch up. This fix only applies to running MDL files back through x2mdl, or possibly through mdl2x, which may not even do animation.

You might hold off on this though because Verdite has a problem with blue CPs that should be red that I haven't figured out yet, and am waiting for a reply with an input model.

P.S. I've also gone and packed in a new EXE called "Original_MDL_viewer.exe" that's just an up-to-date version of what was called "Somimp_view" in the past. It's just a modified version of "assimpview" that you can use for a limited preview of the input model or to view original (old) models before converting them into "modern" MDL files.

138
Devs / Re: EXIT: 25th Anniversary Project
« on: May 19, 2021, 02:17:49 PM »
Patch Patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip (shield demo)

I've had to patch this again concerning one of the "nasty bugs" from the last post. I accidentally made the left trigger to be treated like a regular button in the process because I changed the numeric "ID" for it and missed a place that assumed the old ID.

(I also normalized it when assigned to movement buttons, although I don't recommend doing that, it's technically possible to assign lateral/looking movements to the triggers in the Controls menu.)

Note, I missed this because I assign the menu button to the left trigger, but I suppose a left handed person might assign it to the action button. This patch isn't super critical but still has to be fixed.

Edited: I had to reupload to fix a problem with the keys leaking movements when overridden by [Button] in the INI. Also I've patched the 1.2.3.5 demo.

139
Devs / Re: EXIT: Anti-aliasing announcement
« on: May 14, 2021, 02:47:29 PM »
Notice

Right now I'm planning to switch gears into less intense work and some R&R (rest and relaxation) and won't likely be posting a lot of updates for a while while I do some exploratory work.

I'm mainly interested in getting into my Exselector project and looking at making a switch to using MDO files for everything except animation and I want to try to play more PSVR games and see what I can do with it with a new work computer I'm going to have to be setting up. If I get deep into Exselector it can easily be a many month project that I might keep mostly to myself until it's ready to be published in some form. It's going to be pretty ambitious, it's like a cross-platform addition to SOM that will provide a lot of technical support stuff.

The SomEx source code is very geared to Windows and it's already pretty bloated. The Exselector code will be self contained and auxiliary to it. It's going to have a lot of third party code which SomEx doesn't really use (Edited: I.e. it's virtually all "first party" code. And to the extent it will use the third party code I will probably try to do it in terms of an Exselector API "abstraction layer".) When it comes time to make SOM cross-platform this Exselector part shouldn't require any work. It's going to be quite a diversion and hopefully it will pay off and not steal too much time from core SOM stuff. Anyway, I need a diversion from time to time to stay sane.

140
Devs / Re: EXIT: Anti-aliasing announcement
« on: May 12, 2021, 04:36:09 PM »
Update

I've FINALLY published a shield/counter system preview. I've edited basic information into the original post. I'm doing this pretty low key right now because I'm not enabling shields for SOM's original (Shadow Tower looking) arm model. I would if I had more confidence in my animation software. I'd like to add some features to it first. A shield animation would not be difficult, but I feel like the other system is needed for the control scheme to be balanced.

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

Like I said before I'm going to try to switch to patching this preview for right now. The difference between it and a public release is the updater tool doesn't offer this one in its menu so you have to download manually... although you could edit it into its CSV file if you wanted to.

141
Devs / Re: EXIT: 25th Anniversary Project
« on: May 10, 2021, 02:00:14 PM »
New Project patch

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

I was given an idea to change the default button configuration when making an INI file for a new project because the original default was to use face buttons instead of shoulder buttons.

So I deleted the INI file to see what happened and this turned up a few nasty bugs which this patch fixes.

That's a bad first impression on making a New Project so I'm really glad to have realized this sooner than later, albeit too late.

I need to figure out something for default analog mode. It currently defaults to tank controls. I should probably just force this to 2.

EDITED: I had to reupload to account for the "paddfg6" & "pacCfg7" bug and added analogMode=2. Luckily I went back to encode the defaults as 0x02137645 or I wouldn't have found 6 and 7 not working. It would be cool if SOM games could share a default INI file somehow. I'll try to remember to build that into the Exselector program.

142
Help / Re: x2mdl/x2mm3d download (2021)
« on: May 09, 2021, 05:11:19 AM »
Important fixes and working mdl2x :doh:

I've reuploaded, with a few important fixes to x2mdl that are too technical to explain really, but at least one can output animations incorrectly, that could go unnoticed, although it tends to be pretty obvious when it messes up.

Also the x2mdl I added last time turned out to be a dud. The reason it was on my mind is a I modified it to output (preserve) material names, but I hadn't thought about the fact that the rest of the file uses those same names to refer to the materials (as opposed to using their number) so it produced bad files that x2mdo, etc. won't even accept.

I haven't worked with mdl2x as much as x2mdl, but I've been using it for a while now without issue, so it's probably good enough more or less. I have a feeling if you tried to convert every one of SOM's models to X files with it there would be issues in many, but I haven't used it that way very much.

143
Beginner and other Nonsense / Re: STICKY: Random News
« on: May 08, 2021, 02:43:32 AM »
Unpublished work

I just worked on a nwse_saturation extension that makes the King's Field II style compass easy to adapt to a regular SOM project. This is something I meant to do earlier but completely forgot. It looks like it changes its color but its RGB values are fake: R sets the brightness of any opaque materials, G sets it for translucent materials, and B is an absolute opacity level for translucent materials. The problem with modulating the opacity is these colors can't go above 1.0/255 so to cover the full range you'd be tempted to make your opacity 1.0, but then your material would no longer be detected as transparent and so would not be subject to opacity, so this was just the simplest way. These values can be changed on the fly, mainly in case your lighting is different on different maps.

Other than this it's simple to modify the texture since it's not in the MDO file, it's just in the DATA/MENU folder like anything else. You can also replace the MDO file of course.

Just some things to look forward to. I try to post something when I add anything that could be considered a feature. The reason the 3D compass couldn't be easily used before is KF2 has wildly different colors because it uses a formula to augment it. The compass is still subject to the map lighting, which may not be ideal. I have to figure out a way to specify lighting conditions for individual models at some point (I have a plan of sorts) but there's so many numbers involved in lighting that you can't just feed those into an INI file.

Below is code for how to use this extension after I publish it. do_kf2 currently enables both KF style power gauges and the 3D compass. do_nwse is a way to just enable the compass, although it is a little strange because it dwarfs the SOM style power gauges. I should maybe work on shrinking it down to normal size in that scenario. It's a bit of a novelty for now. I don't know it should work with the do_st (Shadow Tower mode) extension or not since ST doesn't have a compass. (Currently that will probably overlap the magic and compass displays.)

Code: (Ex.ini) [Select]
[Option]
;also want KF style power gauge display?
;do_kf2
do_nwse
[Deatail]
nwse_saturation = id(255,96,128)

For the record, the reason I chose 0~255 values for this is I didn't want to make it 3 extensions or more complicated. This lets it be packed into one extension.

144
Devs / Re: EXIT: 25th Anniversary Project
« on: May 04, 2021, 03:26:54 AM »
UPLOAD FAILURE NOTICE (PATCH)

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip (reuploaded)

Lately my satellite Internet has been overloaded (stretched thin) to the point I can't really use it in the daytime. This is the second time I've uploaded something and software and webpages tell me everything went swell only to later find out either the file didn't actually transfer or is just a part of the file on the host's side (the other time was GitHub, this time it's FileZilla... or my FTP host didn't provide the correct feedback to FileZilla one.)

Honestly if HTTP/FTP can't identify doomed uploads I don't know what the hell they're good for. What's going on with software these days beats me.

Anyway, I've luckily noticed it because I was just quietly uploading a minor, cosmetic fix for the EneEdit and NpcEdit tools (to insert animation frame metadata to the top of the list correctly). Normally I don't expect anyone to be installing SOM. Hopefully no one did yesterday, I did chat with someone earlier today who expressed an interest. Fingers crossed they were in no hurry.

145
Devs / Re: EXIT: 25th Anniversary Project
« on: May 03, 2021, 12:01:07 AM »
Impressive patch

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

First this patch fixes a memory bug in the Ex.ini config file that could be critical (in the [Numbers] section) and corrects the position of the power gauges in the new supersampling mode without do_smooth.

Second for a solid week I've been hard at work on some major improvements to NPC movement. This is an area that's never been touched on before. There a are 3 things to see here:

1) Main thing, NPCs (monsters too) should navigate around 90 corners without any glitches and generally appear to do so in a natural way. This works because of upgrading NPCs to get some of the same benefits as the PC (player character) for smoothing their movements. It's a little complicated because NPCs have very different needs from the PC so there's two layers of smoothing to adjust the NPCs to be properly distanced from each other and obstacles since they're not a ghostly singularity like the PC is. If the PC had a body of speak of it would need some of the same considerations. Unfortunately this is not so cut and dry, so I've done the best I can and expect for this area to improve with more time and experience.

2) NPCs now fall with gravity. Although it's pretty similar to before. Since they don't animate to suggest they're falling/landing it can be a little stiff and is maybe a little slower than the original falling rate (I haven't checked) but the main difference is for a brief moment they accelerate, and they need this time to get further out from the platform they're falling off. Also their radius is reduced to 1/3rd for purposes of climbing and falling, so they don't hover out in midair so much.

3) Climbing is now smoothed out and kicks in at 1/3rd radius. For very large monsters climbing stairs may not be possible (it would look funny anyway) and the default climbing height is now cut in half to 0.25 meters, meaning that monsters are only really meant to climb proper stairs. It would not look good for them to climb higher than that without animations. Also this is fixed, as it's always been, but there's an npc_fence extension in the [Adjust] section that can customize it and incorporate scale as necessary.

Also, off the top of my head monsters are now unable to attack if the PC is vertically out of their range. For non-ranged attacks this is not an issue, since the attacks wouldn't land. For range attacks it might well break something. I've made this change quickly to prevent monsters from making attack noises when they're on a floor above or below (layers) the PC for my KF2 demo on itch.io.

146
Devs / Re: EXIT: 25th Anniversary Project
« on: April 23, 2021, 05:47:39 PM »
I give up!

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

This patch does several things:

1) Fix problem with magic SFX getting lost on map change or game over.

2) Fix problem opening SOM format save files from Windows Explorer with a WIP project... as opposed to a standalone game... which was what I tested the feature with.

3) [Bugfix] section now defaults to turning on all fixes, so you need to use "no" to selectively disable fixes or classes of fixes. This just makes it easier to set up.

4) do_fix_colorkey is added to [Bugfix] so you can use the weird pseudo 16-bit colorkey range for old games. Note, I've never found any explanation for why Direct3D 7 interprets pure black as a range of black up to 7,7,7 ... that makes no sense. FWIW SOM sets this range to 0-0... not 0-7. The Moratheia demo needs this turned on... or rather off.

5) I've uploaded a new itemsicon.bmp file that the Inventory menu uses for its icons adjusted for the new 0-0 range. I should get around to working on the other ones eventually.

6) This build restores an imbalance for the texture AA effect in regular non-supersampling mode. I also uploaded a slightly improved version for this a day or two ago but it severely undercut the texture AA effect that smooths textures with holes in them used for things like grass as seen in the Moratheia demo.

P.S. I've also added a "Strikeout" correction to Reply #33.

147
Devs / Re: EXIT: 25th Anniversary Project
« on: April 21, 2021, 12:14:47 PM »
Important patch #2

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

This patch disables the do_smooth effect in supersampling mode so that the game is as crisp it can possibly be. It's not quite as antialiased but I think being crisp and adequate more than makes up for that.

It also defaults to turning on superMode in the INI file. Since yesterday's patch the native resolution mode is more blurry than before, although it might be a good fit for 4k monitors depending on circumstances. I don't like making supersampling the default but I think it's the intended way to play going forward and this helps to ensure a good first impression, especially for people with systems that can handle it... whereas people with systems that can't are probably used to negotiating performance adjustments.

The supersampling mode always announces itself when the game starts. I don't believe I've added an extension to hide it. So this can be a fair hint I think.

148
Devs / Re: EXIT: 25th Anniversary Project
« on: April 19, 2021, 08:26:31 PM »
Important patch

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

I had a weird time today. And a long day. This patch seems to improve the antialiasing/supersampling modes significantly and fix a new problem on the Continue screen that hides the highlight among other things. And it restores the ability to jump over/onto fences in the Moratheia demo.

Briefly I noticed that one of the power gauges was doing something impossible pixel stuff wise that led me to realize the 1px black border that hides some issues on the outside pixels should be doubled in the source image when supersampling. This actually made the picture less stable in the moving high contrast regions, so I ultimately went back to before which was scaling the image down 2 pixels. For some reason doing it right made it possible to see the pixels behaving in a synchronized way... but my journey didn't stop there. In the final moments (just now) I really began to wonder if I'd introduced a problem at some point (some time ago) because disabling supersampling looked a lot worse than I ever remembered it. Luckily one of the same gauges started to twitch in a way that shouldn't be happening. So I found some code I thought had no effect at one point and turned it back on. And after that the change to double that border also looked alright. So I'm just patching this at the end of the day. Hopefully the supersampling is even better than before now. It really seems very stable on those problem edges, more so than I've seen it...

But I also realized something a little demoralizing along the way. In this supersampling mode, what seems to work is to double the size of the do_aa window. In that case the novel insight to do subpixel sampling by way of rounding error doesn't actually apply, and really it's just sliding the image over by 1 pixel in both directions. That's not nearly as interesting and defeats much of the original wow factor of doing it on the scale of a single pixel. It's like coming full circle and ending up having not really gone anywhere. It wouldn't be so bad except I really have difficulty going back to the 1x mode. I feel like now I have to find some new way to rehabilitate it.

April 23 Strikeout: Actually, this isn't true. I had another hellish day scrutinizing the system yesterday and I finally worked out that at some point I'd (intentionally) switched it over to clamping to half-pixel distances instead of whole pixels. Honestly I don't know how it ever worked with whole pixels... it's just to squirmy from what I can see... so (1) I wrote some notes down to remind myself of this in the future, and (2) I guess in supersampling mode it's not really shifting over the image by 1 pixel units. It's shifting a half pixel to either side, snapped to a point shifted over a quarter pixel from either the middle of the pixel or the edge of the pixel. But now that I have this better understanding I may find time to try different configurations in supersampling mode to see if it can be better.

Edited: Something else bittersweet is the extra sharpness seems to be gone away. That's probably why it looks more stable.

Update: http://www.swordofmoonlight.net/bbs2/index.php?topic=324.msg3151#msg3151

149
Devs / Re: EXIT: 25th Anniversary Project
« on: April 17, 2021, 01:20:26 PM »
Language packs patches

Japanese: http://www.swordofmoonlight.net/text/日本語/最新.zip
English: http://www.swordofmoonlight.net/text/English/Neutral.zip

You can copy these into your TEXT folder or use the updater tool to manually redownload these packs. Note, this process isn't currently automated. (It's difficult to devise a system to automatically detect changes. Not a priority ATM.)

These add page #2 to EneEdit and NpcEdit. They might have other backlogged changes too, but this is why I recommend downloading them (or one of them.)

Edited: There are several animation IDs on EneEdit's page 2 which haven't been implemented at this time but I want to publish it anyway to not sit on it further. #2 and #22 should work because those would've always worked if anyone knew about them. I haven't gotten around to the flight/swim envelope and the cryptic buttons in the turn table do the following:

*Fourth button (where 3 would go) may not last, I've used it to replicate slimes in KF2. IOW move without turning.
*F1 is unknown.
*F2 draws a shadow. I recommend disabling this only for something like the Stoneface monster that hangs on the wall.
*F3 enables "Evade" in SOM_PRM (you can do this from its animation button too.)
*F4 enables "Defend" in SOM_PRM (you can do this from its animation button too.)

I just included the last 4 for completeness. I didn't want to make space for them.

150
Devs / Re: EXIT: 25th Anniversary Project
« on: April 16, 2021, 02:24:08 PM »
One last 1.2.3.4 patch

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

This patch addresses a few bugs I've since come across that don't really warrant mention. Some I probably have forgotten. (Edited: I remembered one important fix that's maybe what prompted me to upload a patch today. The first frame of the red damage flash was coming in at full color because of a change I made a little while ago. You wouldn't think it would matter since the first frame is nearly transparent, but I realized that's what was causing a bad feeling about the red flash that's been bugging me lately.)

I've added some sweeteners to update my itch.io KF2 demo, the main being using the action/menu buttons to confirm/cancel in menus. This is something I got some complaints about. I think it's good addition although I have to get used to it. Of course it's more intuitive. It only works if the buttons are assigned to the shoulder buttons because they're not used by menus. Since I expect people to use the shoulder buttons I think this is enough for now.

There's a quick fix for the arm covering up menus in the recent change I made to put 3D items in front of them. It's clearing the depth buffer when the arms are in front of menus... but now writing that I recall considering putting the menus in a depth-partition with KF2's 3D compass. The only drawback to that is less depth-buffer for the scene, but SOM games probably use very little of it, although I can remember it having problems with 16-bit depth buffers. The compass partition is very thin now, it might not be deep enough for a compass that really requires a depth buffer since it's effectively a 3D item.

I feel like my memory is getting worse trying to remember if there's anything else I should add to this post. It is possible now to set monsters up to attack from further than their damage radius (or less than) by using the second radius in EneEdit. I had to look at that for KF2's skeleton monster. I wrote about it yesterday in another topic/thread. I think it may be a bug that the wrong radius was used. Looking at how the skeleton works it seems like too much of an oversight and it's hard to explain why there would be an extra attack radius in the PRF files that matches the damage radius so closely in every instance.

Pages: 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 ... 58