Accessing Surface pixel data and creating Surface from pixel arrays

[Vovanium]

Hello! Here's little contribution to the project to make direct pixel access available. Added function to obtain Surface.Internals.Pitch. Added generic function to get Pixels as an access type. Added generic function to get specific row address (like an above but with some address arithmetic) Made an example / test for software drawing. UPD: Added a fairly direct binding to SDL_CreateRGBSurfaceFrom Added second binding taking Ada's 2d-array.

I didn't add function to get single pixel address, it

• not always possible (like in 1-bit and 4-bit pixels)
• in most cases is not optimal to recalculate address every pixel
• it require some investigation.

[Lucretia]

Thanks, I'll take a look when I can. It's not going to happen soon, but then neither will any changes to the base source.

I did want to make the interfaces to surfaces and textures as similar as possible, but the thing about surfaces is that, iirc, they are not hardware accelerated and I wondered about keeping them in as textures are.

[Vovanium]

Ok, I got you. My contribution would not interfere with the common part of texture and surface. My own goal is to access pixels directly from Ada. I'm playing with custom software rendering and use Surface to get the result visible.

As far as I understand, Texture is allocated in some GPU-specific way to make accelerated rendering productive. But surface is serving other purpose, it's the effective way for CPU to access the image. There could be a practical example for it, like, say, rendering of a Mandelbrot set.

[Lucretia]

No, fairly sure textures are main memory and then uploaded to the GPU.

[Vovanium]

I don't mean they should be in GPU memory. I mean, SDL hides Texture implementation details from the application, so it's up to rendering engine (say, GPU driver) to store it where and how it needs. Ofcourse if you choose software renderer, it will be in main memory.

P.s. I committed interactive fractal 'Julia set' renderer as an example of an application-side rendering to a Surface. It is not optimized and dirty, however it shows how Surfaces can be used.

[Lucretia]

SDL doesn't really hide textures, it works the same way as GL, Vulkan, D3D and Metal, you create a texture in main memory and then send it to the gpu when you start rendering triangles. The texture is a handle of some sort, that's "hidden," whether that's an address to an opaque structure or an integer index into a hidden table.

[Vovanium]

that's "hidden," whether that's an address to an opaque structure or...

That's what i mean, application cannot access it by simply walking data structures. This gives backend freedom in ways to layout the data. From the point of custom software rendering the other way is writing to texture by SDL_LockTexture / SDL_UpdateTexture so surfaces are not necessary. However surface is a bit more convenient.

[Lucretia]

I'm on IRC where we can discuss SDL.