SkyLock bitmap parser (with code)...

Here's the latest in my game's tech demo's. Sorry if this one's a little lengthy but I think it needs proper explanation.

The book that I learned (or should I say started) game programming from has an example of a very crappy, confusing bitmap parsing routine. The author even says that it's far from great and just there for teaching purposes.

Anyway, I needed a graphics parser to read through a bitmap that contains animation frames for a character and get the RECTs that contain the sprite, load those RECTs into an array and then tuck them away in a file (as an object) so I can quickly load them during the games initialization and use them in my blitting routines.

All code included except for GDIf.cpp/GDIf.h are soley mine in creation. The GDIf.* files are straight out of the book. They work fine for what they do, so I didn't bother rewriting them. The GDIf.* files is a basic GDI functions wrapper.

I'm not going to go into a ton of detail here since I've taken half of the night tonight to go back through and heavily comment the parsing files (tp.cpp/tp.h).

To test it click anywhere on the client area of the window. It takes about 6 seconds to parse it on my system (PIII 933, 128mb RAM).

**also, this tech demo features an update to the (formerly) boxy maintenance bot from the game**

Let me know what you think...

Here's the binary with a log file. Just put the asm.bmp file included in the above tpSource.zip into the same folder as this executable.

**btw - off topic**
When I first bought the book I learned from (back in Feb. this year) I told my wife "No matter what I say or do, don't let me buy another C++ book until I finish this one."

Man, am I glad I said that! This current book is good, but does little to give me the detail my game requires and at first I got frustrated with it. Had I bought a 2nd book I'd have just dropped this one and gone off on some tangent and never learned anything.

Instead I was forced to figure out for myself what my game engine would need and forced to figure out how to implement it. I've learned so much in the last 4 months because nothing was handed to me on a platter.

Sorry for the rant, but conquering a mountain through your own hard work feels great and I'm on cloud nine right now. :-)
**end off-topic rant**

Congrats Jdinger :)

Um either I'm doing something wrong or I'm expecting too much...

When I run the .exe I click on the viewing area, a box pop ups stating that it's going to parse the bitmap, I wait about 15 seconds, and then a box pop ups stating that the bitmap was parsed.and the log file was generated. Then after nothing happens...is that supposed to be the correct procedure? I don't think it is, so what is supposed to occur in the "nothing happens" part of it? I have all of the filres in the same folder. My PC isn't great, but it's sufficient enough (yes it does suck but it gets the job done)...500 mhz celeron, 384 mb RAM, win 2000. :)

EDIT: If that is the correct procedure, then I'm sure great things will come of it in the future.:) I'm not sure if you are showing off how some of the graphics will play out in your game, or if you are trying to help people by including the source to your graphics engine (?).

Quote:

---

Originally posted by TechWins
Um either I'm doing something wrong or I'm expecting too much...

---

You were expecting too much! :D 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.

Keep in mind this isn't actually part of the game engine, but a utility I'll use once I get into the actual content creation stage. It'll create data files that the engine will depend on for animations.

The only thing that this utility is missing is a section to parse "hotspots" or offset points. That is, a center reference point that is used to make sure that all the frames of a sprites animations line up correctly.

Quote:

---

or if you are trying to help people by including the source to your graphics engine (?).

---

That is one of the main reasons I posted it. That's why I posted the full utility source along with taking the time to fully comment the main parsing routine ( I'm normally bad about not commenting my source... *holds head down in shame* :( )...

I mentioned the other main reason above. That is, this is something that my engine depended on and I had to figure out how to do it on my own, so I was just sharing my joy with the world... :p elchulo2002 used the same book as I did, so he can vouch for how horrible the tile parser it shows is.

Ok, see I thought that you were including the picture of your robot in the file for that to be the presentation example. I thought the program would animate the file, but I was wrong. Anyways, though, good job.

Hey J, I like the robots new look. Its a vast improvment over the original.

I don't unserstand the purpose behind the complexity of that file parser. Couldn't you just find the size of the file in bytes then create a new array of characters of that size and read the whole thing into it at once ... instead of using all those complicated for statements? Or is that not possible?

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.