I was searching around for posts that discuss movement and collision using Mappy and found this: http://www.allegro.cc/forums/thread/588658

Inside I found some code and this is what I'm trying to understand:

BITMAP *grabframe(BITMAP *source, int width, int height, int startx, int starty, int columns, int frame)
{
    BITMAP *temp = create_bitmap(width,height);

    int x = startx + (frame % columns) * width;
    int y = starty + (frame / columns) * height;
    
    masked_blit(source,temp,x,y,0,0,width,height);

    return temp;
}

I mean, I KNOW what it's suppose to do.. But, what the hell? Is it some kind of bitmap function? I was trying to use this particular piece of code (in C++), but it's kinda sketchy and I'm getting weird errors like undefined reference to vtable.

Suppose I should also mention I'm trying to use it in a class.

It returns a pointer to a freshly created bitmap using the following arguments:

<b>BITMAP source
This is a single BITMAP which acts as a sheet of sprites you want to grab a sprite from.

int width, int height
The size of each sprite on the sprite sheet. Each sprite on the sheet should be the exact same size and arranged in a grid.

int startx, int starty
Almost pointless. The top left corner of the grid. Most of the time this will be 0,0.

int columns
The number of sprites there are in a single row of sprites on the sprite sheet. For instance, if the grid has 80 sprites, arranged in rows of 10, you would use the number 10 here.

int frame
The sprite number to grab, from left to right then top to bottom. So given a 10x8 grid of sprites, sprite number 23 would be the fourth sprite in the third row. In a 7x15 grid, 23 would be the third sprite in the fourth row.

Since this routine actually creates the BITMAP object, you must store the result into a BITMAP pointer that hasn't been initialized, or is NULL.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

An "undefined reference to vtable" error generally means you haven't defined a function for a baseclass or one of it's children. The error has to do with your code in the class and not the function you posted, so it's hard to pinpoint with what we were given. If you are unable to find the error in your code, post the declaration and definition of your baseclass (and childrens') member functions, as well as the class itself.

I can't imagine how the code you posted could possibly generate that ...

It's worth mentioning that you are also responsible for destroying the object Just making sure you don't forget to manage your memory properly.

temp isn't a very good identifier for this variable. It's temporary in the sense that all local variables are temporary, but in the context of the function it actually stores the BITMAP of the frame you're grabbing.

Out of curiosity, is there an advantage to storing your frames as a sheet of sprites as opposed to an array of BITMAPs or self-defined FRAME objects? It seems that memory usage should be slightly less then if each frame had a separate BITMAP object.

Is the processing time of ripping frames from a sheet of sprites small enough to make it worthwhile getting them from a sheet every time you access them or is it better to store them as separate BITMAPs?

Or was that function designed to initialize an ANIMATION object with FRAME objects?

Ever heard of create_sub_bitmap

create_sub_bitmap() sounds somewhat more appropriate for this function (maybe), however, my question still remains. Is it common/good practice to leave your sprites on a sheet-bitmap and rip them over and over again to save memory or is it better to rip them once into memory (when loading the game or level and reuse them)?

It doesn't mater much how you load them, but a sprite sheet is generally easier to work with. You should load all sprites at the beginning of the game, and not unload them until game exit, unless you're making a really big game and targeting older systems.

Thanks everyone, I think I'm going to try out create_sub_bitmap. I guess that's what this guy was trying to make.

separate images is better.

the big bitmap is stored as a sequence of bits like so:

1478f92379e97397a7893478bc8976d987f

for example.

"image 1" (a box inside the bigger image) might be stored in

1478f92379e97397a7893478bc8976d987f...

whilest "image 2" (a different box inside the same bigger image) might be stored in

1478f92379e97397a7893478bc8976d987f....

etc.

If they are separate then each image is stored completely sequentially.

This probably has a very mimor performance improvement as the memory prefetch system gets more of what you want (as it has finite capability and is wasting less time).

That's about all there is to it. QED etc.

Of course, you're using more HD space by keeping them separate.

But then there's the argument for taking them in as one big bitmap and splitting them up on initialization.

