simple machines forum

Please login or register.

Login with username, password and session length


Remember to make your own backup of posts before submitting.

Pages: [1] 2 3 4 5 6 7 8 9 10
 on: Today at 08:27:43 PM 
Started by Holy Diver - Last post by Holy Diver
Attachments * 1200px-Pieter_Bruegel--doctored-color.png  * Widgets 95 UI.png 
Man... I don't know where the past 10 days went :sweatdrop:

That's software work. It can be hard to decide when it's time to publish software. In the final days it's a weird feeling of not knowing if everything is in place or not. Sometimes it's simple to say yes or no; other times it's only a gut-level instinct. So far that instinct hasn't kicked in for this work.

Mostly in the past 10 days I guess I started rebuilding my COLLADA-DOM code with the addition of this new system. I want to use it somehow with that code, but it's a very simple piece of software, so it would not be appropriate to build a big user-interface experience into it.

In doing so there were also a handful of GLUT subroutines that needed to be added to my list of pseudo-emulated GLUT functionality. I want to say emulated, but really the line between emulation and implementation can be a matter of semantics. I've been researching text also, which is the biggest component. Text rendering that is. I tried to generate bitmap fonts with wxWidgets without success, but it was a good learning experience. It was unable to disable antialiasing effects in fonts, so it couldn't be used to generate bitmaps... literal bitmaps, i.e. where every pixel is 1 bit. So, since I had rendering code as a result, yesterday I worked on copying over the fonts that are built into GLUT. That was the last needed component so to not require use of a GLUT library.

In the attached screenshot is what I ended up with for adding some UI to the COLLADA-DOM file viewer/downloader software. The helpful keyboard cheat-sheet and drop-down menu are new additions made possible by replacing GLUT with an in house implementation. GLUT cannot put up a menu like that just anywhere in response to a key combination. It can only put up menus in response to mouse clicks. The browser history bar actually was designed to act like a command-prompt. But those go up (up arrow key) to go backward in time, in which case going down makes it possible to get a more user-friendly pop-up menu. But either way works.

The second attachment is something I'm thinking about using as a splash screen for the new Daedalus 3D modeler software. I'm not sure how exactly it will work, since it's much larger than a normal splash screen. I'm using Daedalus as an opportunity to inject more of my personality into my work than Sword of Moonlight can afford. I want to explore a "noncommercial" esthetic in Daedalus. In a way, to my mind, the character of Icarus is emblematic of the commercial software community. And it is something that I expect to disappear into the past in many ways, in order for a noncommercial community to take on more responsibility with a coming maturation of our human culture. I can't help but feel that culture has a lot of room for growth. We are really primitive.

EDITED: In theory... in this painting, the little man in the middle looks up into the sky at Daedalus of myth. His line of sight is aimed where the software's icon goes. Icarus has unseen fallen into the water. Their time is past and they fade out of frame without notice. The old man carries on. As they should.

 on: June 16, 2019, 06:19:48 AM 
Started by Holy Diver - Last post by Holy Diver
I think I spent several days wrestling with this on Cygwin/Linux systems to make it work as well as it can for right now. I want to first deploy it with my COLLADA-DOM work, so it needs to work with these systems before I can publish.

That works through the GTK framework. In theory it works with Apple systems too (thanks to wxWidgets) but I have no way to know myself.

To be honest, I have no idea what to do next. I should probably try to publish something on the site. If I cannot think of something else to do, I may start work on the the 3D modeler component.

 on: June 09, 2019, 07:36:21 AM 
Started by Holy Diver - Last post by Holy Diver
Attachments * D3DXLine+do_aa.png 
minor feature patch


I had an idea to fix the lines in ItemEdit by using the ID3DXLine facility from D3DX.

It's a really minor thing for now, since you only see it on the screen that sets up the relationship of the item to the ground, but it will be a good technique for whenever SOM_MAP gets upgraded to use Direct3D9.

The short explanation is the do_aa function doesn't look good enough on lines. I don't know why precisely that is. But the ID3DXLine facility will draw lines as polygons, but only if the width is more than 1 or the antialiasing mode is used. Fortunately the antialiasing mode looks best.

It was unnecessary to disable the do_aa extension. This is only done if it's used. I'm not posting a screenshot because it's really nothing to look at. What's important is that it looks acceptable, and also it's nice that it matches the rest of the image.

EDITED: Okay, here is a screenshot, I just happened upon. It has dithering enabled, which is not technically related to the effects involved. That's why if you look closely the lines look like they are stippled.

 on: June 07, 2019, 12:46:28 AM 
Started by Holy Diver - Last post by Holy Diver
Attachments * GLUI 2019.png 
This is an update image so I can post it. It's the same as the one on without its truly crumby (PlayStation FMV level bad) image compression.

 on: June 06, 2019, 09:30:18 PM 
