Topic: EXIT: Back! (Read 11122 times)

Holey Moley · « **on:** February 01, 2018, 02:25:44 AM »

Quote from: http://www.swordofmoonlight.net/archives/sword-of-moonlight/2018/01/back/

I’ve prepared a new release in 3 days flat, and am rushing it out to make this January 31 blog post.

I am very eager to work on Sword of Moonlight again. I’ve been absent since mid December, working on various things, some tangential to Sword of Moonlight, but mostly I’ve been very frustrated, feeling as if I was not being productive, whether or not I have been, the feeling persisted. Ostensibly I was working on a difficult problem to do with writing XML like documents and accoutrements to ZIP archives, within a framework of my own devising that is — as it turns out — perhaps too transparent for its own good. I cannot say why that work drug itself out for so long, other than it’s highly conceptual and because it was in service of a “software library” its bar is much higher than Sword of Moonlight’s. Adding insult to injury is the feature itself is more a logical gap than a pressing matter — no one really needs it, but logically it should be part of the feature set. It’s refreshing to be able to turn out a new and important feature in 3 days in comparison.

This release adds to Sword of Moonlight new modes for for the first time to be able to see the world model’s boundary geometry. Sword of Moonlight could get away with this as long as developers weren’t in the business of working with boundary geometry. If you found yourself in that boat, you could only play-test the product and inside it virtually rub yourself up against every surface to determine if they are satisfactorily impermeable or not! While this may sound like just good wholesome fun, it isn’t exactly a good use of developers’ time. I myself was doing boundary geometry modeling work toward the end of 2017 and I stopped doing it, because I could see that, by working blind, my work had been prone to error and time consuming. And so I resolved to work on the absent-feature problem, before resuming my modeling effort to polish and streamline the From Software staff’s artistic contributions.

In brief, one of the main editor’s screens is expanded, and a secondary goal involved changing its workflow to make way for near-term expansions, since it will host most if not all of the new map work features in store for 2018 (all of which will serve the greater goal of bringing a complete reproduction of King’s Field II to Sword of Moonlight in 2020 in recognition of both product’s respective 25th and 20th anniversaries.)

Details are coming

