digitalmars.D.learn - Indexed graphics for retro engine?
- Shadowblitz16 (4/4) Sep 18 2019 Is there a way to make a indexed graphics library that can handle
- Shadowblitz16 (2/2) Sep 18 2019 oh I would also like to be able to draw indexed images shapes as
- Shadowblitz16 (1/1) Sep 18 2019 *indexed color images and shapes
- Mike Parker (13/17) Sep 18 2019 I don't see why not.
- Shadowblitz16 (4/22) Sep 19 2019 I wanted to do 4bpp 16 color graphics.
- Mike Parker (8/11) Sep 19 2019 I see. In that case, I suggest you find some tutorials on
- Shadowblitz16 (3/14) Sep 19 2019 can I do this in D and draw them to a 32bpp bitmap pixel by pixel?
- rikki cattermole (12/28) Sep 19 2019 I've done a quick lookup in my red book (seventh edition so 3.1).
- norm (14/32) Sep 19 2019 I'd create a fragment shader to convert each pixel to 8 bit.
- Shadowblitz16 (3/18) Sep 19 2019 the issue with using openGL is its complex and hard to get
- Gregor =?UTF-8?B?TcO8Y2ts?= (35/38) Sep 20 2019 Conceptually, applying the palette to the index buffer is easy on
- Adam D. Ruppe (19/23) Sep 19 2019 My color.d actually can do it.
- Shadowblitz16 (3/8) Sep 19 2019 cool does this store image data as raw byte[]'s?
Is there a way to make a indexed graphics library that can handle importing and exporting true color images? I would guess something like this could be simulated with pointers and references right?
Sep 18 2019
oh I would also like to be able to draw indexed images shapes as well.
Sep 18 2019
Shadowblitz16 <DomainName Email.com> 
On Thursday, 19 September 2019 at 03:47:05 UTC, Shadowblitz16 wrote:Is there a way to make a indexed graphics library that can handle importing and exporting true color images?I don't see why not.I would guess something like this could be simulated with pointers and references right?If you want to, say, take a 24-bit or 32-bit and treat it as an 8-bit image, you'll probably want to actually do a conversion rather than a simulation. In which case you'd probably be better off just using an existing C library like FreeImage. You can find a binding here: https://github.com/BindBC/bindbc-freeimage Otherwise, you'll want to hit up a graphics programming forum for resources on image conversion. Two possibilities: https://www.reddit.com/r/GraphicsProgramming/ https://www.gamedev.net/forums/forum/5-graphics-and-gpu-programming/
Sep 18 2019
On Thursday, 19 September 2019 at 05:22:37 UTC, Mike Parker wrote:On Thursday, 19 September 2019 at 03:47:05 UTC, Shadowblitz16 wrote:I wanted to do 4bpp 16 color graphics. and I didn't want to load anything unnecessary in the image like the palette but instead supply it myself as a Color[16];Is there a way to make a indexed graphics library that can handle importing and exporting true color images?I don't see why not.I would guess something like this could be simulated with pointers and references right?If you want to, say, take a 24-bit or 32-bit and treat it as an 8-bit image, you'll probably want to actually do a conversion rather than a simulation. In which case you'd probably be better off just using an existing C library like FreeImage. You can find a binding here: https://github.com/BindBC/bindbc-freeimage Otherwise, you'll want to hit up a graphics programming forum for resources on image conversion. Two possibilities: https://www.reddit.com/r/GraphicsProgramming/ https://www.gamedev.net/forums/forum/5-graphics-and-gpu-programming/
Sep 19 2019
On Thursday, 19 September 2019 at 18:25:05 UTC, Shadowblitz16 wrote:I wanted to do 4bpp 16 color graphics. and I didn't want to load anything unnecessary in the image like the palette but instead supply it myself as a Color[16];I see. In that case, I suggest you find some tutorials on software rendering in C or C++ and adapt them to D. Most of the modern stuff out there is going to be targeting 24-bit or 32-bit graphics. You might find some older tutorials on indexed 8-bit rendering that you can adapt to 4-bit. Nothing to it but storing the palette indices in a byte array.
Sep 19 2019
On Thursday, 19 September 2019 at 19:16:03 UTC, Mike Parker wrote:On Thursday, 19 September 2019 at 18:25:05 UTC, Shadowblitz16 wrote:can I do this in D and draw them to a 32bpp bitmap pixel by pixel? I would prefer do do this on the gpu but I don't know how.I wanted to do 4bpp 16 color graphics. and I didn't want to load anything unnecessary in the image like the palette but instead supply it myself as a Color[16];I see. In that case, I suggest you find some tutorials on software rendering in C or C++ and adapt them to D. Most of the modern stuff out there is going to be targeting 24-bit or 32-bit graphics. You might find some older tutorials on indexed 8-bit rendering that you can adapt to 4-bit. Nothing to it but storing the palette indices in a byte array.
Sep 19 2019
On 20/09/2019 8:47 AM, Shadowblitz16 wrote:On Thursday, 19 September 2019 at 19:16:03 UTC, Mike Parker wrote:I've done a quick lookup in my red book (seventh edition so 3.1). For OpenGL the choice between RGBA mode vs indexed happens by the system windowing library (context creation) not OpenGL itself. This means without writing a windowing library yourself, you won't get indexed mode and even then you would be stuck with it for whatever window you draw to. Also for x86 cpu's anything less than 32bpp is going to be inefficient. You may as well map your indexed image straight into RGBA8 on load. As for book recommendations here is one for DOS: https://www.amazon.com/Black-Art-Game-Programming-High-Speed/dp/1571690042 You will only want the first five chapters or so, but it should cover the material you need and have some more for when you are interested in 3d.On Thursday, 19 September 2019 at 18:25:05 UTC, Shadowblitz16 wrote:can I do this in D and draw them to a 32bpp bitmap pixel by pixel? I would prefer do do this on the gpu but I don't know how.I wanted to do 4bpp 16 color graphics. and I didn't want to load anything unnecessary in the image like the palette but instead supply it myself as a Color[16];I see. In that case, I suggest you find some tutorials on software rendering in C or C++ and adapt them to D. Most of the modern stuff out there is going to be targeting 24-bit or 32-bit graphics. You might find some older tutorials on indexed 8-bit rendering that you can adapt to 4-bit. Nothing to it but storing the palette indices in a byte array.
Sep 19 2019
On Thursday, 19 September 2019 at 20:47:45 UTC, Shadowblitz16 wrote:On Thursday, 19 September 2019 at 19:16:03 UTC, Mike Parker wrote:I'd create a fragment shader to convert each pixel to 8 bit. There are many examples on the web about creating fragment shaders and 2d opengl scenes, i.e. a 2d scene where OpenGL coordinates are integer pixel coordinates. Once you get that you then just implement the conversion routine. Using the shader you can render the image as a textured quad and send the colour look up table down as an additional 1d texture. This way you can have several D arrays for each colour table and simply swap the texture buffer pointer to instantly switch colours. You can also get cool effects this way when you move to 3d using 8 bit colour tables.On Thursday, 19 September 2019 at 18:25:05 UTC, Shadowblitz16 wrote:can I do this in D and draw them to a 32bpp bitmap pixel by pixel? I would prefer do do this on the gpu but I don't know how.I wanted to do 4bpp 16 color graphics. and I didn't want to load anything unnecessary in the image like the palette but instead supply it myself as a Color[16];I see. In that case, I suggest you find some tutorials on software rendering in C or C++ and adapt them to D. Most of the modern stuff out there is going to be targeting 24-bit or 32-bit graphics. You might find some older tutorials on indexed 8-bit rendering that you can adapt to 4-bit. Nothing to it but storing the palette indices in a byte array.
Sep 19 2019
On Thursday, 19 September 2019 at 23:32:13 UTC, norm wrote:On Thursday, 19 September 2019 at 20:47:45 UTC, Shadowblitz16 wrote:the issue with using openGL is its complex and hard to get working with a widget library[...]I'd create a fragment shader to convert each pixel to 8 bit. There are many examples on the web about creating fragment shaders and 2d opengl scenes, i.e. a 2d scene where OpenGL coordinates are integer pixel coordinates. Once you get that you then just implement the conversion routine. Using the shader you can render the image as a textured quad and send the colour look up table down as an additional 1d texture. This way you can have several D arrays for each colour table and simply swap the texture buffer pointer to instantly switch colours. You can also get cool effects this way when you move to 3d using 8 bit colour tables.
Sep 19 2019
On Thursday, 19 September 2019 at 20:47:45 UTC, Shadowblitz16 wrote:can I do this in D and draw them to a 32bpp bitmap pixel by pixel? I would prefer do do this on the gpu but I don't know how.Conceptually, applying the palette to the index buffer is easy on the GPU. There are two ways to go about that, using either the (programmable) hardware rendering pipeline or the compute shader. The first thing is that you need to end up with your 4bpp image on the GPU. Either as a texture upload or you're rendering something into it as a framebuffer. I guess the first option is preferable. You'll have to abuse an 8bpp texture format like R8UI for the texture. The current palette goes into a separate texture or buffer object. A uniform buffer object (OpenGL terminology) is probably the simplest option. Then you have to invoke either a fragment shader or a compute shader so that it is invoked for every pixel in the input. This performs the palette lookup and writes the palette color to its output. If you go with a fragment shader, you need to set up a projection that is just right, write a dummy vertex shader and setup a framebuffer to render to. and you need a vertex buffer with one or two triangles in it that cover the output so that the graphics pipeline has something to render. In short, it's the classic creative abuse of the rendering pipeline to obtain a full screen effect. The slightly more modern version is a compute shader that gets invoked per pixel and does the same thing. The nice thing is that you get to skip all the vertex buffer, vertex shader and projection stuff. And with DirectX or Vulkan, you even get to bind the current swapchain image to the compute shader, so your shader output goes to the screen as directly as possible. OpenGL requires you to allocate an output texture that you copy to the screen separately (well, it's a bronze age APIs...). It's really quite simple if you understand GPUs. There's a lot of terminology to throw around, but once you get a handle of the general ideas behind of GPU rendering, stuff like that comes easy.
Sep 20 2019
On Thursday, 19 September 2019 at 03:47:05 UTC, Shadowblitz16 wrote:Is there a way to make a indexed graphics library that can handle importing and exporting true color images? I would guess something like this could be simulated with pointers and references right?My color.d actually can do it. http://dpldocs.info/experimental-docs/arsd.color.html it has a true color to indexed quantize function: http://dpldocs.info/experimental-docs/arsd.color.quantize.html my png.d is capable of loading and saving them: http://dpldocs.info/experimental-docs/arsd.png.readPng.html you will want to cast it to IndexedImage or cast it to TrueColorImage and quantize to get an indexed one. and my simpledisplay.d knows how to display them, but it does so via conversions so palette swaps won't just work live like on a real DOS system or whatever. http://dpldocs.info/experimental-docs/arsd.simpledisplay.Image.fromMemoryImage.html all the module's source code are in here: https://github.com/adamdruppe/arsd but otherwise the support is not great because it is just whenever I decide to answer emails and i'm gonna be busy this next week. but it might be useful to you
Sep 19 2019
On Friday, 20 September 2019 at 00:41:58 UTC, Adam D. Ruppe wrote:On Thursday, 19 September 2019 at 03:47:05 UTC, Shadowblitz16 wrote:cool does this store image data as raw byte[]'s? I might have to use this :D[...]My color.d actually can do it. [...]
Sep 19 2019