Page 4 of 5

Re: Raze is not dead yet...

PostPosted: Sat Oct 03, 2020 5:37 pm
by VGA
What does this change mean for Blood support?

Also, will we get that awesome looking Polymer lighting in Raze? It looked amazing but performance was bad in eduke32 and there were some z-fighting issues with sprites that never got resolved I think. World Tour has its own enhanced lighting thing, too!

Re: Raze is not dead yet...

PostPosted: Sat Oct 03, 2020 11:55 pm
by Graf Zahl
VGA wrote:What does this change mean for Blood support?


Nothing. All the other game modules have remained as they are, for Blood the only enhancement in terms of gameplay has been NoOne's extensions and they integrate a lot better into the core game code than EDuke32 does in Duke, so it can remain as it is. And both SW and Exhumed haven't seen any enhancements yet in any port.

VGA wrote:Also, will we get that awesome looking Polymer lighting in Raze? It looked amazing but performance was bad in eduke32 and there were some z-fighting issues with sprites that never got resolved I think. World Tour has its own enhanced lighting thing, too!


Polymer is mostly the effect of specular lighting, that's already supported by GZDoom's backend. So for the most part, once I find the time to write a new renderer, it should be doable, although my suspicion is that Polymer loses most of its time by clipping light visibility, so if that is the case I'll surely compromise in favor of performance.
What I can say with certainty is that dynamic lights in Polymost will never work, the renderer totally mangles the geometry before it ever sees the hardware so placing lights is pretty much impossible.

Re: Raze is not dead yet...

PostPosted: Mon Oct 05, 2020 3:26 pm
by MaxED
Graf Zahl wrote:While we were able to obtain permission from all other contributors, the credits for Exhumed also list MaxED, but I have no idea how to contact him. His forum account here has been inactive for more than 3 years and his Github account doesn't look active, either, anymore. Does anybody know how to get in touch with him?

Feel free to use the sprites.

Re: Raze is not dead yet...

PostPosted: Tue Oct 06, 2020 12:37 am
by mjr4077au
MaxED wrote:
Graf Zahl wrote:While we were able to obtain permission from all other contributors, the credits for Exhumed also list MaxED, but I have no idea how to contact him. His forum account here has been inactive for more than 3 years and his Github account doesn't look active, either, anymore. Does anybody know how to get in touch with him?

Feel free to use the sprites.

Thank you very kindly for this, much appreciated! :D

Re: Raze is not dead yet...

PostPosted: Tue Oct 06, 2020 4:38 am
by Graf Zahl
:rock:

Re: Raze is not dead yet...

PostPosted: Tue Oct 06, 2020 3:34 pm
by Redneckerz
MaxED wrote:
Graf Zahl wrote:While we were able to obtain permission from all other contributors, the credits for Exhumed also list MaxED, but I have no idea how to contact him. His forum account here has been inactive for more than 3 years and his Github account doesn't look active, either, anymore. Does anybody know how to get in touch with him?

Feel free to use the sprites.

I am legit impressed at your return MaxED. I hope that you will roam the streets of ZDoom more often from now on.

Welcome back!

Re: Raze is not dead yet...

PostPosted: Wed Oct 14, 2020 6:58 am
by Xavier Punderridge
Please do not mourn the lack of Polymer. It looks great (when it works that is). But it runs like a dog and it is a huge pain to work with. Much better to jetison it into space and start again with something else. This is from someone who made a mod using it (Hollywood Holocaust Rethinked). Having a nice PBR realtime renderer with dynamic lighting would be great, but I'd quite happily settle for something much simpler which actually worked as intended and could be relied on to host content in a consistent manner.

Loosing compatibility with EDuke for mods is a blow, but one thing you have to keep in mind is that a lot of mods are tied to specific versions of EDuke. Our HHR mod was tied to particular version due to some fixes that were instituted in Polymer specifically for our mod to be able to work. Some of those fixes got un-fixed somehow later on. Other mods are tied to different specific versions of EDuke. So having our version of EDuke and having HHR work fine will break another, older mod. You can't win this way. Having a later version of EDuke as part of the core won't guarantee you that every mod will work with Raze.

Re: Raze is not dead yet...