Started by Holy Diver - Last post by Holy Diver
Update: In the last few days I've returned to this work. I've decided on how to repackage the UI code and have developed an emulator of GLUT that uses wxWidget's wxGLCanvas. GLUT is a framework designed for demos and test projects. It has always consciously limited itself so it is not useful for full-featured software...

Through emulating it it's possible (and easy) to leverage wxWidget facilities to overcome its deficits. That's a first step. Emulation was simply the simplest next move I could contemplate.

GLUI works as a high-level wrapper around GLUT in many regards. Maybe my plan is to use the old GLUT methodology as a low-level description of this new UI framework, since many people are familiar with it, that could help. It also demonstrates that GLUT is obsolete, since you can more easily implement its basic framework in terms of a more mature cross-platform framework like wxWidget's.

The "widgets" in Widgets 95 is to honor wxWidgets. It doesn't look like I've said so here yet, but when I first started developing this software I wanted to call it 95 as a shorthand, but in code you cannot use a number as a name. So what was simple was to replace it with xcv, since that's Roman numerals for 95.

But this was fortuitous, since xcv is also the three letters on the keyboard that are used to do "Cut Copy Paste" that is a paradigm of modern UI. And being lined up, it's very easy to type xcv.

So I thought I'm onto something. I ended up adopting the naming conventions of the C++ Standard Library for this project. So that means the names are all lowercase. And that helps to simplify some things, like do you write ScrollBar or Scrollbar? Checkbox or CheckBox? Well, all lowercase you don't have to decide. But I changed some of the names too. I changed scrollbar to just bar, because GLUI also uses it as a trackbar, so I thought "bar" better represents this dual use, and it's just shorter. And I changed checkbox to "boolean" because I'm trying to approach the system with fresh eyes. It's called Widgets 95 but under the hood I like to think it's 2095 instead of 1995, but it's really a very simple system because I'm a maximalist minimalist myself.

EDITED: Upon proofreading this, I think I was unclear that "XCV" is kind of the informal name of the project. In code while the official "namespace" is Widgets95 the internal file names like xcv_button.cpp, for example, use xcv, and you probably want to alias the namespace to xcv so that you write xcv::button, for example. This is inconsequential to end-users, but it means a lot to developers. I'm developing this more so as a public (reusable) UI framework as opposed to SomEx, which is private, internal (single use) application.

Finding a way to do text with wxWidgets is going to be a big project. I think I can avoid that though for a while by using GLUT in a hybrid way. GLUT has some procedures that just translate to OpenGL code. Its text procedures fall into that category. So it's possible to use it just for text.

Later on I think I will have to implement text in two different forms: one for 2D and one for 3D, since I don't think 3D will be applicable to both, except for large text perhaps. Ideally I'd like to be able to use something like Windows' subpixel text facility for 2D modes. Sword of Moonlight doesn't use it, although it can if you change the font in the language package. It might not look right for this either. 3D text will be required for VR.

I'm leaning toward using this ( technique for it. "Multi-channel signed distance".

 on: June 01, 2019, 04:15:10 AM 
