Hey guys, quick question here. How many pixels can be raytraced or raymarched per second on a mid-range CPU these days?
The application is this: I want to do a game similar to 80s style games where there were a limited number of sprites active on screen at once. The sprites will be depth sprites with a color map (texturemap), a normal map and a height map. If the sprites were 64x64, how many of them would it be possible to raymarch per second?
Further, what if the raytracing was cached for a few frames? EG. we raytrace four per frame, and we have a total of twelve onscreen at once, so the shading and hilighting only updates for each object once every three frames? Are getpixel routines fast enough for this?
Furthermore, perhaps even tilemap tiles could receive some sort of dirtyrect treatment-- the initial picture of a tile would be raytraced, but tiles under the effect of a light or shadow (determined by quick and dirty methods) might also be raytraced.
What if the main light is coming from a standard direction, eg. 45 degrees?
Of course any rational person would use OpenGL. But I am not a rational person.
Am I chasing my tail here?
Let's say we allowed ten to be raytraced per frame. If they were 64x64, that ends up being 6400 pixels, or an 80x80 window. Surely even midrange PCs could handle that, yes?
