Strides Interactive

Jedi Wing 2 Updates - 2D sprites are ass, anchors are WORSEFiled Under: Articles, Discussion, Jedi Wing 2, Weekly Tuesday Dose of goodness

This was supposed to be published yesterday, but I was simply too tired and so therefore, here it is today. My apologises for the delay.

Previously I’ve talked about how 2D sprites in 3D rendering can be an ass right? Well, that’s just the tip of the iceberg.

Meet - SPRITE ANCHORS!

What’s an anchor? It’s basically to tell people if I call a sprite at X and Y position, the starting point will be at one of the 9 possible locations of the square frame.

So where are the 9 locations and what’s so ass about Anchoring?

The eight locations are:
1) TOP_LEFT
2) TOP (centered on X axis)
3) TOP_RIGHT
4) LEFT (centered on Y axis)
5) CENTER
6) RIGHT (centered on Y axis)
7) BOTTOM_LEFT
BOTTOM (centered on X axis)
9) BOTTOM_RIGHT

The first thing that suck about anchoring is the handling attachments. Attachment is a separate topic altogether but simply put, it just an event to attach certain objects (other sprites) onto itself.

Attachments usually use TOP_LEFT for sprites and CENTER for 3D particles. While this is easier to map (since +x and +y are always positive), it’ll pose a problem when other anchors are used in conjunction with attachments. How to even govern the correctness of the attached positions?

There’re several ways, one of which is to make ALL attachment positions anchored to CENTER. Then work accordingly to the target’s anchor side by reducing or add to the final positions respectively. This is really plausible, but will take some efforts and time.

The second thing that makes anchoring an ass is sprite’s Z-axis rotation.

Now, I’ve decreed that all Z-axis rotations must take place in the center of the sprite. This are all precalculated before multiplying the final it with the 4 points prior to rendering.

This no doubt prevents the “blackhole” effect, that is, rotating around an invisible point. But at the same time, it confuses the developer as well because of the anchor.

We have to remember that even the entire surface screen itself, which is really a 2D flat screen is anchored against TOP_LEFT!! Top left meaning that all x-axis and y-axis coordinates are ALWAYS positive. So when a sprite’s anchor is changed, the developer’s perspective of the sprite position is based on the anchor, which in turn, when the object rotates, chances are it’ll cause the developer himself to rotate around an invisible blackhole as well!

This… is ASS!

Coupled with the screen’s natural coordinate set which is anchored against the TOP_LEFT anchor.

This… is a much bigger ASS!

Conclusion?

1) Sprites are always rotated around the center of themselves
2) Screen coordinates are always anchored to TOP_LEFT
3) No matter what position you’ve anchored your sprite to, it’s still within the screen coordinates which is TOP_LEFT. This means, an anchored sprite position is JUST a position. Know it, manipulate it and that’s it.

This is a design pain. Learn to live with it! Just remember what to avoid and what to go for, things should still go well without you going insane.

Signing off,
Jeremy Lee