Sorry your browser is not supported!

Hi Lee/Paul,

I'm trying to implement Pixel Perfect Collision detection, which basically works by detecting a bounding rectangle collision and then testing for a pixel perfect collision by creating a memblock and intelligently working through the pixel data.

However....

Whilst debugging, I get the following error

"Failed to create muemblock from image 10062, atlas subimages are not supproted in MinerWillyControls.agc at line 1039"

Firstly there is a typo in the error message produced, however subimages/atlases have been fundamental to the design of the Manic Miner remake, especially for animations.

I don't really want to slice a couple of hundred images into single sprites, or have to reload them into memory, or redesign the game engine as it is 98% complete now...

Any suggestions for a workaround?

Or better still, can we please have PixelPerfect Image detection inbuilt into AppGameKit please? Blitz Basic has this support natively...

Many Thanks

There are a few ways this could be achieved, however it would require a little work. I'd be happy to help with this to get you back on track. I doubt ppc will be added to the roadmap in the near future.

I would suggest making a memblock of each atlas and creating a method which can check for a collision between any two frames given a pair of world co-ordinates. Not terribly complicated and since you really only need to check for a collision between willy and any other sprites that are also colliding with his "box" you can reduce the number of checks to within an acceptable amount.

Give me a shout if you want some help or clarification on how this would work. Looking at what you've done already I'm sure you are capable of doing this yourself but I'd be happy to make a function that does the pixel collision check if you like.

Your bounding rectangle collision will still work, so the only issue is for pixel perfect collision but you can still do that.
Instead of having a memblock for each subimage, you would have one memblock for the atlas and then use some offsets to find the position of your subimage in the atlas.
You will need the co-ordinates of your subimage within the atlas to calculate the offsets but they are stored in the subimages text file, so you will need to read them in and store them in an array.

It's all pretty straight forward and I would be happy to help if you need it but I see that baxslash has already offered and I know he is more than capable of doing this.

@baxslash, @scraggle, thank you for your suggestion and help

Is the suggestion that I load my main atlas (1024x1024) into one memblock and then determine which sprite within the atlas I'm using and then work out the offset?

I.e. I would then need to read the subimages.txt file to find the prime co-ordinates in the atlas and calculate the offset in the rather larger memblock?

Something like :-



Or am I over engineering this solution?

That's roughly what I had in mind yes.

Thanks for the inspiration @Baxslah and @Scraggle

I've solved the perfect pixel collision detection and although I'm debugging a couple of items, it's working like a charm. Pity TGC couldn't add this functionality natively or give us access to Image Data from Atlases when copying Memblocks.

to solve it, I load the main atlas image into a memblock, and then when I add a sprite, I create a new MemBlock with that image data and add it to a linked list. I check the linked list to determine if I've added that sprite already. So worst case scenario in MM are 8 actors and our hero (9 memblocks), the remaining image data is not treated as an actor (more to come )

I can get away with the first version of this checking type because the sprite blocks don't exceed 32 x 32 pixels each, with some jiggery pokery, I can scan only the overlapping (intersection) of pixels to test, which improves performance, and as I'm using PNG's I only need to check the Alpha Byte to determine if there is a pixel available!

The first version is crude, however taking into account a 32 x 32 pixels sprite, i can further rationalise the algorithm to reduce the image data to a Bit mask of 32 bits, which rests nicely in an AppGameKit int (also 32 bits). So with a clever piece of bit rotation and masking (XOR and AND) I reduce the pixel collision detection test at worst case checking 32 INTS of data.

It's been an interesting challenge, but I think the results will be worth it.

Once I've completed some bug checking (probably over the weekend now), I'm hoping to get a playable (redacted version) early next week (assuming no other major issues). To play test and get feed back.

Thanks Everyone