r.a.sattarov
-
Posts
7 -
Joined
-
Last visited
Posts posted by r.a.sattarov
-
-
23 minutes ago, lowenz said:
If you have VSync enabled it's perfectly normal to get 60 FPS.
Thanks a lot
Confused that in Windows this option is set to off, but there by default 60 fps (and with "Uncap FPS = OFF" too).
-
Hello to everyone!
Found an interesting behavior in Linux related to the FPS counter in menu (and in game)
On Linux (by default), the FPS counter is kept at around 50.
If enabled option "Uncap FPS", then FPS will be 60. And the option "Max FPS" has no effect on this number of FPS.
Linux computer configuration:
cpu: AMD Ryzen 5 2600 (6 core, 3.4GHz)
ram: 16Gb
video card: AMD Radeon R9 280
OS: Xubuntu 20.04 (Linux 5.4.0-33, Mesa 20.0.4, amdgpu driver)Checked this behavior in version 2.08_beta-007 (build 8755).
-
25 minutes ago, stgatilov said:
Which GPU exactly it has? Which version of OpenGL it supports?
Do I understand it right that you have physical access to the machine, and in theory you can run the game (if everything is OK) ?
I have access to "Elbrus 801-PC". It comes with a AMD Radeon R5 230 graphics card (OpenGL 4.1). But various AMD Radeon graphics cards can be used (e.g. Radeon RX 580 with OpenGL 4.5 and Vulkan).
Ref: http://www.ineum.ru/elbrus_801-pc_gen4
23 minutes ago, stgatilov said:And by the way, do you try to compile it for x86 architecture or for Elbrus architecture?
I have successfully compiled RBDOOM-3-BFG for e2k architecture. And I have made some changes to the source code of the game to initially support this architecture.
Ref: https://github.com/RobertBeckebans/RBDOOM-3-BFG/pull/432
33 minutes ago, stgatilov said:The Doom 3 code was pretty much tied to the specifics or x86 architecture, and I guess nobody had time to clean this up.
ARM64/Aarch64 architecture support has recently been added (for the Nvidia Jetson board).
Ref: https://github.com/RobertBeckebans/RBDOOM-3-BFG/pull/473
-
5 hours ago, duzenko said:
I use PDK "OS Elbrus 5" (based on Linux 4.19 kernel) with AMD Radeon GPU (amdgpu driver).
-
1
-
-
6 hours ago, stgatilov said:
The check for C++ standard is both unnecessary and incorrect.
The support for C++14 in Visual C++ compiler is not tied to -std=c++14 keyword (which is not supported, I guess). I think CMake added special keywords for C++ standard exactly for this reason: different compiler implement this setting differently. And according to documentation, CXX_STANDARD_REQUIRED should already produce an error if C++14 is not supported. So I'd better not add an explicit check and more code.Understood. I did not know that such a check appeared in CMake
6 hours ago, stgatilov said:By the way, does LCC support C++? And C++14 in particular?
The current version of the MCST lcc compiler (version 1.24.10) fully supports C++03, C++11, C++14 standards and has experimental support of C++17. This compiler has a nominal compatibility with g++-7.3.0. The compiler (by default) has the -std=gnu++14 mode enabled (C++14 with gnu extensions). Also, it can compile with using of Intel Intrinsics
6 hours ago, stgatilov said:Did you manage to build the engine in the end?
No, I was able to compile only at 88%
After fixing in /ThirdParty/artefacts/devil/include/IL/il.h file, there was a problem with the /idlib/math/Simd.cpp file. It contains "#include <cpuid.h>" string. There is no such header file on e2k.
Can you modify this file, similar to how it is done in RBDOOM-3-BFG (and with adding "USE_INTRINSICS" option)?
Ref: https://github.com/RobertBeckebans/RBDOOM-3-BFG/blob/master/neo/idlib/math/Simd.cpp
RBDOOM-3-BFG compiles on e2k without problems (and runs very well).
7 hours ago, stgatilov said:So if this change is applied as is, it will persist until someone decides to rebuild DevIL and commits new artefacts. Which probably won't happen soon though.
Yes, such a change in the source code would be very helpful for e2k.
-
Hello everyone!
I made 2 changes in the source code. Could you, please, take a look at this?
- CMake: Added check of compiler for support C++14 standard
CXX_STANDARD supported values are 98, 11, 14, 17 and 20.
Ref: https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html
- ThirdParty/devil: fix for MCST lcc compiler
LCC-Win32 and MCST lcc compilers define same identifier (LCC).
Have been added check of MCST Elbrus 2000 (e2k) architecture.Ref: https://en.wikipedia.org/wiki/Elbrus_2000
Attached the patch with my changes.
-
1
-
Pull Request: platform_linux.cpp - added alternative method to get s_numPhysicalCPUCores value
in I want to Help
Posted · Edited by r.a.sattarov
Added alternative method to get s_numPhysicalCPUCores value, when parsing /proc/cpuinfo fails (usable for non-x86 CPU, e.g. for MCST e2k architecture).
These changes was accepted in RBDoom3-BFG
- https://github.com/RobertBeckebans/RBDOOM-3-BFG/pull/478
platform_linux_cpp.diff