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

Being able to use Doom launchers to start it won't make it more doomy, just easier to use... :P

4 hours ago, Graf Zahl said:

Being able to use Doom launchers to start it won't make it more doomy, just easier to use... :P

 

I don't disagree this but I actually means things that not for "easier to use, but feels like it should be like that"... :P

On 2/8/2020 at 3:45 AM, markanini said:

You can run it using this command

raze.exe /j "D:/DeathWishfolder" -ini "DW.ini"

 

I tried this for Death Wish and Shadow Warrior's Twin Dragon (the GOG version that comes as a separate folder), as well as putting Path=F:\folderformod\ under [GameSearch.Directories] but neither of these appears.

The directory based version of Twin Dragon is currently not supported as a separate game mode, but it should work if loaded with '-file dragon'.

Alternatively you can get a packaged version of the mod here: http://www.r-t-c-m.com/knowledge-base/downloads-rtcm/swarrior-addons/tdragon.zip

This file should be autodetectable.

In both cases, make sure you also get the two fixed levels from r-t-c-m.com and put them into the same directory.

If I install that free Shadow Warrior version on Steam, will it be detected by Raze?

4 minutes ago, VGA said:

If I install that free Shadow Warrior version on Steam, will it be detected by Raze?

Iirc the DOS version sold separately is essentially the full game that's distributed with Redux too, minus the port itself of course (not sure about the music though).

If it's not autodetected you can just point the path to it manually and it should be fine. And speaking of free, Shareware Shadow Warrior v1.2 is also supported and works correctly from my testings (older versions unsupported).

Free full Shadow Warrior or free shareware version of it?

*heavy machinery noises*

The answer is free full version!

On 2/15/2020 at 4:23 PM, Graf Zahl said:

The directory based version of Twin Dragon is currently not supported as a separate game mode, but it should work if loaded with '-file dragon'.

Alternatively you can get a packaged version of the mod here: http://www.r-t-c-m.com/knowledge-base/downloads-rtcm/swarrior-addons/tdragon.zip

This file should be autodetectable.

In both cases, make sure you also get the two fixed levels from r-t-c-m.com and put them into the same directory.

 

No luck, I tried many permutations and the only thing that worked so far was dragging that packaged vanilla version into the executable. Trying to alter that zip file's contents with the fixed levels' made it not detect the add-on.

Haven't tried with 0.4.5 Alpha yet, though.

I took a quick look at your work, correct me if I'm wrong, but it looks like a code refactor with some extra post process bits? I'm not sure what all this adds to eduke32?

I wrote PolymerNG and I know how far you can take build, your not going to get far without switching over to Vulkan or Direct3d 12. Even then your going to need virtual texturing, and the new compute vertex render pipeline in the RTX cards so you don't become draw call bound.

I get a crash and an error message when I try to play Redneck Rampage Route 66 with the latest version of Raze. The crash log is as follows:

Log started: 2020-02-20 23:06:03
OS: Windows 10 (or higher) (NT 10.0) Build 18362
    
 adding C:/Raze/raze.pk3, 148 lumps
 adding C:/RedneckGDX/Redneck/REDNECK.GRP, 441 lumps
 adding C:/RedneckGDX/Redneck/, 20 lumps
Texture filtering mode changed to LINEAR_MIPMAP_LINEAR
CPU speed: 3392 MHz
I_InitSound: Initializing OpenAL
  Opened device OpenAL Soft on Speakers (DFX Audio Enhancer)
  EFX enabled

Execution could not continue.

What went wrong?

An interface to handle user maps/mods would be a big plus for me, and probably a lot of other users. Blood especially can be a bit of a weird mess to get some things to play well with the source ports. I use BuildGDX(NBlood didn't work very well on my Intel chip, haven't yet tried it with the GTX 750) and it's a bit annoying even when the mod does work. Other times I get a pack of random files with no clue what to do- I can't get the latest Bloody Pulp Fiction to run properly as the custom music audio won't play, it defaults to the deathmatch taunts. Sometimes I just give up on dealing with it, and some of these mods were never intended to work with a source port as they're often old. That's if the mod doens't crash randomly.

