Building ASCII Graphics Engine and 3D Rendering Pipeline in Windows Command Prompt 

It's great to hear that! I'm currently working on videos describing the nitty-gritty details, but it will probably take a while, so I'll try to give some answers now. There are a few tricks that I've used: (1) Multithreading (a thread pool in this case). To deal with more computationally-demanding cases my engine provides a virtual OnDrawColumn() method. Each call is handled by one of the available threads from the dedicated thread pool. This approach allows for almost full utilization of all available CPU cores. Parts of the rasterizer and raytracer extensions take advantage of this feature. (2) Avoid frequent palette colour changes. I found that the Windows console rendering algorithm is struggling with frequent palette colour changes. So I tried to minimise the number of these changes and instead obtain desired colours by using background-foreground interpolation with ASCII characters. It works quite well, especially at higher resolutions. (3) Luma (intensity) textures. It is somewhat related to the previous point. The engine supports two types of textures: a) luma textures - CSV-based format, where each value is a floating point number from 0 to 1. b) chroma textures - CSV format, where each value is an integer value from (0-16) representing a colour value. These come with palette.txt files, where each RGB triplet represents one of the 16 colour values. Both types of textures can be combined to achieve quite good results. Examples include the ImageViewer. However, in real-time applications, I used luma textures combined with thresholding. This approach gives good levels of flexibility while avoiding colour-switching.

@@kubamaruszczyk4043 One more thing I want to ask, have you ever considered making this in the newer windows terminal instead of the old command prompt?

​@@skwiglyman2052 It's an interesting idea. I looked into it briefly. At first, it seemed quite promising, plus the terminal has support for 24-bit colour. However, it turned out to be a bit of a dead end. For example, colours can only be set via VT sequences Also, from what I read, the terminal aims to be compatible with WSL, so much of the win32 API functionality is not supported, for example, direct buffer access.

Thanks RanPix! Interop services can be quite useful if you need direct access to some lower level system features. You can find the list of method signatures, types, and other stuff (related to calling Win32 and other unmanaged APIs from managed code) on pinvoke net. It's basically an iterop wiki made by developers. Good luck with building your engine!

@@kubamaruszczyk4043 thank you :)

@@kubamaruszczyk4043 by the way you said that windows console only supports 16 colors but there is a way to output any rgb color value, you didnt find it or didnt use it? and if so why you didnt?

@@ranpix I think I said that you can have only 16 colors at one time :) You can set each palette color to a custom rgb color - which I showcased in the video. This can be done via Win32 API. You haven't specified which particular way you have in mind, so I'm gonna guess that you were reffering to "24 bit console color support" introduced in Windows 10 Build #14931, which was announced here: devblogs.microsoft.com/commandline/24-bit-color-in-the-windows-console/ (correct me if I'm wrong). That's the only alternative that I know of. However, it is not suitable for real time puproses, as it can only be accessed via virtual terminal sequences, which makes is basically useless for real-time graphics. The following sources I've come accross indicate that MS is not planning on providing access to 24 bit color via Win32 API. More details: stackoverflow.com/questions/56006863/winapi-access-to-24-bit-color-on-windows-console github.com/Microsoft/WSL/issues/1118 Because there isn't a way of accessing the console buffer directly with VT sequences, like I did with win32, I couldn't use char+attrib memory buffer for fast rendering. So I guess, technically, there is a way of outputing custom rgb values to console, but it doesn't seem relevant for real-time gfx stuff.

@@kubamaruszczyk4043 hello, can you please check the spam section? youtube sent my messages because they had links :/

Thanks Joe! There are quite a few issues with my voice over here, it's uneven at times, and I'm too close to the mic. I'll try to fix these in the future videos. Thanks!

A console whisperer :) I agree though. I recorded it with being too close to the mic and then compressed the crap out of it to compensate for the low levels. Somehow it sounded better on my setup at the time.