[nitrogen]

What's harder is clipping against the sides of the screen. With no branching, there's no way to prevent the sprite from writing past the end of a line/screen (wrapping/mem-stomping). So, there does need to be a test per sprite to detect that case and fall back on a more complicated blitter.

In fullscreen modes, you could also just make your screen buffer bigger than the actual screen by the width and height of your largest sprite.

[lscharen]

In my game engine I wrote for the Apple IIgs a long time ago, I used compiled sprites and maintained a 1-scanline-wide mask that I used to clip the compiled sprite to the screen edge.

This only cost one extra AND instruction and allowed the sprites to be clipped to any size rectangular playfield while still maintaining almost all of the speed benefits.

[vidarh]

That's actually cool, as it would also allow clipping against a "foreground" by varying the address of the scanline mask. E.g. imagine foreground trees in a jungle scene.

[lscharen]

Exactly!

I did extend it to use a full-screen foreground mask that implemented this sort of clipping. I was able to make the mask scrollable which allowed the compiled sprites to appear "behind" fences and other complex shapes with per-pixel accuracy.

It could even be used to mask out individual pixel bits that allowed for fake "lighting" changes with a carefully chosen palette.

[vidarh]

I keep wanting to do a "retro-game" and make use of what I've learned about these types of effects now. Despite how far machines like the C64 for example were pushed, I don't think they were pushed nearly as far in terms of games as with demos and it'd be fascinating to try to push the limits..

(maybe one day..)

[sitkack]

I'd love to see a demoscene version of "Hacker's Delight" [0]

[0] http://www.hackersdelight.org/

[sitkack]

I don't quite understand, could you explain?