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

1 hour ago, Gez said:

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.

 

I couldn't have said it better. This will be taken one piece at a time - especially the Exhumed game module has suffered quite a few regressions from all the swapped out code and so far this has seen very little maintenance.

First Hendricks, now ICD. It's like they can't stand the idea of alternatives and just have to force their views on everyone else.

6 hours 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 :).

From the user perspective, they won't even know what a code refactor is, so this "argument" of yours is, to put it mildly, moot.

You also seem to want to categorize this project for what it is now, and ignoring the repeated clarifications of what it intends to eventually be.

Not to mention trying to educate the Lead Developer on why your grossly overkill requirements are needed, even after being told why such is not the case.

...and stating you don't want to hijack the thread and just consult with Graf, when all that can be solved via PM.

For someone who only releases things in a "technically, you can play it" fashion, you seem to have a lot of ideas on how the whole process needs to go down. Except for the part where you only fixate in its initial state and assume that the whole process will stick to that ethos, that is. Then again, maybe that's why you never actually made a full, binary, widespread release.

A great port really =) i like it 

4 hours ago, Graf Zahl said:

 

I couldn't have said it better. This will be taken one piece at a time - especially the Exhumed game module has suffered quite a few regressions from all the swapped out code and so far this has seen very little maintenance.

I'm curious if you had a chance to read the technical write up I put on the previous page?

