Yes it is intended to check for collisions every update, this is just a test program to test with real quick, my inital test program had timers and logic fps and all that good stuff ;) i just ripped it all out to make this test for you all real quick, plus about it writing out side of screen with +14 ect ect, doesn't matter as its just a test.
Ok, what the true aim is, is have multipule user control lines running around on the screen that leave its trail behind, if you crash into a line then you die. Its like the game snake, except your line doesn't grow, its a line always left behind, i've looked at "snake" game examples, but they all use the TYPE method, of say holding each block of the snake in a type and moving around like that, but here i'm talking about pixels, and a huge screen, plus Many players on the screen at once, that would be alot of stuff to run through, and just seems to be a waste, when it would be so so simple to. Draw on background Image that guys are running all over, and if they collide with crap left on Background Image, then kill player. So Simple, but seems to be a bug in using imagescollide after doing a write to the imagesbuffer.
As you can see when doing imagescollide ever update is not a problem, it is very fast (draw something then move mouse around points you drawed, and see it collides and all that very fast, no stops) so that is not a problem at all, take out the imagescollide and then go and draw, drawing to image if Very Fast also. So why can't you draw to the image and then check for imagescollide
Ok, what the true aim is, is have multipule user control lines running around on the screen that leave its trail behind, if you crash into a line then you die. Its like the game snake, except your line doesn't grow, its a line always left behind, i've looked at "snake" game examples, but they all use the TYPE method, of say holding each block of the snake in a type and moving around like that, but here i'm talking about pixels, and a huge screen, plus Many players on the screen at once, that would be alot of stuff to run through, and just seems to be a waste, when it would be so so simple to. Draw on background Image that guys are running all over, and if they collide with crap left on Background Image, then kill player. So Simple, but seems to be a bug in using imagescollide after doing a write to the imagesbuffer.
As you can see when doing imagescollide ever update is not a problem, it is very fast (draw something then move mouse around points you drawed, and see it collides and all that very fast, no stops) so that is not a problem at all, take out the imagescollide and then go and draw, drawing to image if Very Fast also. So why can't you draw to the image and then check for imagescollide