One more thing, these are 16-bit data types only. They are different if you are using 32-bit DJGPP or Windows. I only use these datatypes in 16-bit and 32-bit DOS code because it helps me logically (not computer-wise) mix C with assembly when the datatypes are alike.
But note that even in 32-bit assembly, a DWORD is still only 32-bits long (unsigned long). The C data types change, but not the assembly ones. This can be very confusing, but if you plan on writing low-level assembly functions you must be aware of this.
In general you should avoid using assembly data types in C code since they are system dependent. Notice that even though I've defined all these types as unsigned, in assembly an unsigned integer and a signed integer are both WORDs. It's just that one is using one bit as the sign bit. And because Intel/AMD CPUs use two's complement mantissa to represent negative numbers, the range of signed integer is -32767 to +32767. But in assembly, this is still a WORD.
MyFunction proc
ARG value:WORD
push bp
mov bp,sp
mov ax,value
add ax,1
pop bp
ret
MyFunction endp
In this function you could pass a signed integer but be careful. If you add 1 to 32767 on a signed integer, it will wrap around to -32768. So even though the sign of the data type is not evident from looking at the assembly source, you could prototype this in C in a couple of ways.
extern "C"
{
unsigned int MyFunction(unsigned int value);
int MyFunction(int value); //implied signed int
}
Both of these are valid prototypes for the assembly function. You could also write 2 more and switch the parameters around, but passing a signed int to a function that returns a unsigned int is useless since the sign will be removed in the result, and likewise passing an unsigned int to a function that returns a signed int is useless in most cases.
My bitmap drawing code is in assembly so if you do not know assembly, it would not help much to look at it.
Drawing a bmp in C is very slow and even slower if you must check for transparent pixels. But it would go something like this.
unsigned int row=0,col=0;
unsigned int x=0,y=0;
unsigned int sx=startx,sy=starty;
while (row<bitmap.height)
{
while (col<bitmap.width+bitmap.padding)
{
Retrieve pixel color or RGB from bitmap at row*width+col
Check for transparency
If not transparent
Draw pixel at x,y
else
Do nothing
increment x
increment row
}
Reset x to bitmap startx on screen (x=sx
Increment Y
Reset row (row=0)
}
This does not check to make sure the bitmap is actually on screen and does not account for the fact
that the bitmap could be leaving/entering the screen on either or both the x,y axes. There are other methods such as blitting one entire line of pixels using functions from mem.h.
