Raze and EDuke32 mod support

Raze and EDuke32 mod support

Postby Teddipetzi » Fri Mar 06, 2020 1:16 am

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.
Teddipetzi
 
Joined: 17 Aug 2019
Operating System: Windows 10/8.1/8/201x 64-bit
Graphics Processor: nVidia with Vulkan support

Re: Raze and EDuke32 mod support

Postby Graf Zahl » Fri Mar 06, 2020 1:53 am

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?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Raze and EDuke32 mod support

Postby Fox666 » Fri Mar 06, 2020 6:20 pm

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.

Graf Zahl wrote: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.
User avatar
Fox666
 
Joined: 24 Feb 2011

Re: Raze and EDuke32 mod support

Postby Graf Zahl » Sat Mar 07, 2020 2:32 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Raze and EDuke32 mod support

Postby Yhe100 » Mon Mar 09, 2020 10:17 pm

Can Raze made to be compatible with this mod?

https://www.moddb.com/mods/duke-nukem-alien-armageddon
Yhe100
 
Joined: 10 Mar 2020

Re: Raze and EDuke32 mod support

Postby Frederick Sacklechet » Tue Mar 10, 2020 9:26 pm

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

Re: Raze and EDuke32 mod support

Postby ReaperAA » Wed Mar 11, 2020 6:16 am

Graf Zahl wrote: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.
User avatar
ReaperAA
 
Joined: 19 Oct 2018
Github ID: AtifArshad1995
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Raze and EDuke32 mod support

Postby Graf Zahl » Wed Mar 11, 2020 6:36 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Raze and EDuke32 mod support

Postby ReaperAA » Wed Mar 11, 2020 12:38 pm

Graf Zahl wrote: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 allExpand view
map maps/z1a5


For zone 2 fight, the command is:
Code: Select allExpand view
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 :mrgreen:
Last edited by ReaperAA on Thu Mar 12, 2020 4:01 am, edited 1 time in total.
User avatar
ReaperAA
 
Joined: 19 Oct 2018
Github ID: AtifArshad1995
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Raze and EDuke32 mod support

Postby sinisterseed » Wed Mar 11, 2020 2:34 pm

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.
User avatar
sinisterseed
GZDoom RO Translator & Raze Tester
 
Joined: 05 Nov 2019
Twitch ID: sixhundredsixteen
Github ID: sinisterseed
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Raze and EDuke32 mod support

Postby Graf Zahl » Wed Mar 11, 2020 2:52 pm

Are you implying they were already borked in EDuke32?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Raze and EDuke32 mod support

Postby ReaperAA » Wed Mar 11, 2020 7:12 pm

lowskill. wrote: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.
User avatar
ReaperAA
 
Joined: 19 Oct 2018
Github ID: AtifArshad1995
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Raze and EDuke32 mod support

Postby sinisterseed » Thu Mar 12, 2020 10:03 am

Yea... sorry about that nonsense everyone. Just one of those moments when I'm trying to think too hard after a long day, oops.
User avatar
sinisterseed
GZDoom RO Translator & Raze Tester
 
Joined: 05 Nov 2019
Twitch ID: sixhundredsixteen
Github ID: sinisterseed
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Raze and EDuke32 mod support

Postby markanini » Thu Mar 12, 2020 10:26 am

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/
markanini
 
Joined: 18 Jan 2020

Re: Raze and EDuke32 mod support

Postby sinisterseed » Thu Mar 12, 2020 10:45 am

markanini wrote: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.
User avatar
sinisterseed
GZDoom RO Translator & Raze Tester
 
Joined: 05 Nov 2019
Twitch ID: sixhundredsixteen
Github ID: sinisterseed
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Next

Return to General

Who is online

Users browsing this forum: No registered users and 0 guests