eukara
commented
1 year ago Technically that's a feature request for the engine, FTEQW and not FreeHL - as this project is merely game code. FTEQW does have a software rasterizer (it's used only for the DOS build, which may have regressed - been a while since I checked but it'd build with DJGPP) but due to the way the renderer is set-up to deal with triangles it does very slow sorting and rendering of triangles.
The original Quake SW renderer had its own specialized routine for drawing world and non-world models (you can find those in the original src tree by looking for 'spans' for world and 'alias' for non-world models respectively). None of that code is there anymore and as it wouldn't work well with the material heavy workflow that games like Quake III Arena make use of (and many mod/game developers rely upon).
The undertaking required for giving FTEQW a good, usable SW renderer would be quite extreme as a result. However, using a software implementation of OpenGL 1.X does perform well enough - even on old hardware that cannot do any type of OpenGL. If you don't have any 3D accelerator of any kind, then you can still either force Mesa (on UNIX-like systems) or install a Software implementation of OpenGL for your target platform. Windows 95 does the same thing when you are not running it with a 3D accelerator (otherwise most of its screensavers won't work!) since it ships with a primitive implementation of GL in software as a fallback.
FTEQW will support the OpenGL 1.X rendering path for many years to come, so any basic GL implementation in either soft or hardware should do fine.
CaptainMuskrat
Shpoike
I would like to request the addition of a software renderer for FreeHL in the future, as well as an Appimage binary for ease-of-use and better maintenance.
The first request may seem a tad strange, after all GPUs are prevalent nowadays especially if you are a serious gamer, however software rendering has numerous advantages (and disadvantages), though from my point of view its advantages prevail. Firstly I will admit that it's much slower than GPU graphics -- GPUs are designed to perform graphics-specific operations very quickly and, more importantly, they can process many pixels (and other elements) in parallel, while a CPU has to compute pixels sequentially one by one and that in addition to all other computations it is otherwise performing. This causes a much lower FPS count. For this reasons SW rendering is also normally of lower quality (lower resolution, nearest-neighbour texture filtering, ...) to allow workable FPS. Nevertheless thanks to the ginormous speeds of today's CPUs, simple fullscreen SW rendering can be pretty fast on PCs and achieve even above 120 FPS on older renderers found in Quake and Unreal; on slower CPUs (typically embedded hardware) SW rendering is usable normally at around 30 FPS if resolutions are kept small.
On the other hand SW rendering is more portable, as it can be written purely in a portable language such as C, is less bloated, and eliminates the dependency on GPUs so it will be supported almost anywhere as every computer has a CPU, while not all computers such as embedded devices have a GPU (or, if they have it, it may not be sufficient, supported or have a required driver. SW rendering may also be implemented in a simpler way and it may be easier to deal with as there is e.g. no need to write shaders in a special language, manage transfer of data between CPU and GPU or deal with parallel programming. SW rendering is the "KISS" approach (Keep It Simple Stupid)
This is what I understand from my research, and I feel it would be useful for the long-term health of this project. To ensure FreeHL is made as portable and flexible as possible.