.:: Bots United ::.  
filebase forums discord server github wiki web
cubebot epodbot fritzbot gravebot grogbot hpbbot ivpbot jkbotti joebot
meanmod podbotmm racc rcbot realbot sandbot shrikebot soulfathermaps yapb

Go Back   .:: Bots United ::. > Cyborg Factory > Sandbot
Sandbot A bot for Gunman Chronicles and They Hunger - by tschumann

Reply
 
Thread Tools
Re: progress
Old
  (#181)
RoboCop
vBulletin Veteran
 
RoboCop's Avatar
 
Status: Offline
Posts: 172
Join Date: Feb 2013
Location: Dundee, Scotland
Default Re: progress - 3 Weeks Ago

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.

Code:
-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:-

Code:
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:-

Code:
#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.





vBulletin Webmaster since 2001
  
Reply With Quote
Re: progress
Old
  (#182)
The Storm
Council Member / E[POD]bot developer
 
The Storm's Avatar
 
Status: Offline
Posts: 1,611
Join Date: Jul 2004
Location: Bulgaria
Default Re: progress - 3 Weeks Ago

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.
  
Reply With Quote
Re: progress
Old
  (#183)
RoboCop
vBulletin Veteran
 
RoboCop's Avatar
 
Status: Offline
Posts: 172
Join Date: Feb 2013
Location: Dundee, Scotland
Default Re: progress - 3 Weeks Ago

@tschumann

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

Name:	sandbot.jpg
Views:	8
Size:	458.6 KB
ID:	1327  





vBulletin Webmaster since 2001
  
Reply With Quote
Re: progress
Old
  (#184)
tschumann
Moderator
 
tschumann's Avatar
 
Status: Offline
Posts: 235
Join Date: Apr 2011
Location: Australia
Default Re: progress - 2 Weeks Ago

Quote:
Originally Posted by RoboCop View Post
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.

Code:
-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:-

Code:
#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).

Quote:
Originally Posted by The Storm View Post
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.

Quote:
Originally Posted by RoboCop View Post
@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.
  
Reply With Quote
Re: progress
Old
  (#185)
RoboCop
vBulletin Veteran
 
RoboCop's Avatar
 
Status: Offline
Posts: 172
Join Date: Feb 2013
Location: Dundee, Scotland
Default Re: progress - 2 Weeks Ago

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.





vBulletin Webmaster since 2001
  
Reply With Quote
Re: progress
Old
  (#186)
The Storm
Council Member / E[POD]bot developer
 
The Storm's Avatar
 
Status: Offline
Posts: 1,611
Join Date: Jul 2004
Location: Bulgaria
Default Re: progress - 2 Weeks Ago

@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.
  
Reply With Quote
Re: progress
Old
  (#187)
tschumann
Moderator
 
tschumann's Avatar
 
Status: Offline
Posts: 235
Join Date: Apr 2011
Location: Australia
Default Re: progress - 2 Weeks Ago

Quote:
Originally Posted by RoboCop View Post
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.

Quote:
Originally Posted by The Storm View Post
@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.
  
Reply With Quote
Re: progress
Old
  (#188)
The Storm
Council Member / E[POD]bot developer
 
The Storm's Avatar
 
Status: Offline
Posts: 1,611
Join Date: Jul 2004
Location: Bulgaria
Default Re: progress - 2 Weeks Ago

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.
  
Reply With Quote
Re: progress
Old
  (#189)
tschumann
Moderator
 
tschumann's Avatar
 
Status: Offline
Posts: 235
Join Date: Apr 2011
Location: Australia
Default Re: progress - 1 Week Ago

Ah okay - that's probably why it didn't work last time.
  
Reply With Quote
Re: progress
Old
  (#190)
tschumann
Moderator
 
tschumann's Avatar
 
Status: Offline
Posts: 235
Join Date: Apr 2011
Location: Australia
Default Re: progress - 1 Week Ago

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.
  
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
vBulletin Skin developed by: vBStyles.com