Raze is not dead yet...

[Graf Zahl]

... but it has seen some major changes.

After months of refactoring work it is finally time to make an announcement. Expect a 0.7 release soon.
This new version will be very different than the last one.

The biggest change has been that I decided to go back to the roots with Duke Nukem support. I removed both the EDuke32 and the RedNukem game module and instead created a new one that is based on older sources that are closer to what the code looked like when 3D Realms released it in 2003. The bases I used for this are: Primarily JFDuke, plus WW2GI extensions from EDuke 2.x and Nuke.YKT's reconstructtion of the original Redneck Rampage code with World Tour support being based on DukeGDX.

The reasons for this change were twofold: With RedNukem I was simply no longer able to update from the parent repo, due to the Duke64 additions and due to its nature of being a de-modernized port of EDuke32 I was neither able to merge features from EDuke32 itself or from older code bases because it differs too much from both.
The reason to drop the EDuke32 module are probably obvious - it never worked right because some of its features are simply not compatible with my vision of what Raze was supposed to become.
So I'm sorry, but mods that require EDuke32 support will no longer work.

So, on to the good stuff. What was done over the course of the last 3 months?

• Complete migration to GZDoom backend code, including main game loop and timer. Raze now runs on one single central game loop, instead of the 100's of loops for every single screen as it was in all these Build games.
• The input system was completely rewritten and mostly consolidated between all games, especially making the control feature set mostly orthogonal.
• Interpolation of weapon rendering in all games
• Major preparations for exporting all intermission screens and status bars to external scripts. For easier debugging they are currently still native code, though.
• Intro movies of Redneck Rampage Rides Again and Exhumed are now working properly
• Move playback has been consolidated in the backend, once exposed to modding all formats can be freely mixed in all games.
• Widescreen assets added for all games, except Exhumed mostly taken from BuildGDX (For anyone concerned, permissions have been obtained from all authors) Exhumed is missing because permission from one author has not yet been obtained, please see the note below.
• Native Duke Nukem World Tour support
• Some automap extensions, e.g. unrotated display, like in Doom.
• lots of fixes for Exhumed, although not complete yet for the sound system
• optional ammo magazine amount display for reloadable weapons.
• New fullscreen HUDs for Shadow Warrior and Exhumed

Last but not least, mjr4077au has joined as a developer on Raze, he is responsible for the bulk of the new input and interpolation system the engine got.


Note about Exhumed's widescreen assets:
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?

[Dynamo]

All of this is fair enough, and in fact, great news, but I am wondering on this specific aspect:

it never worked right because some of its features are simply not compatible with my vision of what Raze was supposed to become.

Which features got in the way exactly? More out of curiosity than anything.


I would furthermore note that in regards to EDuke32 compatibility in particular: as far as my knowledge goes, a lot of the "historical" mods related to EDuke32 in particular (thinking about, for example, Imperium) are supposed to be run *only* on very specific versions of EDuke32 (that the mod comes bundled with anyway), and they don't run properly on newer versions of it either, so for those worried that this change will result in a massive drop for supported mods, I would just like to say that that's not the case at all, because, as Graf said already, most of them never worked on Raze to begin with.

[Enjay]

That sounds like it was a power of work. I have to say that it gives me even more confidence in Raze. I mean, I was confident about it already but this just feels like a much more cohesive, sure and planned way forward and, given his track record for solid, methodical, well thought-through coding, I am utterly confident in Graf's ability to pull it off. The project will be better and stronger because of this shift.

[Graf Zahl]

All of this is fair enough, and in fact, great news, but I am wondering on this specific aspect:

it never worked right because some of its features are simply not compatible with my vision of what Raze was supposed to become.

Which features got in the way exactly? More out of curiosity than anything.

By far the biggest problem was that EDuke32 could run events from inside the menu. The ZDoom/Raze menu runs as a separate layer outside the game code and executing scripted events from there could cause nasty recursion issues. This was the biggest issue with getting Ion Fury to work, because the menu depended on these events.
Other features that I couldn't robustly port were the scripted cutscenes because they depend on a separate render loop and calling the 3D renderer directly from scripts, e.g. to draw a 3D scene to the HUD. In all these cases the reason for the problems was that the engine has little control of what gets called from where. But the goal I had was to get it to the same state as Doom - have a centralized main loop that calls the playsim, the 3D renderer and the 2D renderer successively - which is the polar opposite of what was present in the engine. Sure, I could have kept it like that, but then Raze would never have gotten past the point of "EDuke32 with a different renderer", which really wasn't my idea of a port.

I would furthermore note that in regards to EDuke32 compatibility in particular: as far as my knowledge goes, a lot of the "historical" mods related to EDuke32 in particular (thinking about, for example, Imperium) are supposed to be run *only* on very specific versions of EDuke32 (that the mod comes bundled with anyway), and they don't run properly on newer versions of it either, so for those worried that this change will result in a massive drop for supported mods, I would just like to say that that's not the case at all, because, as Graf said already, most of them never worked on Raze to begin with.