This question has been done to death on the forum. Bottom line is, it doesn't really matter that much. Sprite sheets are generally a bit easier to work with, especially if you use a sub-standard sprite editor (say, MS Paint), and provide a natural way of bundling related sprites together, while single frames are a tiny bit more efficient speed-wise and will probably produce slightly cleaner code. The differences, especially performance-wise, are really negligible, so you should really just use what you feel more comfortable with and enjoy. No need to ponder.

I'm not so sure if I can really use create_sub_bitmap. It seems to be missing some parameters that this other function has, namely int columns and int frame.

My sprite sheet (bmp) looks sorta like this (each number represents the frame):

// yeah.. please try to picture this as 40x80 sprites. hehe

n  n  n  n  n // north
0  1  2  3  4

e  e  e  e  e // east
5  6  7  8  9

s  s  s  s  s // south
10  11  12  13  14

w  w  w  w  w // west
15  16  17  18  19

You would use it instead of this part:

    BITMAP *temp = create_bitmap(width,height);

    int x = startx + (frame % columns) * width;
    int y = starty + (frame / columns) * height;
    
    masked_blit(source,temp,x,y,0,0,width,height);

Like this:

    int x = startx + (frame % columns) * width;
    int y = starty + (frame / columns) * height;
    
    return create_sub_bitmap(source, x, y, width, height);

This way you can spare some memory space on those temporary bitmaps.

Hm.. But, how would that work if those two variables aren't even being used?

Err, they are being used. Specifically, they are being used for calculating the x and y a specific frame starts at. Once you know those, you have all the information about the frame (because the width and height is fixed), so you can create a subbitmap (look them up if you like) that represents the single frame.

I'm trying to avoid using the whole BITMAP *grabframe function thing since I can't seem to get it to work properly.

Edit:

What does "%" and "/" mean and do anyhow?

You really should start at the beginning. Learn coding.

Um. Just because I don't know what those two mean, means I don't know how to code? If you don't have a helpful reply, please don't reply at all.

Edit:

NM asked someone else about it. Thanks for your help.

Nor do you know math They are absolutely fundamental operators in coding. If you don't know what they are, you've missed a TON of stuff.

I may have missed a thing or two along the way. I've just never used these before, or seen them being used.. Well until now.

Sigged!

Isn't there a bridge you should be guarding? Like I said, there's the odd thing I didn't learn when I started c++ (like half a year ago.)

No, and yes, everybody misses the basic arithmetic operators when learning C++.

The basic what?

Like +, -, *, / and %.

+ is addition. It adds two numbers together. If I have 3 posts and I add 2 posts to it, how many posts do I have?
- is subtraction. It takes stuff away. If I have 2,000 posts and I get too trollish, so ML deletes 3, how many posts do I have?

• is multiplication. If ML deletes 3 posts from 5 users, how many posts has he deleted?

/ is division. If 430 posts are posted by 10 users, what was the average per user?
% is modulus. If I have 2356 posts and I want to have my number of posts be a multiple of 3, what is the closest multiple of 3?

God, BAF, you are too good.

Julian_Boolean: Are you sure you ever learn C or C++ ? Last time I was cool, but I should not have been that sweet. I told you something helpful. I told you to learn, and learning is always helpful. Now excuse me, but not knowing how to do a division while it is really basic programming... I could not have been more cool with you than telling you should go back to learn.

BAF: Thank you very much I already know/heard of the first three. I know division, I just thought / might mean something else. % on the other hand, I had no clue what that meant.

GullRaDriel: orly?

Oh, really, yes ?

I could have told you to RTFM, to stop programming, ... Else I told you to go back learn. So, oh, really, yes.

Just launch calc in Windows, and see, the division button, it is a '/' . Astonishing , isn't it ?

EDITED

Hi Julian,

This bit of code is to help you grab individual sprite frames from a sprite sheet. It's actually in a book called 'Game Programming All In One 2nd Edition by Jonathan S. Harbour' which concentrates on developing games using 'C' and Allegro.

An example is of a sprite sheet containing 32 images of a rotating ball, 8 columns wide by 4 rows deep. Each sprite image is 64x64 pixels.

