31–38 of 38 posts
What'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.
Textualize/Frogmouth has a TUI tree control: https://github.com/Textualize/frogmouth
FWICS browsh supports WebGL over SSH/MoSH https://www.brow.sh/docs/introduction/ :
> The terminal client updates and renders in realtime so that, for instance, you can watch videos. It uses the UTF-8 half-block trick () to get 2 colours from every character cell, thus simulating basic graphics.
https://github.com/fathyb/carbonyl :
> Carbonyl originally started as html2svg and is now the runtime behind it.
Always wondered how brew.sh added the brew sprite there; that's real nice.
TIL that e.g. Kitty term can basically framebuffer modified Chrome?
https://github.com/chase/awrit :
> Yep, actual Chromium being rendered in your favorite terminal that supports the Kitty terminal graphics protocol.
FWIW Cloudflare has clientless Remote Browser Isolation that also splits the browser at the rendering engine.
A TUI Manim renderer would be neat. Re: Teaching math with Manim and interactive 3d: https://github.com/bernhard-42/jupyter-cadquery/issues/99
What would you add to make it easier to teach with this entirely CPU + software rendering codebase?
What prompts for learning would you suggest?
- Pixar in a Box, Wikipedia history of CG industry,: https://westurner.github.io/hnlog/#comment-36265807
- "Rotate a wireframe cube or the camera perspective with just 2d pixels to paint to; And then rotate the cube about a point other than the origin, and then move the camera while the cube is rotating"
- OTOH, ManimML, Yellowbrick, and the ThreeJS Wave/Particle simulator might be neat with a slow terminal framebuffer too
I 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,…
Also, speaking as a C++ game developer by profession, taking a shared_ptr copy and moving from it is a common way of saying "I will take a copy of this and keep it alive" whereas a shared_ptr ref only communicates that it can or might
I 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,…
I don't necessarily agree. Using shared_ptr to not worry about lifetimes, a la C#, is not inherently a bad thing, not all code has to pretend to be Rust, especially a hobby project. From what I see, they're only really being used as dependency injection. So it has the benefits of the garbage collected model with none of the downsides Also, speaking as a C++ game developer by profession, taking a shared_ptr copy and m…
Regarding "I will take a copy and ... keep it alive..." That is literally what the copy constructor of a sharedpointer does, you wouldn't need a move for that, the move literally just prevents the atomic increment.
I'm not saying there isn't a use case for shared_ptr, just that in this codebase at least in parts of it you could string replace with unique_ptr and get a free performance boost ( as trivial as it would be if the compiler hasn't already just done that ) because the atomic ref count is not needed.
OP did however clarify some design decisions on why the shared_ptr in some parts of the code and that is fine.
I stick by my statement. Stop using std::shared_ptr. Use std::unique_ptr and then convert to shared when it is actually necessary.
My point in C# was a mean spirited dig, but really though, you are giving up a ton of library features from C# by coding in C++ to then just treat it like C#. Write it in C# using the library that has already been optimised...
Well done! We need more textmode out there!
make
[ 1%] Building CXX object CMakeFiles/Consol3_raster.dir/src/Consol3.cpp.o
In file included from /home/john/Consol3/src/Consol3.cpp:23:
/home/john/Consol3/src/Engine/Input/LinuxInputManager.hpp:8:10: fatal error: linux/input.h: No such file or directory
8 | #include
| ^~~~~~~~~~~~~~~
compilation terminated.
make [ 1%] Building CXX object CMakeFiles/Consol3_raster.dir/src/Consol3.cpp.o In file included from /home/john/Consol3/src/Consol3.cpp:23: /home/john/Consol3/src/Engine/Input/LinuxInputManager.hpp:8:10: fatal error: linux/input.h: No such file or directory 8 | #include | ^~~~~~~~~~~~~~~ compilation terminated. Oh, well ;)
I've compiled it in Windows and Linux and didn't have any issues
make [ 1%] Building CXX object CMakeFiles/Consol3_raster.dir/src/Consol3.cpp.o In file included from /home/john/Consol3/src/Consol3.cpp:23: /home/john/Consol3/src/Engine/Input/LinuxInputManager.hpp:8:10: fatal error: linux/input.h: No such file or directory 8 | #include | ^~~~~~~~~~~~~~~ compilation terminated. Oh, well ;)
Hi, if you want help getting it running please open an issue on github with some info like your OS I've compiled it in Windows and Linux and didn't have any issues
In this case he's probably missing linux-headers for his kernel version?
If people download your project and the build fails, it's very, very, very likely that they'll give up right away. You have to be very, very interested in a project to be bothered to research and install undocumented dependencies and their versions and then fight the build.