Having an all-in-one I can run all the games from one directory will also be a bonus. Most of my Build games sit on my Windows XP computer with DOSbox in their folders, remaining unplayed. Even with BMouse slapped on, it's still kind of an unwieldy mess to play them with mouselook. Okay, so it's an absolute mess...

6 hours ago, icecoldduke said:

your not going to get far without switching over to Vulkan or Direct3d 12. Even then your going to need virtual texturing, and the new compute vertex render pipeline in the RTX cards

exactly the setup we need to play the game from 1996! ;-)

@icecoldduke I like you and your interesting coding endeavours but you never complete your stuff. Graf Zahl is literally the opposite of you, so please stop concern trolling. Raze already has some advantages over eduke32 when it comes to Vsync, frame pacing and, I think, sound quality.

Also, interesting to see that there were some Vsync fixes for eduke32 recently. Seems some competition is good, after all.

8 hours ago, icecoldduke said:

I wrote PolymerNG and I know how far you can take build, your not going to get far without switching over to Vulkan or Direct3d 12. Even then your going to need virtual texturing, and the new compute vertex render pipeline in the RTX cards so you don't become draw call bound.

I don't think the amount of draw calls will be the issue. The Doom engine is quite similar when it comes to the kind of geometry that needs to be handled. In GZDoom some maps can amount to 16000 draw calls and more, and they still handle fine with Vulkan on a modern NVidia or AMD card - on NVidia even on OpenGL.

And in all these cases the bottleneck is not the GPU but the CPU.

OpenGL on AMD is another matter, though - but that has always been a problem.

1 hour ago, VGA said:

Also, interesting to see that there were some Vsync fixes for eduke32 recently. Seems some competition is good, after all.

... and it was quite an interesting approach, but when I asked some system programming experts for an opinion I got some quite raised eyebrows about its viability. It's taking an approach I've never seen before - going down to the driver SDK's functionality to check for vertical sync.

9 hours ago, icecoldduke said:

I took a quick look at your work, correct me if I'm wrong, but it looks like a code refactor with some extra post process bits? I'm not sure what all this adds to eduke32?

I suggest you read the opening post of this thread or the Wiki thread for a global explanation. The 5 games supported are implemented as modules and do not interact with eachother. They are controlled by an overall framework, consisting of EDuke32 and GZDoom code. That is a rough explanation.

Quote

I wrote PolymerNG and I know how far you can take build, your not going to get far without switching over to Vulkan or Direct3d 12.

I thought i never would see the day that one would suggest moving over to an API that's used for shader heavy games, not a 2.5D engine that dates back to the 90s that does not have a lot of visual features that require either OpenGL or Vulkan (or D3D12).

And yes, you wrote PNG (I mean PolymerNG), but was it released?(In a finished state, that is). This is what i have been mentioning earlier to you. You have great idea's, but flawed execution. And whilst it is okay to stop working on a project after some time (For whatever reason), its another to consistently announce new and exciting things and never finish them on a consistent basis.

The paragraph above is one that to date is never taken to heart, as if you do not understand what people mean when they tell you this. You simply announce a new project that has an interesting set of ideas, but given the history, i can never verify if this one will get finished.

In that, you are what VGA says, a complete opposite of Graf. Because Graf released Raze.

Quote

Even then your going to need virtual texturing, and the new compute vertex render pipeline in the RTX cards so you don't become draw call bound.

What you seem to want is to make use of bleeding edge GPU technology and retroactively refactor it into an engine structure that adhers to the design principles of the 90s. GZDoom wouldn't come as far as it is today without the work from Graf. It wouldn't support the advanced visual features now if QZDoom didn't exist (It would obviously have them at some point, but later considering Graf's time is limited like everyone else's). Making an 90s engine work nicely with modern stuff is a different ball game altogether.

Now, i know that you are able to reiterate your idea into practice fairly quickly - Usually within days you have what you proposed. But as soon as it is implemented, you lose the interest to refine the implementation, and eventually you move on to another new idea. Graf's work and time isn't so much about implementation, but about refining the things that get introduced. This is why support for newer OpenGL versions takes time, not in the least because one has to consider the userbase that still runs an older OpenGL version of videocard.

