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?

Maybe the easiest way is to use a rotating sprite...

formulas with sin/cosine are nice but you can't really use then to fill an entire circle.

If you do something like this:

for (r=0;r<50;r++){
for (t=0;t<256;t++){
x=r*sin(2*PI*t/256);
y=r*cos(2*pi*t/256);
draw_pixel(x,y);
}}

you'll see that there are points missing.

Shade8-)

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?

Johan, I think I have some old Allegro demo code of this very thing. I will find it on my HD later tonight and let you know.

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.

You could use ray-tracing. With this technique you can get perfect spheres, because it uses the sphere formula. I don't know how to do it, maybe someone can help you.

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.

How come I was just asking the same question? I've already tried to make my own one, but it doesn't exactly look like a sphere... or actually I didn't even expect it to... I KNEW it'd look like a pyramid with a circle bottom...

If I remember corrent the concept I'm using is:

For every upleft pixel: Count the current radius. Divide it with the maxium radius to get the number 'm'. Now, use a special function (I've got a wrong one) which gets the number 'm' and produces the number 'n'. Now we divide 'n' with 'm' and get the number 'k'. Then, the current upright position where we'll read the color is (centreX -k * (centreX -currentX), centreY -k * ( centreY -currentY )).
Current up-right, lower-left and lower-right coordinates can be calculated similar way using the same 'k'...

OK I somehow think I didn't get it correct. But what is this function that takes 'm' and returns 'n'?

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!)

"maybe it was plush or p3d"

I searched for both of them and it heavily seems they used 3D code and an older allegro version (and even DJGPP makefiles I think...) So....?

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

Yes, p3d was merged into Allegro. However, p3d did NOT do sphere mapping of any kind.

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 :-)

Ok ppl, here's some results then.

1) Paul Pridham mailed me some code by a guy named David Lenhart. I haven't really looked at it that much and I haven't managed to compile it, it uses some old version of allegro I think and I didn't bother. Get it here: [url http://www.dtek.chalmers.se/~d98peitz/junk/earth.zip]

2) My own version. Using lookup tables and is not very mathematically correct, but it's fast enough and looks ok. Instead of sphere-mapping I apply some kind of lens filter to the texture and shows. Get it here: [url http://www.dtek.chalmers.se/~d98peitz/junk/balls.zip]

Feel free ta ask questions and/or come with imporvements.

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 )

hmm, well anyone got a MingW32 edition of the code. I erased my DJGPP compiler because windowsXP forced me to.... or do you at least have an executable I can look at so maybe I can rewrite it if the effect looks good.

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.

Just this week I made a small program which draws a globe if you give it a rectangular world map.
circ.zip (245kB) includes code, exe and bmp.
The current orientation of the ball is stored as a matrix, and you can rotate it a few different ways. Lookup tables are used to convert each screen x,y to (x,y,z) which are converted by the matrix to another x,y,z which worked out which pixel of the rectangular map to use. Slow compared to polygons I think, but if you're using a small enough ball, you'll be alright. There may be room more more optimization in my code.

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.

Pucky's code works great too, and you can use spheres of any size, it also runs a bit slow, but if you cange teh putpixel to a direct memory access and maybe the sqrt() function in draw sprite to a fixed point notation some speed might be improved.. though it ran fast enough for me. I got about 140fps with a radius of 128, and 70fps at radius of 256, that fills the entire screen at 640x480. The effect is good, and you can rotate on all three axis.

Problems with code
- SIZEOFTEX undeclared, define it as 256
- Parse error line blah, add another )
- uncomment the *texture
- malloc your texture before creating the texture table
- FREE all used memory (all three pointers)
- psi, theta, and phi range between 0 and 255, going over will trash the look-up tables and the program.
- texture size must be 256x256x16, but it looks great anyway.

called like:

InitLookupTables();
texture = (unsigned short *)malloc(sizeof(short) * TEX_SIZE * TEX_SIZE);
CreateTextureTable("Earth2.bmp", texture);
do{
    clear(buffer);
    DrawSphere(phi, theta, psi, radius, texture, buffer, SCREEN_W >> 1, SCREEN_H >> 1); 
    blit(buffer, screen, 0, 0, 0, 0, SCREEN_W, SCREEN_H);
}while(!key[KEY_ESC]);

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.

Sorry about the sloppy code. I just lifted it out my test code, and obviously spent little time cleaning it up. Thanks Steve for picking through it and cleaning it up.

I had TEX_SIZE and SIZEOFTEX, which are the same.

I commented out *texture because the code could handle more than one.

Actually not quite true. The texture table is size TEX_SIZE x TEX_SIZE x 16. But when loading a texture, the texture could be of any size... it would just get crudely stretched to TEX_SIZE x TEX_SIZE. Also you can change the color depth of the texture table as well. A better stretching algorithm would improve the look of the texture. Also the element size of the texture table need not be 16 bits; it could be 8 bit or 32 bits depending on color depth.

TEX_SIZE is limited to 256 because it is stuffing two numbers into a short. TEX_SIZE can be expanded to 65536 if the lookup table was a 32 bit array. However you run the risk of the table not fitting in memory cache.

Also the code makes no distinction between texture size TEX_SIZE and the number of bits occupied by the low and high order data when stuffing the two values into one. A few tweaks and you can make this distinction such that TEX_SIZE need not be a power of 2.

Should have pointed this out earlier. Somewhere in the code, one should have psi %= TEX_SIZE; or the equivalent.

You can unroll the loop a bit along with direct memory access to increase speed. For example with 16 bit color:

Obviously you can do the same with 8 bit color by unrolling the loop 4 times.

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]

Steve: I did write an article about this.
Also, this code fades. It doesn't blur. And it only works with 5.6.5 packed pixel formats.

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.

to blend two colour by a factor, you first fade both colours: one by factor, and the other one by the negative factor (i.e. if factor is 0..31 then the neg.factor is 31-f. or f^31(xor operation)).
then you finally add the two scaled colours together, and got your blended version.

Thank you Johan.
I don't know if I will use your lens effect but I'm interest in graphic modifications like that.
Good work!