Tänzer, a "ninja" game (Dev Diary thread)

[mix256]

Heh - nice use of the Shadow of the Beast background art. I loved the hell out of that series. It really demonstrated the best aspects of the Amiga.

You're the second person to say that. Which is strange, since this looks nothing like the shadow of the beasts I've been playing.

[Sik]

It's the clouds.

[Stef]

Ran into some strange things with the animations of everything. Seems that I need to clear the animation timer (sprite->timer = 0;), otherwise the first frame would be skipped. First time you'd use the sprite it would be ok, but not when adding a sprite using the same spriteDef the second time. If you loop them forever it won't make a difference, but for explosions that's supposed to be removed when the animation is done, it was.
@Stef is this something known or am I doing something wrong?

There was a bug in older SGDK version where 1 frame of animation could be skipped when changing animation or frame manually but normally it has been fixed.
What do you mean by " adding a sprite using the same spriteDef the second time" ? Do you mean just adding a new sprite using the same SpriteDefinition as another active sprite ? That shouldn't give any troubles...
If you can post a snippet of code which reproduce the problem that would help me

[mix256]

It's the clouds.

I'd kill for sotb clouds.

What do you mean by " adding a sprite using the same spriteDef the second time" ? Do you mean just adding a new sprite using the same SpriteDefinition as another active sprite ? That shouldn't give any troubles...

spr = SPR_addSprite(def,...) then a few frames later SPR_releaseSprite(spr), then after another few frames SPR_addSprite(def) again, I think.
Like "ordinary" sprite handling, i guess?
Even when doing SPR_setAnim() after the add, the timer doesn't seem to be reset.

When I get home tonight I'll do some more testing and might produce a snippet with the problem.

EDIT: I'm running 1.33...I see now that there is a 1.34. Could that be it?

EDIT2: Ofcourse it is, right? But how come I'm not running the latest...? I probably downloaded the top of the list at the downloadpage, and not the one saying "last version".

[Stef]

Indeed, if you look at the changelog you will see the version 1.34 fix something about that
But what is weird is that normally the issue appeared only when doing animation or frame change manually... not when adding a new sprite.
Can you test with the last SGDK version and tell me if the issue is fixed ?

[mix256]

Can you test with the last SGDK version and tell me if the issue is fixed ?

Yep, seems to have fixed it. Awesome!

[Stef]

Great

[Chilly Willy]

It's the clouds.

And the ground... and the mountains in the back... it's all VERY similar to SOTB. Not exactly the same, but it does stir the nostalgia.

[mix256]

Ey, what's this?
Might not be used for anything, but I had fun doing it.



Edit, now with stolen guyver silhoutte from internet:


And yes, the gray bkg is scrolling.

[Miquel]

The problem with this kind of images is that it wastes big portion of video memory, if you are thinking of using them in a menu, or something rather similar, you will find that there is no much more memory left.
The idea of reusing tiles always pops out.

[Stef]

Sprite masking magic ? :p

[Miquel]

Sprite masking magic ? :p

Is available any utility to do that? I don't know, just asking. If comes with code it will be even greater!

[Sik]

It involves exploiting layer priorities and sprite ordering: sprites are put on top of each other strictly by order (ignoring the priority bit), and then the end result is mixed with the other two layers (only here the priority bit takes place). This means that a low priority sprite can cover a high priority one, and if there was plane A/B with high priority in the same place, you effectively create a cutout (which can be exploited to make silhouette effects).

Also those images seem to have a tad more repeated tiles than Miquel believes. The texturing loops several times.

[mix256]

Sprite masking magic ? :p

It involves exploiting layer priorities and sprite ordering: sprites are put on top of each other strictly by order (ignoring the priority bit), and then the end result is mixed with the other two layers (only here the priority bit takes place). This means that a low priority sprite can cover a high priority one, and if there was plane A/B with high priority in the same place, you effectively create a cutout (which can be exploited to make silhouette effects).

Also those images seem to have a tad more repeated tiles than Miquel believes. The texturing loops several times.

Ah, so I can do this without actually doing any manual masking and copying? That would be awesome!

Here's the rom of what you see in the pics: http://mix256.com/megadrive/transp.bin

Will start experimenting with this masking technique right away. Thanks!

[Sik]

Well, sprite limits are your enemy here so don't try to do it on wide areas...