Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Badazz T

Animation with bitmaps..HELP

This topic is 5195 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

If it matters the language I''m programming in is Blitz Basic but here''s my dilemma...I am trying to create animation with my images in Paint. Well, how can I? I have my image but I don''t know how to make the animation show up on the screen when I compile the code. I''ll tell you what my book says to do.... "Now, to put these(2 images you''ve created) together in a bitmap we need to use our favorite paint program.(I use Paint Shop Pro, which is included on the CD.)I created both images, and put them together in one single image..." What the Heck?! And here''s the code.. Graphics 800,600 ;Handle the images from the center AutoMidHandle True ;Load animated rectangles rectanglesimage = LoadAnimImage("rectangles.bmp",250,250,0,2) ;Create variable that counts how many rotations have occured rotationcount = 1 ;MAIN LOOP While Not KeyDown(1) Cls ;Locate the text at the top left corner Locate 0,0 ;Print the # of rotations Print "Rotation Count: " + rotationcount DrawImage rectanglesimage,400,300,rotationcount Mod 2 ;Increment the frame rotation count variable rotationcount = rotationcount + 1 Delay 100 Wend Print "Press any key to exit." ;Clear the key buffer FlushKeys WaitKey That was thier example, but when I write the same code but try to load my image, in RunTime it shows both pictures in the second frame and sometimes shows only one. Anyone got any Ideas? How do you make a bitmap???

Share this post


Link to post
Share on other sites
Advertisement
This sounds pretty language specific...I''ve heard of animated gifs (which I don''t think are something people would use in a serious game), but never a self-animated bmp file?

To animate anything with bitmaps, you should have two or more ''frames'' (like one with right-leg front, one with left-leg front) and you alternate blitting each to the same location on the screen, or - in the case of walking - moving it a "step" at a time across the screen as you alternate. You want a delay between blitting image1 and image2, but you don''t want the entire game to wait up for it, so you should blit it based on the timer.

From your book reference it almsot sounds like your compiler/language has some sort of special case for it, so you might be on deck for some research. Or someone else on the board might have familiarity with what you''re using in particular.

Share this post


Link to post
Share on other sites
It just occurred to me that what you might be saying is that the two bitmaps are side-by-side in the same bmp file. So you have (as I said before) left-leg front and right-leg front side by side like frames on a film. In this case you do as I said - alternate which you blit to the screen - and instead of blitting from different bmps you blit from the same one, but first from one side and then the other.

Personally, though I might store it that way on disk, I''d likely split it up into individual bitmaps in mem and go from there.

Share this post


Link to post
Share on other sites
I am not familiar with blitzbasic but the basic principle behind loading a single bitmap with multiple frames of animation on it and making it appear to be animated on the screen should be the same. In pseudo code the process looks something like this:

(excuse the C style syntax, been a while since I''ve looked at basic)

memory_surface = load_bitmap( "ninja.bmp" );

source_rect[0] = the bounding rectangle around the first frame;
source_rect[1] = the bounding rectangle around the second frame;
etc....

while()
{
frame = next_frame; // next_frame would obviously wrap back to 0
// draw will look different depending on the graphics api etc
// but they are mostly the same. You perform a bit block
// transfer (blit) of a rectangular region (source_rect) from
// one surface (our memory_surface) to another (the screen).
blit( memory_surface, &source_rect, screen_x, screen_y );
}


While I mentioned before about not knowing blitzbasic, it looks like you are sending the bounding rectangle of the whole image instead of just for the frame you want but I could be mistaken in how the DrawImage function works there.

Evillive2
E-Mail

Share this post


Link to post
Share on other sites
Maybe I should''ve mentioned I just got into programming not to long ago..I have no idea what you mean by left leg font,right leg font and blitting...

Sorry if my ignorance is causing trouble

Share this post


Link to post
Share on other sites
Think of "BitBlt" or "Blit" as another word for draw. BitBlt being short for "bit-block-transfer" or something of that nature. This means we TRANSFER a BLOCK of BITS from one place to another. In this case, our block of bits is a rectangular region of pixels or of you prefer, a rectangular piece of a bitmap. For the most part while dealing with 2d graphics, you can only draw to and from rectangular regions. Bitmaps are basicly a grid of tiny dots of color. For example the raw data for a black and white bitmap that said "HI" would look something like:

001100011000011111100
001100011000000110000
001111111000000110000
001111111000000110000
001100011000000110000
001100011000000110000
001100011000011111100

where 0 would be black and 1 would be white. If each number represented a pixel, then this bitmap would be 21 pixels wide by 7 pixels hi.

If we wanted to draw this bitmap to the screen, we would first have to load it into a memory format that the graphics API we are using can recognize. Not being familiar with BlitzBasic I cannot help you there but I am sure there is a tutorial that explains the process better than I could.

The next step is figuring out what region of the bitmap I want to display. For the sake of 2d, these regions will be rectangles as mentioned before. The top left pixel of a bitmap is (0,0) of the grid and the bottom rigth corner is (width, height). The same applies for the position on the screen. If I wanted to select only the H in my bitmap, the rectangle would start at top left (0,0) and end at bottom right (7,9).

Now that I have my image in a memory format the graphics API can understand and I have a region of the image I want to draw, I can draw that image to a place on the screen. This involves tranfering a block of pixels from one area in memory to another (usually the screen or a back buffer). Most 2d API''s will require you to specify:
1. where the image is in memory.
2. what portion of the image to copy (rectangular region).
3. what is the destination memory to copy to.(the screen)
4. where to draw it.
5. some sort of flags.
As a side note, where to draw it may be a point or a rectangle depending on the API. In the case of it being a rectangle, some 2d API''s will stretch/shrink the image to fit inside the destination rectangle, others will ignore it and some others will only draw what fits into that destination rectangle. This action is specific to what API you are using and/or what your video card supports. In the case of it being a point, this usually refers to the location to start drawing the top left corner of the image.

When serratemplar was talking about right foot forward, and left foot forward, they were more than likely talking about frames in a walking animation. Take a look at my sig for example. The image there is an animated gif made up of a total of 8 different frames repeated over and over again in a sequence. This effect can be achieved by the same method I mentioned above.

Hope it helped.

Evillive2
E-Mail

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
first of all rotation count should should be 0. also make sure the frames are the same size as your largest bitmap and use those dimensions.the bitmaps shouldnt overlap

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!