I'm sorry, but I also don't know what the problem is. Could you elaborate on:

What's happening?

How is it reproducable?

What should happen if the code was well-formed?

Following are a few suggestions, which as I always point out are meant as suggestions, and are of course neither mandatory nor objective, so add a "imho" to everything I say

A construct like this:

int i =0;while( i < SOMETHING ){/* do something */
i +=1;}

Is better expressed with a for loop, like here:

for(int i =0; i < SOMETHING;++i ){/* do something */}

It's not wrong, mind you, both work just fine.

On a similar note, assuming you won't need i to be a specific value later on, this could be rewritten:

int i =0;while( i < SOMETHING ){/* break out of loop */
i = SOMETHING;// <-- this line I'm talking about
...

Breaking out of the loop can be achieved by making its condition false, but what I saw in your code, you don't need to execute the rest of the loop body, and you also don't access i in any way that it'd be important that it had the value SOMETHING.There's a keyword for exactly that situation, namely break, which I find fits better here. There's another side of the coin, though, as break tends to make analysis of program flow somewhat more complex a task, which is why you'll find some programmers opposing its use. I don't want to get political about that, so I leave it up to you to decide - just pointing out another way (if you already knew that, you can ignore this comment ).

Some of the formatting might have been lost somewhere during the copy & paste, however I feel obliged to point out to follow at least basic indentation rules. I'm sure Google will know something about them.

In your class part, the member active is declared as int, however it is used like a boolean variable. I suggest using bool instead, because that's the data type you really want here.

Sorry, I was rushed when I wrote that. During the game, blocks fall from the top of the screen. You need to draw lines through them using the mouse to cut them. For the blocks to be hit, the line needs to actually cross through the object's on-screen image. Right now, attacks will sometimes hit blocks near the top of the screen, even if the are on the opposite side of the screen form where you drew the line.

If obj_x > obj_size*3/2 or obj_y > obj_size*3/2 then this will be a white square from outside the screen buffer.

Then check if any pixel in the buffer except those on the right or

bottom are light blue.

This doesn't seem to have anything to do with checking if a line cuts an object. My advice would be to start is_cut from scratch after asking how to do so in this thread. Try looking up do_line, it might be a good start.

If the writing above has offended you, you've read it wrong.....fool.And if you read that wrong it means 'All of the above is opinion and is only to be treated as such.'

The is_cut function does the following: using its arguments, it grabs a portion of the bitmap (obj_layer), and scans it for LIGHT_BLUE pixels. LIGHT_BLUE is a color used ONLY in the slash lines. The -1 to obj_size are because position starts counting at zero. (If you have a bitmap 100 pixels wide, the far left will be 0, the far right will be 99)

My bad, I got the source_x/y and dest_x/y back to front again:-[. Good thing 4.3 has a better format. I also assumed you wanted to check the line to see if an object was under it rather than check each object to see if the line is on it.

Quote:

The -1 to obj_size are because position starts counting at zero.

Then you want:obj_y <= obj_size-1but:obj_y < obj_sizewill be slightly more efficient.

On a side note: It would probably be more efficient to create clip_board in main() and pass it to is_cut so it doesn't have to be created and destroyed for every check.

If the writing above has offended you, you've read it wrong.....fool.And if you read that wrong it means 'All of the above is opinion and is only to be treated as such.'