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

[Gez]

You'll find the same file in Raze. Don't forget the aim is to use the same code as much as possible.

[MrFlibble]

Any chance support would be added for the shareware version of Blood? The main difference is that it uses a single ART file called SHARE000.ART to store all the graphics. I don't suppose there should be gameplay differences compared to the registered E1 except that the registered version weapons must not be available even with cheat codes, and the splash screen upon exit. (I am aware that the original DOS shareware version was not synched with the latest retail patches, but for the purposes of the port this could be ignored I guess?)

 

You can get the preinstalled Blood shareware (latest version 1.11) here.

[seed]

1 minute ago, MrFlibble said:

Any chance support would be added for the shareware version of Blood? The main difference is that it uses a single ART file called SHARE000.ART to store all the graphics. I don't suppose there should be gameplay differences compared to the registered E1 except that the registered version weapons must not be available even with cheat codes, and the splash screen upon exit. (I am aware that the original DOS shareware version was not synched with the latest retail patches, but for the purposes of the port this could be ignored I guess?)

 

You can get the preinstalled Blood shareware (latest version 1.11) here.

 

I think that, at the moment, this depends more on what happens in upstream (NBlood) rather than what ends up happening here.

 

Similar to how WT support was added, it was first added in upstream and then backported.

[MrFlibble]

Yesterday I played some Shadow Warrior and noticed certain differences compared to VoidSW, which I had the impression were fixed/introduced in Raze, rather than imported from a yet unreleased revision of VoidSW, but I may be wrong.

[seed]

47 minutes ago, MrFlibble said:

Yesterday I played some Shadow Warrior and noticed certain differences compared to VoidSW, which I had the impression were fixed/introduced in Raze, rather than imported from a yet unreleased revision of VoidSW, but I may be wrong.

 

What differences did you spot?

 

Currently Raze is indeed a bit ahead of VoidSW, that is true.

[MrFlibble]

The ATM machine secret in the first level works, and the remote screen for the toy car area is rendered at high resolution, not pixellated. Also in Raze, coolie corpses stay as they are if they do not spawn a ghost, whereas in VoidSW (and in vanilla SW too) the upper half still disappears.

 

But these are differences compared to an x64 build from 22 May, while I haven't yet tested the current from 28 May. I guess it's a good idea to switch to the 32-bit version.

 

UPD: I just confirmed that apart from the ATM machine secret bug which has been fixed in the 28 May build, the other differences remain.

Edited May 30, 2020 by MrFlibble

[Graf Zahl]

Currently it's not fully merged with VoidSW so a few things are not in yet. Also, when I started I used SWP to pick some code and in a few instances this may cause slight differences to vanilla because that engine did a few enhancements. The Coolie corpses may be a result of that, it's surely the kind of thing SWP would have added to the game.

 

 

 

 

[Master O]

6 hours ago, Graf Zahl said:

Currently it's not fully merged with VoidSW so a few things are not in yet. Also, when I started I used SWP to pick some code and in a few instances this may cause slight differences to vanilla because that engine did a few enhancements. The Coolie corpses may be a result of that, it's surely the kind of thing SWP would have added to the game.

 

Weren't you also working on Raze's graphics backend or was it the renderer?

[seed]

2 hours ago, Master O said:

 

Weren't you also working on Raze's graphics backend or was it the renderer?

 

Backend unification, still WIP.

 

A new renderer is also planned, but we're not yet there.

[Graf Zahl]

The backend stuff is extremely tedious, the existing renderer is so volatile that it constantly breaks when changing things - that brought progress to a near standstill. Obviously this just amply demonstrates that in the long run this code needs to go away.

[MrFlibble]

It seems that Raze does not yet recognise the Wanton Destruction GRP.

 

Yesterday I tested Blood shareware with the latest version of nBlood. I got to the main menu after renaming SHARE000.ART to TILES000.ART but when I tried to start Episode 1 it crashed and reported "Map file is wrong version" in the log.

 

Raze doesn't seem to recognize Blood shareware data at all at this point, even if SHARE000.ART is renamed to TILES000.ART.

[seed]

1 hour ago, MrFlibble said:

It seems that Raze does not yet recognise the Wanton Destruction GRP.

 

It does, what GRP do you have? The one available on Steam and found on the internet works fine.

[MrFlibble]

The original one from here. I haven't gotten around to test the GOG version yet (nor was I aware that there are differences?).

 

Maybe I had to put both the registered SW.GRP and WT.GRP in the Raze folder? VoidSW detects a separate WT.GRP if it is renamed to SW.GRP, crashes otherwise. Raze tells me no game data is found either way.

[seed]

11 minutes ago, MrFlibble said:

Maybe I had to put both the registered SW.GRP and WT.GRP in the Raze folder? VoidSW detects a separate WT.GRP if it is renamed to SW.GRP, crashes otherwise. Raze tells me no game data is found either way.

 

Pretty much.

 

Raze looks for them in its directory, Steam, or GOG install (via registry keys). You can also use -grp wt.grp as a command line argument to load the addons, it works similar to -iwad in Doom.

[Jawohlf]

Would it be feasible to include non-Build based engines on Raze? Or is Build an intrinsic, unavoidable part of it? 

[Redneckerz]

12 hours ago, Jawohlf said:

Would it be feasible to include non-Build based engines on Raze? Or is Build an intrinsic, unavoidable part of it? 

Raze utilizes Build rendering with GZDoom mechanics and its supposed to run Build games from the get go.

 

