I planning a game where the player rolls balls around. Very exciting.

Anyway, I need to map a texture on a 2d circle so that it looks like a ball in 3d. The texture is 64x64 in this case and the ball is a circle with a radius of 16 pixels.

What I would like is a lookup table for the circle so I know what pixel to draw from the texture.

Has anyone got some cool mathematic formulas or something for this? I'm pretty sure someone has posted a question like this before and that someone else wrote something with a picture of the earth mapped on a circle... Any ideas?

Hmm... Maybe I didn't express myself very clear. I don't want to simply rotate a sprite. I want to wrap a texture around a ball.

The thought was to create a lookup table for a circle and the map the texture to the circle. The effect of getting the ball to roll would be achieved by shifting the texture. But! How to I calculate the lookup?

also there's this library once made for allegro, maybe it was plush or p3d...whatever, it had several routines for rendering "3d" spheres, i.e. the all-famous, vectorballs having their textures projected and even shaded in different ways. it doesn't include perspective warp, but you don't actually notice that for spheres unless they're very close, or your fov is very twisted.

I posted code to do this on [AGP] a little while ago. I'm not at my computer (for a few months), so I can't send it to you. Perhaps you can ask there if someone still has a copy of it.

hmm...if anyone finds a good sollution/explanation to this problem, please post info here!
however, it might prove interesting too look for people mad about maps...
I've once tried to map a texture onto a sphere using (quite logical...) spherical coordinates, i.e. for each vertex I calculated the latitude and longitude angles and just made them u and v!
this "worked" pretty nice, but distorted the texture somewhat, so you have to be careful when drawing it, expecially the area around the poles will be somewhat warped together!! I believe there's other ways to map square textures to a sphere that give better results.
for 2d (without any 3d model in between) you'd have to go raytracing...sounds complicated, but for a simple sphere it's quite easy and can be optimized a lot...
another idea that might be even faster would be to implement one of those classical 2d lens effects (basically an array with texture offsets that warps anything it's applied to a bit like a magnifying glass). by calculating the lens like half of a sphere and scrolling/rotating the texture underneath, it might also do the trick (quite fast even!)

wasn't p3d slurped up by allegro? Or did it get removed?

hmm, it could be that it was called "more3d". yes, it's quite old, but it had this textured sphere rendering code that wasn't actually fast, but worked fine :-)

hehe well, and I finally remembered (& then searched my hd, and even found!!!) the library that was able of doing "3d" spheres!! actually the code is quite messy to read, but it works and it's also quite good commented...the name was AllegPak!! (har, the only one allegro 3d lib I hadn't mentioned yet )

Some years back I played with a spherical texture mapping algorithm using lookup tables that was developed by a Hans Kopp. I apparently don't have his original source, but I found my variation of his algorithm written for Allegro.

His algorithm in a nutshell: It is relatively easy to wrap a texture on a sphere for rotations about the sphere's N-S pole axis. For this you need a lookup table from pixel coordinate to spherical coordinate. Add the rotation (longitude), and finally convert spherical to texture coordinates. The problem is when you want the sphere to rotate on all 3 axis. Hans' solution was to recognize the ease of rotating on a N-S pole axis and so created a lookup table that transformed a spherical coordinate such that one of the E-W axis is rotated to the N-S axis. After the coordinate system transformation, just add the now-longitudinal rotation. Perform this transformation once more, and you have rotation for all 3 axes.

Hi Johan,
I read your code, very impressive result with so small things
Have you found this lookup table ? I'm no sarcastic.
I have not complete understand it (render_ball) but I'm working on it!
I'd like to use some stuff like this in my games.

Kloks, glad you like it. I made up the lookup table myself. I had a general idea of what I wanted and then I tweaked it until it looked ok.

It is not by any means a very stringent way to solve the problem. Also, it does not map a texture on a sphere. It's more like a lens funciton on a texture, giving the impression of a ball. This is mostly noticeable on the red/white squared ball. All squares are really squares, and this is not possible on a sphere.

Feel free to use what ever you want of the code.

hehe, cool, well it doesn't give much of a speed-up using the 32 bit packed way, and oddly it gives some weird fuzzy stuff around teh pixel blocks the other one doesn't have. That's okay anyway. But now i'm wondering if anyone has any tutorials on how to do the packed routines. I've tried incorperating them in other functions I've made and it doesn't quite work. My way was just doing this:
((short *)dest -> line[y+center_y])[x + center_x] = texture[alpha_beta3];
which gave the same amount of speed-up.
Another method I've ran across is this:
color = (color |(color<< 16)) & 0x07E0F81F;
color = ((color * alpha)>> 5) & 0x07E0F81F;
color = color|(color >> 16);
for doing faster blurs, it also does not work:'(
Oh and be sure to check that y+center_y and x+center_x are within dest->w and dest->h or you will murder the program.
I'm kinda new at learning how to optimize in Allegro, but I caught onto fixed point, bitshifts, and vectors fast.
For now i'm forced to use:
r = getr16(color);
r*=a;
g = getg16(color);
g*=a;
b = getb16(color);
b*=a;
((short *)src -> line[y])[x] = makecol16(r, g, b);
which is quite um .. crappy.
[edit]
The color = (color | color << 16... stuff i'm not trying to put that into yoru function, i'm just wondering if there are any tutorials or if someone could help me out on incorperating that into my functions.
[/edit]

hehe yeah i've seen that code before, yes it takes one pixel and fades it by a factor from 0 to 32. I think it was used in fade16.c which worked ok. I think i'll just have to play with the code a bit more. I also had an example of blending two colors using the same technique, but I misplaced it or something.