This is the fundamental difference between your workflow, and his as far as im concerned. You may iterate quicker than Graf does, but you forfeit the steps that come after, because the real interest for you is to implement your idea into code. As soon as that is done, the interest is lost.

7 hours ago, JimFlasch said:

I get a crash and an error message when I try to play Redneck Rampage Route 66 with the latest version of Raze. The crash log is as follows:

 

Log started: 2020-02-20 23:06:03
OS: Windows 10 (or higher) (NT 10.0) Build 18362
    
 adding C:/Raze/raze.pk3, 148 lumps
 adding C:/RedneckGDX/Redneck/REDNECK.GRP, 441 lumps
 adding C:/RedneckGDX/Redneck/, 20 lumps
Texture filtering mode changed to LINEAR_MIPMAP_LINEAR
CPU speed: 3392 MHz
I_InitSound: Initializing OpenAL
  Opened device OpenAL Soft on Speakers (DFX Audio Enhancer)
  EFX enabled

 

Execution could not continue.

 

What went wrong?

Please use the Bugs section at the ZDoom forums for this :)

2 hours ago, Redneckerz said:

I suggest you read the opening post of this thread or the Wiki thread for a global explanation. The 5 games supported are implemented as modules and do not interact with eachother. They are controlled by an overall framework, consisting of EDuke32 and GZDoom code. That is a rough explanation.

From the user perspective who cares if 5 games are implemented as modules? It doesn't matter, that simply a code refactor :).

Quote

I thought i never would see the day that one would suggest moving over to an API that's used for shader heavy games, not a 2.5D engine that dates back to the 90s that does not have a lot of visual features that require either OpenGL or Vulkan (or D3D12).

I stand by that recommendation. The problem with the build engine with OpenGL is you become draw call bound really quickly, and you need the control that D3D12 and Vulkan provide to get proper performance gains with Build.

Quote

And yes, you wrote PNG (I mean PolymerNG), but was it released?(In a finished state, that is). This is what i have been mentioning earlier to you. You have great idea's, but flawed execution. And whilst it is okay to stop working on a project after some time (For whatever reason), its another to consistently announce new and exciting things and never finish them on a consistent basis.

Yes it is in a finished state, you can play the entire game with PolymerNG. 

Quote

In that, you are what VGA says, a complete opposite of Graf. Because Graf released Raze.

I disagree. Raze seems like a simple code refactor with making Polymost API agnostic, while still leaving it in OpenGL? It also adds some post process bits. I'm just trying to understand that's all this is.

Quote

What you seem to want is to make use of bleeding edge GPU technology and retroactively refactor it into an engine structure that adhers to the design principles of the 90s. GZDoom wouldn't come as far as it is today without the work from Graf. It wouldn't support the advanced visual features now if QZDoom didn't exist (It would obviously have them at some point, but later considering Graf's time is limited like everyone else's). Making an 90s engine work nicely with modern stuff is a different ball game altogether.

You don't get how graphics optimization works. It doesn't matter how old the data is, modern day graphics cards require the data to be submitted in a certain way. The build engine, because everything can move, you can't build stuff offline. There for you have to batch things up dynamically, which is what virtual texturing is good for. If you don't your going to submit small batches, and theres going to be lots of GPU idle time, which is what you have in stock Polymost.

Quote

 I like you and your interesting coding endeavours but you never complete your stuff. Graf Zahl is literally the opposite of you, so please stop concern trolling. Raze already has some advantages over eduke32 when it comes to Vsync, frame pacing and, I think, sound quality.

This isn't trolling, but I do have lots of experience in the Build engine, and my post was simply trying to figure out what this project actually is. Is it just a code refactor(the 5 modules thing), with some post process bits, or is it more then that? Because you can download reshade to get the post process bits in stock eduke32. Stock eduke32 had vsync :).  

2 minutes ago, icecoldduke said:

Yes it is in a finished state, you can play the entire game with PolymerNG.

