Sorry Scienthsine
I did read your post, its just that I caught up in learning how to use the collision layers as opposed to ImagesCollide.
Anyhow you are right, it does make a BIG difference when the smallers images are overlapping every frame, however I get do about 611 of these (on MGEs program he kindly supplied) before I get a frame drop, where as I can only do about 19 approx before slowdown on the small vs large image test. So there is a big difference.
Of course you are right about looking into alternative methods but it does seem odd it is so slow. Really to do one collision check (in my example) a function needs to check only 32x32 pixels against another 32x32 square. Thats why I wanted a faster ImagesCollide function when doing a small image vs big image check.
Do graphics cards have blitters?, I rember the old Blitz used to tell you if a blitter was available in certain gfx modes. Sorry if you thought I ignored your post - I really appreciate your help and input. Thank you very much!
To tonyG and MGE,
Thank you both for running the program and for writing a better one! (MGE). Yes I noticed that I can a very fast fps when the image is colliding with the background every frame. Maybe after detecting a collision once at a position it doesn't check again? until the image is moved ? I don't know how the collisions work internally.
My computer (well, I'm using someone elses actually)isn't amazingly fast but I am thinking of buying a new one. I will however have to change my approach, I like Dreamora's idea of just checking against the players immediate surroundings. I could chop the background up into 32x32 squares and then only check the 4 squares under the character (but still use CollideImages). I was wondering if there is an easy way to write part of a image to a collision layer, beacuse it would be ace if I could just write the 32x32 section of the background below the player to a collision layer.
The only thing is, is if I have a lot of objects moving around the screen all doing collison checks against the background I might end up effectively drawing the whole background to the collision layer anyway albeit in 32x32 chunks. Anyhow I can see ways this can be speeded up like Dreamora said. So I'll get to work on it
Thanks - Rico
P.S. Just tryed MGE's program using ImagesCollide instead of CollideImage and I get the same fps value. I thought you guys said CollideImage was faster! ;)
I did read your post, its just that I caught up in learning how to use the collision layers as opposed to ImagesCollide.
Anyhow you are right, it does make a BIG difference when the smallers images are overlapping every frame, however I get do about 611 of these (on MGEs program he kindly supplied) before I get a frame drop, where as I can only do about 19 approx before slowdown on the small vs large image test. So there is a big difference.
Of course you are right about looking into alternative methods but it does seem odd it is so slow. Really to do one collision check (in my example) a function needs to check only 32x32 pixels against another 32x32 square. Thats why I wanted a faster ImagesCollide function when doing a small image vs big image check.
Do graphics cards have blitters?, I rember the old Blitz used to tell you if a blitter was available in certain gfx modes. Sorry if you thought I ignored your post - I really appreciate your help and input. Thank you very much!
To tonyG and MGE,
Thank you both for running the program and for writing a better one! (MGE). Yes I noticed that I can a very fast fps when the image is colliding with the background every frame. Maybe after detecting a collision once at a position it doesn't check again? until the image is moved ? I don't know how the collisions work internally.
My computer (well, I'm using someone elses actually)isn't amazingly fast but I am thinking of buying a new one. I will however have to change my approach, I like Dreamora's idea of just checking against the players immediate surroundings. I could chop the background up into 32x32 squares and then only check the 4 squares under the character (but still use CollideImages). I was wondering if there is an easy way to write part of a image to a collision layer, beacuse it would be ace if I could just write the 32x32 section of the background below the player to a collision layer.
The only thing is, is if I have a lot of objects moving around the screen all doing collison checks against the background I might end up effectively drawing the whole background to the collision layer anyway albeit in 32x32 chunks. Anyhow I can see ways this can be speeded up like Dreamora said. So I'll get to work on it
Thanks - Rico
P.S. Just tryed MGE's program using ImagesCollide instead of CollideImage and I get the same fps value. I thought you guys said CollideImage was faster! ;)