Another compiler error

[loopyd]

Describe the bug Hey there, realized that I closed my issue too soon. Here's another compiler error. Rather than reiterate my system specs, I'll get straight to the error.

To Reproduce Compile the project per the documentation with the retail cmake preset. I just used cmake-gui . when in the neo folder.

Expected behavior The build succeeds, and you have working build output.

Screenshots This time, here's some more terminal log:

[ 95%] Building CXX object CMakeFiles/DoomBFA.dir/sys/sys_lobby.cpp.o
[ 95%] Building CXX object CMakeFiles/DoomBFA.dir/sys/sys_lobby_backend_direct.cpp.o
In file included from /usr/include/string.h:548,
                 from /home/saber7ooth/Documents/repos/Classic-RBDOOM-3-BFG/neo/idlib/sys/sys_includes.h:141,
                 from /home/saber7ooth/Documents/repos/Classic-RBDOOM-3-BFG/neo/idlib/precompiled.h:34,
                 from /home/saber7ooth/Documents/repos/Classic-RBDOOM-3-BFG/neo/sys/PacketProcessor.cpp:30:
In function ‘void* memcpy(void*, const void*, size_t)’,
    inlined from ‘bool idDataQueue<maxItems, maxBuffer>::Append(int, const byte*, int, const byte*, int) [with int maxItems = 64; int maxBuffer = 8000]’ at /home/saber7ooth/Documents/repos/Classic-RBDOOM-3-BFG/neo/idlib/../idlib/DataQueue.h:112:8,
    inlined from ‘void idPacketProcessor::VerifyEmptyReliableQueue(byte, byte)’ at /home/saber7ooth/Documents/repos/Classic-RBDOOM-3-BFG/neo/sys/PacketProcessor.cpp:660:16:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:33: error: argument 2 null where non-null expected [-Werror=nonnull]
   29 |   return __builtin___memcpy_chk (__dest, __src, __len,
      |          ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
   30 |                                  __glibc_objsize0 (__dest));
      |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:33: note: in a call to built-in function ‘void* __builtin___memcpy_chk(void*, const void*, long unsigned int, long unsigned int)’
