If a 1/10 scale map of the U.S. were layed atop (and within the border) of a full scale map of the U.S., there would be at most one invariant point. In other words if Kansas City were the invariant point, then Kansas City on the smaller map would be directly above Kansas city on the larger map. ( An invariant point will occur even if the smaller map is flipped over)

Now consider the plane that is the domain of the maps and consider this domain the field of complex numbers...(real on the X axis, imaginary on Y). The origin for this argand coordinate system is the invariant point. To expand the map to any size we can merely multiply the radius vector (r) for any and all points by some constant value with a similar constant adjustment for the angle or amount of rotation. (A good basis for some coding i think considering that the amount of screen pixels is finite.)

Now windows of course uses square bitmaps and i'm thinking StretchBlt processes every pixel. I want to make a progy that stores bitmaps in an unconventional manner (any shape..were not talking square photos..a sphere is a sphere) and can expand or reduce their size quickly.

So as a starting point i want to know if anybody knows exactly how StretchBlt works. This could give me a good idea of whether it is even worth attempting considering execution speed etc. If StretchBlt already uses something similar then my idea is in the toilet.

Thanx for any info :alright:
Posted on 2002-05-20 21:58:05 by titan
"......Now windows of course uses square bitmaps and i'm thinking StretchBlt processes every pixel....."

titan,

StretchBlt merely copies or deletes vert & horz slices of the original.....

also, if you were to have a circular image in memory how would you define the memory block....it would still resolve to rects no matter how you did it.....

Brad
Posted on 2002-05-21 02:04:45 by Brad
this remembers me to the good old game "Comanche" on PC, that used something similar - a circular projection of a rectangular map, in combination with some height info. If I'm right, this was called "Voxel" space. If you are interested, I can look for some technical info texts. (I have an AMIGA assembler routine :) )

Another idea might be the usage of the panoramic projection, described here
Posted on 2002-05-21 04:18:29 by beaster
BRAD : The origin i refer to in my first message woul'd define the beginning of the data. After that any pixel set is just a radius vector and angle of rotation from that origin plus color data. A figure stored in this manner would require far less storage space than a rectangular bitmap since pixels that are not set are ignored. Of course you would not be able to depend on any Win32 api calls that normally work with bitmaps unless you defined the rectangular region around the figure. The point is to eliminate data that is not required to display the figure. Thanx for the info on StetchBlt. I can see the windows method is efficient when it comes to rectangular bitmaps but this is what i want to avoid.

Beaster: Thanx for the link. I'll check it out.
Posted on 2002-05-21 17:31:49 by titan