@icecoldduke i am pretty sure (from my experiments with renderers) that OpenGL 3.3 is enough for what Polymer can do. dynamic BSP can cope with moving sectors without much troubles. and software culling system can be made tiled (and so multithreaded), if it is necessary (but i don't think so; after all, U1 did it all in one thread and was able to get away with it). as we already need cache for dynamic BSP, the same mechanics can be used to cache generated surfaces. plus supplemental blockmap for faster spatial queries.

interesting project. too bad i'm not interested in build-based games enough to write it. ;-)

Feature-wise OpenGL 3.3 is certainly good enough to handle Polymer - there's really nothing there that isn't available in GZDoom (e.g. specular lighting and PBR both are present), but of course real GL 3.3 hardware would be a bit too underpowered to run these shaders efficiently.

For writing such a renderer I would use the same approach as in GZDoom, i.e. let the main thread perform the culling, then pass the elements to be rendered to a second thread to create render data from it, and then (what I'm still working on in GZDoom with slow progress) use a third thread to pass that processed data to the hardware and create a command buffer from it. There's absolutely no need here to require high end GPU features to get decent frame rates out of it. What may be needed is to cut down large sectors into smaller chunks to make map processing a bit easier in places where there's overlaps.

4 hours ago, Graf Zahl said:

For writing such a renderer I would use the same approach as in GZDoom, i.e. let the main thread perform the culling, then pass the elements to be rendered to a second thread to create render data from it, and then (what I'm still working on in GZDoom with slow progress) use a third thread to pass that processed data to the hardware and create a command buffer from it. There's absolutely no need here to require high end GPU features to get decent frame rates out of it. What may be needed is to cut down large sectors into smaller chunks to make map processing a bit easier in places where there's overlaps.

 

Your main thread should be for the game bits. You have a render thread that builds up the command buffers, but your going to need to leave the culling in the render thread. The way your describing your pipeline your going to have 2 frames of latency, rather then just a single frame of latency. In a FPS game when the player hits a button they expect immediate results. One frame of latency people can deal with, two frames not so much.

Build is deceptively complex for GPUs. Your at the foundation stage at the moment. Lots of people have written graphics bits for Build, and trust me when I say it's such a kick in the ass when you realize you hit a ceiling with the graphics API.

The gains you get from Vulkan/Direct3d 12 come from less driver overhead in the pipeline, trust me when I say you need it on more complex user maps. User maps are the issue here not the retail maps. Remember I was targeting 60 to 144 fps, if your targeting 30fps you'll be fine in OpenGL.

@ketmar I was able to get the software occlusion bits down to a few milliseconds if I remember right, the issue was the command buffer generation and ensuring the GPU was properly saturated with work which I couldn't fix without switching to Vulkan or D3D12. 

Good source port however when i try to name a save file and press enter, it doesn't save.

1 minute ago, Spooky Skeleton boi said:

Good source port however when i try to name a save file and press enter, it doesn't save.

In what game? Works fine for me.

Finally, a Duke 3D source port that let me use custom music without using these annoying ".def" files, and it even supports GZdooM's looping oggs!

Been playing through Episode 2 of Duke and the game plays and feels way better than any other port I've tried recently.

A big thanks to everyone involved in this project, you guys rock! :D

46 minutes ago, Spooky Skeleton boi said:

Good source port however when i try to name a save file and press enter, it doesn't save.

Did you install it correctly?

Remember that it must exist in an accessible directory that isn't locked by Windows (that means it must exist in folders like the Users folder). Installing to Program Files won't work.

7 minutes ago, Cacodemon345 said:

Did you install it correctly?

Remember that it must exist in an accessible directory that isn't locked by Windows (that means it must exist in folders like the Users folder). Installing to Program Files won't work.

This is what I was about to suggest.

If you're on Windows make sure the location where Raze is installed has writing privileges, and isn't write-protected - or Raze's folder isn't set to read-only. Directories such as Users, and especially Program Files are protected - the latter is by far the most common mistake in these cases, seriously why do people think installing games there is a good idea?

17 minutes ago, seed said:

seriously why do people think installing games there is a good idea?

maybe because saving game data into .exe directory is not a good idea according to microsoft guidelines?

p.s.: yeah, i know, i am doing the same thing in my software. i mean, who cares about m$ guidelines at all?

I am using to play Blood and yes Raze is located in the Users folder

3 minutes ago, Spooky Skeleton boi said:

I am using to play Blood and yes Raze is located in the Users folder

That's probably why. Try moving it elsewhere, like another partition or even the desktop.

Moved it to desktop and it still doesn't work

9 minutes ago, Spooky Skeleton boi said:

Moved it to desktop and it still doesn't work

 

Did you mess up with the permissions?

Make sure it isn't a shortcut.

It isn't a shortcut but how exactly do i change its permissions?

What precisely happens when you try to save? The Users directory should be perfectly fine.

1 hour ago, ketmar said:

maybe because saving game data into .exe directory is not a good idea according to microsoft guidelines?

That's correct for regularly installed software but not for portable installs. GZDoom and Raze can be done both ways. When installing in Program Files they will store their data in the respective user folders - the config in appdata/roaming/GZDoom|Raze and the savegame in Saved Games/GZDoom|Raze.

I have zero problems starting them from inside Program Files, although I find portable installs outside these directories far more convenient.

16 minutes ago, Spooky Skeleton boi said:

It isn't a shortcut but how exactly do i change its permissions?

Does saving return any messages in the console? It should indicate something going wrong.

Nope nothing in console.

Is there any way to have a .txt file of the console output?

like a report cause i don't know how to use command lines in raze.

The console log should be written automatically.

Is there any way I can get it in like a .txt file.

@Graf Zahl

Wow this is amazing.

I've been waiting for a nice way to play Redneck Rampage for ages and this seems to be it :)

It runs silky smooth even in 4K. Haven't encountered any bugs yet.

I wonder if it's possible to play co-op somehow?

4 hours ago, seed said:

 

This is what I was about to suggest.

 

If you're on Windows make sure the location where Raze is installed has writing privileges, and isn't write-protected - or Raze's folder isn't set to read-only. Directories such as Users, and especially Program Files are protected - the latter is by far the most common mistake in these cases, seriously why do people think installing games there is a good idea?

I install things in Program Files (and Program Files (x86) too. Now what? *

*If you know what you are doing and you know how Windows works, its not that harmful. For people who just play games and do not know much more about their machine than that, then yes, than its a concern.

28 minutes ago, Redneckerz said:

I install things in Program Files (and Program Files (x86) too. Now what? *

 

*If you know what you are doing and you know how Windows works, its not that harmful. For people who just play games and do not know much more about their machine than that, then yes, than its a concern.

I am not referring to software in general, but particularly video games, as these tend to have issues if you install them there.