All of the methods defined here:
https://github.com/Helion-Engine/Helion/blob/20300d89ee4091c...
Are available in the kitchen sink:
https://learn.microsoft.com/en-us/dotnet/api/system.numerics...
Same idea applies to methods like GetProjection, which could be replaced with methods like:
https://learn.microsoft.com/en-us/dotnet/api/system.numerics...
Advantages of using this library are that it is uses intrinsics (SIMD) to accelerate operations. There is a lot of Microsoft money & time that has been invested into these code piles.
There's also another hint:
// THIS FILE WAS AUTO-GENERATED. // CHANGES WILL NOT BE PROPAGATED. // ----------------------------------------------------------------------------
(Of course this could be a result of something having nothing to do with the contents of the file, but maybe the author has to meta library that can generate the types in different languages).
There seems to be fixed-precision variants of the vector types as well which seems to be not available in the .NET framework.
Plus, of course, you can't add your specifics needs to library types (like the fixed precision). They are closed to modification.
I am just guessing, of course.
That being said, it would also make total sense to use the .NET types.
https://github.com/Helion-Engine/Helion/commit/e6affd9abff14...
Someone should learn some CS and then how to make proper commits.
https://www.youtube.com/watch?v=5wAo54DHDY0
If you've read House of Leaves, do yourself a favor and check it out.
Agreed, it is an incredible art piece, and now I want to go find a copy of House of Leaves.
All I'm seeing is they got their hands on the domain, which can be (and was in the past) just part of whatever settlement they agreed on, and the game press spinned that into "Nintendo bought Ryujinx".
The more recent .NET versions by themselves are likely to have some impact on the performance, let alone any changes in Helion code between versions.
Though I wonder how sprites, which are a different problem orthogonal to polygonal rendering, are handled. So, cough cough, Doxylamine Moon benchmarks?
Software rendering engine, yes (and even then you can parallelize it). But there is really no reason why doom maps can't be broken down in polygons. Proper sprite rendering is a problem, though.
However, proper recreation of the original graphics would require shaders and much more modern extensive and programmable pipelines, while the relaxed artistic attitude (or just contemporary technical limitations) unfortunately resulted in trashy y2k amateur 3D shooter look. Leaving certain parts to software meant that CPU had to do most of the same things once again. Also, 3D engines were seen as a base for exciting new features (arbitrary 3D models, complex lighting, free camera, post-processing effects, etc.), so the focus shifted in that direction.
In general, CPU performance growth meant that most PCs could run most Doom levels without any help from the video card. (Obviously, map makers rarely wanted to work on something that was too heavy for their systems, so the complexity was also limited by practical reasons.) 3D rendering performance (in non-GZDoom ports) was boosted occasionally to enable some complex geometry or mapping tricks in popular releases, but there was little real pressure to use acceleration. On the other hand, the linear growth of single core performance has stopped long ago, while the urges of map makers haven't, so there might be some need for “real” complete GPU-based rendering.
And I don't think any of the above is necessary. Even according to their graphs popular doom ports can render huge maps at sufficiently high fps on reasonably modern hardware. The goal of this project, as stated in the doomworld thread, is to be able to run epic maps on a potato.
Legend.
Old Note 9, Chrome and Firefox.
Non flagship mobile devices could very well choke on one of those pages, but most newer devices should display these pages with little grief.
If the authors wanted to protect engine development while allowing indies to sell games made on it, they would have picked LGPL or a more permissive license.
I'd love to be wrong, so if you have a few examples, I'm all ears.
GPL vs LGPL definitely isn't a blocker for a commercial game, in any case.
[0] https://github.com/madame-rachelle/hgzdoom https://store.steampowered.com/app/1072150/Hedon_Bloodrite/
[1] https://store.steampowered.com/app/1898610/Hands_of_Necroman...
Edit: ohh i found it:
http://www.gamespy.com/articles/641/641662p6.html
The GPL license will allow people to take the Quake 3 engine and even go so far as to release a commercial product with it - provided that the source code is published alongside. Nobody has done this with any of the Quake engine games yet, but he hopes to see it happen someday.