Upcoming release

[ibm5155]

I see some good stuff with uwp like:
-apps are never going to touch your regedit again (they are going to have their own virtual regedit)
-one click uninstall app.
-one click install app (no more softwares that downloads the software that you want + some trash).
-sandbox apps, so I belive the chances of implementing a vírus are quite null.
-apps doesn't leave trash when uninstalled.

Someday I'll try to play with that console app that ports your desktop app to uwp (testing with zdoom / gzdoom)...

The only draw side for now that I see from UWP is that they're going to force you to use directx only render, (could use opengl es with angle api, but rip opengl and vulkan)...

For a normal user, if UWP gets a good amount of good desktop software, they'll love it, and the developers will hate it since they'll not be able to use all the normal windows features.
In case someone is curious, this is the tool for converting desktop apps to uwp without any code change https://www.youtube.com/watch?v=MdxK9-3N5Qs

[Graf Zahl]

For a normal user, if UWP gets a good amount of good desktop software, they'll love it, and the developers will hate it since they'll not be able to use all the normal windows features.

However: If the developers hate it because it's so limiting, they won't use it. And people won't learn to love it without software.
Keep in mind: Lots of desktop software these days is cross-platform, using some sort of UI wrapper, like Qt or wxWidgets. And if these cannot be easily ported to UWP it's a losing proposition, because a significant quantity of software will remain on Win32. Which will also mean that no user can go exclusively UWP and once they notice that UWP apps are focussing on the superficial tasks, the game will be over.

The good things in there should be ported to Win32 in a way that allows full use of its features - if it's only the distribution that's being changed it'd be win-win for everybody. But as it is now, it's lose-lose.

[Rachael]

There's only one reason you'd want to even consider UWP: If you want to target Windows Phone or Surface Tablets. Something, from what I understand, that has a very low usage compared to iOS and Android.

It's ironic: Nobody designs for PC Linux because hardly anyone uses PC Linux. Android (originally based on Linux) is by far the most commonly used phone/tablet operating system in wide use today. The same thing is happening with Windows for ARM. But Microsoft doesn't want to admit they made a mistake here - as Graf said, shareholder skepticism can be a real issue.

From a user standpoint: Yes, UWP is convenient. But nothing more. It's too stripped down to be of any use to a real developer.

And now you're in a catch 22: Nobody designs apps for Windows Phone, because nobody uses Windows Phone, because there are no apps for Windows Phone, because nobody uses it...

[Graf Zahl]

As someone who did some work in that area, the real catch 22 actually was that Windows Phone 7, despite its name has nothing in common with Windows. It was a completely new platform with zero source compatibility with anything. That was enough to outright kill developer momentum from the start.

That changed with WP 8 but it was too late, the damage was done. WP 7 had already proven that the platform was not commercially viable and here came a new iteration which was - yes - completely incompatible with its predecessor. All old code had become useless. Guess what most developers did...

And the fact that it had no OpenGL support also did not help - only topped by a very crippled D3D version. But the fact that it was totally hostile to any attempt of writing cross-platform code certainly did not encourage developers. One particularly nasty trait of WP is that it got a timeout on any file operation - Microsoft wants developers to use asynchronous file IO (which of course is a concept that cannot be integrated into existing code at all.) Needless to say, this wreaks havoc with most code coming from iOS or Android, in particular, because the synchronous file API can only be used on assets, not on external files.

The amount of deadly mistakes Microsoft made here is absolutely staggering, and this ultimately cost Ballmer his job.

[Rachael]

Every time someone mentions Steve Ballmer....

I'm sorry, I have to do this

LINK

[dpJudas]

That one is way too calm for Ballmer. You need something like this:

LINK

Totally agree with Graf on this subject. Microsoft failed in every possible way you could fail!

[ibm5155]

Uhhh, WP7, that's actually an os (Windows ce fork D:) that should never have ever existed, they really should have waited to at least release wp8.1, there were not even Direct 3D support by normal code, only if you used the dead XNA D:::::
It's also weird to know that Microsoft tried to make an universal platform since Windows 95, but only now they are starting to do something ...

OFF: ehm, shouldn't all those talk be splited into another thread? or is it ok here?

[Graf Zahl]

It's also weird to know that Microsoft tried to make an universal platform since Windows 95, but only now they are starting to do something ...

That was against Ballmer's vision. At his heart he's a bean counter who only saw the customers as a source of revenue that, due to Microsoft's quasi-monopoly had no other choice but to stick with them. Well, the customers had different ideas and now, where they had a choice, they chose differently.
And weirdly, Apple is starting to do the exact same mistakes now, which started the whole thing... (only without the monopoly to guarantee survival.)

