Is there a way to speed this up? The problem is because of a whole lot of _putpixel32 calls.

Or the _getpixel32 calls. What exactly is this function suppose to do?

http://img277.imageshack.us/my.php?image=ff5ee.jpg

Draws the football pitch in 3D.

First is to use floats and not fixed, second is to use some bitshifts (dividing by 2 is the same as >> 1), and lastly some direct memory access may speed it up by using the line pointers. I also see a lot of use of sin/cos with the same angle value, I would call those once in a variable at the upmost level you can so you aren't calculating it all the time. Lowering your Bpp to 16-bits will also make an improvement but you will have less colors, but judging by your screenshot you could do it in 8-bpp.

"First is to use floats and not fixed, second is to use some bitshifts (dividing by 2 is the same as >> 1),"

I think this won't give any significant speed. Those fix* routines maybe even do bitshifts themselves.

"and lastly some direct memory access may speed it up by using the line pointers. I also see a lot of use of sin/cos with the same angle value, I would call those once in a variable at the upmost level you can so you aren't calculating it all the time."

Maybe direct memory access hmm. How to use it? How to apply it in 16 bits and 640x480?
Second... from Allegro Docs looks like fixed trigonometry already uses lookup tables.

"Lowering your Bpp to 16-bits will also make an improvement but you will have less colors, but judging by your screenshot you could do it in 8-bpp."

Seems to work cool but no speed change.

I thought about returning to my first idea and to use the textured polygon3d function from Allegro, but I don't know if it would be faster. Maybe I should really switch to OpenGL w/AllegroGL. Would it be possible to use sprites without some bilboarding tricks, just by simple stretch_draw_sprite? Models would take out the oldschool feeling. I wanted to make crappy graphics to make it run on slower PCs but with this routine it seems impossible. Or maybe there's somewhere on the net an addon Allegro library with a draw_sprite routine with skewing (deformation of the sprites border rectangle), stretching and rotating. There's one for AA sprites so maybe ;]

The fixeds are fine, especially since he's using tight loops. Might be better to replace the fixtoi calls with >>16, though (not sure if Allegro inline's the function to do the same thing). Also, check out the exflame example for direct bitmap access. Specificly, you want the functions:

bmp_select
bmp_read_line
bmp_write_line
bmp_read32
bmp_write32
bmp_unwrite_line

compute bmp->w/2 and bmp->h/2 outside the for(...) loop instead of computing it each loop.

Use a Table of cosinus&sinus that you will have filled since the start of the program.(I dunno if fcos & fsin already do EDIT: they already do)

Try to avoid this line if possible, it is inside the loop and it is not needed if you check boundary correctly before

if ( fixtoi(space_x) > 0 && fixtoi(space_y) > 0 &&
                 fixtoi(space_x) < tile->w && fixtoi(space_y) < tile->h )

So that direct memory access... I have 16 bits 640x480 bitmap so bmpread32 would get two pixels of the image at once and I would have to do a 320x480 loop -- correct?

Yes, though you could use bmp_read16/bmp_write16 instead of having to worry about endian issues.

If they did, they would first have to check to see if the number is a power of two. When multiplying and dvividing by powers of two, always use shifts. When using normal arithmetic, the compiler is smart enough to convert "/2" to ">>1", but if the arithmetic is embedded inside a function such as fixdiv(), it is no longer possible for the compiler to optimize.

Also, once you've followed the advice above and pre-calculated as much as you can outside the loop, you should acquire and release the bitmaps to save the bitmaps from having to be locked each time. If you are writing to a memory bitmap or if the screen-memory on your platform does not require a lock, you won't get a speed increase, but otherwise, you will. Have a look at the following functions:

acquire_bitmap
release_bitmap

Oh, and in case you haven't done so, use your compiler's optimization flags to optimize your code.

polygon3d[_f]() can do this. Give it your sprite as a texture and an array of 4 V3D[_f] for the corners. I'm not sure you want this tho. I suspect you just need stretch_sprite() to get the effect you want.