cc1plus: all warnings being treated as errors
make[2]: *** [CMakeFiles/DoomBFA.dir/build.make:5690: CMakeFiles/DoomBFA.dir/sys/PacketProcessor.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:174: CMakeFiles/DoomBFA.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
``*

Additional context Here's my version of GCC:

gcc --version

gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

From research, seems to be a compiler bug. Using precomipled headers has no effect. Code should be modified to work around this bug. I'm not a C++ programmer. The comments around this area of PacketProcessor.cpp:

    // drop some stuff that is potentially dangerous and should not transmit
    idDataQueue< MAX_RELIABLE_QUEUE, MAX_MSG_SIZE > clean;
    RELIABLE_VERBOSE( "rollback send sequence from %d to %d\n", reliableSequenceSend, reliable.ItemSequence( 0 ) );
    for( int i = 0; i < reliable.Num(); i++ )
    {
        byte peek = reliable.ItemData( i )[0];
        if( peek < keepMsgBelowThis )
        {
            RELIABLE_VERBOSE( "keeping %d\n", peek );
            clean.Append( reliable.ItemSequence( i ), reliable.ItemData( i ), reliable.ItemLength( i ) );
        }
        else
        {
            // Replace with fake msg, so we retain itemsequence ordering.
            // If we don't do this, it's possible we remove the last msg, then append a single msg before the next send,
            // and the client may think he already received the msg, since his last reliableSequenceRecv could be greater than our
            // reliableSequenceSend if he already received the group of reliables we are mucking with
            clean.Append( reliable.ItemSequence( i ), &replaceWithThisMsg, 1 );
            RELIABLE_VERBOSE( "dropping %d\n", peek );
        }
    }

Considering the code comments referring to malicious packet protection and my lack of experience with C++, best leave it to the experts.

Also side note, libglew1 and libglew-dev are installed, but not found when generatring, I noticed in the cmake-gui. I'm not sure if this is relevant or not.

[loopyd]

Just wanted to update here, I fixed the compiler error by using an older compiler (gcc/g++ 11) without the string_fortified.h bug.

Here are the steps documented:

sudo dpkg --add-architecture i386 && sudo apt-get update
sudo apt-get install g++-11 g++-11-multilib gcc-11 gcc-11-multilib
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-13 13
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-11 11
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-13 13
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 11
echo -e "1\n" | sudo update-alternatives --config gcc
echo -e "1\n" | sudo update-alternatives --config g++
cmake-gui .

Select Retail from combo box. Press Configure and wait. Check ALL_STATIC, ONATIVE, WINDOWS10 and press Configure again. Press Generate Exit cmake-gui

cd ../buildRetail
make -j$(nproc)

Result: It works, and it builds static with ALL_STATIC optimized for your CPU. Output in the buildRetail folder.

Highly recommend get this into docker container. As if user forgets to set compiler back, it can cause issues.

This can be done with:

echo -e "0\n" | sudo update-alternatives --config gcc
echo -e "0\n" | sudo update-alternatives --config g++

[MadDeCoDeR]

Thanks for the report. Sadly due to Ubuntu WSL jerking off with CMake (no, that's not a bad worded phrase) I can't replicate the issue in order to fix it. Again as I mention and in the previous issue YOU DONT NEED TO COMPILE THE LINUX BUILD the nightly builds come with PRECOMPILED EXECUTABLE BINARY which is automatically generated by the github actions

[loopyd]

I would much rather compile things for myself natively for my CPU's instruction set. This is by preference and of course not a requirement, but I do so anyway for that extra 5-10% in performance. Especially for games.

But, thank you for making it easy for folks to download/use. There's no need to Caps-Lock the issue. Once agian wanting to compile from source is definitely by preference.

Speed issues

The game runs extremely fast on my system and gains a 7% performance boost from being built specifically for my CPU's instruction set. Almost too fast...still messing with frame sync settings trying to dial those down as projectiles, enemy AI, and fire rate are increased in speed well beyond stock now...even with vsync on. Its become something I've had to tune thanks to my system being newer. As it increases the difficulty of the original title immensely.

For example:

• Imp fireballs are now 4x fast in projectile travel time and throw rate. Making them aggrivatingly impossible to dodge.
• Security Officers with machine guns/shotguns fire ridiculously fast, rendering their damage output broken and insane. It only takes 3 bursts which last about 1 second for all 3 on Veteran difficulty to wipe your entire armor and health.
• The afformentioned Lost Souls shouldn't be left floating on screen as they will instantly travel toward the player without any travel time.
• Have loaded entire chaingun clips in Pinky. 50 or so rounds required to kill it. Brutal difficulty scaling in this version of the game. Common mobs have noticably more health on higher difficulty settings.

It should be mentioned that I am playing with Ultimate HD -- This mod increases graphical fidelity. It does not change any physics, enemy AI, or rebalance any mobs. What's coming out of the game right now would be as if running stock zBFA.

Despite these issues, I've managed to make it all the way to Comms Transfer while racking up close to 80 deaths....on a new save I tested it on.

Concerns

It isn't stated any where that Classic-RBDOOM drastically increases the base game's difficulty through its increase in speed. So I think this may be a result of optimizing the game for my system.. It seems to run 4x faster than the original (even with VSync on and using a 60 hz monitor, physics run very fast).

Thanks to having experience with FPS, alone, and a complete DOOM 2016/DOOM Eternal Ultra Nightmare playthrough, I'm trained...but I don't recommend this for casuals in current format. The difficulty increase over running this fast is fine for me, but I understand it may not be for more traditional players that want closer to a stock experience...

I think the game itself ingoring the VSync setting has a lot to do with what I had to do to proton prefix in Steam to get achievements to load correctly. I used protontricks here to get the game to work properly. I'm not willing to complain, since I enjoyed it. But I wish we had speed hacks so we could slow physics back down to the original standard on modern systems.

[MadDeCoDeR]

Hi there. The original compiler issue with gcc 13 is now fixed. As for the speed issue, keep in mind that I am aiming for the pre-build binaries to be useable by anyone and for that reason I am not using the ONNATIVE flag. Also I have (hopefully) succesfully optimize the engine to run well without the ONNATIVE flag (so well that the Steam Deck can run the game @60FPS with even less CPU usage than the Windows version under proton)