Then where's the place where I can find it?

1 minute ago, icecoldduke said:

From the user perspective who cares if 5 games are implemented as modules? It doesn't matter, that simply a code refactor :).

You asked what Raze adds over eDuke32. Its why i redirected to the OP first and formost.

1 minute ago, icecoldduke said:

I stand by that recommendation. The problem with the build engine with OpenGL is you become draw call bound really quickly, and you need the control that D3D12 and Vulkan provide to get proper performance gains with Build.

You don't think that has something to do with the inherent nature of Build in general?

1 minute ago, icecoldduke said:

Yes it is in a finished state, you can play the entire game with PolymerNG. https://github.com/BlackenmaceStudios/PolymerNGPublic

You aren't referencing the encompassing point and i don't feel entering a meta discussion asking you more about PNG.

1 minute ago, icecoldduke said:

I disagree. Raze seems like a simple code refactor with making Polymost API agnostic, while still leaving it in OpenGL? It also adds some post process bits. I'm just trying to understand that's all this is.

Its very simple indeed. I wonder why nobody else tried it. Aside the jest, lets tag @Graf Zahl for this and you can have that debate then.

1 minute ago, icecoldduke said:

You don't get how graphics optimization works.

Thank you for this assumption based on the quoted cite!

3 minutes ago, Cacodemon345 said:

Then where's the place where I can find it?

His linked Github. But its not a compiled executable.

26 minutes ago, Redneckerz said:

You asked what Raze adds over eDuke32. Its why i redirected to the OP first and formost.

You don't think that has something to do with the inherent nature of Build in general?

 

You aren't referencing the encompassing point and i don't feel entering a meta discussion asking you more about PNG.

 

Its very simple indeed. I wonder why nobody else tried it. Aside the jest, lets tag @Graf Zahl for this and you can have that debate then.

 

Thank you for this assumption based on the quoted cite!

 

His linked Github. But its not a compiled executable.

So what if I linked my GitHub(https://github.com/jmarshall23/PolymerNG), it's still a completed project, and you can play the game all the way through, even on the Xbox One, which is why I didn't release binaries, because PolymerNG works on Xbox One and PC. I can't legally redistribute a completed Xbox One Package.

I'm not trying to hijack your thread with my work, I didn't even realize you were the developer, I just read the OP and went "what is this project?". I'm sure Graf is awesome guy and I'd love to speak with him. But I don't see what this project offers above what (ReShade + Stock EDuke32) gives you. You can download ReShade here https://reshade.me/ drop it into stock EDuke32, and you have all the post process bits you want.

2 minutes ago, icecoldduke said:

I'm not trying to hijack your thread with my work, I didn't even realize you were the developer, I just read the OP and went "what is this project?". I'm sure Graf is awesome guy and I'd love to speak with him.

And you should, because i am not the developer, Graf is. :) I simply made the release thread when Raze got released.

12 minutes ago, Redneckerz said:

And you should, because i am not the developer, Graf is. :) I simply made the release thread when Raze got released.

Ah I see :). When you get a chance, you should download ReShade and drop it into stock EDuke32. I'm curious to see your thoughts between that and Raze. 

4 hours ago, VGA said:

@icecoldduke I like you and your interesting coding endeavours but you never complete your stuff. Graf Zahl is literally the opposite of you, so please stop concern trolling. Raze already has some advantages over eduke32 when it comes to Vsync, frame pacing and, I think, sound quality.

 

Also, interesting to see that there were some Vsync fixes for eduke32 recently. Seems some competition is good, after all.

And it was mostly meaningless, because Adaptive and traditional VSync is still very much broken...

7 hours ago, diosoth said:

An interface to handle user maps/mods would be a big plus for me, and probably a lot of other users. Blood especially can be a bit of a weird mess to get some things to play well with the source ports. I use BuildGDX(NBlood didn't work very well on my Intel chip, haven't yet tried it with the GTX 750) and it's a bit annoying even when the mod does work. Other times I get a pack of random files with no clue what to do- I can't get the latest Bloody Pulp Fiction to run properly as the custom music audio won't play, it defaults to the deathmatch taunts. Sometimes I just give up on dealing with it, and some of these mods were never intended to work with a source port as they're often old. That's if the mod doens't crash randomly.