In the meantime please refer to a previous forum announcement (http://www.swordofmoonlight.net/bbs2/index.php?topic=257.msg2413#msg2413) including a screenshot of the newly expanded 3D map preparation screen. (I'm in a rush to file this before February, since I try to make a substantive blog post every month, give or take. Sorry, but for what it's worth this development is because I realized a January release was possible, when I had not expected to finish this work before February.)

Quote

P.S. This is http://csv.swordofmoonlight.net/SomEx.dll/1.2.1.12.zip.

SVN Update is required to get the white MAP/TEXTURE/dummy.txr file:

http://svn.swordofmoonlight.net/Sword-of-Moonlight/data/map/texture/dummy.txr

Language pack update is required to get the new buttons, etc.

www.swordofmoonlight.net/text/English/Neutral.zip

I may patch some things into it, that didn't make it in the rush.

Holey Moley · « **Reply #1 on:** February 02, 2018, 05:47:19 AM »

Attached is a side-by-side show of how the newly expanded screen (165) looks/works.

The view on the left shows the MHM file's model, wherein the button is toggled. The view on the right shows the (business as usual) MSM file's model, wherein the toggle button is depressed.

The 3x3 tile preview screen shows the blue/white MHM models also. And the Cliptest... button generates an MPX file that replaces the MSM models with the MHM models, so that what you see is identical to the clipper's polygons.

With the toggle on, the simple triangle button generates an MPX that is like Cliptest... instead of like Playtest...; The Playtest button on the main screen opens the player to the MPX file whether it was created with MHM or MSM models in mind.

The shade of blue is just a number I chose intuitively when I first programmed the feature. It was this color on the the first attempt. Maybe there is a better color, but it is not such a bad color. The white edges are so, only because white is the default color when there is a not a texture bound to the model. Needless to say, that's simpler than managing a texture for the time being.

Originally screen 165 just had the two checkboxes shown and OK and Cancel buttons. With the new workflow it's possible to generate an MPX without saving the checkboxes to the MAP file. That makes one-off tests straightforward. The old OK button becomes the Playtest... button, and the new replacement for it just records the checks in the two boxes. The new toggle button is not recorded in the MAP file, and is not subject to the new Record button; it's just tucked away inside this specialized screen, since it's pretty much the only remaining screen that has room for expansion.

For now, the Playtest... and Cliptest... buttons have the side-effect of closing the screen. It will probably be difficult to make them not do so, however presently there is no reason not to return to the main screen, since logically nothing remains to be done afterward, and so it would be uneconomical to not return.

It can be a little tricky to make sense of the all white walls inside of the player. I'm unsure what to do about it. I don't know if there is a satisfactory way to generate texture maps; without which the walls can only be the same color throughout.

I think some relief can come from modifying the per-vertex lighting values in the MPX data. I don't know how to do that for the moment. In that case, something could be done, like to highlight the different kinds of clipping surfaces, so they would stand apart, and to use a secondary color to form a checkerboard tiling, so that it would be less likely that disconnected faces would blend confusingly into one another.

Furthermore, although not a great priority, do_aa applies to the MHM models in this test mode, and so cracks can appear if care is not taken. It's of no importance to the end product (of course) however there's no reason that the development process cannot be an unblemished esthetic experience in itself

Holey Moley · « **Reply #2 on:** February 02, 2018, 09:16:19 AM »

Japanese text is now available at http://www.swordofmoonlight.net/text/日本語/最新.zip and via the language set up tool.

I'm thinking about experimenting with a top down projection for texture mapping and instead of using dummy.txr, maybe making an atari.txr file up for the job. (Atari means "hit" in Japanese, and it is the word PrtsEdit uses, or rather hit-judgement.)

If so (I probably won't change dummy.txr back to yellow) the texture will be visible on the floor, but vertical walls will just be vertically striped. But that can be useful because slopes will be in between, and so can be seen according to the shapes that will appear on them.

The player can easily detect MPX models that use only this special texture and may take the opportunity to show NPCs and "objects" as their clip models, and also 3D patterns can be applied to them via dedicated shaders/extensions that might make for more pleasing experiences.

Holey Moley · « **Reply #3 on:** February 03, 2018, 11:22:40 AM »

Patch

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

SVN Update is required to get the white MAP/TEXTURE/atari.txr file:

http://svn.swordofmoonlight.net/Sword-of-Moonlight/data/map/texture/atari.txr

This patch changes the MHM->MSM models to saying "atari.bmp" instead of "dummy.bmp" (SOM changes bmp into txr; kind of annoying that you have to use bmp2txr all of the time to convert these.)

I made an atari.bmp file that looks like the screenshot attachment. It's 256x256 and looks crisp except on very steep slopes. Something that dismayed me is the UVs have to be adjusted by half a pixel, which means that textures can't be hotswapped for textures of different resolutions. I don't know if this is a common dilemma for 3D artists, or if SOM is doing something, or if Ex should establish a system for adjusting UVs according to the size of the texture.

Update
It looks like 256x256 textures don't have this centering issue, and trying to correct them results in being off center. My hunch is this is a bug inside of som_db or mapcomp one. I'm thinking it has to do with how MDL's UVs work, which are funky because they are 8-bit, but the corrections that apply to them should not apply to MSM and MDO's UVs. It seems like MSMs are getting the same treatment, erroneously if so.

Without a matching (atari.txr) texture, SOM_MAP will complain about not being able to open a file, but it doesn't say which one.

(P.S. About this screenshot's map; if it looks nuts, it's just islands of tiles laid out in clusters for feature testing/seeing how if they fit together. Green walls are on a 1 meter mark.)

EDITED: Code is up. And I think the prior release had a lot of patches, not yet in the CODE folder.

Holey Moley · « **Reply #4 on:** February 04, 2018, 11:11:36 AM »

Important bug/feature patch

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

Today I worked on correcting the aspect ratios of pictures. I was going to include this work in a patch, since I wanted it to be in the rushed release...

BUT LUCKILY while I was doing tests, I noticed last second that I must have introduced a bug into SOM_MAP's new "play" button feature (I must have edited it to act like the Save prompt is an OK/Cancel menu instead of Yes/No while working on the new 165 features.)

SO! You definitely want this patch for the bug-fix. And the picture fix is very nice too...

P.S. I worked on aspect ratios before, and I ran into troubles. I'm not sure why exactly. I might have been trying to do something more ambitious before. However I did realize at some point, that in addition to changing the picture (SOM stretches them out) simultaneously another variable happens to be the extension that stretches the window out in 640x480 mode; which is something that I'm pretty sure never occurred to me before, and so very well could've been why I got stumped in the past when trying to fix this.

For the record, I think everything works, picture wise. I believe that one of the picture event options is made redundant by this. That is the one that stretches to fullscreen, won't stretch anymore. I can fix that with more work, however I'm not sure there is a good reason to stretch an image out when monitors today can vary so much...

This work made me realize that the start screen graphics (text) need to be corrected also. Still, while doing tests they never look bad per se, so I'm going to put that off for the meantime. They do look funny if the window is much taller than it is wide (speaking of which, I discovered a bug when trying tall settings that because a viewport calculation wasn't rounded, it was somehow making the viewport smaller and smaller every frame until rounding was no more necessary. Funny that the problem has never occurred with horizontal settings) however there are many other issues in that case, including the text is very likely not fitting in the window, and weirdly I noticed in 600x1024 mode the gauges onscreen display was scaled larger than the compass and was taller than it was wide... I don't know if this is a bug, or if SOM is doing it, or if it's an original bug if so.

Holey Moley · « **Reply #5 on:** February 15, 2018, 04:26:02 PM »

Patch

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

I'm about to do a new release tomorrow, but I've discovered a few bugs in the last days that I want to fix in this release, since it's only two weeks old.

The next release's feature is not in this build. Some unrelated enhancements are.

I was going to let the bugs slide, but I just found one, where SOM_MAP would refresh saved PRM files without creating placeholders in the unused slots. It looks like I removed the extended processing for refreshed files, but failed to replicate some essential processing, including this.

Some other bugs I can recall, is pressing spacebar in list-box elements was generating two double-clicks, which was disastrous for SOM_MAP's event table and programming screen. This was a side effect of the new search function. Another bug is the search function itself would not load the found item in SOM_PRM. I discovered the former bug while investigating the possibility of other loading issues.

There might be other slight bugs. One I recall from yesterday, is for the knock-back extension, traps stored their 3D position 1 off from NPCs. I should probably double check that their scale factor is right too. I intended to revisit magic missile damage stuff today before going forward with a new release. Something that made me curious about that, is that traps use the same classification. (Which is a problem for the alternative hit mode extension, since it would follow that the Magic variable would be all that stands between the PC and trap damage. Never mind that some indirect attacks--like arrows--are legitimately not magic born, and so will require some further extension work.)

EDITED...

Holey Moley · « **Reply #6 on:** February 15, 2018, 06:59:53 PM »

EDITED: Reuploaded the patch so that the new _MODE number is not set, and the old default damage formula is used. (Also made it so _MODE can be set to opt to use an older mode/lock-in the mode that the game is designed to use.)

Holey Moley · « **Reply #7 on:** February 16, 2018, 03:04:02 PM »

Patch Patch

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

Yesterday's patch makes SOM_PRM's save unfinished work prompt overzealous.

1.2.1.14 (unannounced) is also patched. Including making objects that aren't traps default to 0 Strength & Magic instead of 50. Just for looks.

simple machines forum

News:

Sword of Moonlight|

Devs|

EXIT: Back!

Author Topic: EXIT: Back! (Read 11122 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,

simple machines forum

News:

Sword of Moonlight| Devs| EXIT: Back!

Author Topic: EXIT: Back! (Read 11122 times)

Sword of Moonlight|

Devs|

EXIT: Back!