How exactly does Z order and color detection relate?
My Shipsim (http://scratch.mit.edu/projects/dinther/32891) uses color detection for a unique and nearly invisible color of green that borders all the land area's This color is used to detect a ship collision.
However, I have major problems with color detection and controlling Z order.
Am I correct in assuming that color detection is performed while the new sprite is painted? Therefore the sprite can only detect colors on the canvas of layers already painted but not of layers that are yet to be painted?
Yet, somehow in my latest program with prop wash ( http://scratch.mit.edu/projects/dinther/34346 )the above logic doesn't apply because I get color detection when sprites above the detection sprite inadvertently obtain the collision color due to anti aliasing while rotating.
I even tried a debug version where the prop wash sprites are not rotated but the online version insists on throwing funny colours around the dots. Also tried a propwash sprite without transparency around the dots but they of course overlap and kill the effect.
Can someone help me out please?
Last edited by dinther (2007-09-05 02:19:43)
Offline
I am not sure this will work, but maybe you could try building sprites in photoshop and save them as JPG with full compression. Clean up any artifacts and save again. I think your problem might be compression artifacts.
Offline
Are you saying that bitmaps are compressed regardless of using the compression option in the "extras" menu? I ask this because I have tried to compress the bitmaps using that option which resulted in a 70% reduction in file size. This was no good because it compressed my background tiles to death. So currently I work without compression or so I thought.
I am hoping some tech from the scratch team will fill me in on how color detection actually is supped to work so we I can determine what I am doing wrong or possible locate a bug in scratch.
Offline