Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(3 edits)

Very interesting and cool insights you got there, as always!  I'm curious about the freebasic or  inline assembly way to make it faster as I would presume this is how FastExt does this effect.

There is also this one idea that I am very interested with the outcome from Fredborg which RemiD described before that you might look into below. I guess you might use some form of light trails effect for the rays and perhaps you can have a go at it! ๐Ÿ˜Š

"the idea was to have a subdivided quad parented to the camera, have its vertices colored with the sun color, and use linepicks from the sun to each vertex, and set the vertices alphas accordingly (if a light ray can reach a vertex, alpha 0.5, if a light ray can't reach a vertex, alpha 0)
with blendmode add or multiply2..."



Interesting, but a ray resolution of 256x256 would be 64k Linepicks which might be slow too. Below 128x128 it becomes really blurry.

I was thinking of another simpler way of rendering the rays and then doing a 2D image mask on the objects in front so the scene will be like a 1 or 2 pass render to texture effect.

(+1)

Either way, while the FestExt library by mikail seems distincted online, luckily I found my purchased version on the harddrive, containing RenderToTexture. If time permits...

There's a copy on the blitzcoder forum as well for posterity. btw, would a normal render to texture work? not specifically using fastext..?

(1 edit) (+1)

Maybe I'm wrong, but as far as I remember Blitz3D doesn't support Render to Texture. The addition of Flag 256 allowed for faster access ("Store texture in vram"), but no direct render to texture. Copyrect from backbuffer to vram-texture is rather fast tho. Lockbuffer is slow and the actual problem. A way around would be:

render actual scene, without rays.
render mini version 256x256 and copyrect to texturebuffer (optimized with details like grass hidden)
render rays mesh alone ontop

This 3 render method does not allow for pixel access, so I'd use EntityColor 0,0,0 for shadow casting things, like in the source. Most important: no lockbuffer required. That should lower the 16 ms to 2 ms. The beauty of extracting the texture from the first render using readpixel etc. was, that its speed is independent from scene complexity, but well, it required lockbuffer, so..

edit: I just tried that, not significantly faster, unless I did something wrong. Then there was also a hack, to directly peek/poke VRam and Buffers, I guess using the memory.lib. Most likely not very stabile.

(4 edits) (+1)

Yes, I meant the copyrect function.

Do you think a rendertotexture function is faster than copyrect?

More interesting findings you got there! ๐Ÿ‘๐Ÿ‘๐Ÿ‘

btw, I did a decent benchmark which I posted on a new comment above as this nested replies is getting too long and narrow.. ๐Ÿ˜