-
Notifications
You must be signed in to change notification settings - Fork 0
/
PGE-WoW.txt
222 lines (161 loc) · 13.2 KB
/
PGE-WoW.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
/*
###################################################################################
PGE-WoW.txt
Way of Working snippets for PGE
###################################################################################
*/
Note: for configuring WSL and CMake stuff, see: https://github.com/proof88/PRooFPS-dd/issues/9
0) Projects and Dependencies
This is a multi-project solution.
All projects are in 1 solution: PGE-misc.
The reason why the whole solution is called PGE-misc is that the main project here is PGE and the other
projects are side projects needed to be created for PGE during development.
Update in 2023: the primary project now is PRooFPS-dd, a game using PGE.
Project dependency tree (with the build output formats):
- SoLoud (.lib)
- PFL (.lib)
- CConsole (.lib)
- PGE (.lib)
- gfxcore2 (.dll) (notice multiple runnables explained later in 1))
- GGame (.exe) (not published on GitHub so it might be absent)
- ELTE-FAIL (.exe)
- PRooFPS-dd (.exe)
- UnitTests (.exe)
Build order is from top left to bottom right.
So CConsole depends on PFL, PGE depends on SoLoud, CConsole and PFL, etc.
ELTE-FAIL, gfxcore2, PRooFPS-dd and UnitTests can be built in parallel since they have the same dependencies.
We have the following repos:
- PFL
- Console
- PGE (this includes copied source code of both GameNetworkingSockets and SoLoud libraries)
- gfxcore2
- ELTE-FAIL
- PGE-misc (for solution and other textfiles like this txt)
- PR00FPS (legacy Delphi project from 2007, not part of the solution)
- PRooFPS-dd (new project being worked on in 2022)
- proof88.github.io - online form of documentation
So as seen above, almost every project has its own repository.
Exceptions:
- SoLoud project, it lies in the same repo as PGE.
- UnitTests project, it lies in the same repo as PGE.
I highly recommend cloning them separately into the same directory!
---
1) Build
Currently supported under Windows.
My projects are written in C++.
I try to stick to ISO-C++ and avoid any MSVC-specific stuff.
Some of my projects require C++17 compiler, some require older. You don't need to configure anything! You just need Visual Studio installed and it can
handle all my debug and release mode project settings.
Note that due to the different compiler and linker settings used across projects, it might happen that you either cannot build everything properly with
a different version of Visual Studio, or you experience unexpected exception raised during running the debug build of any of the projects.
I can successfully build all my projects with this exact version, so this is what I recommend:
Visual Studio 2022 Community Edition (64-bit) Version 17.5.5.
Sometimes I upgrade VS and verify everything is working. If not, I fix the issues so all my projects could be built with the latest version of Visual Studio.
As described in section 0 above, all relevant Visual Studio projects are tied together in a single solution called: PGE-misc.
Due to dependencies, it is highly recommended to load the PGE-misc solution in Visual Studio and initiate any build from that point!
For that you need to clone most of the repositories as described in section 0 above, the better if you clone all of them before doing anything!
When you load up the PGE-misc solution in Visual Studio, you might see error messages about the missing GGame project. You can ignore it, nothing depends on it.
I never published GGame on Github, it is just an old project of mine.
Since the project dependencies are correctly set (except for GameNetworkingSockets which needs to be built separately for first time), building all projects is very easy:
one click in Visual Studio, and all projects will be built in the required order considering their dependencies.
If you have just freshly cloned the repositories and want to build the PGE library from first clean state, you need the following library available:
- GameNetworkingSockets.lib - you can build it as described below. This need to be built only once on your computer.
GameNetworkingSockets is linked dynamically, which means that in order to run PGE-based applications, you need:
- GameNetworkingSockets.dll
- libcrypto-3.dll
- libprotobuf[d].dll (you will have the 'd' at the end in case of debug build only)
These are also built as described below, need to build only once on your computer.
GameNetworkingSockets building is officially explained in Network/GameNetworkingSockets-1.4.0/BUILDING.md.
If you want to skip reading BUILDING.md, here is how I do the first time I build GameNetworkingSockets:
First the VCPKG-related stuff needs to be set up (only once on your computer):
- start Visual Studio;
- start Visual Studio Command Prompt from Visual Studio's Tools menu;
- in Visual Studio Command Prompt, go to main directory of GameNetworkingSockets, e.g.: "cd PGE/Network/GameNetworkingSockets-1.4.0";
- execute: "git clone https://github.com/microsoft/vcpkg"
If git is not known, you should set your PATH environment variable properly to contain path to your installed git:
this is how to change your PATH environment variable:
https://stackoverflow.com/questions/4492979/error-git-is-not-recognized-as-an-internal-or-external-command
You can specify Visual Studio's git directory,
e.g.: "c:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw64\bin\"
Note: you need to log out and log in again for the new environment variable setting to take effect!
- after successful cloning, execute: ".\vcpkg\bootstrap-vcpkg.bat";
- execute: ".\vcpkg\vcpkg install --triplet=x64-windows" (this will take a while, this is the longest step, ~15-20 minutes);
Now you have all VCPKG-stuff set-up, you dont need to do this again on your computer.
Next step is to actually build GameNetworkingSockets (only once on your computer):
- still in Visual Studio Command Prompt, execute: "cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo"
(this will take a while, this is the longest step, ~10 minutes);
- by default Debug build is built, but you can override it with defining CMAKE_BUILD_TYPE as shown above, for Release build I recommend using RelWithDebInfo;
- then execute: "cd build";
- then execute: "ninja".
Now you have successfully built GameNetworkingSockets, you don't need to do this steps again on this computer!
The required DLL files are placed in PGE/Network/GameNetworkingSockets-1.4.0/build/bin directory.
Please copy them to any project directory that needs it (e.g. for PRooFPS-dd, copy it into: PRooFPS-dd/PRooFPS-dd directory).
Note that "NAT traversal through google WebRTC's ICE implementation" is working only if USE_STEAMWEBRTC=ON is also defined, e.g.:
"cmake -S . -B build -G Ninja -DBUILD_EXAMPLES=ON -DBUILD_TESTS=ON -DUSE_STEAMWEBRTC=ON"
This didn't work for me because I failed to update some submodules with "git submodule update" command, so manual cloning of
some subrepos may help, but then I had wrong paths in webrtc stuff, probably I cloned webrtc from wrong place or wrong version ...
Anyway including WebRTC would take an evening for sure, so I postponed it for the future.
Important: GameNetworkingSockets is configured to be built with external linkage to MSVC runtime lib, so if we want to run it
on a machine not having VS installed, we need to provide the MSVC runtime as well. Recommendation is to handle the
MSVC 2022 Runtime Installer to the user.
Other notes irrelevant to GameNetworkingSockets below.
PRooFPS-dd uses Debug, Release and DebugTest_PRooFPS-dd configurations.
DebugPR00FPS and ReleasePR00FPS configurations are for the legacy PR00FPS, please do not mix them up with PRooFPS-dd stuff!
DebugTest_PRooFPS-dd configuration is for running unit tests for PRooFPS-dd: it defines the TESTING macro used by PRooFPS-dd project to decide which
WinMain() to be used: either the one in PRooFPS-dd.cpp or the other in PRooFPS-dd-Tests.cpp.
Unit tests for PFL and PGE use the basic Debug or Release configuration shared with other projects.
The SoLoud audio library has multiple Visual Studio Projects under PGE/Audio/soloud-RELEASE_20200207/build/vs2017, however the only relevant project file is SoloudStatic.vcxproj and that is added to this PGE-misc solution with proper dependency setting, which means that the required soloud_static_x86.lib (or soloud_static_x86_d.lib for debug build) is automatically built before PGE project is being built.
Build time measurements of PRooFPS-dd from clean state (including building the other projects on which PRooFPS-dd depends, Debug configuration):
Machine 1: 55 sec (Core i5 4570 3.2 GHz (turbo 3.6 GHz), 2x 8 GB 1833 MHz CL10 DDR3, Crucial MX500 500GB SSD SATA)
Machine 2: 120 sec (C2D E7300 2.66 GHz, 2x 1 GB 800 MHz DDR2 CL6, Kingston KC600 256GB SSD SATA)
Machine 3: 50 sec (Core i5 8250U HT 1.6 GHz (turbo 3.4 GHz), 2x 4 GB 2666 MHz DDR4, Adata XPG SX6000 Pro 256GB SSD M.2 2280 PCIe NVMe)
---
2) Different Runnables
A project may have multiple configurations, that could mean not only Release and Debug outputs but also executing different runnables.
Currently the only project having multible runnables is gfxcore2:
- configurations with name EV2008P03* will build gfxcore2.dll, copy it to EV2008P03 sample directory and run EV2008P03 sample;
- both Debug and Release versions of this configuration will do these same actions, but obviously compiler and linker settings are different according to name;
- configurations DebugPR00FPS and ReleasePR00FPS will build gfxcore2.dll, copy it to PR00FPS directory and run PR00FPS;
- Debug and Release settings for compiler and linker obviously don't affect the existing legacy PR00FPS build since that is a Delphi project, we leave it untouched,
so if you want Debug or Release build of the legacy PR00FPS, you need to solve that from Delphi.
Even though EV2008P03Debug, EV2008P03Release, DebugPR00FPS and ReleasePR00FPS are valid project configurations for other projects such as UnitTests, there they
act like the project's simple Debug or Release configuration: build&run the given project, not a sample runnable or PR00FPS.
---
3) Documentation
Documentation can be generated with Doxygen (https://www.doxygen.nl/index.html).
There are multiple project files that can be used with Doxygen in PGE\PGE\Docs\ directory:
- PURE_Doxyfile_external - this is for PURE end-users who are interested in API usage only;
- PURE_Doxyfile_internal - this is for PURE developers who are interested more in the engine and its internals.
Both use PGE_DoxyLayout.xml as layout file.
When using PURE_Doxyfile_external, during documentation build process doxygen will print a lot of warnings like:
- no uniquely matching class member found for (...);
- documented symbol (...) was not declared or defined.
These are expected warnings. The reason is that we also use the source cpp files for documentation since the detailed
description of member functions are there, but we dont include the internal header files and we also exclude some
symbols such as all Impl classes. This is not affecting the quality of the external documentation since we just try
to hide as much internal stuff as we can. These warnings are not present with the PURE_Doxyfile_internal since there
we don't want to hide any internal stuff.
As you can see, all stuff required to generate either internal or external documentation is in PGE directory.
However, there is a separate repo called proof88.github.io, which contains generated internal documentation.
The content is updated at every major PGE or Pure version release and available online at: https://proof88.github.io/pure-doc/index.html .
---
4) PureAllHeaders.h and PGEallHeaders.h should be included in EVERY SINGLE Pure header file
5) PureAllHeaders.h and PGEallHeaders.h MUSTN'T include anything
6) include/internal/PurePragmas.h and PGEpragmas.h MUSTN'T be included in any header files.
They should be included in cpp files only.
7) We have EXTERNAL and INTERNAL header files.
EXTERNAL headers are public, meaning that they will be delivered
to API-users as well, so they should contain as minimal info about internals as they can.
INTERNAL headers are private headers, used for compiling the library, etc. They MUSTN'T be included in EXTERNAL headers.
8) PGEconsts.h and PureConsts.h are INTERNAL headers thus MUSTN'T be included in EXTERNAL headers.
---
I) adding support for a new TC (texture compression) in Pure
1. - new enum(s) should be added to both TPURE_TEX_COMPRESSION_MODE and TPURE_TEX_FORMAT
2. - texture format enum(s) should be handled in both PureTexture::DescribeTexFormatAndSize() and PureTexture::getTargetInternalFormat()
3. - PureHwVideoDiscoverOpenGL_1_3::DiscoverTextureCompressionAvailability() should be also updated with checking for the new TC
4. - creating textures in unit tests with the new TC is not neccessarily needed but testGetInternalFormat() should handle them when PURE_TC_AUTO is used:
tex128x128x24_cmpAUTO and tex128x128x32_cmpAUTO cases.
testGetUsedTextureMemory() should be also updated when the compression ratio is different than the already checked ratios (1:4, 1:8) for the cmpAUTO cases
mentioned above.
5. - update relevant comments regarding to the TC. For example, if borders are supported by the TC or not: PureTextureManager::setDefaultCompressionMode().
II) ...