Not for right now though. For the time being, the main priority is fixing bugs, stabilizing things, and building™ a solid foundation. Once that's out of the way other features will come. All in due time.

Also nice trolling we've got ourselves here in the meantime. Ha. Ha.

1 minute ago, icecoldduke said:

Ah I see :). When you get a chance, you should download ReShade and drop it into stock EDuke32. I'm curious to see your thoughts between that and Raze. 

I would yield zero success with that as ReShade relies on a semi-modern GPU. In comes me that has no semi-modern GPU.

Also, if you don't what to hijack the thread then don't :P

As for the rest, i refer back to my earlier post.

7 minutes ago, seed said:

And it was mostly meaningless, because Adaptive and traditional VSync is still very much broken...

I'd be curious to see what your fail case is(in either Raze or EDuke32 stock), vsync is obviously controlled by the driver. In OpenGL its a single API call the app has to make to enable/disable vsync, but after that it's up to the driver to implement vsync properly. 

31 minutes ago, icecoldduke said:

From the user perspective who cares if 5 games are implemented as modules? It doesn't matter, that simply a code refactor :).

For that part, correct, but it's not the objective here - it was merely done this way for convenience and consolidation.

31 minutes ago, icecoldduke said:

I stand by that recommendation. The problem with the build engine with OpenGL is you become draw call bound really quickly, and you need the control that D3D12 and Vulkan provide to get proper performance gains with Build.

How many polygons would you expect? Build's hard limits are a lot lower of what a limit removing Doom engine can process, so if in Doom it won't be bound by draw calls, how can it be in Build?

31 minutes ago, icecoldduke said:

Yes it is in a finished state, you can play the entire game with PolymerNG. 

You may be, I am not - have you released the source?

31 minutes ago, icecoldduke said:

I disagree. Raze seems like a simple code refactor with making Polymost API agnostic, while still leaving it in OpenGL? It also adds some post process bits. I'm just trying to understand that's all this is.

Right now that's all there is. You got to start somewhere and create a solid foundation to build upon. Otherwise the result can quickly become another vaporware product with grand aspirations but nothing to show. It's also not just about the renderer but also the backend, i.e. getting rid of SDL and the ancient sound engine that's being used in all Build ports.

Before moving on this stuff should first be stable, and that's where we're at right now - playtesting the games and fixing what shows up. The focus right now is on Duke and Blood, with Shadow Warrior following when these two are done.

And please don't blame me for all the fanfare - some other people got carried away a bit here...

31 minutes ago, icecoldduke said:

You don't get how graphics optimization works. It doesn't matter how old the data is, modern day graphics cards require the data to be submitted in a certain way. The build engine, because everything can move, you can't build stuff offline. There for you have to batch things up dynamically, which is what virtual texturing is good for. If you don't your going to submit small batches, and theres going to be lots of GPU idle time, which is what you have in stock Polymost.

Uhhh... The Doom engine is precisely like that - I already have a renderer working with that, and working efficiently. It does not perform virtual texturing, it does not perform any kind of convoluted draw call optimization, it just pushes everything out as single polygons, and it still cannot keep up with the CPU-side preparation of all the data - if the scene was static and unchanging, just recording the draw calls and replaying them would play back at 300+ fps even on very complex levels.

The obvious conclusion to draw here is that trying to optimize the GPU side by letting the CPU do more work is utterly counterproductive. You add work where the engine is already stalled to save some in a place where there's still room to breathe.

5 hours ago, icecoldduke said:

I'd be curious to see what your fail case is(in either Raze or EDuke32 stock), vsync is obviously controlled by the driver. In OpenGL its a single API call the app has to make to enable/disable vsync, but after that it's up to the driver to implement vsync properly. 

