Raze and EDuke32 mod support

[Teddipetzi]

After playing with this for several days I must say that for the original games and for mods from the 90's and early 2000's, as for non-Duke mods, this is really great. There's surprisingly few problems to be found here, even Shadow Warrior's support looks to be quite good, if we disregard the shadow rendering bug.

However, the area where I was less thrilled is modern EDuke mods. Never mind that many of them don't appear like they are using the available features well, I ran into several problems. I got some crashes on Nuclear Showdown and Duke TM features lots of visual corruption, like garbage sprites.

So what's the official state here and what can we expect? I am well aware that some will probably never be playable because the entire backend code has been replaced and any script depending on this may break as a result, but these are only a small minority, right? Even here most mods should not go further than using scripts to define more game content.

[Graf Zahl]

You are raising a few good questions here.
Don't forget that I wasn't fully aware on how EDuke works when changing the underlying system, so there may have been a few accidents down the line. What you report here seems to match the results with Ion Fury quite well.

In general I think that mods which only operate on the gameplay side of things should be safe. Those which try to modify the UI reasonably should also work but due to lack of testing may exhibit some visual glitches.

Where I see the problems is those big mods that try to do extensive customization through an interface that's not really up to the task - the issue being that there's insufficient abstraction between the implementation and the scripting interface - change the implementation and the script may cease working. Duke TM - like Ion Fury - is a good example for such a thing. I'm afraid but supporting these may be out of scope if their behavior depends on engine internals that differ between EDuke32 and Raze.
The main blocker for testing here is performance. Running Ion Fury in a debug build is so slow that I cannot check any issues with it. It's comparable to expecting feature driven GZDoom mods to run in K8vavoom. While a certain degree of compatibility is there, there will always be things where the internal implementations disagree about how some feature is supposed to work

The visual corruption you mentioned with DukeTM is a known issue, and the crash needs to be investigated. What did you do to cause it?

[Fox666]

The visual problems in DNTM are caused by some special flags for displaying the textures. They were not just broken in Eduke32 main branch the last few months, but there was a lack of documentation on them.

DNTM uses a flag to force palette emulation off (GLOBAL_NO_GL_TILESHADES | GLOBAL_NO_GL_FULLBRIGHT).

Then we have 2 kinds of flags for the palettes:

The texture is colorized based on specified RGB values (HICTINT_GRAYSCALE | HICTINT_USEONART | HICTINT_BLEND_OVERLAY).

The texture is always displayed as 8-bit (HICTINT_APPLYOVERPALSWAP | HICTINT_ALWAYSUSEART). Even if the texture is 32-bit, the 8-bit version is displayed.

The last one may sound strange, but is how the original game did it. The only difference is that the sprites were pre-converted to the 256 colors palette, while the TC when the game starts, since it's already necessary to support classic mode.

Where I see the problems is those big mods that try to do extensive customization through an interface that's not really up to the task - the issue being that there's insufficient abstraction between the implementation and the scripting interface - change the implementation and the script may cease working. Duke TM - like Ion Fury - is a good example for such a thing. I'm afraid but supporting these may be out of scope if their behavior depends on engine internals that differ between EDuke32 and Raze.

What is the problem with Ion Fury? The only issue I see is the skybox conflicting with other features in displayrooms.

[Graf Zahl]

So far the known issues with IF are:

- some of the menu events do not work, which means that the episode unlocking does not work.
- rendering is somewhat broken at the beginning of the first level. This is a recent regression, I probably just have to find the commit where it broke.
- some scripted game events do not trigger.
- in a few places the game is really slow, I've seen it dip below 30 fps on occasion - the main issue here seems to be the voxel renderer which at the moment is extremely inefficient and eventually needs to be redone.

But there's the general lack of time. On a normal work day I'm able to put 2, maybe 3 hours into it, provided I don't work on GZDoom. With so little time things cannot move fast.

[Yhe100]

Can Raze made to be compatible with this mod?

https://www.moddb.com/mods/duke-nukem-alien-armageddon

[Guest]

I tested AA in Raze, it at least loads, although the special keys and some projectiles (from the Plasma rifle) are missing.

The special keys are:

ALT FIRE
SWAP CHARACTERS
ALTERNATE WEAPON
PORTABLE VENDOR (this must be unlocked in game)


AA uses a regular version of eduke32, perhaps this mod will be a good benchmark on what features Raze still needs.

[ReaperAA]

The main blocker for testing here is performance. Running Ion Fury in a debug build is so slow that I cannot check any issues with it.

Would it help a bit if I can provide the save games for the places where there are broken scripts. Usually the broken scripts occur at boss fights.

[Graf Zahl]

I already tried to have a look at one of the boss maps. The map as a whole is unplayable in a debug build, which also means it's undebuggable. The savegames also won't help me much - what I need to find out is when it broke - and thanks to the savegame code in EDuke (and all the other supported games) savegames cannot be interchanged between different builds if only a tiny piece of the saved data changed.

[ReaperAA]

thanks to the savegame code in EDuke (and all the other supported games) savegames cannot be interchanged between different builds if only a tiny piece of the saved data changed.

Yeah, in Eduke32, the old savegames are not compatible in newer builds. Luckily in Ion Fury's case, testing some of the maps don't need the save games as getting to the boss area takes 5 to 10 seconds.

The Zone 1 final map can be easily accessed via ingame console by typing:

Code: Select all

map maps/z1a5

For zone 2 fight, the command is:

Code: Select all

map maps/z2a5

And as far as testing which commit broke the scripts, I suggest doing something like a "binary search" .

Suppose if the scripts worked in r5000 of Raze (i.e commit no. 5000 of Raze) but they are broken in r10000, then test r7500 (which is in between r5000 and r10000) . If they are broken in r7500, then test r6250 (in between r5000 and r7500). Go on until you can narrow down a few commits. Most likely you are already aware of this technique, but just posting in case.


I hope I am not bugging you too much

[sinisterseed]

I wouldn't be surprised if the scripts broke around the time other major engine changes occurred, aka around the time the collision code got borked.

[Graf Zahl]

Are you implying they were already borked in EDuke32?

[ReaperAA]

I wouldn't be surprised if the scripts broke around the time other major engine changes occurred, aka around the time the collision code got borked.

AFAIK collision code changes have nothing to do with the scripts. The scripts work fine in Eduke32. And besides, Ion Fury was released after those collision code changes had already happened.

EDIT: When I mentioned stuff like r5000, r10000 etc. I actually was giving hypothetical names for different builds of Raze. Only to give an example of how one could reduce the number of builds to test before reaching the "bad commit". Graf probably already knows about this technique but I just posted it in case.

[sinisterseed]

Yea... sorry about that nonsense everyone. Just one of those moments when I'm trying to think too hard after a long day, oops.

[markanini]

Was it established if mod was functional in recent eDuke32 build to begin with? This post suggests it isn't: https://www.reddit.com/r/dukenukem/comm ... 0_march_6/

[sinisterseed]

Was it established if mod was functional in recent eDuke32 build to begin with? This post suggests it isn't: https://www.reddit.com/r/dukenukem/comm ... 0_march_6/

The version of AA from last year definitely worked in EDuke32, I even made a let's play of it at the time.

If it broke it must have happened in a later version of the mod or eduke. I'll investigate it a bit in the evening.