[Source port] Introducing Raze: ''That's one Duked up Space Marine!''

[Redneckerz]

5 hours ago, Cacodemon345 said:

What's the legal limbo?

Im thinking of Witchaven and not Shadow Warrior. Woops!

Edited February 5, 2020 by Redneckerz
Witchaven, not Blood. I need coffee.

[Graf Zahl]

4 hours ago, Woolie Wool said:

So is software rendering going to be included in any way? I understand the software rendering code is...eccentric, but even a Doom-like software renderer would be nice if it could look more or less like traditional Build to the player.

 

Sorry to disappoint you. I understand why some may find it desirable to keep but this isn't Doom where the renderer is a logically separated module the game merely calls.

 

The thing here is simply that I cannot restructure the hardware renderer to properly deal with ROR portals without shooting the software renderer in the foot.

This isn't like Doom. In Build such a map consists of multiple scenes drawn on top of each other by the game code, i.e. it's the game that invokes the renderer multiple times - for portals, mirrors and camera textures. And this is a setup that seriously stands in the way of adding postprocessing options to the engine or streamlining the render setup. But unlike GZDoom where these features are late additions, they are part of the original games here so they cannot be given second class treatment which only works in one renderer but not the other.

What this boils down to that here, far more than it ever was in Doom, the software renderer's design dictates how things need to be done, and this reaches deep into the game code. And due to the "esoteric" nature of its code, as you named it, it is virtually impossible to change. Let's never forget that both Polymost and Polymer are the way they are because they have to coexist with the software renderer - they never could take any optimization route that would have necessitated a fundamental restructuring of how software rendering works in Build.

The bottom line is that my time is not infinite. I have to pick the parts I want to work on to get somewhere. And the software renderer is by far the biggest roadblock for progress. If I had a second developer on my hand who solely could look after this it might be doable - but as things stand, everybody having a look at that code went away in horror shortly thereafter. The good thing is that the hardware renderer has a pretty good palette emulation feature (courtesy of Nuke.YKT) so you can get a lot closer to a pure software look without using a software renderer as in GZDoom.

Also, you cannot graft Doom's software renderer on Build, it lacks certain critical engine features that are essential for Build support.

 

2 hours ago, Spectre01 said:

ooks like the "palette emulation" option adds a more software look, similar to the palette tonemap in GZDoom. Unfortunately, it also has the side effect of disabling AF, which is no bueno.

 

That's an inevitable drawback of using paletted textures. Unlike GZDoom's tonemap this gets right down to the original shade tables (i.e. what Doom calls colormap) You cannot use hardware texture filtering options anymore - the filter unit would interpolate between palette indices and the result then looks very wrong.

[Jawohlf]

Well, just tried dragging the Shadow Warrior .GRP and was extremely please to see it load. Gonna try to go through at least part of the first level later. But I'm already salivating at the modding possibilities if this gets to a stable enought point. Thank you so much, @Graf Zahl and the whole Raze Team!

[seed]

17 hours ago, High On Berserk said:

Like Q1 zombies?

 

No like Schrodinger's cat :p.

[NY00123]

Can probably just wish good luck with the act of experimenting with the codebases of the games and related libraries.

I maybe weren't contributing to Build Engine ports as much as others (like TerminX or Hendricks266) had been, and also didn't get to release that much user-made contents.
But, I've seen enough of the code, especially Duke3D and the differing libraries, that I can say that it is often very far from easy to get something decent and new done, especially if you want it to be done well. The differing game codes being quite distinct (even if eventually derived from the same Ken-Build test game) obviously add to the above.

[Murdoch]

Nice. I recently decided to play the extra maps supplied with Shadow Warrior Classic Redux. The vsync was, to put it diplomatically, a bit terrible. 

[Graf Zahl]

11 hours ago, NY00123 said:

But, I've seen enough of the code, especially Duke3D and the differing libraries, that I can say that it is often very far from easy to get something decent and new done, especially if you want it to be done well.

 

Yeah, that's a very good description. I think it's best exemplified by RedNukem. The amount of game dependent execution in the engine is staggering - but with the existing code structure and its limitations there's no way around it.

 

9 hours ago, Murdoch said:

Nice. I recently decided to play the extra maps supplied with Shadow Warrior Classic Redux. The vsync was, to put it diplomatically, a bit terrible. 

 

Yes, I know, it's the same for all Build games because the root cause for these vsync problems lies in ages-old code from JFDuke. The entire texture management in the engine just doesn't work well with modern hardware anymore. Once I got this transitioned to the modern way of doing things all the VSync problems suddenly went away and never came back - regardless of how many textures I created, even with SDL.

[Murdoch]

1 hour ago, Graf Zahl said:

Yes, I know, it's the same for all Build games because the root cause for these vsync problems lies in ages-old code from JFDuke. The entire texture management in the engine just doesn't work well with modern hardware anymore. Once I got this transitioned to the modern way of doing things all the VSync problems suddenly went away and never came back - regardless of how many textures I created, even with SDL.

 

Ah so JFDuke is the source for those "new" ports? That would explain a lot.

[ketmar]

1 minute ago, Murdoch said:

Ah so JFDuke is the source for those "new" ports? That would explain a lot.

yeah. i believe that pretty much everything was based on JFDuke, directly or indirectly.

[seed]

2 hours ago, ketmar said:

