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?
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?
Quote from: Fessor on 00:36, 05 February 20
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 :laugh: !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.
Quote from: sigh on 12:12, 05 February 20
I'm going to be honest and say that I have no idea what is going on in that sheet :laugh: !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
Quote from: roudoudou on 12:47, 05 February 20
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?
Quote from: sigh on 14:20, 05 February 20
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 :D
Quote from: roudoudou on 14:29, 05 February 20
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 :D
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?
Quote from: sigh on 15:18, 05 February 20
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 ;D
you may work with this, i guess all sprites are in order but there is different width each rows
Quote from: roudoudou on 16:29, 05 February 20
you may work with this, i guess all sprites are in order but there is different width each rows
:o 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.
If you patch the png i will reinject data in a binary :D
Quote from: roudoudou on 17:46, 05 February 20
If you patch the png i will reinject data in a binary :D
How do I do that?
Quote from: sigh on 17:50, 05 February 20
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
Quote from: roudoudou on 18:52, 05 February 20
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
Quote from: sigh on 16:58, 05 February 20
:o 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)
Quote from: andycadley on 21:19, 05 February 20
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.
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.
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)
Quote from: roudoudou on 22:18, 05 February 20
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?
I guess approx 8 tables of 256 bytes each
Quote from: roudoudou on 22:53, 05 February 20
I guess approx 8 tables of 256 bytes each
That's a huge saving.
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...
Quote from: Fessor on 23:57, 05 February 20
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!
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.
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.
Quote from: Sykobee (Briggsy) on 12:43, 06 February 20
On the CPC it looks like the shadow is simply a y-flip of the feet drawn in black.
Are the shadows flipped in code with the existing graphics, or are they a separate sprite animation?
Quote from: sigh on 12:59, 06 February 20
Are the shadows flipped in code with the existing graphics, or are they a separate sprite animation?
I will check tonight
It may be clever to use another tile routine with a 16b table
Quote from: roudoudou on 16:48, 06 February 20
I will check tonight
It may be clever to use another tile routine with a 16b table
Thank you once again.
Quote from: sigh on 01:39, 07 February 20
Thank you once again.
The line are copied reversed by height, with a conversion table of 256 bytes
Once again this is a very unoptimised routine, like the WTF clear screen routine (done with LDI)
People are using 64 bytes width screen to optimised INCrements but they dont
The code was already too fast for them ;D
i hope i have all the sprites ;D
I wonder where they have hidden the sprites when one got hit or is knocked out, lying on ground...
Took a memorydump with vice64 and inspected it for graphics in winape.
i took only the 2 big bunches of tiles
Excellent work roudoudou and Fessor.
I only see 3 frames that are being reused in that Sprite sheet! There are a few moves missing like the flying kick, double head kick, The various types of KO animations etc.
That back flip is easily the biggest animation that takes up the most sprite space. It's a brilliant piece of animation.
Imagine if they had optimised this properly. Could of been a 3 player game.
Quote from: sigh on 12:43, 07 February 20
Imagine if they had optimised this properly. Could of been a 3 player game.
I patched the clearscreen with a very small routine (i freed up 128 bytes doing this) the frame rate jump from 7fps to 12fps
Quote from: roudoudou on 15:10, 07 February 20
I patched the clearscreen with a very small routine (i freed up 128 bytes doing this) the frame rate jump from 7fps to 12fps
So by adding that routine, you have made the game run at almost twice the speed.
How does the game feel running at 12fps?
This is a huge update and almost warrants this faster version to be classified as a remaster ;D
Quote from: roudoudou on 15:10, 07 February 20
I patched the clearscreen with a very small routine (i freed up 128 bytes doing this) the frame rate jump from 7fps to 12fps
Thats a lot! you should put this patched version available here for everyone, i would like to know how it plays :)
Quote from: sigh on 16:32, 07 February 20
This is a huge update and almost warrants this faster version to be classified as a remaster ;D
Much enjoyable, so i patched the shadow routine too :laugh:
Quote from: jesusdelmas on 16:54, 07 February 20Thats a lot! you should put this patched version available here for everyone, i would like to know how it plays :)
Sure, when i will be done with the modifications
If you can get it up to 17fps, and if you design some intermediary frame graphics to make the animations smoother (sure, 128KB), you'll get a twice as smooth game :D
Was it really 7fps? Sheesh. I thought those 12.5fps games were sludgy. I guess it doesn't matter for a game like this, you're limited by animation frames anyway.
(https://www.spriters-resource.com/resources/sheets/28/30294.png)
Quote from: Sykobee (Briggsy) on 18:55, 07 February 20
If you can get it up to 17fps, and if you design some intermediary frame graphics to make the animations smoother (sure, 128KB), you'll get a twice as smooth game :D
Was it really 7fps? Sheesh. I thought those 12.5fps games were sludgy. I guess it doesn't matter for a game like this, you're limited by animation frames anyway.
Those 16 bit version frames are interesting. It shows that the 8 bit versions have the exact number of frames and I always felt that the Amiga and C64 versions were very smooth.
It's amazing that with the small routine that Roudoudou has done which increases the frames by 5, he could probably get it even faster and may well hit that 17fps mark. I done think it would be necessary to have any more intermediary sprites for game like this.
Here is the release (with a brand new loading screen)
Great job !!!
Screen intro is really nice, but with your optimisations game seems too fast ! :(
Next ?
That's cool. Never thought that could be sped up. Can it be done with other games that ran too slow on CPC?
(also could you activate the music on Turtles 2 the Coin Op ? :) )
Nice full-screen loading image too.
Quote from: Carnivius on 09:40, 08 February 20
That's cool. Never thought that could be sped up. Can it be done with other games that ran too slow on CPC?
thanks, i'm glad the game still fit in 64K
most of games may be smoother using extended memory, but i won't do a proper version of outrun ;D
Sad binary loading that init the palette/mode and show garbages. :-\
I don't like the "TURBO VER" text... :P
Quote from: roudoudou on 09:47, 08 February 20
thanks, i'm glad the game still fit in 64K
most of games may be smoother using extended memory, but i won't do a proper version of outrun ;D
Outrun probably can't be salvaged. But there are many other quality games that could use a lil speed boost where possible. :)Just tired of seeing people say the CPC port of games "would be the best but is slower than the Spectrum and C64 versions".
Quote from: roudoudou on 01:48, 08 February 20
Here is the release (with a brand new loading screen)
IK+ is really more enjoyable with this version, the original version seems sluggish now.
Are the "hits" and "stars" over the players sprites? Because, using the yellow colour for that will be cool.
About the bonus stage, it is always slow when we should expect the balls speed to be twice now. :)
Maybe some colors of the Background Tiles can changed when building the Background. In the Palette there are two inks set to ink 13, maybe they can be used?
Quote from: Fessor on 16:41, 08 February 20
Maybe some colors of the Background Tiles can changed when building the Background. In the Palette there are two inks set to ink 13, maybe they can be used?
The Yellow is already available as it is used for the master's karategi.
Quote from: TotO on 16:45, 08 February 20
The Yellow is already available as it is used for the master's karategi.
What i think is, because the Sprites are colored at Runtime the same applies to the Background Tiles.Remapping from Pen 6 (Purple) to Pen 2 (Red) for the Sunset in the Clouds. From Pen 14 (blue) to Pen 8 (orange) for the heavenAnd giving the lake the now independent Pen 14 and a more fitting ink.
The Ink of the "blue" Sprite (Pen 6), now independent and used for the third sprite, can also be changed to a blue ink.
What i ment was Pens 11 and 12. Both are set to ink 13.
Quote from: roudoudou on 01:48, 08 February 20
Here is the release (with a brand new loading screen)
My oh my! You've done a truly fantastic job here. How many frames is it running now at now?It feels so smooth!
Has anyone youtubed reviewed this truly lovely speed update? I found one, but it was in spanish.
I have tried this version and I must say that it is truly exceptional, but I have a couple of questions / observations to make regarding the bonus phase. If the speed of the game has increased, how come the bouncing of the balls in the bonus section has been slow and jerky? Are these other routines to optimize or something else? Another thing that I noticed is (always in the bonus level) a "flicker" in the sprite of the karateka when turning to hit the balls ... is this a bug?
There would be so many games to optimize in terms of speed besides this! Is the principle adaptable to other games? ;D
Thanks for the work done! However, an exceptional technical test remains! ;)
i think there is a kind of slowing routine in the balls scene (as there is only one karateka) to avoid the scene to speed up
that said, the clear screen is triggered too early (when it was slow there was no problem) so you can see some lines cleared causing a flickering
i only touched the clear routine and some draw routines so the management remains the same
the interrupt routine is triggering many events, the solution is hidden in it, maybe i will take a look later
May be it is just the ball speed init value to set, because it increase with the time.
Quote from: roudoudou on 18:59, 26 February 20
i think there is a kind of slowing routine in the balls scene (as there is only one karateka) to avoid the scene to speed up
that said, the clear screen is triggered too early (when it was slow there was no problem) so you can see some lines cleared causing a flickering
i only touched the clear routine and some draw routines so the management remains the same
the interrupt routine is triggering many events, the solution is hidden in it, maybe i will take a look later
Did you manage to find the problem? Also - what is the new frame speed?
Quote from: sigh on 13:21, 04 March 20
Did you manage to find the problem? Also - what is the new frame speed?
Hey sigh, no time for this now (i'm on a huge project)
But i went to an illusion exhibition and there was a cool experiment of size-weightillusion :)
Two weights, a big one and a small one. The small one is on the top of the big:
First you raise up the small (which is "heavy")
Then you raise the big one, with the small on the top of it so you expect it will be 3x heavier
But when you raise both weights, it seems that both weights are lighter than one :o
My point is: if the fight scene is speeded up and not the balls scene, the balls scene will be slower (for your brain ;D )
++
And what about the interesting Karatian ?
https://www.cpc-power.com/index.php?page=detail&num=3625 (https://www.cpc-power.com/index.php?page=detail&num=3625)
sorry to necro this thread but this is relevant.
attached are the sprites from the c64 version reconstructed from the byte data. the data is bytes because the 3rd c64 player is created from characters.
I have extracted the sprites with a view to passing them to the BBC crowd, as they are quite prolific atm.