Raze officially revealed!

[Graf Zahl]

Please post exact error message(s).

Cmake says it could not find LIBVPX, and the libraries folder in the source has no libvpx library, unlike bzip2, jpeg etc. Do I need to provide it, or just not?

No. LibVPX is special, this one's quite a hassle to get working on Windows thanks to a very Linux-centric build setup so the repo contains a compiled version of the library to link to - this library was already provided by EDuke32 because it had the same problems with handling this on Windows.

[mjr4077au]

Please post exact error message(s).

Cmake says it could not find LIBVPX, and the libraries folder in the source has no libvpx library, unlike bzip2, jpeg etc. Do I need to provide it, or just not?

No. LibVPX is special, this one's quite a hassle to get working on Windows thanks to a very Linux-centric build setup so the repo contains a compiled version of the library to link to - this library was already provided by EDuke32 because it had the same problems with handling this on Windows.

No problems, thanks! (tried this as it compiles in Visual Studio, but still had dramas).

Got it all working now without specifying a path. Can't play it properly on the work laptop with no mouse (left it at work) but it feels amazing. Can't wait to do proper testing this weekend

[Redneckerz]

So what benefits does it have compared to other ports?

How about you look up the preliminary * wiki page for that.
*Preliminary, as i just heard from Rachael on Discord that this will move to its seperate Wiki. For the time being though, this should be sufficient.
** In writing this, i stuck to the facts as close as possible, using documentation from the Github and the commentary put forward by Graf and Rachael here. They obviously know what's best, but as a skeletal article, it serves its purpose, or so i hope.

[Graf Zahl]

It depends on what you want. If you want Duke's Polymer renderer, stick with EDuke32 (at least for now), if you want the software renderer, ditto. This will most likely not come back because with the software renderer in the way there's little chance of really cleaning up and optimizing the hardware renderer at all. It's currently only there for rendering camera textures. Build never advanced to the point where these could be drawn with the hardware renderer and this is currently the biggest blocker I am facing and definitely the next big thing to do (i.e. reworking the renderer output to draw camera textures with OpenGL.)

[mjr4077au]

It depends on what you want. If you want Duke's Polymer renderer, stick with EDuke32 (at least for now), if you want the software renderer, ditto. This will most likely not come back because with the software renderer in the way there's little chance of really cleaning up and optimizing the hardware renderer at all. It's currently only there for rendering camera textures. Build never advanced to the point where these could be drawn with the hardware renderer and this is currently the biggest blocker I am facing and definitely the next big thing to do (i.e. reworking the renderer output to draw camera textures with OpenGL.)

I'd only argue for the software renderer for posterity, it'd help make the port the only port you need and not just the port for x and y, but not z, etc. I guess if it has to go to advance forward though, then so be it.

[Graf Zahl]

I understand. But you also have to understand my reasons. To add certain things to the map it will be inevitable to restructure some low level data.
So far all Build ports have gone out of their way to do this without altering the core data structures and adding more and more stuff in parallel data structures to them, because the software renderer has some very specific needs (less so in Raze because I tossed out all assembly code, but it's still there.)

And much has been said about Ken Silverman's coding style, so this would inevitably bog me down to the point where I'd lose motivation to go on. I already tried to compartmentalize some of the global variable state, but it never worked out. The interdependencies of this code and its data are so complex that each time something broke. It'd forever be a piece of heavy baggage. Some of the data dependencies reach deep into the game code and impose the structure of how the game side render setup code works. Nothing of this is in any way compatible with how a hardware renderer should properly set this up to be efficient. Unlike Doom, where the game just calls a "Render my view" function inside the backend which then performs the entire task, in Build the high level scene renderer must set up all mirrors, all camera textures, all ROR effects and sometimes even more itself. This gets particularly nasty with mods which render multiple scenes on top of each other - Ion Fury does this for its skyboxes, for example. All this stuff needs to be moved down into the backend, but if I do that, the software renderer will no longer work anyway. So I'd rather not spend time with it at all.

[mjr4077au]

Sounds like it needs to he shit-canned then

[Redneckerz]

Coverage post at Doomworld. Will be moved to the right section as i was stupid.

I am awarding DW one minus point for its bizarre (to me) rendition of envoking Spoiler as BBCode, hiding everything underneath it instead of the designated section.

And with that im done doing PR for Raze for today Ill put up a post at R667 later.

[Fox666]

I understand. But you also have to understand my reasons. To add certain things to the map it will be inevitable to restructure some low level data.
So far all Build ports have gone out of their way to do this without altering the core data structures and adding more and more stuff in parallel data structures to them, because the software renderer has some very specific needs (less so in Raze because I tossed out all assembly code, but it's still there.)

And much has been said about Ken Silverman's coding style, so this would inevitably bog me down to the point where I'd lose motivation to go on. I already tried to compartmentalize some of the global variable state, but it never worked out. The interdependencies of this code and its data are so complex that each time something broke. It'd forever be a piece of heavy baggage. Some of the data dependencies reach deep into the game code and impose the structure of how the game side render setup code works. Nothing of this is in any way compatible with how a hardware renderer should properly set this up to be efficient. Unlike Doom, where the game just calls a "Render my view" function inside the backend which then performs the entire task, in Build the high level scene renderer must set up all mirrors, all camera textures, all ROR effects and sometimes even more itself. This gets particularly nasty with mods which render multiple scenes on top of each other - Ion Fury does this for its skyboxes, for example. All this stuff needs to be moved down into the backend, but if I do that, the software renderer will no longer work anyway. So I'd rather not spend time with it at all.

Welcome to Hell

Good luck with Ion Fury, I'm looking forward to it

[Phredreeke]

Perhaps surprisingly, I agree with the decision to remove the software renderer. It's still available upstream after all. Though someone on the Duke4 forums or Discord suggested adding a mode that enables the Y-shearing CVAR and disables palette interpolation

[Graf Zahl]

I would, unfortunately I broke the y-shearing mode early in development and when I noticed it didn't work anymore, the sky was all screwed up.
Palette interpolation can be disabled, so that's not a problem. But this is a nice-to-have feature, let's take care of the bigger things first. And Polymost isn't supposed to last anyway - for better effects I need a real polygon renderer.

[theleo_ua]

What about language support (like in GZDoom) - is it planned?

[Graf Zahl]

The basics are all there, many of the menu texts that were directly taken from GZDoom are already translated.
The biggest blocker here is not the text, but how the fonts are organized. They are not in such a nice and handy format as ZDoom's so a lot more groundwork is needed to allow printing text with extended fonts.

[Dzierzan]

More importantly, the way Duke Nukem defines its actors means that something like DECORATE is not really doable, there is no concept of action functions like Doom has, it is all controlled by CON events. Blood depends a lot on binary scripts, but there is one guy who added a lot of customizability to NBlood, but what it lacks is documentation.

As a matter of fact, it is documented. http://cruo.bloodgame.ru/xxsystem/ (English might be a bit rough here). He's been basically expanding NBlood customizability to be able to add own ideas for his maps. His latest map which uses all these custom stuff is named No Hope in Sight (https://www.youtube.com/watch?v=5KsGxeEUAPw) and is about to be released soon. Now I wonder, if you keept up with NBlood changes, this map should be compatible with Raze too.

[Graf Zahl]

Yes, I've kept up with NBlood. Now that will be interesting.