Yes, that, too. It may be possible over time to gradually add some features back, but this needs to be done with the utmost care to avoid breaking things, and of course it needs to have a point, i.e. there have to be mods this re-enables. So far I even kept EDuke 2.x's access to the map data out to make sure that no potentially unstable element is added, but these are things that wouldn't be too hard to get in at a later stage. For now, though, there's still a few more fundamental problems to address, like migrating the voxel and model code to GZDoom's and make the models work again, or to get the palette emulation right again. It is generally functional but still has some issues because the GZDoom backend produces slightly different results for some operations. These 3 are the big issues to tackle after 0.7.

That sounds like it was a power of work. I have to say that it gives me even more confidence in Raze. I mean, I was confident about it already but this just feels like a much more cohesive, sure and planned way forward and, given his track record for solid, methodical, well thought-through coding, I am utterly confident in Graf's ability to pull it off. The project will be better and stronger because of this shift.

[Phredreeke]

I feel that ditching the EDuke32 module was the right call. It'd be chasing a moving target.

I'm not sure if it's part of the renderer or game logic code, but assuming the latter, have you implemented the fixed shrink state that avoids the camera clipping through the floor causing HoMs?

BTW I believe only one sprite in the Exhumed WS pack was by MaxEd (although I can't say off the top of my mind which one it is)

[sinisterseed]

That sounds like it was a power of work. I have to say that it gives me even more confidence in Raze. I mean, I was confident about it already but this just feels like a much more cohesive, sure and planned way forward and, given his track record for solid, methodical, well thought-through coding, I am utterly confident in Graf's ability to pull it off. The project will be better and stronger because of this shift.

Oh yes, you can say that again.

These last couple of months have been pretty damn intense for our development, it took a lot of time, work and effort to bring the games where they are now and carefully checking things to stay faithful where needed, not to mention fixing the myriad of bugs (you've no idea how many of them were) that surfaced in the process.

It's good to be able to more-or-less talk about the current state of things, and at the bare minimum tell everyone that we're not dead and in fact, we're more alive than ever . I'm sure some people doubted the future considering the repo hasn't seen changes in quite a while, not since the backend migration. But fear not, we're still going strong.

We're confident in what we have, and the next release will quite hopefully be the most polished and modern-feeling to date, notably Exhumed which was rough the last time, despite not being quite there yet. I know the announcement of the loss of support for EDuke32 mods will be a blow to some, but it was a necessary step in order to move forward.

[Graf Zahl]

I feel that ditching the EDuke32 module was the right call. It'd be chasing a moving target.

The "moving target" part really wasn't a problem - the architectural differences were. It's close to impossible to port a game to a different base setup when some of its features depend on how the underlying code works.

I'm not sure if it's part of the renderer or game logic code, but assuming the latter, have you implemented the fixed shrink state that avoids the camera clipping through the floor causing HoMs?

Most likely not. The game logic is currently nearly unaltered original Duke code - I only ported two fixes from EDuke32 (the laser beam rendering and an interpolation issues with some sprites) Is there any place where this can be easily reproduced?

BTW I believe only one sprite in the Exhumed WS pack was by MaxEd (although I can't say off the top of my mind which one it is)

[/quote]

Hm, pity that you cannot say which one. I hope this gets cleared up.

[Phredreeke]

Find a mirror and fire the shrinker into it and look down.

[sinisterseed]

Find a mirror and fire the shrinker into it and look down.

I know the bug you're talking about, saw it many times in EDuke before it got fixed, but we should be fine, I tried to reproduce that error many times, all of them unsuccessful.

And if it does show up at some point, we'll fix it.

[Graf Zahl]

I couldn't reproduce it either. Looks like the fix was renderer-side then.

[Guest]

I think leaving EDuke32 behind is the right move. it will give Raze a more stable base, I'm sure.

[Phredreeke]

BTW I believe only one sprite in the Exhumed WS pack was by MaxEd (although I can't say off the top of my mind which one it is)

Hm, pity that you cannot say which one. I hope this gets cleared up.

it's the mummy staff

[Dzierzan]

As far as i remember, all widescreen sprites were made by me expect the mummy staff. However i didnt hestitate to edit the staff even further for better widescreen support. I tried to contact the guy who did widescreen sprites for the staff too, but he never replied. IMO you should not care this much, just make sure he is credited too.

[wildweasel]

As far as i remember, all widescreen sprites were made by me expect the mummy staff. However i didnt hestitate to edit the staff even further for better widescreen support. I tried to contact the guy who did widescreen sprites for the staff too, but he never replied. IMO you should not care this much, just make sure he is credited too.

That's not how open source licensing works.

[Phredreeke]

As far as i remember, all widescreen sprites were made by me expect the mummy staff. However i didnt hestitate to edit the staff even further for better widescreen support. I tried to contact the guy who did widescreen sprites for the staff too, but he never replied. IMO you should not care this much, just make sure he is credited too.

That's not how open source licensing works.

Technically wouldn't that bar all the widescreen sprites, as we don't have permission from the rights holders of respective games? (at least as I know of)