LÖVE

UnixRoot wrote: ↑Tue May 30, 2023 7:38 am But for lower resolution software rendered ray casters, you don't really need the GPU.

Well of course not, but why not do it anyway? I was really just looking for something to rekindle my interest in the project and at the time I fancied figuring out how to use some of the more advanced graphics APIs Love provides (I ended up ripping apart the G3D engine for inspiration when I couldn't get the hardware depth buffer working right so I was happy to learn how that works too).

Plotting the pixels on a frame buffer is really fast if you use FFI and pointers.

That's a fair point, before I stopped working on it I had started experimenting with FFI in my software implementation but hadn't got as far as an FFI framebuffer. It was a while ago but IIRC I used it in the texture mapping as sampling the default image object was slow. I'd gotten bored of it by that stage, but I still have the code for that version somewhere so I might give the FFI framebuffer a go and see how it changes things.

I'd be curious to see how your performance changes when you have sprites implemented, the "plotting pixels" statement above really also includes the overdraw you get with sprites, especially if you have a really close one or two, you can end up filling up the whole screen a second or third time. Depending how you implement that you can reduce it massively though. If you use a z-buffer and sort your potentially visible sprites every frame you can probably eliminate sprite-over-sprites. I didn't bother sorting mine in the software version, and the GPU version can brute-force it so didn't bother then either.

Yeah, sprites will definitely be a small hit in performance but nothing to worry about. A 1D Z-Buffer and sprite sorting isn't a big problem, I know all the depths from shooting the rays anyways.

Overdraw isn't a big problem either. I'm reading and writing directly from and to the memory. The "slow" part is replacing the Imagedata in the framebuffer after you're done with setting pixels directly in memory via pointer.

You don't actually refresh after every single pixel, you write all the pixels into memory and Swap the buffer. I love working with framebuffers

Edit: but you're replacing the same amount of pixels every frame. It doesn't really matter how much objects you draw if the calculations aren't to expensive.

On the software rendered version of my Pseudo3D racing engine, it doesn't matter if I draw 100m or 10.000m, the performance is the same because the pixel count stays the same.

Hey, I am working on a raycaster and found this topic.

I wonder how you use ffi for the framebuffer. Do you have some small example code?

Nvm, found example code looking in your history.