yeah. i believe that pretty much everything was based on JFDuke, directly or indirectly.

 

This, both eduke and Megaton borrowed from it.

 

I think the only exception to this was World Tour, where GB wanted to go back to the drawing board, but failed in the process.

[Master O]

6 hours ago, Graf Zahl said:

 

Yeah, that's a very good description. I think it's best exemplified by RedNukem. The amount of game dependent execution in the engine is staggering - but with the existing code structure and its limitations there's no way around it.

 

 

Yes, I know, it's the same for all Build games because the root cause for these vsync problems lies in ages-old code from JFDuke. The entire texture management in the engine just doesn't work well with modern hardware anymore. Once I got this transitioned to the modern way of doing things all the VSync problems suddenly went away and never came back - regardless of how many textures I created, even with SDL.

 

It sounds like you're doing a massive overhaul of antiquated code.

[seed]

Cleaning up, fixing stuff, modernizing, essentially.

[ketmar]

45 minutes ago, Master O said:

overhaul

if "throw away alot of old shit and replace it with something sane" can be called "overhaul"... then yes. ;-)

[Redneckerz]

6 hours ago, Murdoch said:

 

Ah so JFDuke is the source for those "new" ports? That would explain a lot.

JFDuke is essentially the DOSDoom of Build ports.*

 

*Except compared to DOSDoom, you are required to use all its lesser known features aswell for it to work.

[Master O]

2 hours ago, ketmar said:

if "throw away alot of old shit and replace it with something sane" can be called "overhaul"... then yes. ;-)

 

https://www.merriam-webster.com/dictionary/overhaul

[xvertigox]

How does Blood support work? I can't see a GRP file in either the One Whole Unit or Fresh Supply directories.

Edit: I've tried moving the biggest file in the dir (game.gog) to the Raze dir but it doesn't pick it up when launching.

Edited February 7, 2020 by xvertigox

[Cacodemon345]

Blood uses a different format.

[seed]

2 hours ago, xvertigox said:

How does Blood support work? I can't see a GRP file in either the One Whole Unit or Fresh Supply directories.

Edit: I've tried moving the biggest file in the dir (game.gog) to the Raze dir but it doesn't pick it up when launching.

 

Point the Path= to its directory, ex: D:/Games/Steam/Steamapps/common/One Unit Whole Blood/

 

Blood does not use .GRPs.

[Graf Zahl]

The file it looks for in Blood is Blood.rff. RFF is just an alternative container format the Blood team invented before the core engine got GRP support and from what I have read, they stuck with it because Ken's initial GRP code was not the most stable thing around.

 

Also, although Blood does not have any GRPs, Raze can easily load Blood mods packaged in GRPs (or Zips), though. NBlood should also but I never tested that part.

[Devalaous]

Will it have support for Duke's various expansions? I have Megaton Edition that includes them, but thats a discontinued game that I probably wont have forever, would like to futureproof those things if possible.

 

[Gez]

The expansions from Megaton Edition are supported. It's just World Tour that isn't.

[Vermil]

I can't offer any coding/technical help, but I can say I am very happy with this development :)

[seed]

And to expand on WT, the base levels are supported just like in EDuke32, but because the source for WT was never released, adding support for its extra Episode 5 is not possible (and reverse-engineering it is out of the question too).

 

Unless someone else manages to add support for it and the new content it brings somehow, I'm afraid it's forever going to stay only partially supported - the team behind EDuke32 expressed disinterest in adding support for it as well, so mainline won't receive that either anytime soon, if at all.

 

Because the expansions from Megaton are both very old and its source was released, their support is mighty fine, it's unchanged otherwise.

[Chris Moyer]

Following. I'm very interested in seeing where this goes and how things Develop.

 

@Redneckerz or @Graf Zahl, can you elaborate on: 

 

"Multiplayer and networking however have a different implementation per game, and thus this was left as-is"? Will net games be supported and user friendly? Always wanted to get a Duke coop game going without running into syncing issues all the time.

[seed]

Not at this time, no, their implementation varies between games and it isn't in a good state in the first place.

[Gez]

25 minutes ago, Chris Moyer said:

Will net games be supported and user friendly?

Not planned, sorry. Unless a netcode developer pops up and asks to join the team, it's simply not going to happen.

[Chris Moyer]

37 minutes ago, Gez said:

Not planned, sorry. Unless a netcode developer pops up and asks to join the team, it's simply not going to happen.

Damn, ok. Well, I'm still excited about this either way. I'll take what I can.

[Spectre01]

5 hours ago, seed said:

And to expand on WT, the base levels are supported just like in EDuke32, but because the source for WT was never released, adding support for its extra Episode 5 is not possible (and reverse-engineering it is out of the question too).

I read somewhere that E5 of WT was playable in eduke32, aside from the new weapon and enemies. Also, what makes the weapon/enemies difficult to add in the form of a mod? I doubt their behaviour and AI are so advanced that it's impossible to replicate while having all the art/sound assets.

[Graf Zahl]

You first got to decompile the code that got added. And Duke isn't like Doom where all actor data is well structured and relatively painless to expand. A partial mod for WT exists which takes care of the scripted elements. It's the non-scripted parts that stand in the way.

 

[Devalaous]

12 hours ago, Gez said:

The expansions from Megaton Edition are supported. It's just World Tour that isn't.

 

Neat. So I back up the GRP files from Megaton or something?