Raze is not dead yet...

[Graf Zahl]

Regarding EDuke32 features, I just repeat myself. I have to do it carefully. Full support of all current features is not going to happen, though, but it'd be a great win already if I got support up to - say 2011 or 2014. But development has to go forward from the current state, so this cannot be instantly.

if you're implementing a subset of EDuke32 functions I'd suggest calling it something else to avoid confusion like "extended CON scripting", otherwise you'll have people asking why specific mods won't work on it I think.

Whatever gets done here after adding EDuke 2.1 support will be to support specific mods. Right now I neither have an overview over mods worth supporting nor the features they need so it's hard to say where things will go. Don't worry - I won't advertise this as EDuke32 version xyz compatible, because that's misleading.

[Master O]

... 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....

Thanks for the update.

On a semi-related note, are SSI files (the ones for the physical CD releases of Duke It Out in DC and Duke Caribbean: Life's a Beach) now supported by Raze? In the previous version of Raze, those did not load correctly.

[Graf Zahl]

No. I have to be honest, this completely fell off my radar.

[PlayerLin]

Get the new base engine done first and later to add more things like EDuke32 map/mods supports and others, sounds good idea.

Personally, if I want run maps/mods for EDuke32, I would like just go use EDuke32(I already used it for ten more years), I see it's nice thing if Raze supports them but I don't really use Raze to run them. I would like use Raze for its own maps/mods.

Losing past 10 years of better mods of Duke? I don't think that's big deal, if Raze can get its own things like GZDooM, I'm sure something good will happens.

[Redneckerz]

I would suggest just ditching CON and introducing a new scripting syntax entirely, which is better structured and offers similar flexibility as current eduke32 CON.
The pseudo-assembly style of coding of CON is tedious to work with and not having true functions where you can pass by value or reference leads to a ton of issues when trying to write safe, readable code.
Maybe, and this is more pipedream thinking than anything else, such a new syntax could also be designed such that it can work for more than one of the supported games.

Well, ZScript. But CON is a primary part of Build engine tech so removing it altogether without some compatibility layer may seem a challenge. In a lot of ways Build is just really different from Doom tech, so when Graf says that changes need to be done carefully, i fully understand why that is.

Another question is interpretation of map format, i.e. will features such as TROR, sloped sprites etc. be supported?

That seems more like an ambitious roadmap for the long term, if anything else.

Regarding EDuke32 features, I just repeat myself. I have to do it carefully. Full support of all current features is not going to happen, though, but it'd be a great win already if I got support up to - say 2011 or 2014. But development has to go forward from the current state, so this cannot be instantly.

if you're implementing a subset of EDuke32 functions I'd suggest calling it something else to avoid confusion like "extended CON scripting", otherwise you'll have people asking why specific mods won't work on it I think.

Maybe GZCON?

As for Graf's main news: Its half reinventing the wheel and half departing from the roadblocks that prohibit Raze from progressing further. If anything if stability improves because of it, all the better. Its great that its here, in the first place.

[Graf Zahl]

Well, ZScript. But CON is a primary part of Build engine tech so removing it altogether without some compatibility layer may seem a challenge. In a lot of ways Build is just really different from Doom tech, so when Graf says that changes need to be done carefully, i fully understand why that is.

CON is not a primary part of Build tech. It's a primary part of Duke tech. Don't mix them up, none of the other games not based on the same engine uses CON. But since it's an integral part of the game it cannot be ditched because all the original CON code needs to keep working.

As for Graf's main news: Its half reinventing the wheel and half departing from the roadblocks that prohibit Raze from progressing further. If anything if stability improves because of it, all the better. Its great that its here, in the first place.

Since this comes up again and again, even in PMs, let's give a short explanation why EDuke32 code was such a major roadblock. It's actually very simple:
EDuke32's main method of extending the engine has been to grant broad means of access to internal state to the CON language - consisting of a set of CON commands allowing changing nearly every field in every structure in the game and events that get called in various places of the engine.
While this is a great and simple way to extend an engine, it also virtually locks the engine state in place, it's a corset that's impossible to remove without breaking things all over the place.

Even with Raze 0.6 this caused major issues with Ion Fury because my menu replacement and the transition to ZDoom style CVARs for game configuration severely affected these things - the menu events never worked fully and some of the game state wasn't properly retrievable anymore. The biggest issue I faced was how the scripted cutscenes worked - they run a render loop within the script - and one of these was called from the menu, which ran outside the game logic so I ended up with nasty recursion issues.
But it did not end there - there's event hooks everywhere in the engine - in the movie player, in the weapon drawing code, in the intermission screens, the sound code and so on, and so on - meaning none of these systems could be refactored without breaking more things. Virtually nothing of the above list is still in the same state as in the parent code - it has been completely rewritten. And like the menu, the problems with the events would have been inevitable.

So, to summarize, the essence of the above is that in order to support EDuke32 the engine has to be EDuke32, but what would be the point then? I didn't start Raze to copycat another engine, even though now, while it's still in the beginning it may look like that - which is hardly surprising considering that I haven't found much time yet to add some bona-fide new features to it. So far all the work went into building the foundation for the new features.

[Master O]

No. I have to be honest, this [SSI File Support] completely fell off my radar.

Thank you for adding that support to Raze.

[JudgeGroovy]

Very cool to see you're making a new port for Duke. Reading on your posts about support for eDuke32, I still had a question. You mention not supporting eDuke32 mods. I'm curious if vanilla Duke user maps will work? Stuff that was made for the original version? Also if limit removing vanilla style maps, just with more walls, objects etc, that may have been played on eDuke32 may work? A lot of those also work on Megaton and even World Tour, though with black skyboxes and other quirks in WT.

Get the new base engine done first and later to add more things like EDuke32 map/mods supports and others, sounds good idea.

Personally, if I want run maps/mods for EDuke32, I would like just go use EDuke32(I already used it for ten more years), I see it's nice thing if Raze supports them but I don't really use Raze to run them. I would like use Raze for its own maps/mods.

Losing past 10 years of better mods of Duke? I don't think that's big deal, if Raze can get its own things like GZDooM, I'm sure something good will happens.

It's more like 20 years, isn't it? 16 or so for eduke32. Either way, this is a worthwhile and cool venture, but I do think it would be a big deal if no maps from that time period worked. But that's why I'm asking, since I only see mention of mods in particular, and I'm more into the idea of preserving the great many maps with vanilla gameplay. Very cool that you're making this Duke port either way, just wondering about the ol' user maps.

[Graf Zahl]

Standard Duke mods are still supported, of course. The removal of EDuke32 support was due to migrating Duke to game code closer to the original release - the current support level is roughly EDuke 2.1 with a few rarely used things not working due to implementation differences.

The limits are still the same as EDuke32, i.e. 16384 sprites and walls, and 4096 sectors. 16384 for walls and sprites is a hard limit of the original engine code. It can theoretically be lifted but require some major effort to remove some hacks from old times - mainly finding all places where such hacks are being done.

It's more like 20 years, isn't it? 16 or so for eduke32. Either way, this is a worthwhile and cool venture, but I do think it would be a big deal if no maps from that time period worked. But that's why I'm asking, since I only see mention of mods in particular, and I'm more into the idea of preserving the great many maps with vanilla gameplay. Very cool that you're making this Duke port either way, just wondering about the ol' user maps.

It's actually 17 years for the Duke source release and 14 years for EDuke32 - but you can subtract a few years during which people got acquainted with the engine before releasing something.

"No maps" is a bit of a hyperbole, if you ask me. Just look at Doom: Has ZDoom made mapping for vanilla or Boom non-existent? Of course not! There's maps being made for all these standards, depending on what's of interest to their makers.

[JudgeGroovy]

Right on, thanks for the reply. Wondering about maps a bit still. I see eduke 2.1 is from 2004. Does that mean that Duke maps made after that, which were typically made for eDuke32 users, those won't work? To be more specific, say the vanilla style maps "Sin Center" and "Done and Dusted", from around 2011 or 2012. Would those be something that could be compatible with Raze in the future?

I know there are a lot of quirks to different versions of eDuke32, and some maps may do stuff like making ornate sprite origami style creations that look wrong in different editions etc. And I'm not even wondering about true room over room maps, which while cool didn't work properly in Polymost etc. I just mean your usual vanilla gameplay with limit removing stuff, that would be released over the years. Since some of those by luck or whatever happen to work on Megaton and World Tour, this is another reason why I'm unclear on this eDuke version comparison etc.

Long story short, I'm not as well versed on under the hood, so I'm not sure what specifically this means, as far as what you're targeting for user map compatibility. Is it pretty much that anything from 2004 or earlier is expected to be playable, and any map after that made with mapster is something we'll see how it goes a bit later?

[Graf Zahl]

I do not know all Duke maps, but if they only use vanilla features they should work. But considering that for years EDuke32 was the only port in town I really cannot say if some maps unknowingly exploited engine quirks. You'll have to play them to make sure. But if they work in Megaton or World Tour, they should work in Raze as well, and most likely in DukeGDX as well.

EDuke2.1 vs. EDuke32 is a lot less clear. EDuke 2.1 was a DOS only engine so I don't expect much content to exist for it.

My general advice can only be to try. If some map clearly states "EDuke32" it's a lot less likely to work, although pure maps without any CON scripting may still work as long as they do not use any Room over Room features.

[JudgeGroovy]

Cool, sounds good. Thanks.

[PlayerLin]

As Graf said, you could try it to find out, and most of user maps for vanilla Duke will had txt files about info, remember to read them too. if it didn't said "only test with EDuke32" or something like "Designed for EDuke32/Needed EDuke32 to play" then I think you can just load them without any of problems with Raze(unless other bugs happen).

EDuke 2.0/2.1 just existed on very short of time(1-2 years then EDuke32 happened), not sure many maps/mods using its things(many of mods for EDuke was either canceled or move on to JFDuke3D/EDuke32) so I don't think that would be a problem...I guess.

[Trusty McLegit]

Oh, hell yeah! After so long, I was wondering if this project had died a quick death. I know I don't participate a whole lot here, but I just want to say Graf (and of course everyone else who has contributed to Raze and GZDooM) words barely express my gratitude for the incredible work you do here. You've put an incredible amount of work and time making these projects what they are today, so that people like me can get enjoyment out of them. GZDooM is by far the best looking and best playing version of DOOM out there by a long shot, not to even mention the astounding mod support. I never thought I'd see the day BUILD got the same treatment, and I'm so glad that I have. It's certainly a shame not to be able to play most classic/current Duke mods with this great new engine, but if that's the cost of pushing Raze forward unhindered by the issues that come with eDuke32, then I think that's absolutely worth it. It's not like eDuke32 is going anywhere anyways.

[Graf Zahl]

The classic mods surely will still work. It's only the ones requiring EDuke32 features that won't. Since this is based primarily on JFDuke, any mod working with that should still work, if not, that'd be a bug.