IK+ Animation Frames (How many?)

[sigh]

Looking at IK+, there seems to be quite a lot of animation frames (especially the back flip) and more so, thee is a shadow beneath the fighters that is a mirror copy and not just a blob.Does anyone know what the sprite sheet looks like and how it was packed?

[Fessor]

It looks like a bunch of 8x8 tiles with four colors which are converted to Mode 0 at runtime and put together to form a sprite ...
Kind of Emulation of the C64-Charset-Mode?

[sigh]

It looks like a bunch of 8x8 tiles with four colors which are converted to Mode 0 at runtime and put together to form a sprite ...
Kind of Emulation of the C64-Charset-Mode?

Thank you.
I'm going to be honest and say that I have no idea what is going on in that sheet !So has this been designed in mode 1 and then converted into mode 0?
On the left hand side - I can see parts of the characters face, but I have no idea what is going on, the left hand side.

[roudoudou]

I'm going to be honest and say that I have no idea what is going on in that sheet !So has this been designed in mode 1 and then converted into mode 0?
On the left hand side - I can see parts of the characters face, but I have no idea what is going on, the left hand side.

It's not mode 1 because pixels are stored linearly. It's 4 pixels with 4 colors per byte (similar to mode 1 but it's not the CPC bit storage)
The code use the first nibble (value from 0 to 15) and a table to get a full byte from this value, then with the second nibble to get another byte
The purpose is to reduce x2 the size of the tiles AND to convert the packed pixels to any fighter color changing the conversion table

[sigh]

It's not mode 1 because pixels are stored linearly. It's 4 pixels with 4 colors per byte (similar to mode 1 but it's not the CPC bit storage)
The code use the first nibble (value from 0 to 15) and a table to get a full byte from this value, then with the second nibble to get another byte
The purpose is to reduce x2 the size of the tiles AND to convert the packed pixels to any fighter color changing the conversion table

What are the drawbacks to using this method? Does this result to making the game slow due to the process of converting?

[roudoudou]

What are the drawbacks to using this method? Does this result to making the game slow due to the process of converting?

The conversion routine is not optimised but the game runs fine anyway because there is no scrolling, no background so why try to speed up? More speed implies also more sprites

[sigh]

The conversion routine is not optimised but the game runs fine anyway because there is no scrolling, no background so why try to speed up? More speed implies also more sprites

It's not optimized? That's interesting. I wonder if it were optimized, it may have been able to have some more of the background animations that the C64 has.

So how are the graphic sprite split into the tiles? Is this the same method used for Prince of Persia, as that also has unique frames? In fact - both of the sprites in this game have limited detail so I'm guessing that sprites with more complex detail would struggle with this method?

[roudoudou]

It's not optimized? That's interesting. I wonder if it were optimized, it may have been able to have some more of the background animations that the C64 has.

So how are the graphic sprite split into the tiles? Is this the same method used for Prince of Persia, as that also has unique frames? In fact - both of the sprites in this game have limited detail so I'm guessing that sprites with more complex detail would struggle with this method?

If you keep 4 colors for each sprite it's ok (background, black, skin and clothes color) you may add more detail it will be free!
"Just" need to get the pieces of the puzzle in the correct order 

[roudoudou]

you may work with this, i guess all sprites are in order but there is different width each rows

[sigh]

you may work with this, i guess all sprites are in order but there is different width each rows

This is insane!!!
There are literally NO REUSABLE SPRITES on this sheet! Everything is unique! I think that Prince Of Persia must of been done the same way.From an animators point of view, this cuts out the need to figure out how to optimize the frames for re-use and trying to be economically smart in terms of sprite space. The animator can just go on their merry way and animate without having to plan any of this (to a degree).
What an interesting way of handling the sprites for this particular game.

[roudoudou]

If you patch the png i will reinject data in a binary 

[sigh]

If you patch the png i will reinject data in a binary 

How do I do that?

[roudoudou]

How do I do that?

don't know what you use to do GFX, photoshop?
here is a better resource. if you patch karateka (keeping pixels in respective tiles) i will do the transfer back to the CPC

[sigh]

don't know what you use to do GFX, photoshop?
here is a better resource. if you patch karateka (keeping pixels in respective tiles) i will do the transfer back to the CPC

Aaahh - I see what you mean

[andycadley]

This is insane!!!
There are literally NO REUSABLE SPRITES on this sheet! Everything is unique! I think that Prince Of Persia must of been done the same way.From an animators point of view, this cuts out the need to figure out how to optimize the frames for re-use and trying to be economically smart in terms of sprite space. The animator can just go on their merry way and animate without having to plan any of this (to a degree).
What an interesting way of handling the sprites for this particular game.

This might well be an artefact of having converted the graphics from the C64. Its display is character based and it is possible that was how the data was structured for the C64. It has been too long since I did any C64 stuff, so I can't remember if the sprite memory was layed out in a similar fashion (even if it wasn't, there may have been technical advantages to doing so there)

[sigh]

This might well be an artefact of having converted the graphics from the C64. Its display is character based and it is possible that was how the data was structured for the C64. It has been too long since I did any C64 stuff, so I can't remember if the sprite memory was layed out in a similar fashion (even if it wasn't, there may have been technical advantages to doing so there)

