what is the fast method?, 1)use iterative loops 2)memcpy 3)other.

Direct memory line access? Depends really what depth you are running at, you can use block memory access in 8bpp, or 32-bit words at a time in 16-bpp, etc.

direct line access is the first option right?.
When Im mean iterative loops is:

for(int x=0; x<bmp1->w ;x++)
 for(int y=0; y<bmp1->h ;y++)
  bmp1->line[x][y] = bmp2->line[x][y];

Right...

3) MMX.

But then again, you didn't specify video/memory/system bitmaps and the destination, and also any blending.

this is the fastest method?, ¬_¬ ....

Depends on how much time you want to spend on your custom blitter MMX is great but it is kinda complex.

Bitmap line array works as line[y][x], but remember about different bits per pixel count in different formats. Also you should blit in rows, not in columns, to make better use of cache. Using memory pointers can help a bit too.

int y,*s,*d,*e;
for(y=0; y<bmp1->h ;y++)
{
  s = bmp1->line[y];
  e = s + (bmp1->w*bpp+3)/4;  // bpp = bytes per pixel
  d = bmp2->line[y];
  while(s<e)
    *d++ = *s++;
}

And MMX is completely useless in blitting unless you are doing blending in 24/32bpp, since it just gives additional math operations and none are required here.

are you sure this is the fastest method?, memcpy seems more useful, it dont iterate... just take a block of memory a copy it to another-

I'm not saying memcpy wouldn't work however that will only allow you to copy a bitmap, not manipulate it or make a custom blitter, why not just use blit instead?

You can move 8 blocks of data using the MMX movq operators, instead of the one block at each time with memcpy. Problems: target machine should be MMX enabled, the addresses should be aligned, and the array should be 4x multiple. I have the code at home, will check it out later.

Just blitting straight to the screen is extremley fast (I can pull thousands of frames per second). Its putting that data into memory first, then to the screen thats slow (ie double buffer)

Faster way will always be using DRS instead of updating the whole screen.

of course memcpy iterates, how else would it move more than one piece of data?

I dont know its code. but at least it just does one for(), not 2

What exactly are you trying to accomplish, we may find the best method for what you want to implement.

Kris, There is a difference between manually iterating (using a loop and jump) and letting the processor iterate for you (like, in example, using repnz movsb):

ah cool, didnt know about that, no wonder it's so fast :B

I'm not sure, but I think that my method and any other which should be faster than it will be memory bus limited anyway.

And of course fastest blitting method is to use HW acceleration.

Wouldnt bother writing your own blitting methods unless blending is applied tho, if even then.

I really don't think it's worth spending the time trying to optimise things like this. Doing the rest of the program is more important..

who likes to optimise blit?

Well, first optimize your game fully. You don't try optimizing printf, you try optimizing your program so that it won't use that many first.

Er.. your thread title is 'fastest blitting method'

(And I didn't say blit, I said things like this..)

read my sig

Can someone explain to me what the hell is going on? Optimize blit or optimize your code, if you need to optimize your code then it has nothing to do with blit, make your algorithms faster, not blit.

Fastest blitting method is, as KK said, your video card's video ram->video ram accelerated blit.

End of story!
And as far as actual time is concerned, the fastest blitting method is:

blit(something);

because you don't start a thread like this, waste time debating things, and blit is only 4 letters!

Ive never said that Im trying to optimise.
I just like to know, like my topic says, what is the fastest.

ReyBrujo explained me why is better memcpy() than use loops, that was what I like to know.
Thanks!.

Here is the code I used to optimize. Note that, if the processor does not have MMX support, it just copied with memcpy. Of course, the bitmaps must be aligned, and you cannot use these with the screen bitmap. I tried it a couple of times with that old project (DRS system), and worked quite fine. I can tell you it won't crash unless you don't meet the requirements

thanks one more time reybrujo!.
Im not trying to optimise, my idea is try to make my own blit, so I can use it in a machine without allegro.

I agree with Richard, make your game first, make it run faster later.
But of course, all of us want to own the faster blitter ever made.

people you are crazy!, Im not trying to optimise!!!!!!!!, ahhhhhhhhhhhhhhhhhhhhhhhhh

Then say that you are writing your own blitter, it makes more sense now. Since you are not using allegro I'm not sure what you are using, if it's good ol mode 13h then memcpy would work best since you probably have your bitmap stored linear anyway as well as the screen, just beware the screen "wraps" around