PostPosted: Wed Oct 14, 2020 9:35 am
by Graf Zahl
Xavier Punderridge wrote:Please do not mourn the lack of Polymer. It looks great (when it works that is). But it runs like a dog and it is a huge pain to work with. Much better to jetison it into space and start again with something else. This is from someone who made a mod using it (Hollywood Holocaust Rethinked). Having a nice PBR realtime renderer with dynamic lighting would be great, but I'd quite happily settle for something much simpler which actually worked as intended and could be relied on to host content in a consistent manner.


The good thing is, GZDoom's render backend supports these things so the biggest part for those features is already present, i.e. if you define a material with the proper layers it will render them as intended. Of course, what will become tricky is doing proper occlusion math for the lights, because of Build's ability to have overlapping sectors.

Xavier Punderridge wrote:Loosing compatibility with EDuke for mods is a blow, but one thing you have to keep in mind is that a lot of mods are tied to specific versions of EDuke. Our HHR mod was tied to particular version due to some fixes that were instituted in Polymer specifically for our mod to be able to work. Some of those fixes got un-fixed somehow later on. Other mods are tied to different specific versions of EDuke. So having our version of EDuke and having HHR work fine will break another, older mod. You can't win this way. Having a later version of EDuke as part of the core won't guarantee you that every mod will work with Raze.


Yeah, that was part of the reason why I pressed the reset button. I noticed this with Ion Fury - nearly every change I made broke something in the game which depends on a very specific engine behavior, and in the end it was clear that keeping support was a losing proposition, especially with this "moving target" characteristic.

Re: Raze is not dead yet...

PostPosted: Tue Oct 27, 2020 1:55 pm
by Hudson
Greetings,

I have been following the development of Raze for a while and am very interested in the possibilities of how to utilize GZDoom features in an EDuke 2.1 mod using the latest released version?

I apologize for my ignorance, however while I have been educating myself on GZDoom and it's features I am still fuzzy on how those functions and features could be used in conjunction with a BUILD game utilizing the EDuke 2.1 code now used in the release.

I attempted to locate tutorials and information however the wiki I located was out of date from February and while there are many fantastic tutorials on how to manipulate .CON I haven't been able to find resources detailing how to implement any GZDoom features (or if it is even yet possible).

After searching around for a while I thought I would simply ask, this is the most up-to-date thread of information about the project that I could find. I am really excited about the possibilities Raze has and will have to offer and am just very interested in getting as much accurate information as I can to educate myself on it. Thank you very much for any help you can provide.

Re: Raze is not dead yet...

PostPosted: Tue Oct 27, 2020 3:14 pm
by wildweasel
Outside of the renderer, input, and console, the Gzdoom features that are currently in Raze are not ones that apply to editing. It's all back-end stuff, for the moment.

Re: Raze is not dead yet...

PostPosted: Tue Oct 27, 2020 3:17 pm
by Graf Zahl
GZDoom and Raze are separate projects and while both are built on the same engine backend they actually share no editing features. Raze is also still in alpha development, i.e. there's missing or incomplete important features so right now there is no focus on adding editing features.

What precisely are you interested in? The only major component that can be considered complete and accessible to modding is the menu, but that doesn't seem to be the most compelling thing - it just came by reimplementing all menus with GZDoom's menu system.

Re: Raze is not dead yet...

PostPosted: Tue Oct 27, 2020 4:56 pm
by Hudson
Graf Zahl wrote:GZDoom and Raze are separate projects and while both are built on the same engine backend they actually share no editing features. Raze is also still in alpha development, i.e. there's missing or incomplete important features so right now there is no focus on adding editing features.


Okay, so they don't share any editing features at the moment. Thank you, this is what I was mainly curious about. Where would you recommend looking as a reference if I wanted to keep up to date with the status of features and development? (I am already watching on GitHub). Understandably being Alpha there is much more that would need to be implemented. I was just curious if there was any information about what features the team was hoping to get implemented by 1.0 or a future release. A roadmap for instance, or something similar?

What precisely are you interested in? The only major component that can be considered complete and accessible to modding is the menu, but that doesn't seem to be the most compelling thing - it just came by reimplementing all menus with GZDoom's menu system.


I think you have already answered my question here, but what I was curious about was if there were any plans (at a future point, not anytime soon) to potentially see if any GZDoom editing features like ZScript, FraggleScript, ACS, MBF and/or GZDoom's OpenGL renderer features could be implemented in Raze to supplement, enhance or replace those from BUILD/EDuke2.1