Started by Holy Diver - Last post by Holy Diver
:blow:New Release ( Announcement:blow:

The deed is done :king:

Update: There’s a new release centered around a new feature called SoftMSM that blends lighting where cells touch in-game.

Use SVN Update to get the new MSM files that have (all) been modified. It took a real long time to upload them through the SVN system. I don't know why Subversion can't do burst processing of small files on checking in.

Language packages are slightly modified...


These can be (manually) updated in the updater app (SOM.exe) but there isn't yet an automatic update detection process for the language packs. They add the Tools menu to PrtsEdit and a minor enhancement to SOM_MAP's elevation facility (it lets you change the unit for using with Shift, which is 0.1 by default. KF2 uses 0.125 because of how the PlayStation worked. You can use it to work with any increment, but it's kind of a burden to have to use Shift.) 

There is background information here ( and here (


[organic cells blended into one large organic map model]

This is a pretty sexy update. It's something I've been planning to do since working on layers last year. It doesn't have anything to do with layers (other than it integrates with them) but the layer work was the impetus to dig into the MapComp tool. I exhausted myself on layers, but planned to return to MapComp to work on this.

After I completed a major project a little while ago I've been doing small things. This idea captured my imagination a week ago. I thought it would go faster than this, but it turned out there are a lot of details involved.

I haven't made an effort to scrutinize every MSM file. I just mass converted them with the new SoftMSM tool (that you shouldn't have to use) and a few of the exterior set MSM files needed to be forced to blend their edges since they looked like hard edge polygons. PrtsEdit has a new Tools menu that provides easy access to this for when you want to just force a particular MSM to blend indiscriminately. It helps for organic models, but if model edges are a mix of hard and soft polygons then you must remodel them to achieve what you want.

This won't always be the case (forever) but there isn't (currently) a guided system for choosing which vertices to blend or not. Worst case scenario you somehow have to make a hard (flat) polygon be ever so slightly soft (somehow) because you want it to blend but you also want it to appear to be flat, or don't have enough geometry to get the effect you want. Usually models are either organic or not. Another possibility is you have an edge that you really want to be hard (flat) but it's connected to a soft polygon. Unfortunately there isn't a fix for this. Just move the feature away from an edge (note: edges belonging to the same cell aren't blended.)

EDITED: If you're in the business of making custom MSM files know that MapComp will automatically modify the files with the same process as the TOOL/SoftMSM.exe (mode 0) so that you don't have do that. If you need to force a tile to be soft (mode 1) then PrtsEdit is available from inside SOM_MAP. It can also force a tile to be hard (mode 2) but that is more like disabling the blending feature for that tile and its neighbors.

The SoftMSM tool also removes duplicate vertices that x2msm generates, and it "normalizes" your surface normals, because they need to be so for the blend feature to efficiently compare their angles. Normally normals are normalized (that's probably why they're called normals or the process is called normalization one) but for whatever reason some or many of SOM's stock MSM files had normals that were far from normalized. Normalization changes their appearance. This is also described in the background links.

 on: May 31, 2019, 01:20:31 AM 
Started by Holy Diver - Last post by Holy Diver


I've reuploaded the patch from earlier today with a fix for the = button under multi-select. The problem had to do with work from earlier to let it work with any elevation. The multi-select version took a different path I hadn't thought to consider.

I also enabled the SoftMSM feature for this patch via MapComp to let it be tried out. Maybe that's a bad idea. But what the heck. It won't work automatically for all tiles, since some tiles that should be soft have hard edges.

Today or tomorrow there should be an update/release with some new MSM files, at least for SOM's exterior set. And tools for spotfixing files. There will be a slight language pack element. Now I mainly just need to make the command-line SoftMSM tool a little more user-friendly.

SOM_MAP has a new box for changing the elevation ticker's increment. This came from King's Field II using 0.125 instead of 0.1. There's also an extension to set the project's increment. Currently this increment is just used when holding down the Shift key with the ticker. The large step size of 0.5 is not changed, since for KFII it just means 4 steps instead of 5.

 on: May 30, 2019, 08:09:50 PM 
Started by Holy Diver - Last post by Holy Diver

Critical fix for more SOM_MAP problems born of the the new layer system.


This fixes Copy/Paste on the maps menu, and a big problem with saving your MAP file. Sorry.

I introduced a problem a little while back into the layer system that was meant to be a diagnostic for myself. I really think this is the end of it. For me (debug mode) it would alert me to the problem when saving, but I just never saved after I set it up I guess. I probably thought I would (in time) but I didn't expect the alert to trigger.

I may have been using it in public (release) mode for a time. Or it's just my luck.

I'd like to think this is the end of it, but I only just discovered the Copy/Paste problem last minute.

I'm working on a new release for any day now. But I wanted to get this fix into this release. This morning I worked somewhat doggedly to get the stuff I'm working on right now finished so that this patch cannot present any surprises later, since it has a new MSM blending feature built into it, but it still requires files to work with it that will come later. Maybe I should've enabled the automatic file generating system, but it didn't occur to me to.

P.S. I discovered just earlier that SOM_MAP's = button that does elevation assignment seems not to work for multiple selections. I can't believe I've noticed this before. It really makes me think something is broken. But it's something I have to figure out before a new release.

The new release will just be tacked onto this topic/thread. I think the "website" problems it speaks to are bound to start any day now.

 on: May 28, 2019, 06:54:31 PM 
Started by Holy Diver - Last post by Holy Diver
Attachments * SoftMSM.png 
As a little project between projects I've taken advantage of the some inroads into MapComp from last year to blend together the MSM models in the MPX model.

This is going to be a new release sometime this week. The MSM files are modified slightly. This is done "opportunistically" by MapComp so that you don't have to do anything. There will be a SoftMSM program that can do this. But also I've added a menu to PrtsEdit that does the same operation with the same code used by MapComp.

The PrtsEdit menu has an option to force edges to act like soft polygons even if they are not. This is useful in some cases. I need to add that as a command-line switch to the tool. The default behavior is to ignore hard polygons. That means to make two MSM files blend together they need to have vertices that touch and belong to a soft polygon and they need to be naked edge vertices. Although there is a slight problem with that, since the algorithm doesn't yet understand edges that coincide but are technically different because of UV texture coordinates.

The UV problem wouldn't exist for a format like MHM or MDL. But MSM and MDO double up vertices as necessary to satisfy hardware constraints.

A tile will not blend with itself, so the texture coordinate problem doesn't present a true problem. But it's something that can stand to be improved. I just don't know if it's worth tackling now.

If the same tile has multiple vertices owing to UV differences, then they are averaged before blending; weighted according to the number of doubles.

I've set the cutoff angle to 66 degrees. This is pretty conservative. Anything beyond that must be dealt with by remodeling the MSM file, or making a new MSM file. This figure could be exposed as an extension.

I ran into some surprises with SOM's MSM files. For one, there are duplicate vertices in them. I think that's because x2msm doesn't reuse vertices when it subdivides the mesh. The SoftMSM tool must remove the doubles, so that the edge connectivity can be used to make sense of the mesh.

Another curve ball is the surface normals in the MSM files are not always "normalized" and so I made the potentially destructive decision to have the SoftMSM process normalize them. The reason being, the cutoff angle is hard to compute otherwise. It would require making copies of the surface normals and normalizing them in MapComp.

Unnormalized surface normals are kind of an artists' trick, but I don't know if Blender is producing them, or if they are leftovers from From Software's art tools, or what. I think SOM shouldn't use them though, ideally. Because what it means is if you shine a light on them, they will change the power of the light. That can be a useful tweak, but it's kind of like embedding occlusion lighting into a 3D model. It's not exactly kosher, and it's easy to lose the custom normal if it goes through software that normalizes normals.

I looked for examples of smooth-normal algorithms that don't normalize. I didn't find any. So I think it's safe to normalize them. It may even solve some problems with From Software's art, if that's where they're coming from.

But it is destructive, since it changes the character of the artwork.

Attached is a screenshot of a simple test map that is representative of the final effect. The modified MSM files should be backward compatible, not that it matters. But it's a slight change to the format. I don't envision many more changes to it. I think the process could be guided somewhat. But that would need a format other than MSM to use as the source material. To make this screenshot I ran the MSM files through the tool, and a few that hard hard polygons I used the "force" solution on, so I don't have to edit the model itself for the time being.

I don't intend to check every MSM file for this release. I've noticed some models that seem like they should have soft normals use hard normals; for example some slopes in the cave sets. This feature is more geared toward facilitating new custom map sets. I think my King's Field II project will benefit from it a little bit, but not a whole lot. I didn't really do it for KFII. It's been a longstanding problem, and as soon as I could catch a break, I wanted to tackle it, since it was within reach.

It's supposed to work across layers. I don't know if it will in the first release. I planned to implement it that way from the beginning, but it actually came together pretty easily, and so I forgot all about doing it in terms of layers. KFII will definitely need layer support. So maybe I will use the next few days to work on a system for layers, or maybe I will put that off for another day. (I will probably work on it. I totally forgot about it until I was writing this. That's why it's helpful to keep a development blog.)

 on: May 26, 2019, 02:07:29 AM 
Started by Holy Diver - Last post by Holy Diver
It turned out the MapComp code I was investigating yesterday was not so interesting, since it only converted some other data from another step into the MPX format. But I did work on following that lead to the source.

There are lighting surface-normals for every vertex instance during the lighting stage. So, with any luck, they can be averaged (at the right time) before the light stage is entered.

To blend the seams between tiles, I wanted to narrow the problem down to smooth polygons that sit on open edges.

I decided that computing that information in MapComp seemed overly labor intensive, though I'm sure MapComp does a lot of unnecessarily labor intensive work.

What I came up with is to modify the MSM format by adding one extra number onto the back of the files.

I think that will be done automatically by MapComp, and it will then save the file over itself modified. I can see how that might be a bother, but it seems like a simple way to make things easy for users. Just hopefully they're not confused about their files being modified without their own personal involvement.

I worked on a tool I've called SoftMSM right now, that does the same thing. Its code is the same as the SomEx.dll code, except it's packaged for use as a command-line tool.

It's mainly so you can prepare your MSM files without MapComp, as that would require a MAP file and a MapComp session. Obviously I will need a tool to apply this process to all of the MSM files in the DATA folder.

The "soft" files differ by having their soft-edge vertices pushed to the back of the vertex list, and duplicated if necessary to preserve hard vertices. The first soft vertex is the number added to the file, on the end. So this way MapComp can know which edges it should attempt to blend, and so not waste any processor time on the others.

The blending criteria is going to be pretty conservative in order to accommodate two-sided polygons, like KFII's waterfall. If not, it's very hard or impossible to avoid blending both sides of the polygon together and so produce wrong lighting.

I programmed most of the SoftMSM tool today. It's going to work with layers.

I think it will be done in a few days. It will probably be reason enough to do a new release if so. It will include the modified MSM files.

Future MSM tools will have this process built into them. They may offer more control over it too. Open/soft faces can include faces in the middle of the model that might have no relationship to neighbor tiles. Those will have to be considered regardless. Though tiles can also now connect via layers. And layers are not just for vertical relationships.

EDITED: SoftMSM information is continued here:

Pages: [1] 2 3 4 5 6 7 8 9 10