In their mind the USA=the default country=the world
73 karma · joined January 14, 2020
Also to the ones saying this is malware or would qualify as "causing harm to computing equipment". How about you read the license? not that I would expect any vibecoder to even care, but:
"6. Disclaimer of Liability
EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, AND TO THE EXTENT PERMITTED BY APPLICABLE LAW, NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES."
I've compiled it in Windows and Linux and didn't have any issues
The SIMD idea there was more in the direction of structuring the data in a more vector friendly way, and then seeing if manually vectorized code would run better - but right now I haven't really invested much time into it :/
There's also multi threading which I wanted to add, by having the rasterizer handle triangles in parallel in different regions of the screen, but this is also just an idea which I haven't explored much yet
Depends on the scene and the CPU of course, typically I get between 20-60 FPS on a small scene with a floor and a few models, but features like shadow maps or normal maps bring the performance down a lot though
The scenes themselves don't have a lot of triangles, for the first scene with marvin and the car in the rasterization video there's 7427 triangles
There is no parallelization whatsoever in the engine at the moment, so I feel like it could get much faster if I multi thread it, or use SIMD vectors
Another aspect that influences the performance a lot is the output mode being used, for example the TextOnly mode is a lot faster than others since it uses no colors at all, the full RGB color mode has to have an escape sequence prepended to each character "pixel" so its quite slow
It also depends on the frame disposition itself, the Windows console does some attribute caching when its rendering continuous character rows, so if a frame has a lot of different colors horizontally, it will be slightly slower than if it didn't
There are some niche cases where software rendering on the CPU is used nowadays but it's pretty rare
There are a lot of optimizations that could be done to make a CPU renderer faster, but even so I don't think there are many real world use cases
I do have quite a lot of shared_ptrs throughout the entire code base, that could be reduced
The main reason behind that is I wanted a lot of flexibility between the components and didn't want to end up centralising too much logic in a single one
For example: there is a resource_manager which is a shared pointer created in the game component, it's shared with the scene_renderer (it needs to use it to get the resource data), but I like to keep it also in the game component for loading new resources
of course I could have it owned by just the scene_renderer and access it from there avoiding the reference counting
but this was a design decision that I stand behind as it really helped with clearer separation between components, and the performance, well let's say that the reference counting isn't the bottleneck here as using the console for output is pretty slow
Also the moving of shared pointers is just an optimization to avoid increasing and then immediately decreasing the ref count, no UB there since its passed by value in the argument, so it gets copied before being moved :)
I don't think it was a case of pandering to economically important regimes, it was more like disgusting and malicious incompetence, like most things that come out of the public sector in Lisbon with this government