Invincible, if I understand your question, I'm not reading in the bitmap pixel by pixel. I'm searching through it to find out the extents of the actual sprite RECTs. This way (as an artist) I'm not confined to a set size of sprites.
Knowing the RECTs that encompass the individual sprites allow each of my characters can have unique sizes (along with each frame of their respective animations having unique sizes).
Each of my sprites has a max size limit of 240x180. The sprite's individual frames can be any imaginable size up to 240x180.
Without this I would have 2 options: 1 - Blit a 240x180 pic for every sprite frame (this would be a huge waste) OR 2 - Be forced to restrict every sprite animation to a pre-defined smaller RECT (which would really limit the artistic side of it).
Here's a generic example of what I mean:
Animation 1 frame 1 (idle, hovering) for my ASM bot is 79x78.
Animation 2 frame 1 (shooting) for my ASM bot is 83x90.
Like I said before, this is only a tool that I will use when I start to add content. The only thing relevant to the end game is the CTP object itself.
I didn't include it in this example but the output of all this is taken care of with:
Code:
HANDLE hFile=CreateFile("asm.dat",GENERIC_WRITE,0,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);
DWORD fp=0;
WriteFile(hFile,&ctp,sizeof(CTP),&fp,NULL);
CloseHandle(hFile);
Which runs SO much quicker than the HDC hungry parser. End game players won't even need to know that the parser ever existed.
And then in the game when I need to load the CTP extents I'll just use:
Code:
HANDLE hFile=CreateFile("asm.dat",GENERIC_READ,0,NULL,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);
DWORD fp=0;
ReadFile(hFile,&ctp,sizeof(CTP),&fp,NULL);
CloseHandle(hFile);
The alternative to making this file parser would be for me to scroll through each frame of my animations (for every character) in Paint Shop Pro and figure out the extent RECTs then hard-code (which would make upgrading/changing graphics a nightmare) them. Considering the final game will have dozens of uniqued characters with a minimum of 128 frames of animation each, doing it the long way (ie: scrolling then hard-coding) would take ages.
What you see here is the jist of the utility. It scans a series of animation frames in a bitmap and retrieves the rectangles that encapsulate each one. Without a bitmap parser all of your graphics would have to be of uniform size in order to blit them in the right place.
)...
elchulo2002 used the same book as I did, so he can vouch for how horrible the tile parser it shows is.
