Releases

[mjr4077au]

Very exciting news indeed! Of course this happens when I'm away from home for the week on work assignment . Will be very excited to test this out when I can

[sinisterseed]

Yes indeed it is , good to hear that things have also stabilized a bit more now. The reason why I've slowed down recently was because the heavy lifting wasn't done yet, so there was no point in messing around with things before they reached a more stable state.

[Graf Zahl]

A small progress report.

Today I spent some time to make the ZScript compiler work, it was still missing a few pieces. I'm going to use this to transition all those static screens to a common framework. There's literally dozens of them, each with their own waiting loop and consolidating this to a single utility class would help clean up stuff a lot. But being able to do these screens as scripts would be much better than doing them natively so it was an important step forward.
On the other hand I put the scripted menu rewrite on indefinite hold - there's little to be gained there but a lot of work required, so this might be done at a later time. Right now it's not something worth undertaking, though, as it cannot be consolidated with GZDoom.
Last but not least, I tried the Vulkan and Softpoly backends. Vulkan is quite a bit broken but Softpoly at least renders the 2D content but for some reason the global vertex buffer is uninitialized so rendering the scene will crash it.

[sinisterseed]

Small? Oh no, how dare you, this sounds quite important I daresay , now that the static screens will be taken care of and their handling will be reworked.

The fact that Vulkan and Softpoly can "run" (kinda), albeit quite broken at the moment, is wholesome as well.

[mjr4077au]

Agreed that it sounds like a great milestone for the project . I saw the reversion of moving GZDooms menu code back to the game-side code. What are the limitations for sharing the code between the projects?

[Graf Zahl]

The menus are simply too different. Although the code shares a lot, Raze's menus work *just* differently enough to make a shared implementation problematic. That doesn't mean it can't be scriptified but there's really no immediate benefit - the menus are working fine, after all, and we're a long way from considering mods that might want to rewrite the menus.

[mjr4077au]

Yeah no worries. I was more just thinking of unified menus in terms of unified backend options such as hardware rendering post-processing, texture upscaling etc similar to what GZDoom has. I know none of that stuff is prime-time yet but it'd be nice to have all the bells and whistles exposed

Given that the SoftPoly and Vulkan backends are now enabled in the GUI, is a goal for 0.7.0 to have those backends mostly or fully working?

[Graf Zahl]

The primary goal right now is to get the palette emulation back. And of course adding the missing menu options. Since this is mainly MENUDEF it can be done without a new implementation.

[mjr4077au]

Ahh yep, that makes sense regarding the MENUDEF stuff. Hopefully the palette emulation stuff isn't too hard to stitch back in

[sinisterseed]

But speaking of which, how did the palette emulation get lost in the process anyway? I never understood how exactly that happened.

[Graf Zahl]

The palette emulation never was part of the backend, it was only in the old render code that just got removed. As a first step I concentrated on getting the true color renderer to work, now that this is complete the palette emulation will be done.

[sinisterseed]

The palette emulation never was part of the backend, it was only in the old render code that just got removed. As a first step I concentrated on getting the true color renderer to work, now that this is complete the palette emulation will be done.

Alright then, makes sense that way.

By the way, what other bad parts got removed so far? I'm saying this because I remembered the good ol' flickering wallsprites issue recently, and jumped on E1M1 of Blood since that's a good place to spot this, and to my surprise, I've not had luck reproducing the flicker anymore - or, not as of yet in the worst case. Has their handling changed?

[Graf Zahl]

No, there wasn't any change, for me it still looks just as messed up as before - this is an unfortunate problem of how Build manages wall sprites. Once I can leave Polymost behind they should be rendered like Decals in GZDoom.

[Tea Monster]

Glad to see this progressing.

[Graf Zahl]

0.7 is out:
https://github.com/coelckers/Raze/relea ... .7.0_alpha

Most of the changes are laid out here: viewtopic.php?f=347&t=69875

Work over the last two weeks has been mostly to finish the new input systen, fix bugs and to finalize the new input system and World Tour support - as of yesterday it supports the developer commentary feature as well.
Next up are adding the final features to move Raze out of Alpha stage into Beta - this mainly means fixing the sky renderer and migrating the model system, which is currently non-functional, to GZDoom's, plus investigating the remaining sound issues with Exhumed.

Known issues with this version:

* palette emulation currently only works in the 3D view but not on the weapon sprite.
* hires replacements only work in the game view but not the UI.
* there's still sound issues with Exhumed - some sounds are not playing.
* potential ambient sound positioning issues in Shadow Warrior - there's two known instances where a sound seems to play in the wrong place, but possibly more.