Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU

github.com

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU

#11

Post by jpc0 »

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, the advantage of managed languages is that you are in control of the memory, to then proceed to just use ref counting means you may as well have written the code in Java / C# since you incur all the same overhead of atomic references and don't get the advantages of a sophisticated GC.

unique_ptr can also trivially be upgraded to shared if you actually do need ref counting.

Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU

#12

Post by lukan »

Blahah wrote: post #9
lukan wrote: post #8

Earlier 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?

Running it remotely on a cloud instance? Or on any machine without a GPU.

Well yeah, I remember those software renderer options from old computer games.

I might not have known the difference between GPU and CPU back then, but I learned very quickly that Software renderer means slow and makes your Computer very hot. Not cool (literally) I thought back then.

Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU

#14

Post by moffkalast »

tetris11 wrote: post #13

This is definitely one of those "but, why?" projects that has me grinning from ear to ear, and makes HN the interesting place it is when it's not being drowned in AI or Fintech

I wonder if it works on a headless server plugged into a display where you only get a TTY. If so it would actually be useful as a kiosk environment on machines without a GPU.

Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU

#15

Post by mandarax8 »

jpc0 wrote: post #11

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,…

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));
      ...
  }

Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU

#16

Post by victormeriqui »

jpc0 wrote: post #11

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,…

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 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 :)

Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU

#18

Post by victormeriqui »

lukan wrote: post #8
raytopia wrote: post #7

Earlier quoted context omitted.

And it has shaders. Can't get any cooler

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

Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU

#19

Post by victormeriqui »

teaearlgraycold wrote: post #10
lukan wrote: post #8

Earlier 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?

It's much easier to debug. And CPUs are actually fast enough to do real-time rendering of simple scenes. Because writing for the CPU is so different, and so much easier than writing for the GPU, a pure software stack allows you to explore new ideas.

Exploring new ideas without worrying about GPUs was exactly one of my motivations :)

Re: Show HN: Consol3 – A 3D engine for the terminal that executes on the CPU

#20

Post by victormeriqui »

mysterydip wrote: post #4

Really nice, thanks for sharing! I like the pseudo-shader implementation. What kind of framerate were you seeing and how many triangles could you push?

Thanks!

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

Post reply on HN