[Jimmy]

Just my two cents, but mods can always have patches released. I wouldn't worry about mods.

[Little Tijn]

Hendricks266, on 07 May 2018 - 04:04 PM, said:

r6880 amends the problematic commit and another one I'm unsure of to only apply in WWII GI mode. Do the issues that affected Duke before r6879 also apply to WWII GI in r6880?

The might boot is still working correctly in Duke and NAM with r6880, so that is fixed The "knife" in WW2GI animates now the same as the original, although with the problem that when tapping the fire button, it doesn't register a hit. Only when keeping the button down. That was the problem with the revisions before 6879.

But I don't mind it. And I guess nobody does, seeing that this is the first time this game can actually be played now at all with a very nice port. I would say, keep it as it is now. It's working fine for Duke3D and these games. Maybe someone can revisited this topic again later when the time is right. Try to focus now on something that matter and that gives positive energy, instead of fixing some silly commercial mods

And remember, what started as a simple bug report of the auto-aim turned thanks to your hard work into a full-blown recreation of the logic of the game.

[Little Tijn]

Couldn't edit my post anymore. Notices that the BAR (4) also has this problem somehow.

[Hendricks266]

Little Tijn, on 24 April 2018 - 03:06 AM, said:

Maybe it is possible to add a OPL3 emulator, also for authentic sounding music in Duke as well. Although that would be quite a change for a game (NAM) that isn't that great. Maybe for Duke

I am happy to report that I have secured the necessary permissions to add Nuked OPL3 to EDuke32.

[Little Tijn]

Hendricks266, on 09 May 2018 - 10:45 AM, said:

I am happy to report that I have secured the necessary permissions to add Nuked OPL3 to EDuke32.

Wow! Didn't expecting that. That is great news! Eager to hear a version with that added. Btw. A option to choose between the OPL3 emulation or the current midi player would be nice.

[Little Tijn]

Sorry to bother with this again. Just found out that all automatic weapons (and the KNEE_WEAPON) in WW2GI have the problem when tapping the fire button.

I might make a new forum thread for it, if desired.

I guess I found the offending line:

if (TEST_SYNC_KEY(playerBits, SK_FIRE) == 0 && (PWEAPON(playerNum, pPlayer->curr_weapon, Flags) & WEAPON_RESET || WW2GI))

It's in player.c. I just do not know at the moment how to fix this, because I gladly would if I could.

If someone has some time to check this out someday, that will be great!

[Little Tijn]

Hendricks266, on 09 May 2018 - 10:45 AM, said:

I am happy to report that I have secured the necessary permissions to add Nuked OPL3 to EDuke32.

I recently noticed that the OPL3 emulator is available in EDuke32! Thank you and the other devs involved for adding this! It just sound great and very accurately. Great job!

I even see that the Windows based MIDI playback is still available as a option. Ah, good old Microsoft GS Wavetable Synth. Like I remember it in Windows Me

[Cherno]

Long ago I asked about the same issue here. I'm glad it finally got noticed

[OVERLORD]

Hello there!

I noticed that enemy tank's turret in WWII GI does not follow the player and constantly shoots in one direction.

You may stand by the side of the tank or behind and it won't even turn its turret to aim at you.

In original DOS version of the game, the enemy tank's turret used to follow/aiming at player when spotted.

What could be the problem here?


I noticed that there some turret related strings in WW2GI.con

ai AITANKSEEK VCTANK 0 seekplayer
ai AITANKAIM VCTANK 0 faceplayer
ai AITANKSHOOT VCTANKSHOOT 0 faceplayer
ai AITANKHURT VCTANK 0 faceplayer

Changing either of these to 1 makes turret living it's own life.

When you shoot from bazooka it jumps off the tank chassis and continues shooting at you from the ground.

Sounds like a joke but that's how it is.


===============================================

Also is it normal in NAM that there are some Vietcong pretending to be dead by just lying on the ground and when you come up to them they stand up and start shooting at you?

[Hendricks266]

Does it work in Rednukem?

[OVERLORD]

Hendricks266, on 25 August 2020 - 08:02 AM, said:

Does it work in Rednukem?

What is Red Nukem?

Update:

Just checked - not it does not.

It doesn't even launch.

