I'm working on a Software Rasterizer on a sub-30 MHz RISC CPU My current focus is on zooming-in on a slowly rotating planet. For maximum quality, no 3D polygons are involved with the planet - the planet texturing is purely image-based. This is what I have:
- the planet rotates only around Y axis and is always viewed straight
on with camera at the equator (so you can't see poles, hence the
default pole distortion artifact is not an issue here at all)
- midpoint Bresenham circle algorithm to compute 8 endpoints at each iteration, effectively giving me 4 horizontal scanlines
- simple linear remapping between texture row and planet's scanline - e.g. if the planet is 64 pixels tall on screen and texture is 128 pixels tall, I simply skip every other row
- same linear remapping within each scanline - e.g. if the current scanline is 64 pixels wide, and texture is 128 pixels wide, I simply skip every other texel in current texture row
The above works and is great as a first working and reasonably fast prototype. However, when the planet rotates, despite the low screen resolution, due to the simple linear remapping (within each scanline), it does not feel and look like planet rotation, as the perspective/distortion/stretching at the sphere edges (left and right edge of the circle) is obviously missing.
What is the equation that can give me the exact texture coordinate, for a current texture row, of each on-screen pixel of that circle's scanline ?
Please note that I can't afford to compute sin/cos (or use precomputed tables). Division is expensive, but I could perhaps hide its latency via interleaving with other instructions (while division is being computed). So, ideally, I could compute it just via add/sub/mul/bitshift. Obviously, due to symmetry, that computed coordinate will be reused for 3 other points, so we're in reality computing that for only 25% points of the circle.