This is so unbelievably awesome! Projects like these are why I browse HN
Maybe you are also interested in: https://www.mesa3d.org/
Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU
21–30 of 38 posts
Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU
#22Thanks for posting this. This is probably the coolest project I’ve seen all year.
Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU
#23I would strongly encourage you to reduce your use of std::shared_ptr in your code. There is one instance where I saw you take a shared_ptr and then proceed to move from it. That could literally have been a unique_ptr and if you are making an assumption that that shared_ptr is still valid in another part of the codebase you at best now have UB but it is almost certainly a bug. Just replace shared_ptr with unique_ptr,…
Thanks for the feedback 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…
> 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 saw that, that function is probably completely inlined by the optimiser as well so likely the move doesn't even happen there.
Just wanted to make sure since I know a lot of devs not super proficient in C++ just sticks a shared pointer on things to get around worries about ownership and don't concider the tradeoffs.
For me I concider using a unique_ptr a form of compile time check for how I'm thinking about the code. I find shared_ptr to be a smell. It's not necessarily wrong but probably needs some reasoning about.
Another note, I saw some comments somewhere about SIMD vectorisation that needs to be implemented. I would check whether the compiler isn't already doing that and if it isn't I would see about changing the code to make if possible for the optimiser to generate vectorised code.
I still haven't been at a PC so haven't been able to properly look through the code but it is nice to at least see modern C++ being used in a codebase
Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU
#24I would strongly encourage you to reduce your use of std::shared_ptr in your code. There is one instance where I saw you take a shared_ptr and then proceed to move from it. That could literally have been a unique_ptr and if you are making an assumption that that shared_ptr is still valid in another part of the codebase you at best now have UB but it is almost certainly a bug. Just replace shared_ptr with unique_ptr,…
Agree on the over-use of shared_ptr (there is _a lot_ of copying shared ptrs going on here). But moving from the shared_ptr like this is quite idiomatic no? void Consol3Engine::RegisterFrameDrawer(std::shared_ptr frame_drawer) { frame_drawers.push_back(std::move(frame_drawer)); ... }
Its idiomatic sure but specifically with shared pointer a lot of time people are using shared pointers because they don't want to think about ownership, this turns out not to be the case here but think about it, the function is taking shared_ptr by value which increases the ref count when looked at from the signature.
In the calling code you then dereference that shared_ptr because it should still be valid but it isn't because it is now a moved from value.
I would in this specific case just replace shared_ptr with unique_ptr in the entire call stack up until here. If there isn't an implicit conversation here, put the conversation to shared in this function.
That makes it explicit ownership of the pointer is being moved into this function, it wasn't clear at all that that is happening with the shared_ptr.
EDIT:
You have to think of shared_ptr as global, if you moved from it ownership was changed but there is no way for everyone else holding a reference to thay shared pointer to know that.
Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU
#25Earlier quoted context omitted.
What am I missing here? Why is it cool to not use the fast GPU and instead do everything slow in a software renderer on the CPU? It surely is interesting to do it for the sake of it, but are there any practical use cases?
There's no real practical use case besides just being a fun hobby project 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
Then I probably should not have commented here, as I am very practical and l'art pour l'art is not my take. But I hope you had fun and continue to have fun ;)
Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU
#26This is really fun, thank you for sharing it!
Recently, I've personally and professionally been going between TUI and deep 3D (mesh shading FTW) so this was fun to see. Your work is inspiring me to think about how to apply those principles to my own work. There have been other ascii renders but I've not seen anything quite like Consol3.
I made a half-baked PR with some initial Mac support [1]. I don't have time this weekend but I'll pull on it later -- or maybe somebody here with more low-level Mac skills than me can take a look?
Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU
#27Earlier quoted context omitted.
Thanks for the feedback 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…
> 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 saw that, that function is probably completely inlined by the optimiser as well so likely the move doesn't even happen there. Just wanted to make sure since I know a lot of devs not super proficient…
The compiler for sure does some vectorization for me currently, I would expect much worse performance otherwise, it's quite good at that
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
Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU
#28This is really fun, thank you for sharing it! Recently, I've personally and professionally been going between TUI and deep 3D (mesh shading FTW) so this was fun to see. Your work is inspiring me to think about how to apply those principles to my own work. There have been other ascii renders but I've not seen anything quite like Consol3. I made a half-baked PR with some initial Mac support [1]. I don't have time this…
Thanks!
I really appreciate the PR
Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU
#29What's the advantage of re-implementing the GPU programming model (shaders) instead of just writing regular C++ code? I would think that would just introduce overhead for no reason.
Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU
#30What's the advantage of re-implementing the GPU programming model (shaders) instead of just writing regular C++ code? I would think that would just introduce overhead for no reason.
There's no performance reason really, the motivation behind it was flexibility for trying out new ideas and to decouple logic from the rasterizer