[Hendricks266]

Yes it does. Rednukem supports WWII GI. https://lerppu.net/wannabethesis/

[OVERLORD]

Hendricks266, on 25 August 2020 - 09:37 AM, said:

Yes it does. Rednukem supports WWII GI. https://lerppu.net/wannabethesis/

I just tested it and I confirm that in REDNUKEM, when playing WWII GI, tank turret operates correctly, It aims at player, follows it and may be blown out with one shot from bazooka (may be I'm just lucky).

Jut launch E1L7 and come to any tank. It will follow you with it's turret and will shoot at you.

Now we need to find out why EDuke32 has this bug and what causes it.

[OVERLORD]

If set "ai AITANKAIM VCTANK 1 (instead of 0) faceplayer" inside of WW2GI.con the tank turret starts acting as intended - it follows player and shoots them.

But when you blow out the turret with your bazooka it jumps off the tank chassis and starts shooting at you from the ground.

That's some crazy stuff out there. See the screenshots attached.


I think that proper and correct fix for this should be implemented as addition into command line parameter "-ww2gi" which makes EDuke32 run in compability mode when WWII GI is launched.

That's the only glitich I found so far when making walkthough of WW2GI. Everything else worked just right in my opinion.

In Rednukem, tank turrets in WWII GI operate correctly.

Attached thumbnail(s)

• 
• 

[Hendricks266]

OVERLORD, on 25 August 2020 - 11:50 PM, said:

I think that proper and correct fix for this should be implemented as addition into command line parameter "-ww2gi" which makes EDuke32 run in compability mode when WWII GI is launched.

That option is a holdover from before proper GRP detection and selection was implemented. Implementing a change like this for only one of the game modes is a last resort.

I think you've correctly identified the source of the issue by changing move 0 to move 1 to work around it, and whatever is causing it has effects on any game or mod that uses CON, therefore the system itself should be fixed.

[OVERLORD]

Hendricks266, on 26 August 2020 - 08:27 AM, said:

That option is a holdover from before proper GRP detection and selection was implemented. Implementing a change like this for only one of the game modes is a last resort.

I think you've correctly identified the source of the issue by changing move 0 to move 1 to work around it, and whatever is causing it has effects on any game or mod that uses CON, therefore the system itself should be fixed.

Is there any way to establish a proper behavior of tank turret and get away from the bug I mentioned?

Rednukem handles it without any problems, but I would love to see this issue eliminated in EDuke32 since it's the source port of my favor.

[Doom64hunter]

Hendricks266, on 26 August 2020 - 08:27 AM, said:

I think you've correctly identified the source of the issue by changing move 0 to move 1 to work around it, and whatever is causing it has effects on any game or mod that uses CON, therefore the system itself should be fixed.

The tank aiming broke almost 12 years ago, between the builds of 2008-11-25 and 2008-12-14.

Edit: Found it! (thankfully there were 2 source code archives on synthesis from around this time)

Between these revisions, the following check was added to the function `X_Move()`, nowadays called `VM_Move()`, in gameexec.cpp:

+    if (vm.g_t[1] == 0 || a == 0)
+    {
+        if (deadflag || (ActorExtra[vm.g_i].bposx != vm.g_sp->x) || (ActorExtra[vm.g_i].bposy != vm.g_sp->y))
+        {
+            ActorExtra[vm.g_i].bposx = vm.g_sp->x;
+            ActorExtra[vm.g_i].bposy = vm.g_sp->y;
+            setsprite(vm.g_i,(vec3_t *)vm.g_sp);
+        }
+        return;
+    }

This is what it looks like today, with some surrounding context added:

GAMEEXEC_STATIC void VM_Move(void)
{
    MICROPROFILE_SCOPEI("VM", EDUKE32_FUNCTION, MP_AUTO);

    auto const movflagsptr = &AC_MOVFLAGS(vm.pSprite, &actor[vm.spriteNum]);
    // NOTE: test against -1 commented out and later revived in source history
    // XXX: Does its presence/absence break anything? Where are movflags with all bits set created?
    int const movflags = (*movflagsptr == (remove_pointer_t<decltype(movflagsptr)>)-1) ? 0 : *movflagsptr;
    int const deadflag = (A_CheckEnemySprite(vm.pSprite) && vm.pSprite->extra <= 0);

    AC_COUNT(vm.pData)++;

    // #### The code causing the problem:
    if (AC_MOVE_ID(vm.pData) == 0 || movflags == 0)
    {
        if (deadflag || (vm.pActor->bpos.x != vm.pSprite->x) || (vm.pActor->bpos.y != vm.pSprite->y))
            setsprite(vm.spriteNum, &vm.pSprite->pos);

        return;
    }
    // ####

    if (!deadflag)
    {
    ...

In other words, if the move is set to 0, the VM_Move() function aborts early, and therefore the code associated with the `faceplayer` flag does not execute.
This did not used to happen prior to the build compiled on 2008-12-14, and thus breaks the WW2GI Tank. Maybe other mods are also affected.

[Doom64hunter]

Addendum: The code above isn't new, but was previously executed only after the `face_player`, `spin`, `jumptoplayer` and `face_player_smart` logic was executed.

I analysed the CON code of all official addons using grep, and from what I can see, WW2GI is the only official Duke-based game that uses a zero move in an AI definition.

[OVERLORD]

That's really nice to find out.

How do you think this may be fixed?

Is there a need to implement changes into source code of EDuke32 or to make some specific amendments into WW2GI.con?

[Hendricks266]

This can be fixed in the source code.

[OVERLORD]

Some kind of mysterious bug here. What are those semi-transparent lines going up to the sky?

They emerge from geometry angles from the walls, where textures stack with each other.

This occurs at E3L1 and E3L5 in "MULTIPLAYER 1" episode at WWII GI.

Can this be fixed somehow? Please see screenshots.

It appears when CLASSIC renderer is used

I use modified build r8642 (git-svn 8798) by the creator of RedNukem source port.
It has tank turret fix for WWII GI implemented.

Attached thumbnail(s)

• 
• 

[OVERLORD]

Hey guys, take a look at what I've done - Widescreen Status Bar For NAM!

Use the following command line to use it:

"-g DN3DAE_16_9_Aspect_Ratio_NAM_Weapons'_Sprites_Fixes.zip"

It also contains widescreen version of hands for Сlaymore Mine (taken from Duke Nukem 3D widescreen tiles)

Attached thumbnail(s)

• 
• 

Attached File(s)

•  DN3DAE_16_9_Aspect_Ratio_NAM_Weapons'_Sprites_Fixes.zip (6.57K)
  Number of downloads: 370

[OVERLORD]

Hey guys, take a look at what I've done - Widescreen Status Bar For WWII GI!

Use the following command line to use it:

"-g DN3DAE_16_9_Aspect_Ratio_WW2GI_Weapons'_Sprites_Fixes.zip"

It also contains widescreen version of hands for TNT (taken from Duke Nukem 3D widescreen tiles)

Attached thumbnail(s)

• 
• 

Attached File(s)

•  DN3DAE_16_9_Aspect_Ratio_WW2GI_Weapons'_Sprites_Fixes.zip (8.58K)
  Number of downloads: 384

[OVERLORD]

OVERLORD, on 01 September 2020 - 09:07 AM, said:

Hey guys, take a look at what I've done - Widescreen Status Bar For NAM!

Use the following command line to use it:

"-g DN3DAE_16_9_Aspect_Ratio_NAM_Weapons'_Sprites_Fixes.zip"

It also contains widescreen version of hands for Сlaymore Mine (taken from Duke Nukem 3D widescreen tiles)

Made a little amendment. Here is the latest version.

Attached thumbnail(s)

• 

Attached File(s)

•  DN3DAE_16_9_Aspect_Ratio_NAM_Weapons'_Sprites_Fixes.zip (6.57K)
  Number of downloads: 371

[Doom64hunter]

You should probably post the widescreen tiles in a separate thread, otherwise it will be very hard to find in the future.

[OVERLORD]

Yes, I also posted my works at "What are currently working on for duke?" thread.

[OVERLORD]

So, finally there is a fixed build with WWII GI Tank Turret Bug eliminated.

Courtesy of our mega man - Hendricks266.

http://hendricks266....k-fix-32-bit.7z


But...


Some kind of mysterious bug here. What are those semi-transparent lines going up to the sky?

They emerge from geometry angles from the walls, where textures stack with each other.

This occurs at E3L1 and E3L5 in "MULTIPLAYER 1" episode at WWII GI and at numerous places else, in NAM for instance... or at third mission of Platoon Leader expansion pack for WWII GI...


My observations:

"At levels which have cropped sky (yet another bug), there are
semi-transparent lines going up to the sky. They emerge from geometry
angles of the walls, where textures stack with each other.
It appears as they only emerge from geometry angles of the borderline
walls which separate level area from total emptiness."

Please see the screenshots in attachment.

It appears when CLASSIC renderer is used.

I use modified build r8642-AMENDED by Hendricks266.

Original r8642 does not have such an issue with semi trasparent lines going in the sky.


Additionally, I would like to show some information from EDuke32.log regarding r8642-AMENDED :

///////////////////////////////////////////////////////////////////////////////// ///////////

EDuke32 r8642-AMENDED
Built Jan 3 2021 18:15:19, GCC 10.2.0, 32-bit
Running on Windows 10 (build 10.0.19041)
Initialized 1ms system timer
CPU: Intel® Core™ i3-3120M CPU @ 2.50GHz
Initializing SDL 2.0.10

///////////////////////////////////////////////////////////////////////////////// ////////////


and for comparison purposes, here is the information regarding original r8642 build:


///////////////////////////////////////////////////////////////////////////////// ////////////

EDuke32 r8642
Built Feb 12 2020 01:06:43, GCC 8.3.0, 32-bit
Running on Windows 10 (build 10.0.19041)
Initialized 1ms system timer
CPU: Intel® Core™ i3-3120M CPU @ 2.50GHz
Initializing SDL 2.0.10

///////////////////////////////////////////////////////////////////////////////// /////////////

Attached thumbnail(s)

• 
• 

[OVERLORD]

Are there any console commands or cvars to improve performance of EDuke32 in CLASSIC renderer ?

In NAM there are lots of semi-transpatent sprites like grass and lots of dynamically occuring explosion sprites, which may decrease fps in some conditions i think.

For example when your radioman calls for fire mission (smoke) - some time later there are many semi-transparent sprites of smoke occur, if I get closer to them or go through - my fps drops from 98.8 to 57.4 approximately. If you call two smoke fire missions - you will be surrounded by smoke cloud sprites and in this case my fps is around 35-47.

In fact, NAM and WWII GI are much less stable in terms of fps than Duke Nukem 3D. I don't really remember to have any fps drops in Duke Nukem 3D.

In WWII GI there is considerable fps drop in e1m1 when the front door of landing craft explodes, from like 98.8 to 67 or something, but it restores to initial value quite fast.

So I would to know if performance can be improved & tweaked by using console commands and command line parameters available in EDuke32.

I play at CRT monitor @ 1024x768 , 100 hz , vsync enabled.

[Doom64hunter]

OVERLORD, on 13 January 2021 - 10:39 AM, said:

Are there any console commands or cvars to improve performance of EDuke32 in CLASSIC renderer ?

In NAM there are lots of semi-transpatent sprites like grass and lots of dynamically occuring explosion sprites, which may decrease fps in some conditions i think.

For example when your radioman calls for fire mission (smoke) - some time later there are many semi-transparent sprites of smoke occur, if I get closer to them or go through - my fps drops from 98.8 to 57.4 approximately. If you call two smoke fire missions - you will be surrounded by smoke cloud sprites and in this case my fps is around 35-47.

In fact, NAM and WWII GI are much less stable in terms of fps than Duke Nukem 3D. I don't really remember to have any fps drops in Duke Nukem 3D.

In WWII GI there is considerable fps drop in e1m1 when the front door of landing craft explodes, from like 98.8 to 67 or something, but it restores to initial value quite fast.

So I would to know if performance can be improved & tweaked by using console commands and command line parameters available in EDuke32.

I play at CRT monitor @ 1024x768 , 100 hz , vsync enabled.

You can toggle the "upsampling" option in the Display menu to 2x, which should substantially improve performance at the expense of rendering quality.

[Doom64hunter]

The tank bug is now fixed in mainline, by the way.