In Raze it very much does its job, in EDuke32, NBlood, and probably VoidSW (didn't actually bother to try it there tbh) it turns the game into an unplayable mess. It doesn't play well with modern drivers at all in these 2 - or maybe it does, I keep hearing that there are no issues for 120hz or 144hz, but that's too bad, I have a basic 60hz monitor and I'm not interested in upgrading.

@Graf ZahlDon't worry I've been on the internet :P. I hope you don't take my developer critiques for trolling as these guys did, I've been in the game industry for over 12 years, and back and forths like this help expand knowledge and frankly is a great way to make new friends :). Source code for my Direct3D 11 port of the build engine(PolymerNG) is on my GitHub. I'm not going to saturate your thread with my work, but the link is a couple posts up. 

I was able to get clcoast(worst case build engine map) running at under 16ms on the Xbox One. I think it was even under 11ms at one point. The gains weren't from switching the renderer over to Direct3D 11, but from all the various other things I did, but if I wanted to get more gains on top of that, I had to switch over to Direct3D 12, which is also on my GitHub, but it's in a broken state because I switched that stuff over to Direct3D 12 raytracing, which works, but doesn't have texture mapping or moveable sectors. That is also on my github

Let me start from all of your points and let me slowly remember what I did 4 years ago :).

To ensure were talking about the same thing, a render backend is usually when you offload the command buffer creation to another thread. It seems like you developed a RHI layer into Polymost to abstract away the graphics API?  In PolymerNG I separated out the actual command buffer generation into a separate thread, and also abstracted away the graphics API. This was the biggest win with Direct3D 11 at the time, was being able to multi thread the renderer. 

Also in PolymerNG I moved occlusion culling to the CPU, basically I software rasterized each sector, color coded each sector, then had another job scan over the resulting buffer to know which sectors were visible and which ones weren't. So I disagree that with your statement about moving work to the CPU being counterproductive, because I have videos on my youtube channel that prove my point.

The next iteration of the software occlusion culling I think heavily modified Polymost to be an occlusion culling system rather then rendering and that was faster then what I described above. I ran that in another thread.

To your point about the CPU not keeping up with the prep of the data, the way Polymost and Polymer work is not ideal. So outside of moving the command buffer building to another thread, and creating a CPU occlusion culling system, the next bit of gains would come from Virtual Texturing, you can also vomit out a single 16k texture atlas that contains all of the original Duke Nukem 3D tiles in it, which is something I think I did at one point. For most maps, the amount of vertexes isn't an issue, were as the number of visible sectors is the issue. I remember building the vertex buffers each frame(double buffered), then you simply submit the vertex buffer(which contains all of your visible geometry), with the dynamic or statically created atlas, and instantly the GPU is completely saturated with work, with no idle times. Even if you record your draw calls in OpenGL(which has been a hit or miss for me with that working), the wavefront's are not going to be as saturated, compared to the method I just described.

It's really early here, and I need to get ready for work, so I hope all this makes sense :). 

Also the issue with Direct3D 12 raytracing and the Build engine, because all the sectors can move, rebuilding the acceleration structures in some of the worst case situations, was too CPU intensive and couldn't keep framerate.

2 hours ago, icecoldduke said:

This isn't trolling, but I do have lots of experience in the Build engine, and my post was simply trying to figure out what this project actually is. Is it just a code refactor(the 5 modules thing), with some post process bits, or is it more then that? Because you can download reshade to get the post process bits in stock eduke32. Stock eduke32 had vsync :).  

The post-processing stuff is just a bonus, not really the point. It comes free from using the GZDoom backend.

The point of Raze is to have a Build port that is free to kill the sacred cows to offer a more stable and convenient experience. Refactors is the way to achieve that, progressively and gradually. Since Raze is its own thing, it can get away with sacrificing a lot of things that couldn't (and shouldn't) be removed from conservative ports, like the menu code or the sound code.

1 hour ago, icecoldduke said:

@Graf ZahlDon't worry I've been on the internet :P. I hope you don't take my developer critiques for trolling as these guys did,

I never once called your critique trolling first and formost. You will find that the only one of these guys who threw up that term was @VGA.

Don't put everyone in the same basket when its only one person who even remotely said something like this.