[Rachael]

If Apple does meet its demise, I hope Mac OS X and its source code gets released into the public domain. It's probably not the best operating system on the planet, but it'd be a real shame to lose all that.

[Graf Zahl]

If Apple meets its demise those would be hot properties that would be sold to the highest bidder.

[Graf Zahl]

Now that the savegame rewrite is finally out of the way, the question is, how to go on.

My next thing on the list is to add normal handling to the existing code - of course with voxels I have no good idea what to do because any attempt at realistic lighting calculations fail with voxels. Does anyone here have a good suggestion? As it stands I might just disable normal based lighting altogether on voxels or use a normal that's the sum of all touching faces on each vertex.
Once that is in I need to implement proper application of dynamic lights for any sprites that use a fixed world position, that'd be wall and flat sprites plus models.

So the big question now is, how all this may affect dpJudas's work. For example, would SSAO be ready for merging? And does this in anyway have an impact from the normal storage? Since you already said it requires face normals, I think it should be able to use those for elements where these are being used, it'd just require a check in the shader to do it differently for models.

And once the normals are in, I would like to see them used for applying dynamic lights, of course. Since that was also an experimental build, I guess it will require some touch-up to be ready for use.

[Rachael]

For voxels, it is possible to merge pixel art into vector shapes. It's never perfect, but when applying lighting to voxels it will definitely be necessary. The upside to that is when you go back to using vector models, the processing on them goes down significantly.

This could be done in two ways: Have an algorithm do it, or allow the modder to supply a model, themselves. The latter would be preferable, the former would be a fallback. I will have to look up some algorithms but I know there's some that are definitely available. Even if not, it might be possible to adapt a 2D raster->vector algorithm into a 3D one. The key is, obviously, if the 2D one uses bézier curves, they will have to be transformed into lines, with a possible addition of vertices.

[dpJudas]

of course with voxels I have no good idea what to do because any attempt at realistic lighting calculations fail with voxels. Does anyone here have a good suggestion? As it stands I might just disable normal based lighting altogether on voxels or use a normal that's the sum of all touching faces on each vertex.

Wondering a bit about this I tried creating two boxes in 3ds max. The left box would be a "voxel" with the normal sum, and the right with the face normal:


Not sure which would work best in practice. The left creates more distinctive highlights and makes the shape a bit less clear, but that could be both be a pro or con. Personally I'd probably pick the variant that is easiest to code (averaged normal if the voxels already share vertices today, or otherwise face based if they don't) and see how it looks in practice. I think we have a little too many unknowns to make an informed decision at this stage, unless someone knows a voxel viewer that can show the visual difference.

So the big question now is, how all this may affect dpJudas's work. For example, would SSAO be ready for merging? And does this in anyway have an impact from the normal storage? Since you already said it requires face normals, I think it should be able to use those for elements where these are being used, it'd just require a check in the shader to do it differently for models.

The code I have in the SSAO branch is stable as it is right now. There's only really three things missing in it that I'd like to add: ssao overall quality setting (low, medium, high), a setting for how many portals it applies ssao to if they are present, and finally some way to flag geometry not to be included in ssao. Except for the flagging part, I could create a PR this weekend that includes all of it.

And once the normals are in, I would like to see them used for applying dynamic lights, of course. Since that was also an experimental build, I guess it will require some touch-up to be ready for use.

Note that the dynamic light shader part that wants smoothed normals is completely independent to the SSAO stuff. I can include or exclude it in a SSAO PR, or create a separate PR with just that part for you. The only thing needed for this part to be hooked up with model normals is a 'in vec3 Normal' instead of the face normal it uses now (two lines of code change).

[Graf Zahl]

For now, I think making an SSAO PR with the current feature set would be best. I'll have to do the normal stuff anyway before it can be used.

[ibm5155]

what about using Marching Cubes on the fly for converting voxels models in a polygonal 3D model?
It could generate quite good 3D models like:

(a) segmented volume of interest—voxel mesh, (b) surface mesh generated from marching cubes algorithm (no interpolation), (c) rendered view of surface mesh generated from marching cubes algorithm (including partial volume-based interpolation).

EDIT: I also once tried to convert each voxel pixel into a polygonal 3D model, but it ended up it was so heavy that I couldn't handle a 256x256x3 voxel D: idk if with the gzdoom engine maybe the result could be faster on gzdoom since VTK was a pain in the ass to render things that werent ready inside his code box