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

[mix256]

Pulseman gets away with just using a sprite per digit.
That can get you started since it's easier, though it also eats more into the sprite limits, so you go see if it's too bad.

I think I'll start with that, actually. Still, having a num digit limit for the score is probably good anyway.

So, a cap of seven digits and 1 sprite for "1p" or whatever -> 8 sprites, 18 tiles of vram.
Gold coin counter, 1 gold icon and 3 digits -> 4 more sprites, ~10 tiles.
And one sprites for the elemental attacks. Was thinking 3 sprites, 12 tiles.

Sum: 15 sprites, 40 tiles. Well, the HUD is a huge part of the game so I'd say it's worth it. Or maybe I calculated this wrong?

As said, it's a start and I can just change it if the need should arise. Even Hagane uses a black window, so I can always go that route if all else fails.

[Miquel]

Take into account the sprite limit per line. That's why is a good idea to group 4 numbers into one sprite (or 2 characters, if they are 16 pixels wide).

edit:
Otherwise, to avoid this problem, you can display the status bar in vertical.

[mix256]

Take into account the sprite limit per line. That's why is a good idea to group 4 numbers into one sprite (or 2 characters, if they are 16 pixels wide).

edit:
Otherwise, to avoid this problem, you can display the status bar in vertical.

Yeah, think I've settled how to do this.
Will make the score take up 3 sprites, 10x2 tiles. Then the SpriteDefinition will have the tiles for the actual digits (0-9) as well.
Like this:

Code: Select all

Sprite *scorespr = SPR_addSprite(&digitsFont, 8,8, TILE_ATTR(PAL0, TRUE, FALSE, FALSE));
SPR_setAutoTileUpload(scorespr, FALSE);
SPR_setVRAMTileIndex(scorespr, vramIndex);

and then manually load the tiles into vram, depending on digit and pos:

Code: Select all

void setDigit(u16 scoreDigit, u16 digitPos){
  u16 vramIndex = TILE_USERINDEX + (digitPos << 1); 
  Animation* anim = font.animations[0];
  TileSet* tileset = anim->frames[0]->tileset;
  VDP_loadTileData(tileset->tiles + (scoreDigit << 4), vramIndex, 2, FALSE);
 }
 

Sprite vram always gets allocated in a row, hopefully. Especially if this is set up from the start. Font can't be compressed, no big deal.
See any problems with this?

Maybe I should do all this with VDP_setSprite() instead?

[Stef]

If you are using the Sprite Engine for other parts then you can do it that way, it's the good way to do it.
You cannot really mix SPR_xx (ghigh level) and VDP_setSpritexx (low level) methods, so better is to use manual allocation in the sprite engine as you did

[mix256]

If you are using the Sprite Engine for other parts then you can do it that way, it's the good way to do it.
You cannot really mix SPR_xx (ghigh level) and VDP_setSpritexx (low level) methods, so better is to use manual allocation in the sprite engine as you did

Haha, I was just about to ask about that. If I have SPR_init(...) in there, the VDP_setSprite code stops working.

I guess I need to manually create a SpriteDefinition, to make me get the size I want (if it's different than the frame size generated from the font graphics using rescomp) ?

[Stef]

I guess I need to manually create a SpriteDefinition, to make me get the size I want (if it's different than the frame size generated from the font graphics using rescomp) ?

Yeah but you can also build your own "number" only font image so it's adapted to your needs

[mix256]

Yeah but you can also build your own "number" only font image so it's adapted to your needs

That's what I got now, numbers 0-9, taking up 10 x2tiles. But the sprite created from that is then 10 tiles wide on screen.
So if I just want it 7 digits wide, I would need to create a "dummy sprite def" with the size that I want and use that for the addSprite(), right?
Or can I change the size after having added it, ah. Maybe?

Fell asleep while taking the boys to sleep yesterday, so no progress made. Argh.

[Stef]

The simplest way to do is to use 1 sprite for each digit, so you have a sprite definition of 1x2 tiles, with 10 rows defining the 10 possible digit.
Then you just use 1 sprite to display 1 digit with at the good animation index depending which digit to display.

If you want to not waste your sprite then you need to define a sprite of nx2tiles where n is the number of digits you need.
For instance 7 digits, you sprite sheet will look like this :

1st row - 0123456
2nd row - 56789

The second row is needed just for missing numbers so you can use it to feed missing digits.
Using this method you of course need to manually allocate VRAM index to your sprite and also manually upload the tile data as you made with your previous code except that you also require tileset data from animation[1] for number 789

[mix256]

For instance 7 digits, you sprite sheet will look like this :

1st row - 0123456
2nd row - 56789

Ah, that's clever!

Turned out I might need to use all of the sprite-space, afterall.


But having "1p" is just stupid...since there never will be a "2p". Or, maybe there should be, come to think about it.

[Sik]

If you want to not waste your sprite then you need to define a sprite of nx2tiles where n is the number of digits you need.
For instance 7 digits, you sprite sheet will look like this :

1st row - 0123456
2nd row - 56789

The second row is needed just for missing numbers so you can use it to feed missing digits.
Using this method you of course need to manually allocate VRAM index to your sprite and also manually upload the tile data as you made with your previous code except that you also require tileset data from animation[1] for number 789

Wait, what's going on here, what's the deal with 56 being repeated, is this something to trick rescomp or what? o.O

[Stef]

Oh it was just an example sorry, of course it's better to not duplicate tiles indeed so better to do that :
0123456
789

The idea is just to have extra animation rows for missing numbers

[mix256]

Slow progress lately. Got a terrible cold and a head ache out of this world. Just like the dropship here...



...beaming you down to "earth". Ship itself is WIP but I'm quite pleased with it.

Also, we now have the first elemental attack in place, ground raising ftw! \o/
Thought you'd be able to upgrade it, by turning in coins to a merchant, somewhere. Or rather forge it out of the gold, or...I don't know. And you'd also be able to acquire new elemental attacks the same way. We'll see where this leads us.



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?

In different news I've commissioned someone to make the cover art. Really looking forward to how that turns out. Could be an inspirational boost.

[Sik]

How long before somebody complains about the vertical dither on the beam?

Anyway, on a more important matter: you may want to push in the HUD a tile inwards horizontally (the safe margins are 2 tiles horizontally and 1 vertically - and yes, HDTVs still eat the margins if they come from analog signals).

[mix256]

How long before somebody complains about the vertical dither on the beam?

That's in the dissolve part of the beaming, so I think it's legit.

Anyway, on a more important matter: you may want to push in the HUD a tile inwards horizontally (the safe margins are 2 tiles horizontally and 1 vertically - and yes, HDTVs still eat the margins if they come from analog signals).

Thanks! Didn't know that. Was thinking about it the other day, though, but thought that somehow there was a border involved here. I don't even have a crt tv...been meaning to get one, for quite some time now.
Will need to move it more than that since I want some air around them as well.

[Chilly Willy]

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.