As I am not a programmer I apologize if any of this sounds silly - I just happen to see a lot of potential in this project that I believe one day could be the better choice for BUILD/Duke3d modding. I do not expect any of this to happen overnight, development of any kind takes time (even more time if you want to get it done right) and am simply excited about what (even distant) future possibilities may hold.

Thank you very much for your time to respond and answering my questions, I really do appreciate it.

Re: Raze is not dead yet...

PostPosted: Tue Oct 27, 2020 11:43 pm
by Graf Zahl
Doom engine specific features like ACS and FraggleScript surely not, thsese are features tied directly to how Doom handles its maps. Some scripting will surely come but don't forget that the infrastructure of Build engine games is very different from Doom, so DECORATE/ZScript style actor definitions are definitely not coming, especially for Duke. Another important thing to know is that the Build games share a lot less code with each other than the Doom engine games.
The Doom engine was licensed as a whole package, including gameplay logic. The Build engine was just the naked renderer witha few functions for collision detection, so each of the games implements actor logic totally differently, meaning that whatever editing manual exists for Duke has no meaning at all for Blood or Shadow Warrior, and vice versa.
Here lies the main problem for editing: Raze consists of 4 game engines whose only unifying factor is that they use Build as a base. But to expose the games to more powerful editing many of the needed changes have to be done in parallel in all games which slows progress down considerably.

Re: Raze is not dead yet...

PostPosted: Wed Oct 28, 2020 3:07 pm
by Hudson
Graf Zahl wrote:Doom engine specific features like ACS and FraggleScript surely not, thsese are features tied directly to how Doom handles its maps.


Okay, that makes complete sense - I did not know how far those features could be shared, or in this case at all.

Some scripting will surely come but don't forget that the infrastructure of Build engine games is very different from Doom, so DECORATE/ZScript style actor definitions are definitely not coming, especially for Duke.


Understood. I was curious about how difficult the infrastructure of Build was going to make it for you all, even with my limited programming knowledge it seems to be held together quite fragile. I have just always wondered what it could look like if Build game could be adapted to run under a better engine - a question sparked by Ken Silverman's short lived and now defunct BUILD2 project where theoretically earlier Build games could potentially be compatible and take advantage of the new features.

Now I understand more clear than ever that this is not, nor will it ever likely be the case. I appreciate your explanation.

Another important thing to know is that the Build games share a lot less code with each other than the Doom engine games.The Doom engine was licensed as a whole package, including gameplay logic. The Build engine was just the naked renderer witha few functions for collision detection, so each of the games implements actor logic totally differently, meaning that whatever editing manual exists for Duke has no meaning at all for Blood or Shadow Warrior, and vice versa.


This was also something I was concerned would be problematic, as you point out even Build games made by the same developer (Duke3d and Shadow Warrior) are completely splintered regarding logic further complicating the process. Then factor in even more changes by other studios and so on and so forth.

Here lies the main problem for editing: Raze consists of 4 game engines whose only unifying factor is that they use Build as a base. But to expose the games to more powerful editing many of the needed changes have to be done in parallel in all games which slows progress down considerably.


Thank you, this is what I was mostly curious about without being able to properly explain, with the differences between Build games I did not know how it was being approached. I believe I have a complete understanding of my questions and thank you for answering them. While it will understandably slow things down for what my opinion is worth I think you're taking the right direction should you decide to attempt to expose Duke and other Build games to other more powerful editing tools and techniques. Implementing changes across the board in parallel definitely sounds like a smarter, superior way than trying to hit everything at once with a "spray and pray" approach that I've seen others attempt.

Again, I thank you kindly for taking the time to listen to and answer my questions. I'll be continuing to patiently observe development and am excited at what may be in store in the future. Keep up the great work!

Re: Raze is not dead yet...

PostPosted: Thu Oct 29, 2020 4:41 am
by sinisterseed
Hudson wrote:I have just always wondered what it could look like if Build game could be adapted to run under a better engine - a question sparked by Ken Silverman's short lived and now defunct BUILD2 project where theoretically earlier Build games could potentially be compatible and take advantage of the new features.

Now I understand more clear than ever that this is not, nor will it ever likely be the case. I appreciate your explanation.

It would, theoretically, be possible and we can see this at Blood Fresh Supply, which, while using Build code, runs on a different engine.

But the amount of work required for such a task would outweight the benefits and results in far too many complications, as we have seen with the remaster, which is still buggy following Atari's decision to pull the plug early.