No precompiled Windows binaries for v5.0.x?

[SenhorFlibble]

Apologies for possibly missing the point, but where can one obtain the 5.0.x Windows binaries save for compiling them oneself?

[Andrettin]

I've added a release binary to the 5.0.1 release now: https://github.com/Andrettin/Wyrmsun/releases/tag/v5.0.1

You will also need to download the dependencies and extract them on your game's directory, to make it run on Windows: https://github.com/Andrettin/Wyrmsun/releases/tag/2021-08-30

Let me know if this works for you :)

[SenhorFlibble]

Thanks a lot!

I was able to start the game, the main menu works fine, albeit with relatively small but noticeable lags between sub-menus (like accessing single player options from the main menu). But the game then crashed when loading a custom map. Both stdout and stderr files are empty but there's also a crash dump file, attached here (I had to append .txt at the end to upload it). crash.dmp.txt

On a second try I managed to run everything fine though. I tried the First Dwarves scenario and a custom map as the Dwarves, everything worked (I used Map Default). I was able to reproduce the crash though, it seems to be related to the custom map I selected on my first try. It was called Svanisdaug from the Nidavellir set. The game crashed while loading again when I tried it.

On an different note, I have not found a way to change the screen resolution. The game defaults to desktop resolution (1600x900 in my case), with everything rather small, while using the 2xBRZ results in the interface taking up most of the screen for me. I remember previous versions running in a window at 1066x768 or something like that by default, and definitely allowing to select different resolutions from the menu.

On yet another note, nice new menu font! I like it. The whole game got an even more polished feel with this release.

[Andrettin]

You're welcome! :)

About the Svarinshaug map, you are right, that map was no longer compatible with the current version of the game (it relied on some legacy stuff). I've removed it now from the custom game map selection. Thanks for letting me know that that map was causing a crash!

Regarding the main menu, that is unfortunately unavoidable, since the UI code (in QML) has to be loaded when a new menu is opened. It would be possible to preload that code, but then we would just move the loading time upfront, and require potentially unused UI elements to be held in memory.

As for the resolution, I made it so only borderless fullscreen is supported with this new release. The main reason why windowed mode was supported was to get around technical fullscreen issues with SDL1, and because when using SDL fullscreen the game couldn't be seamlessly alt-tabbed. I'm not sure whether reintroducing windowed mode and resolution selection would bring much, as it would just result in the player seeing less of the map; and it would require a bit more code to be maintained. If you have a different take on this issue I would be glad to hear your opinion though, as maybe I didn't consider all possible aspects of this issue.

I'm happy you liked the new font! I agree that the menus feel more polished now :) Being able to do that was one of the main motivations in reworking the UI code to use the Qt framework / QML.

[SenhorFlibble]

I'm not sure whether reintroducing windowed mode and resolution selection would bring much, as it would just result in the player seeing less of the map; and it would require a bit more code to be maintained. If you have a different take on this issue I would be glad to hear your opinion though, as maybe I didn't consider all possible aspects of this issue.

You see, small sprites and small text can be a real strain on the eyes. I already struggle to discern the small details at 1600x900 fullscreen mode, and at higher resolutions it would likely be even worse, although those should be better suited for the 2x scaled mode. But that one is not really the solution either, as the screen size would still vary depending on the host system's desktop resolution.

It's the common problem of many 2D RTS games that if there is no scaling available, the player's field of view will vary depending on the resolution (which could theoretically be considered unfair in multiplayer matches). While true 3D games can effortlessly scale output to whatever resolution is selected while maintaining the same field of view for all players.

Recent SVN builds of DOSBox include built-in GLSL shaders, one of which is called sharp and can produce decent uniform scaling of pixels without much blur. Here's a side-by-side comparison that I made of the original Warcraft II demo to show the difference between normal OpenGL rendering without shaders, and the sharp shader in DOSBox running in fullscreen mode at 1600x900 resolution.

Theoretically, if implemented in Wyrmsun, this method could allow you to render the game screen at fixed dimensions of your choice regardless of the end-users' desktop resolution and without excessive blurriness inherent to the default OpenGL scaling method.

But I also have to note that I used to play older Wyrmsun builds at 800x600 on the same PC, with the hardware doing the scaling, quite comfortably and without excessive blur too.