It is not an interpreter like ScummVM is where you can simply add new engines to a universal framework.

 

Whilst such a thing would be neat, it would also be impractical. Supporting things like Doom, Build, Jedi tech into one framework seems like a nightmare to maintain.

[taufan99]

6 minutes ago, Redneckerz said:

Raze utilizes Build rendering with GZDoom mechanics and its supposed to run Build games from the get go.

 

It is not an interpreter like ScummVM is where you can simply add new engines to a universal framework.

 

Whilst such a thing would be neat, it would also be impractical. Supporting things like Doom, Build, Jedi tech into one framework seems like a nightmare to maintain.

Basically this. The very same reason the XL Engine died off before the rise of the Force Engine out of its ashes.

[Graf Zahl]

In short: The engine internally still *is* Build. Adding games based on different technology is not going to work out.

If it was that easy, Raze and GZDoom would be one project, not two.

 

[Master O]

On 5/30/2020 at 4:33 PM, Graf Zahl said:

Currently it's not fully merged with VoidSW so a few things are not in yet. Also, when I started I used SWP to pick some code and in a few instances this may cause slight differences to vanilla because that engine did a few enhancements. The Coolie corpses may be a result of that, it's surely the kind of thing SWP would have added to the game.

 

Then I take it you're also fully aware of https://voidpoint.io/terminx/eduke32 ?

[Vermil]

EDIT: Please delete this post.

Edited June 7, 2020 by Vermil

[A Nobody]

What about Software mode support for people with weak computers?

 

I wonder if this will be on Android.

[Graf Zahl]

If you want software mode, use one of the parent ports. This was something I didn't want to saddle myself with because a) I have zero interest in software rendering and  b) Build's software renderer is on a completely different level of "convoluted" compared to Doom's. This goes far enough that it can become a genuine blocker for refactoring because it sticks its dirty fingers into places where it should have no business.

 

Regarding Android: Probably not. Right now the biggest problem I am facing is that there's only two people providing feedback, which is simply not enough to develop a stable foundation - there's surely no plans to branch out to other platforms unless somebody else comes along to help out.

 

 

[seed]

53 minutes ago, Graf Zahl said:

only two people providing feedback

 

But also committed to the job👌.

[ReaperAA]

1 hour ago, Graf Zahl said:

Right now the biggest problem I am facing is that there's only two people providing feedback, which is simply not enough to develop a stable foundation - there's surely no plans to branch out to other platforms unless somebody else comes along to help out.

 

I might start providing feedback too once I get free from certain real life stuff (should be after 3-ish weeks). 

[Cacodemon345]

I would, more often than not, avoid touching the mobile platforms. Especially Android and iOS. The platforms are full of proprietary commercialized ports of otherwise open-source programs.

 

If someone wants to make profit off open-source work, I am fine otherwise.

[Graf Zahl]

I persinally do not care about Mobile.

iOS is as toxic as it comes with Apple constantly changing the rules and GPL code for all intents and purposes forbidden due to the App Store requirement and developing for Android is as un-fun as it can gets with second grade tools and the Java mess.

 

[A Nobody]

You don't have to use Java for Android.

[taufan99]

I know Raze's DN3D support is based on EDuke32, but now that Rednukem now supports DN64 (provided that you own the ROM dump), will Raze add some support for it as well? Given that Raze also has some Rednukem code (for Redneck Rampage).

[seed]

8 hours ago, InDOOMnesia said:

I know Raze's DN3D support is based on EDuke32, but now that Rednukem now supports DN64 (provided that you own the ROM dump), will Raze add some support for it as well? Given that Raze also has some Rednukem code (for Redneck Rampage).

 

And the classic Duke compatibility level as another example.

 

Edit: Nevermind, see below.

Edited July 5, 2020 by seed

[seed]

Actually I got an update regarding DN64 support in Raze.

 

According to some very recent conversations with Graf, the answer for the time being is actually a strong "no". When nuke added support for it, the game code also got mixed with GL 2.x code, which renders it fully incompatible with Raze's codebase.

 

Unfortunately, this also has the side-effect of making backporting stuff from Rednukem's repo no longe possible either, the codebase just got rendered useless for our project. So for the foreseeable future, folks wanting to play DN64 on PC natively will have to use Rednukem instead.

 

Quote

"I wish he'd have done it as its own project. This essentially makes it impossible to fetch any updates from his repo again. The way he did it is simply not compatible with Raze at all, putting OpenGL 2.x code directly into the game."

 

Quote

"To clarify what I mean:

RedNukem's biggest problem has always been that the code tried as hard as possible to reduce any redundancy - leading to endless checks for the active game throughout the entire code base. This has been an issue from the start because it is virtually impossible to understand the program flow. It was bad with Duke, RR and RRRA, then Deer Huntin' got added by using the same approach and now again the same method for Duke 64. I grudgingly took Deer Huntin although I have no interest in that game but couldn't really go on without it - but this latest addition is simply too much. With this state of things I am entirely dependent on upstream for handling the game code which is not my idea of source port.

The new renderer is just the final straw on top of that. It's OpenGL compatibility profile with various modern additions and entirely incompatible with Raze's render backend. I'd have to rewrite this code from scratch to make use of it. I'm sorry but at some point it becomes too much work - and this Duke64 thing is that point. But since the additions to the game's core code are so invasive I'd rather pass on RedNukem as a whole from now on."

 

Edited July 5, 2020 by seed