Thank you very much for all the advice - I really appreciate it. I've just visited the tutorial you gave and I am currently reading through it. I wish you could buy a manual or something (I used to love manuals!) which could tell you exactly what each function does - I wasn't entirely sure what collision layers were before.
I do have some further questions though
1. Why does Max create a collison 'mask' showing what pixels have collided exactly - surely it justs needs to know that a collision has occured, not store the details. Is there another function that accesses this then?
2. When using ImagesCollide does Blitx just use a mask (like a 2 colour bitmap - black and white) for each image.
The program I wrote above was just a test to compare speeds because I thought that there shouldn't really that much difference between checking a small image with a small image AND a small image with a large image - given that the number of pixels checked should be the same. It just seems weird that I can only do 28 of the latter type of collision in a frame (60Hz).
I know my approach is somewhat inefficient but I was planning on using the power of modern PCs to save me programming time and make it very easy to add new enemies, obstacles and objects to my program. When I had my character going up a slope for example I could just check the next 2 positions up in a vertical direction using ImagesCollide and if the first one was free I'd move the character there, and if not He'd go to the 2nd one, and if he couldn't go there then the slope was too steep. It meant I could just draw my game background in Paint without much regard to actually defining slopes as slopes etc and I could just destroy bits of the background and my game objects would move happily about :)
Well this is really ineffiecient but I divided each frame up into 20 units and I never had an object moving more than 20 pixels a frame. This meant the most an object could move is 1 pixel before a collision check is done, hence objects never pass through each other or the background. I only actually updated the screen though every 20 units, so the objects weren't being drawn every unit.
I just thought this would not be too strenous for a fast computer, I can do 3000 of the first type of collision( small with small), so i don't think it was wildly optimistic.
I will definitely give collide image a go though. Are the 32 layers related to bitplanes at all, or are they totally different entities?
Thank you very much again for all the help - everyone here is very helpful!
Rico :)
P.S. I do eventually want to do a system using polygons, because I would love to do a 2d physics system for a platform game where you can shoot platforms down which tip and fall and where evvery object can be pushed or picked up - like Phun I suppose.
I do have some further questions though
1. Why does Max create a collison 'mask' showing what pixels have collided exactly - surely it justs needs to know that a collision has occured, not store the details. Is there another function that accesses this then?
2. When using ImagesCollide does Blitx just use a mask (like a 2 colour bitmap - black and white) for each image.
The program I wrote above was just a test to compare speeds because I thought that there shouldn't really that much difference between checking a small image with a small image AND a small image with a large image - given that the number of pixels checked should be the same. It just seems weird that I can only do 28 of the latter type of collision in a frame (60Hz).
I know my approach is somewhat inefficient but I was planning on using the power of modern PCs to save me programming time and make it very easy to add new enemies, obstacles and objects to my program. When I had my character going up a slope for example I could just check the next 2 positions up in a vertical direction using ImagesCollide and if the first one was free I'd move the character there, and if not He'd go to the 2nd one, and if he couldn't go there then the slope was too steep. It meant I could just draw my game background in Paint without much regard to actually defining slopes as slopes etc and I could just destroy bits of the background and my game objects would move happily about :)
Well this is really ineffiecient but I divided each frame up into 20 units and I never had an object moving more than 20 pixels a frame. This meant the most an object could move is 1 pixel before a collision check is done, hence objects never pass through each other or the background. I only actually updated the screen though every 20 units, so the objects weren't being drawn every unit.
I just thought this would not be too strenous for a fast computer, I can do 3000 of the first type of collision( small with small), so i don't think it was wildly optimistic.
I will definitely give collide image a go though. Are the 32 layers related to bitplanes at all, or are they totally different entities?
Thank you very much again for all the help - everyone here is very helpful!
Rico :)
P.S. I do eventually want to do a system using polygons, because I would love to do a 2d physics system for a platform game where you can shoot platforms down which tip and fall and where evvery object can be pushed or picked up - like Phun I suppose.