<== Continued from previous post
HLAM's user code currently uses OpenGL 1.1, typically referred to as immediate mode. Pretty much anyone using a graphics card made this century can run it, though performance may vary. Qt5 uses OpenGL 3 features but they are optional.
Qt itself uses OpenGL through an abstraction layer that exposes the OpenGL ES (OpenGL for Embedded Systems, aka mobile devices) 2 and 3 APIs.
This abstraction has multiple implementations. By default Qt tries to pick an OpenGL implementation that provides the most complete support. If your driver supports OpenGL 3 then it will use desktop OpenGL. Otherwise it will fall back to using Google's ANGLE
library to provide support, which means it may use Direct3D under the hood. It's also possible to use a Software implementation.
HLAM's user code (model rendering code) doesn't use Qt's API for OpenGL rendering. It instead uses a library called GLEW (OpenGL Extension Wrangler). This library works only with desktop OpenGL, which means HLAM requires the use of desktop OpenGL.
The use of this library caused some problems because some users have a graphics card that doesn't support OpenGL well enough, causing Qt to use ANGLE instead of desktop OpenGL which broke things.
HLAM currently forces the use of desktop OpenGL. I plan to remove GLEW and rely on Qt's API for OpenGL to allow the use of ANGLE which should ensure maximum compatibility.
Independently of this change i will also be rewriting the graphics code to use modern OpenGL (using shaders, retained mode). This means the minimum requirement will be OpenGL 3.3.
Although OpenGL 3.3 was released in 2010 the first graphics cards to support it were released in 2007:
Intel integrated cards lagged behind, the first card to support 3.3 and newer on Windows was released in 2012: https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Gen7
Requiring OpenGL 3.3 means you'll need a graphics card made in the last 15 years. To put that into perspective, it's like requiring a Voodoo 3 card in 2014: https://en.wikipedia.org/wiki/Voodoo3#Models
Because there are some users whose systems don't support OpenGL 3.3 i will hold off on making that change until i've done a bunch of other work first. There is a lot of refactoring, user interface and bug fixing work that needs doing so i'll do that first. I'll leave the switch to shaders until after that point.
Unfortunately it is not possible to support both versions of OpenGL. Immediate mode and retained mode are very different in how they work. I've also looked into supporting OpenGL 2.0 as a fallback, but the differences between that and 3.3 are significant enough that supporting both at once is a very complicated task.
As with Windows i don't want to raise the system requirements, but the use of immediate mode makes adding features that require graphics support more difficult. Performance issues on newer cards that don't support immediate mode well are also an issue, and the use of such an old API can cause the driver to switch to less efficient ways of handling things behind the scenes (which is one of the reasons why Vulkan exists).
OpenGL 3.2 added the concept of core and compatibility contexts. Compatibility contexts allow the use of immediate mode while core contexts do not. I expect that immediate mode and everything that interacts with it will suffer from performance issues, now or in the future. OpenGL 2.0 shaders were built on top of immediate mode, so i expect that to run into problems as well at some point.
I want to make sure this program continues to function correctly and efficiently for a long time, so using OpenGL 3.3 is the best option here, at least for the foreseeable future.
Qt6 introduced a new API called QRhi (in preview in Qt5, and some of the tools are restrictive in license) that allows you to switch between OpenGL 3, OpenGL ES 2, D3D11 and Vulkan. If and when HLAM upgrades to Qt6 this API could be used to allow users to pick the backend that performs best. Hopefully this would also allow users to sidestep issues with APIs no longer being fully supported.
I'm not planning to do this at this time since it requires Qt6. The licensing seems to have changed, but only for Qt6.3 onwards. It's something to keep in mind for the future. I expect that the amount of work won't be anywhere near the amount required for the move from immediate mode to shaders since QRhi supports OpenGL 3 and uses cross-compiling to convert shaders.
There have been a few requests for an Android version. I've said in the past that an Android version would require at minimum a working Linux version and shaders. I've looked into this further to determine whether is it viable to provide an Android version.
Making a native program work on Android requires the use of a Java wrapper. This is mostly automated for Qt CMake projects from what i've found so it shouldn't be a problem, but it does add some complexity.
HLAM depends on third party libraries. These have to be available on Android for the program to work. Qt5 supports Android and OpenAL-Soft provides Android support, though it appears it has to be built manually.
A recent issue seems to have popped up that makes targeting newer versions of Android (Android 11, released almost 2 years ago) more difficult when using Qt: https://bugreports.qt.io/browse/QTBUG-91255
Since Qt5.15 is no longer supported for non-commercial licensees this is possibly a deal-breaker. Qt6 would be required for HLAM to target newer Android versions.
HLAM is designed for use in desktop environments. Android requires a completely new user interface to rely on touch-screen input. I doubt it will be possible to provide the entire interface.
I suspect all users requesting an Android version are doing so because they are playing Half-Life using Xash for Android. Xash uses a slightly modified version of the Studiomodel format that makes it incompatible with HLAM. HLAM loads models and converts them to allow them to be edited. Since Xash re-purposes unused data this causes the program to crash.
My solution for this will be to add a means of detecting this format and forwarding users to Paranoia 2 Model Viewer if they have it installed and HLAM is configured to know of its location. In the long term, if and when a plugin system is added it may be possible to load these models in HLAM directly but that's not possible at this time because Xash is GPL-licensed, which would require HLAM to also be GPL-licensed.
HLAM still uses Half-Life SDK code (slowly getting refactored out, almost all of the remaining code will be replaced with the shader update) and is intended to be MIT licensed (which i need to sort out as well), so Xash's code can't be used here. I'm not a lawyer, so i don't know under what conditions it is possible to use that code here. The research i've done is inconclusive about this.
Although Xash for Android requires the original game to be installed along with models that don't include the new data, there is no way to know just how many models use the unmodified format and how many don't. An Android version could be completely useless if a significant number of models can't be loaded.
I also don't have an Android tablet to work with, only a phone which limits my ability to develop and test such a version.
Lastly, there have been only a handful of these requests. Developing an Android version is a lot of work, and justifying it considering the small number of requests is difficult. There is a lot of work needed elsewhere such as adding support for other model formats and other asset types (hence the name) so an Android version would always keep getting pushed back.
I don't want to promise a feature that will never be made, so i've decided to cancel this version. I should've done this sooner but i expected to finish the Unified SDK a lot sooner. The delays ended up pushing this further back, which is why i've investigated it now to make a decision.
For Android users that want to view models on Android i'd recommend directing your requests to the Paranoia 2 Model Viewer developers. The GameBanana page has links relevant to this: https://gamebanana.com/tools/6828
I'm still working on the Unified SDK so until V1.0.0 is done i won't be working on HLAM. It is getting closer to being finished so hopefully i can get things going soon.
See the Half-Life Updated
thread for more information about that.