progress

[RoboCop]

Also I've been looking at your src code and didn't find anything wrong. But I've figured that the optimisation flags may need altered a bit.

-O2 -march=i686 -mtune=generic -msse2 -mfpmath=sse -fomit-frame-pointer -finline-functions \
-falign-loops=2 -falign-jumps=2 -falign-functions=2 -pipe -m32 \

As for Windows builds, I've been using the newer VS 2019 as well been analysing any potential coding issues. It seems possible that the bot.cpp is not dependant on the 'cbase.h' header. Plus my VS2019 gave me some warning messages on 'bot_t::bot_t()' in line 1832 contains uninitialised members, for whatever it means to me... But my ReSharper C++ suggested on the solution to fix that warning message by typing this into this line:-

bot_t::bot_t(): respawn_state(0), bShouldInit(false), skin{}, not_started(0), start_action(0), kick_time(0),
                create_time(0), bot_team(0),
                bot_class(0),
                bot_money(0),
                idle_angle(0),
                idle_angle_time(0),
                blinded_time(0),
                prev_speed(0),
                prev_time(0),
                f_find_item(0),
                pBotPickupItem(nullptr), ladder_dir(0),
                f_start_use_ladder_time(0),
                f_end_use_ladder_time(0),
                waypoint_top_of_ladder(false),
                f_wall_check_time(0), f_wall_on_right(0),
                f_wall_on_left(0),
                f_dont_avoid_wall_time(0),
                f_look_for_waypoint_time(0),
                f_jump_time(0),
                f_dont_check_stuck(0),
                wander_dir(0), f_exit_water_time(0),
                f_waypoint_time(0),
                curr_waypoint_index(0),
                prev_waypoint_index{},
                f_random_waypoint_time(0),
                waypoint_goal(0),
                f_waypoint_goal_time(0),
                waypoint_near_flag(false),
                prev_waypoint_distance(0),
                weapon_points{},
                pBotEnemy(nullptr),
                f_bot_see_enemy_time(0),
                f_bot_find_enemy_time(0),
                pBotUser(nullptr),
                f_bot_use_time(0),
                f_bot_spawn_time(0),
                killer_edict(nullptr),
                b_bot_say_killed(false),
                f_bot_say_killed(0),
                f_sniper_aim_time(0),
                f_engineer_build_time(0),
                sentrygun_waypoint(0),
                b_build_sentrygun(false),
                sentrygun_level(0),
                sentrygun_attack_count(0),
                f_other_sentry_time(0),
                b_upgrade_sentry(false),
                dispenser_waypoint(0),
                b_build_dispenser(false),
                dispenser_built(0),
                dispenser_attack_count(0),
                f_shoot_time(0),
                f_primary_charging(0),
                f_secondary_charging(0),
                charging_weapon_id(0), f_pause_time(0),
                f_sound_update_time(0),
                bBotHasFlag(false),
                b_see_tripmine(false),
                b_shoot_tripmine(false),
                b_use_health_station(false),
                f_use_health_time(0),
                b_use_HEV_station(false),
                f_use_HEV_time(0),
                b_use_button(false),
                f_use_button_time(0),
                b_lift_moving(false),
                b_use_capture(false),
                f_use_capture_time(0),
                pCaptureEdict(nullptr),
                bUseArmory(false),
                fUseArmoryTime(0), points_spent(0),
                bBuild(false),
                fBuildTime(0),
                bBuildAlienResourceTower(false),
                bBuildHive(false),
                bUseDoor(false),
                fUseDoorTime(0),
                iGoalIndex(0),
                current_weapon(), m_rgAmmo{},
                pLightEnt(nullptr),
                fMaxSpeed(0),
                fSpeed(0)

Or by using a different method for Sandbot. Also I've noticed h_export.cpp had depreciation warnings on 'strcmpi' but I think the best way is to add near h_export line 22 is this:-

#ifdef WIN32
#define strcmpi _strcmpi
#endif

Even though those alterations to the code didn't effect the VS2019 compiler as it gave less warning messages, but I cannot guarantee that it will work better for Windows Servers. Besides it was tricky and painful as Sandbot Linux had problems with the CXX ABI errors as having Sandbot not compiled with GCC/G++ 4.8 or earlier caused those CXX ABI errors. Due to the Steam Runtime Libs being outdated, unlike Sven Coop v5 that has most of the up to date libs and its own custom modified Svengine from GoldSrc.

[The Storm]

The C++ runtime can be statically linked to the binary. This will resolve all problems with
the ABI. It will also increase the binary size of the final .so file but nowadays that is really not as issue.

[RoboCop]

@tschumann

Also I've been using the trial version of PVS Studio Analyser on SandBot and spotted a few performance issues here:-

[tschumann]

Originally Posted by RoboCop

Also I've been looking at your src code and didn't find anything wrong. But I've figured that the optimisation flags may need altered a bit.

-O2 -march=i686 -mtune=generic -msse2 -mfpmath=sse -fomit-frame-pointer -finline-functions \
-falign-loops=2 -falign-jumps=2 -falign-functions=2 -pipe -m32 \

