what problem are you solving? do you want to write to a texture? or do you want to write to screen “directly”? do you want to read pixels after doings lots of graphics operations?
all I know is that the API around SDL_Surface is the older not fast one.
uuuh SDL_WriteSurfacePixelFormat is not available on SDL2
I had a working ray tracing code that used SDL_Surface, writing to raw void *pixels directly. this evening I’ve rewritten everything to use SDL_Texture, but in the end I’m still writing to void *pixels, but with several extra steps and two blind decisions. is there any gain? I have no idea. I’ve done the rewrite based on some blind suggestion that SDL_Surface is supposedly some slow API. I don’t know? is it?
what annoys me the most is that the SDL documentation is abysmal. there is no guidance on best practices, it doesn’t even have links to blogs or books that could provide such guidance. Microsoft of all companies does an excellent work linking external tutorials and blogs in their official documentation
but hey, I’m still using SDL2, right? can I even complain about legacy API? I don’t see SDL3 on MSYS2 neither on emcc --show-ports
OP, once I’m finished and I clean up my code, I’ll share my code hosted on GitHub which contains a complete example to write individual pixels, but I don’t even know if it is the fastest way.
I totally agree with you @elefantinho that there is a very little information available for SDL.I think on SDL’s website there must be some examples codes and getting started guide should be available, with proper explanation so that anybody can easily use SDL.
@elefantinho My suggestion would be too slow for raytracing. And sorry, I didn’t mean to push SDL3 on to you. SDL2 is still very much supported, and if you don’t need the new features of SDL3, I wouldn’t suggest transitioning.
I share your frustration about documentation and examples. There are some 3rd party guides and tutorials for most things. SDL3 has improved on documentation and examples though. Hopefully we can make discourse a useful resource.
I did raytracing in SDL2 with writing pixels directly to a texture in an x/y for loop. Let me dig it out for you.
I created a streaming texture with the format SDL_PIXELFORMAT_RGB888. Then this is the magic code;
yeah, my code is similar!!
but this parameter pitch, it terrifies me. I’m always scared about byte-order, and I don’t know anything about memory alignment
well, as long as it works! bugs only exist when they appear, after all lol
(1)What is pixols and its datatype ?
(2)What is pixolP and its datatype ?
(3)What is display->RaytraceH() and display->RaytraceW() ?
(4)Extraction of R/G/B content is necessary. i mean can’t we have a dedicated fast routine/method?
(5)cant we need SDL_UpdateTexture and SDL_RenderCopy and SDL_RenderPresent ?
(6)At last what is the size of raytraceTexture (means it one pixel wide or covering whole window)?
Note: Sir,may be these questions are vary basic but without it ,its very difficult for me to work.
I said I wanted to clean it up, but it is becoming more horrible by the passing day. also, it crashes sometimes when resizing the window, so I can’t say my approach is correct. anyway
@Shri my example was a little snip of a massive project, just to give a clue / hint on how to do it. It’s the best I can do, and it requires some understanding and work to interpret for your own needs. All the information is there. If I write all the code for you, it won’t help you understand how it works to tailor it for your own needs.
I’m sure there are better examples / tutorials somewhere.
@elefantinho in this case, pitch is just the size of the row, in case there is padding at the end of the row. The chosen pixel format is always going to be 4 bytes in the same order. In in doubt, SDL_MapRGB will always map to the correct format until you’re confident enough to optimize.