Programming crashing on sprite collision

[Kman1011]

I am currently developing a full version of MECHA and am working on the BOSS sub-routine.

I got the BOSS to move and animate but it seemed everytime my character collided with the BOSS, the program would crash. I tried to narrow down the problem and when I removed the the line -

SpriteCollisionMode Boss,6

The crashing seemed to stop. Now  SpriteCollisionMode 6 is - Pixel Perfect mode. Is there any reason why the program would crash on pixel perfect? the image itself is an Fx loaded image 445 x 326 and am using the AlphaAddColour Sprite Draw mode.

Pixel perfect seems to work everywhere else but here. Don't understand ???

[kevin]

      That's certainly an very odd shaped image.   You could try pulling in the UV cords of the top right,  bottom right and bottom left, verts on the sprite.   The width/height may be causing overflows (be larger than the texture size).

      Also, I'd actually resize the image and get rid of the dead pixels (the black space around the image) to save you self some memory (lots of it i suspect) and speed up rendering.

[kevin]

   It doesn't crash here, anyway here's an example that show that clipping your images can help speed up your programs.  In this example using a clipped version the image makes it run about 35->40 % faster, for free.   And uses 26% less memory !

[Kman1011]

Kevin,

You definitely have a case. I tried the demo of the clipped image and got Fps's over 108 as opposed to around 77 with the non clipped. I did intend to trim the clear part of the image in a final gfx check but didn't realize there was such a difference in speed.

As for memory, I thought that the dead pixels were not allocated in PNG images. Like in these explosion images.
Each one is the same size image but the top one is smaller memory wize. I thought it was because of the amount of pixels used in the image out of the total image.

Speed wize though, makes a noticable difference and I'm always looking for extra speed. I still need a 'Wait 15' in my routine to slow it down a bit though but I'm sure that'll change after awhile 



 

[kevin]

    In terms of in memory usage, those two frames are the same size.   I can see your assumption, since the image is compressed on disc,  then it must be compressed in memory,  which is a pretty common misconception.   In reality,  when an  image is loaded (regardless of it's load from a raw or compressed format on disc (bmp/png/jpeg)), the surface is allocated in memory with the images absolute width/height and the pixel data is decompressed into it.   So if the image was 160*160 in 32bit, then in memory it'll use 160*160*4 bytes (at least) per frame.   Moreover,  virtually all video hardware tends to pad the images so their widths fall upon even boundaries (multiples of 8,16,32  bytes wide etc) which will make them larger again in memory.
               
Read this,
Added RawImage Animation Library

[Kman1011]

looks like I have some clipping to do ;D