<table width=100%><tr><td style="background: transparent url(http://64digits.com/users/DesertFox/header_line.PNG) repeat-x scroll 0%; width:100%; height: 24px;"><h2 style="color:black">Marquees</h2></td></tr></table>Me and JakeX were having deep conversations about the meaning of life, the universe, and everything (it's 42, by the way) when we got into the discussion of the marquee - I wondered why it hadn't been brought back.

As it turns out, it was getting its data from a log of changes, and this log was eating up the database. So the marquee was removed. JakeX and I talked about this, and the suggestion of simply keeping a single mysql entry, and changing that was brought up. An efficient, easy solution.

Then, lo and behold, less a day later, the marquee reappears! It needs a little parsing work, but it is awesome to see it back.

EDIT: Awwww - it's gone again!

<table width=100%><tr><td style="background: transparent url(http://64digits.com/users/DesertFox/header_line.PNG) repeat-x scroll 0%; width:100%; height: 24px;"><h2 style="color:black">On the Subject of Collisions</h2></td></tr></table>I don't think many people here truly appreciate the pixel-perfect collisions of GM - even through rotations, the collisions still work. I don't think you really appreciate! It is i fact rather irritating, writing your own collision algorithm.

After a bit of research, I have found a nice solution, added a little optimization. It implements bounding box collisions as well as sprite dependent collisions. As a rule, bounding box collisions are a lot faster than comparing images with offsets. So here is the theory behind simple sprite collisions

First, we take the bounding boxes of the two images, and compare them. If they don't overlap at all, then exit - they don't collide. If they do overlap, it creates a rectangle - the collision box. Now, there are a few possibilities here - the collision may be between 2 sprite-dependent objects, 2 bounding-box dependent objects, or one of each.

Now, if both are bounding box dependent, and they overlap, there is a collision, end of story.

If there is a sprite-dependent, calculate the offset, and start comparing values in the pixel arrays of the images. If the other is bounding-box dependent, treat it as a filled sprite. If you find a coordinate that is non-transparent in both image pixel arrays, there is a collision.

Now, that can be quite slow, especially with very large sprites - can you imagine 2 512x512 things overlapping exactly? That is 262144 comparisons, which can take time. So you definitely want to optimize. To optimize, you can do something such as staggered/binary-tree checking. Staggered and binary checking - things I'm sure has been done (I haven't found it on the internet, but I haven't checked) -are obvious optimizations.

A picture for your viewing pleasure - staggered detection:

<p align=center><img src=http://64digits.com/users/DesertFox/staggered.PNG></p>

Staggered optimization is based on the fact that <b>we don't have to check the pixels in order</b> We can check them backwards, forwards, sideways, any damn way I want. Staggered checking is checking 1 out of every n pixel coordinate, and then checking those you miss - instead of checking pixels 0,1,2,3,4,5,6,7, you can check 0,2,4,6,1,3,5,7. This is based on that images are usually filled - and is especially effective if using a mask.

The above picture shows staggered checking with only a staggered x-coordinate detection - the staggering is done by checking every 3 coordinate as a whole. You can stagger it any way you want - such as staggering both x and y - so from a 12x12 array, you check x-coordinates 0,3,6,9 in only y-coordinates 0,3,6,9. This takes a bit more calculation, because you have 2 layers of staggering. This way of staggering is in effect shrinking the image.

A picture for your viewing pleasure - binary tree detection:

<p align=center><img src=http://64digits.com/users/DesertFox/binarytreedetection.PNG></p>

First we check the center pixel of the collision box, and if that pixel is a collision point (non-empty in box images) there is a collision. If not, then then we divide it into quarters - half the width, half the height. Then we check the center pixel of the 4 smaller boxes. if there is no collision there, divide those boxes into 4 smaller boxes each, and check the center pixels. And so on - you divide until you reach pixel level.

Of course, you can always combine the two - but that gets rather confusing - be sure to keep your head straight.

<table width=100%><tr><td style="background: transparent url(http://64digits.com/users/DesertFox/header_line.PNG) repeat-x scroll 0%; width:100%; height: 24px;"><h2 style="color:black">The Truth Revealed</h2></td></tr></table>So the image that I had in my blog last night - it was in fact real - 100%. I took it with my built-in webcam. It is unmanipulated. The only person that genuinely figured it out was Andes - known here as monkeys - he checked the image name, and compared it to the image name of a preview picture I posted in my blog. Here are a few quotes for your enjoyment: