@Simeon - yes, it’s essentially a 2D horizontal scan. I also like the fact it’s based on what the car can see. It’s more versatile than doing a 2D scan against a memory map, because it doesn’t need any map and can handle objects moving around in the scene. Against that, it is just one row of pixels…
I’m guessing if you use the physics raycast function, it actually examines all the points between you and the horizon (unless it just examines the other physics objects based on their position and orientation), whereas the shader just draws one row of pixels and you can encode the z value in the colour.
@Ignatz I believe the physics engine will use a bounding volume hierarchy to quickly find the point of intersection (i.e., it can throw away large portions of the scene and quickly isolate the approximate intersection point). Other objects could be modelled as 2D polygons for the purposes of intersection tests. I suspect it would be the most computationally efficient. (Not that it really matters.)
Because your shader version is essentially “2D” (one row of pixels) you could make it a little more robust by scaling the map and all cars on the Y axis so they are infinitely tall for the purposes of rendering the collision row. This would ensure that the nearest objects are always detectable within the single row of pixels.
@Archimedes - the player stats are very simple, just position (vec2), angle and speed, ie 4 numbers.
However, the game would need some work, eg better collision detection, start and end, etc.
I’ll have a think about it. It might be better to start with a simple 2D game, which will be easier for other people to adapt.
wrt 3D, I may have other, more exciting options to choose from [past work], such as a large 3D dungeon, or a fighter plane dogfight, either of which would require very little socket traffic.
As soon as you have a workable socket setup, let’s talk about it some more.