Oh - so this isn't really a (normal/regular) way of packing sprites on CPC? Usually you split torso from the legs, but you wouldn't be able to do that with a game like IK+. If this is taken pretty much from the C64, then I'm guessing that it's almost a port. it makes me wonder if they would have used the same method if they had done it from scratch.

[andycadley]

Well "normal" is a somewhat fuzzy term with these kinds of things. It's not really a particularly optimal way of storing the data, but there may me other advantages to having a fighter split out into smaller sections like this such as some sort of generalised hit detection. It's often hard to entirely discern exactly what the thinking behind some unusual structures is and whether it was stored that way purely as a result of targeting/converting from some other platform or because the developer was focused on some other aspect. Indeed sometimes it might just be because a coder happened to have code for working with that format from some previous project where it made more sense.

[roudoudou]

In this case, the tiles organisation allow to easily revert sprites to look the other side of the screen.

We can see it in the Z80 assembly.
One routine read upper nibble first, another one read the lower nibble first. The conversion table is changed btw
Each conversion table is only 16 bytes (so there is 6 tables, 2 per fighter color)

[sigh]

In this case, the tiles organisation allow to easily revert sprites to look the other side of the screen.

Each conversion table is only 16 bytes (so there is 6 tables, 2 per fighter color)

How many bytes would this of taken otherwise? Is the saving quite substantial?

[roudoudou]

I guess approx 8 tables of 256 bytes each

[sigh]

I guess approx 8 tables of 256 bytes each

That's a huge saving.

[Fessor]

I think its a Port of the Speccy Version (Screen Layout 32*24 Cells) with the Graphics of the C64.One can clearly see the Multicolor-Chars of the C64, comparing with screenshots of the C64.
Caught it drawing the next Scene in the Double-Buffer at &8000...

[sigh]

I think its a Port of the Speccy Version (Screen Layout 32*24 Cells) with the Graphics of the C64.One can clearly see the Multicolor-Chars of the C64, comparing with screenshots of the C64.
Caught it drawing the next Scene in the Double-Buffer at &8000...

Ahhhh - the C64 sprites can have 3 colours (though it can have more when combined with other sprites) and this was made by System 3 with the C64 being their machine of choice. So the porting makes sense. Speccy + C64 port combo!

[andycadley]

Nicking graphics from the C64 was a common way of doing a slightly less "Speccy Port" version without a lot of extra effort. Three colour Mode 0 sprites is often a bit of a giveaway that something was done like that.

[Sykobee (Briggsy)]

C64 sprites are 12x21 (in 4 colour mode, this fits into 64 bytes nicely), so from the screenshot above you can see that with 3 players, and the players being 2 sprites wide (6 character squares) at most, there would be 6 sprites on any one line.


I guess the C64 version multiplexes (reuses with some raster register updates) the sprites to build the 48+ pixel high character for obvious reasons.


On the CPC it looks like the shadow is simply a y-flip of the feet drawn in black.