Software Renderer + Appimage binaries for Linux

[CaptainMuskrat]

Software Renderer + Appimage binaries for Linux

[eukara]

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.

[eukara]

And as for AppImage support - that'd be more related to FTEQW again. It'd also be very awkward as we cannot distribute any content to go along with it (so you'd still be dealing with lose files anyhow). The builds for FTEQW on the website at https://www.fteqw.org are already statically linked against all dependencies that the engine has and are deliberately compiled against an older libc to help compatibility.

But still, creating AppImages for it may still be an avenue worth exploring for FTEQW considering @Shpoike also is working on Flatpak support.

[CaptainMuskrat]

Thank you for the detailed reply. I heard of a Quake engine that features a brand new custom software renderer, known as Retroquad. It's not completely finished, but the author likes to showcase it's superior rendering to the stock one found in Quake, as well as that of Unreal. He intends for it to be usable for original games as well. It appears to be very capable and competent.

https://www.moddb.com/engines/retroquad
https://www.youtube.com/@mankrip-

I understand it may be too late to switch engines, but my primary concern is the long-term viability of FreeHL once OpenGL is completely deprecated and loses support, even on Linux systems. It's already been phased out of the Apple ecosystem years ago, and if hardware vendors and software developers have their way, we'll be looking at a very fractured and cumbersome ecosystem in the near future. While OpenGL can indeed do software rendering, what I'm thinking of is something standalone and independent of any third-party API. Half-Life as a game really doesn't need more hardware power than what modern CPUs can provide, and it would be interesting to see just how lean and optimised the codebase can get if GPUs were off the table. Perhaps I'm alone in having this curiosity, but I just wanted to bring it up nonetheless.

And on a completely unrelated note, is there any plan to eventually replace all proprietary assets with free alternatives, like in FreeDoom?. This may be more difficult given Half-Life's greater focus on storytelling, but I feel a similar plot can be conveyed, especially with the possibility of using A.I voices.

[Shpoike]

1. setrenderer "d3d11 warp" achieved 200fps at 1920x1080 last time I tried it on this 13-year-old cpu, something I wouldn't be able to rival.
2. stuff like mesa/pixelflinger/lavapipe/warp have a greater awareness of the os and general system than any generic code I would end up writing would have. (I'm too lazy to learn every sse/avx/neon extension and use them properly on each system)
3. such implementations tend to be ubiquitous enough that the extra dependency is not much of a concern.
4. even if I were able to rival their framerates, I'd also need to rival their featuresets too.
5. they have bigger teams, willing to spend far more time on improving them.

regarding apple trying to kill off opengl so they don't have to bother writing competitive drivers... zink, angle, moltengl, etc can all translate opengl usage to other rendering apis.
meanwhile fteqw itself is able to render directly via vulkan, or d3d on windows, or gles etc, so I wouldn't worry about that perspective. worst case some installer just needs to bundle an additional dependency.

aesthetics is a different matter, but also kinda irrelevant when you have glsl able to do stuff like r_softwarebanding 1.

[CaptainMuskrat]

What do you think of TinyGL?.

https://github.com/C-Chads/tinygl

[Shpoike]

Subset of GLX for easy testing with X Window.
compile it as a shared object, set gl_driver to name said shared object. see if it works.
fte should be capable of working on gl1.1 contexts, but gl(es)2 is required for the 'full' feature set. frankly gl1.1 is just too limited to be relevant. its not even complete, so there's likely to be significant chunks missing that eg q3-level stuff would depend upon.