[Andrettin]

Thanks for the clarifications! I wasn't sure whether your concerns had to do with the removal of the windowed mode, or with fullscreen scaling. It is clear now that it is the latter.

Regarding the scaling, that could be improved upon by adding more scaling options, e.g. a 150% scaling option alongside the current 200% one. That would be helpful for resolutions such as 1600x900, which are too big for 1x, but too small for 2x. There would be greater quality loss than with the 200% scaling, but it would at least be better than for arbitrary scaling factors, e.g. 167%. This is specially important for Wyrmsun since its graphics are mostly pixel art. IMO it is also more intuitive to have an explicit scaling option, instead of scaling occurring as an indirect effect of resolution choice.

On the multiplayer fairness angle, that could also be achieved by limiting the map's field of view in some other way. For instance, simply not drawing (in a multiplayer match) the tiles beyond the field of view of the player which has the smallest field of view.

About the shader you mentioned (thanks for letting me know of it!), the results are better, and it would be cool to use it. But for that I would have to add proper shader support for the game, which is something more complicated to do (it would require substantial time and effort).

[SenhorFlibble]

About the shader you mentioned (thanks for letting me know of it!), the results are better, and it would be cool to use it. But for that I would have to add proper shader support for the game, which is something more complicated to do (it would require substantial time and effort).

Doesn't Stratagus/Wargus already have GLSL support built in? There are glsl files in the shaders folder inside Wargus installation directory, although I'm not certain if they work or not. IIRC they can be activated via command prompt -- I remember stumbling upon a file with all Stratagus command line parameters, which I think included an option to run with shaders.

[Andrettin]

Doesn't Stratagus/Wargus already have GLSL support built in? There are glsl files in the shaders folder inside Wargus installation directory, although I'm not certain if they work or not. IIRC they can be activated via command prompt -- I remember stumbling upon a file with all Stratagus command line parameters, which I think included an option to run with shaders.

Shader support was added to Stratagus sometime after Wyrmgus had been forked from it, and by now the two codebases are too different as far as rendering goes for it to be simple to integrate that into Wyrmgus.

At some point, Stratagus upgraded from SDL1 and SDL2, and AFAIK the Stratagus shader code requires SDL2. While Wyrmgus now relies on the Qt framework for rendering. There are classes in Qt which help handling shaders, though; it would just require some time/effort investment to make it work for Wyrmsun/Wyrmgus. And that is something I want to do eventually, as shaders open up a lot of possibilities, but I'm not sure when I will be able to get to it.

[Andrettin]

I've upgraded Wyrmsun's binaries to use Qt 5.15 on Windows, so I've updated the dependencies package accordingly:

https://github.com/Andrettin/Wyrmsun/releases/tag/2021.09.19

[SenhorFlibble]

Regarding the scaling, that could be improved upon by adding more scaling options, e.g. a 150% scaling option alongside the current 200% one.

I just checked the 5.2.2 release and the 1.5x scaling option, it works just perfect, thank you very much! Way better than sticking to lower resolutions. Cheers!

[Andrettin]

I just checked the 5.2.2 release and the 1.5x scaling option, it works just perfect, thank you very much! Way better than sticking to lower resolutions. Cheers!

I'm glad you like the new feature! :)

[SenhorFlibble]

I forgot to ask, which scaling algorithm is being used? The 1.5x sixe looks very good and smooth, and very accurate to the original art. Is this just 2xBRZ downsampled to 1.5x the original size, or some other scaler?

I'm interested in the possibility of using that in other projects like source ports of Duke Nukem 3D etc.

[Andrettin]

I forgot to ask, which scaling algorithm is being used? The 1.5x sixe looks very good and smooth, and very accurate to the original art. Is this just 2xBRZ downsampled to 1.5x the original size, or some other scaler?

Thanks, I'm happy you enjoyed the results!

It's the xBRZ 3x scale factor downsampled to 1.5x. Usually halving dimensions by (powers of) 2 yields better results, and IMO it indeed worked better than using 2x downsampled to 1.5x in my tests.

For the downsampling, I used the QImage::scaled function, with the Qt::SmoothTransformation mode: https://doc.qt.io/qt-5/qimage.html#scaled