Yes, by using

if (bmp1 == bmp2)

However, the code you posted will not yield that result, because those two BITMAP* objects do NOT point to the same image. They point to two different images that happen to have the same color values.

If you want to check for that, you will need some (expensive) function to check for you.

I would suggest you rethink your design if you need this function. Perhaps keep a global array of BITMAP*s and instead of checking to see if two objects have the same color info, you can just check the index of their pointer.

ie.

BITMAP* bmpArr[20];
...
class Object
{
private:
    int m_bmpIndex;
    ...
};
...
if (Obj1.GetGfxIndex() == Obj2.GetGfxIndex())

A more creative solution for if you are doing a lot of putpixel-y stuff, wrap the BITMAP object in a class that puts pixel for you and adds the color value (adjusted with the x-y coordinates of where it's putting it) into a long int (maybe more memory, even) that can keep track of the value stored in a compact fashion. In effect, what you're doing here is hashing the BITMAP, so you only need to make a couple cheap integer comparisons.

If this is a large-scale deal, I bet there's a magical pattern-detection algorithm somewhere on Google/Wikipedia. If you just want it done, just go brute-force and _getpixel and compare everything.

Hm.

pseudocode:

make a scratch BITMAP
while there are tiles to get
  while possibilities > 0
    get the next pixel and put it to the scratch BITMAP
      for every BITMAP in possibilities
        check current pixel with same pixel from possibly-matching BITMAP
        if it's not a match, remove possibly-matching BITMAP from possibilities
      if we're on the last pixel, and there is still a BITMAP in possiblities,
        we have a match, so ignore this tile (since we already have it)
    if we're not ignoring this tile,
      we have a tile that doesn't match any already in memory,
      so copy the scratch BITMAP to the list of unique tiles
    re-fill possibilities with all unique tiles you've found
  get the next tile

Questions?

I would just go with my pseudocode, I don't think he's looking for anything high-performance. A hash would be optimal in terms of performance, but for performance vs. time spent coding, I think a brute force method that at least weeds out non-matches is good.

I guess it does depend on the tileset, though.

Wow, there are a lot of repeats. Maybe you should use a hash.

http://luneknight.com.ru/games/test.PNG
OK, here's a BMP. I originally didn't post a BMP because, well, you know the filesize on these things is huuuuuuuuge.

The check that I've implemented (still crashes though because I can't seem to get it find the right number of unique tiles before saving them. It says there are 650 unique tiles...but crashes when it tries to save the 130th because it doesn't exist) says there are 129 unique tiles in this map. I'm not sure if that's true, I guess I'll have to manually check each to see if this working properly.

EDIT-- Made the image a PNG

I didn't think Paint was any good at saving PNGs. I seem to remember trying to save one before it getting a bigger filesize than BMP. Oh well, guess I'm corrected here. Image editted to be a PNG.

Got something that works (let's just assume it does because I don't want to manually check). Even made it output the tiles into a nice little tileset (although a little disorganized and that grass is a bit too variable, making it seem like there are repeats. I may ease the test so that it might eliminate some of this that are so similar.):
http://luneknight.com.ru/games/set.PNG

What I did was divide the map into each tile. Then I took the first tile and compared it to the rest, comparing every other pixel. If a pixel was not the same, I aborted the test for that tile and went to the next. If the testing tile was determined to be the same as the first tile, I deleted the testing tile. I then put that first tile aside and chose the next non-eliminated tile and repeated the process.

I think that's pretty much the same as Kibiz0r's psuedo-code.

Thanks, everyone.

Yeah, I used the same image.

Looking at your method, I'm guessing that you added 63*pixel_number in an effort to not miss out on a unique tile because it happens to use the same colors the same amount of times as another tile. But couldn't a tile be set up in a way that it is different from another tile, but still generate the same hash? I don't really understand how the hash in generated...

What I did was first ripped EVERY tile from the image and put them into an array. Then I ran through this loop:

It's entirely possible (and I hate to say this, but probably likely) that there's a bug somewhere in my check. First off, unique.size() returns a value of 650, which is why I added the incrementation of deadTiles, so that I can just subtract that from the total of the number of tiles in the map to get the number of unique tiles so that I don't go out of bounds of the vector unique. Plus there's a lot of embedded loops which only complicate things...

Hash collisions are fun.

Yeah, the brute force is pretty much instant. Maybe if the maps were super huge with even more unique tiles then it would be slower, but it gets the job done.

At least Matthew's method seems to arrange the tiles nicely...

Neil Walker has done work on this sort of thing — see his Game Mapping Tool. VB source is included with his download if you want to check out whatever he is doing...