What you need to do to make it work is to include this code (say in main()) for ease of showing it is as follows:

BITAMP *temp;

//load 32-frame tiled sprite image
temp=load_bitmap("sphere.bmp",NULL); // this is the sprite sheet
for(n=0;n<32;n++)
{
ballimg[n]=grabframe(temp,64,64,0,0,8,n);
}
destroy_bitmap(temp);

Before main() you need to include:

BITMAP *ballimg[32];
int n;

a quick re-cap of the grabframe function arguments:

temp = spritesheet (in this case sphere.bmp)
64 = pixel width of frame on sprite sheet
64 = pixel height of frame on sprite sheet
0 = x start position of 1st frame on sprite sheet
0 = y start position of 1st frame on sprite sheet
8 = columns of frames (in this case 8 cols x 4 rows)
n = frame number (get this from for loop statement)

You can have more then 1 set of sprites in a sheet and thats why you can alter the sizes of the width/height of the frames and where in the sprite sheet x,y to start grabbing them from.

Hope this helps, but if you need a demo i'll supply a complete code listing and graphics for you to play with

Yes! Thank you very much!

What I wanted to know was how could I do that in C++? (Please don't laugh at me )

// eh?

BITMAP* myclass::grabframe(...)
{
  ...
}

Edit:

Would it make it easier to take rows into consideration and use it as a parameter?

Sorry, I am only just learning myself how to use Allegro to create games, and I'm using the book mentioned in my previous post which uses C only, and I'm having to learn that too . I have no experience yet of using C++, so I can't help you with your problem

Uhm... what's not C++ about the original? I don't see many changes you can make to it, unless you put it in a class and make a whole animation system.

NM! I guess I was just doing something wrong, it compiles now.. But crashes.. BUT I get no errors! So I'm on the right track.

If it's compiling OK then ur code is fine. One reason it may be crashing, cos this has happened to me before, is to make sure that the graphics file is being loaded properly into temp - put an error checker on it to see if this loads in correctly first.

My brother actually has that book, well the third edition. I found a different function inside of it that seems to work better (it doesn't crash and even displays the first frame in the sheet!) But I can't move it around with my arrow keys.

Here's the function:

void drawframe(BITMAP* source, BITMAP* dest, int x, int y, int width, int height, int startx, int starty, int columns, int frame)
{
  int framex = startx + (frame % columns) * width;
  int framey = starty + (frame / columns) * height;

  masked_blit(source, dest, framex, framey, width, height);
}

I fooled around with it and it seems like it should work.

  drawframe(image, buffer, x_being, y_being, 80, 80, 0, 0, 8, curframe);

If I replace curframe with just a number, the correct frame will pop up when I compile it, but I still can't move it.. I think I might know what's wrong but I'm VERY happy this function works.

Edit:

Okay something is really screwed up:

It's still showing frame 0 on my sprite sheet for some reason.

Hum...

There is NOTHING magic in programming. If you need it to step one frame, you must tell it to do so.

The line drawframe(image, buffer, x_being, y_being, 80, 80, 0, 0, 8, curframe); will always draw the same frame until you make some change.

I see a curframe = 10, I do not see a curframe ++ or something else.

I think that you should really spend some times understanding how this (simple) function works.

Your point? I already found the problem and it a simple mistake (had nothing to do with the function.) After fixing it setting curframe to 10 works, obviously.

If you've fixed the problem yourself, you should make an addendum to your post, so that others don't keep trying to solve the problem for you.

Also, why does your function take x and y parameters if they're not being used?

First: You never wrote that your problem was solved.
Second: If you are initializing curframe to 10 without knowing why, you do not understand the function correctly
Third: If something need to change for you seeing the sprite moving, that is curframe.

Ending:
I never said there was a problem with the draw_frame function, I say there is one with the way you use it.

EDIT: beaten a few by LennyLen

They are being used, just not in the code I showed.

I set curframe to 10 so I could test to see if the proper frame would show up on the screen, using the x and y coordinates given somewhere else in the program.