As for Windows builds, I've been using the newer VS 2019 as well been analysing any potential coding issues. It seems possible that the bot.cpp is not dependant on the 'cbase.h' header. Plus my VS2019 gave me some warning messages on 'bot_t::bot_t()' in line 1832 contains uninitialised members, for whatever it means to me... But my ReSharper C++ suggested on the solution to fix that warning message by typing this into this line:-

Or by using a different method for Sandbot. Also I've noticed h_export.cpp had depreciation warnings on 'strcmpi' but I think the best way is to add near h_export line 22 is this:-

#ifdef WIN32
#define strcmpi _strcmpi
#endif

Even though those alterations to the code didn't effect the VS2019 compiler as it gave less warning messages, but I cannot guarantee that it will work better for Windows Servers. Besides it was tricky and painful as Sandbot Linux had problems with the CXX ABI errors as having Sandbot not compiled with GCC/G++ 4.8 or earlier caused those CXX ABI errors. Due to the Steam Runtime Libs being outdated, unlike Sven Coop v5 that has most of the up to date libs and its own custom modified Svengine from GoldSrc.

Thanks - why remove -mmmx and -msse though? Are they implied by something else?
There's an init function that sets all those things that the constructor should set - it's a change I'll get around to sooner or later. There's plenty of messy and non-performant code that I want to fix but I've been concentrating on features for now (converting HBP Bot which was mostly C to C++ is still in progress).

Originally Posted by The Storm

The C++ runtime can be statically linked to the binary. This will resolve all problems with
the ABI. It will also increase the binary size of the final .so file but nowadays that is really not as issue.

Yeah I couldn't figure out how to do this last time I looked into it.

Originally Posted by RoboCop

@tschumann

Also I've been using the trial version of PVS Studio Analyser on SandBot and spotted a few performance issues here:-

I'm not sure about some of those changes - they may be possible but for safety I think the declarations are compatible with how the engine has them declared.

[RoboCop]

Well I wasn't sure if adding MMX and SSE were necessary as well as adding too many opt flags as well as using -O3 could cause some adverse effects as well increase the build size. As for using like -march=pentium4 or higher may not be compatible with the old GoldSrc engine as it was released since 1997/1998 and maybe pushed to it's limit. Also some older compilers like GCC 4.8 appear to recompile those builds in a smaller size but won't have the latest C++14 nor C++17 standard features - if I am not mistaken.

[The Storm]

@tschumann It's a bit tricky for GCC but not hard. Locate the 32bit version of libstdc++.a file on your system and copy it on the same location where your Makefile is, then add -L. to the linker flags. Thats all.

@RoboCop You've got it wrong about optimization flags. It does not matter if the engine is compiled with or without these flags, the only thing that matters is if the target CPU supports them. MMX and SSE are pretty common in modern CPUs and even in CPUs that are 10 years old. Of-course one should be careful with the newer revisions of these instructions such as SSE3 and SSE4.x as these are not available on the 10 years old CPUs.

Also -03 may increase the build size but it optimize much more on performance which is good. Modern HDDs are not 20MB so the size does not matter that much. However -03 is not recommended for legacy code base until all warnings that the compiler outputs on the highest warning level are not fixed(this does NOT include 3rd party static analyzers). That's because -03 is much more aggressive(but conforming) to optimizations and many bugs that are caused by code that is somewhat in the category undefined behavior(like signed integer overflow for example) will pop up.

[tschumann]

Originally Posted by RoboCop

Well I wasn't sure if adding MMX and SSE were necessary as well as adding too many opt flags as well as using -O3 could cause some adverse effects as well increase the build size. As for using like -march=pentium4 or higher may not be compatible with the old GoldSrc engine as it was released since 1997/1998 and maybe pushed to it's limit. Also some older compilers like GCC 4.8 appear to recompile those builds in a smaller size but won't have the latest C++14 nor C++17 standard features - if I am not mistaken.

Yeah The Storm is right - it doesn't matter what the engine uses. Not sure how much of the instruction set extensions this sort of code would use though, or whether optimising for size or speed is better.

Originally Posted by The Storm

@tschumann It's a bit tricky for GCC but not hard. Locate the 32bit version of libstdc++.a file on your system and copy it on the same location where your Makefile is, then add -L. to the linker flags. Thats all.

Ah makes sense - thanks! When I went searching last year I really couldn't find any useful information.

[The Storm]

Well, actually it does not makes sense, because the GCC compiler is always choosing the dynamic C++ runtime if it sees them both in the same directory, regardless of staticlib flags. This trick is just bringing the static file in the first search path, so the compiler have no choice but to use it.

[tschumann]

Ah okay - that's probably why it didn't work last time.

[tschumann]

Okay, a question for those who know g++ and Makefiles better than I do - where do I put -Wall -Wextra -Werror etc and have warnings get displayed etc? I tried putting them in various places but things which should have generated warnings (assigning 256 to char for example) did not.