Football Fever (aka - Games with smooth "1" pixel multi directional scrolling.)

[TFM]

One pixel is one pixel ...

Of course   and sometimes not. The Plus can move its sprites on a Mode 2 grit even if Mode 0 is switched of.... So this is what I call pixel split 

[fano]

Of course   and sometimes not. The Plus can move its sprites on a Mode 2 grit even if Mode 0 is switched of.... So this is what I call pixel split 

Right , was waiting this one 

(maybe some will find objection)

[sigh]

Here's what I'm thinking with all the information gathered on this thread to make this work:



1) Split the screen into 3 sections

2) For the crowds: Redraw the tilemaps of the crowds in the top part of the background.

3) For the main field: 2 layers of the white lines with one of them being shifted by 2 pixels. Scroll these screens by swapping the layers and using hardware scrolling and R3. to achieve 1 pixel smooth scrolling at 25fps (YAYYYY!!)

4) For score: Static score hud at the bottom of the background.

5) Compiled sprites for the player sprites and football.

6) Normal sprites for ref and linesman.


How does this sound folks? Any problems with this?




1) The fastest!

2) Easy implementation

3) Cheap to use/less CPU strain

[sigh]

Could someone please point me to some games that make heavy use of compiled sprites?

[redbox]

Could someone please point me to some games that make heavy use of compiled sprites?

Anything that's fast 

Clipping is a problem, as you say.  Maybe there's a solution using something like JP (HL) to get to a row, but I haven't written something like this yet...?

[Axelay]

Could someone please point me to some games that make heavy use of compiled sprites?

I used them for all the main sprites in Dead on Time, which looks to be in the game downloads section of the forum if you want a look.  It doesnt clip sprites on the left or right screen edges though, it's a 64K game.  It reuses frames in the different colours, but with a limited number of registers, which is why there are only two inks for the areas of enemy sprites that change colour.

[sigh]

I used them for all the main sprites in Dead on Time, which looks to be in the game downloads section of the forum if you want a look.  It doesnt clip sprites on the left or right screen edges though, it's a 64K game.

Took a quick look on youtube but will play it when I get home. The enemies bounce off the edges of the screen and also move off the screen on the bottom and top of the screen, The bullets however are clipped at the left and right side of the screen? Are the bullets a different type of sprite?

It reuses frames in the different colours, but with a limited number of registers, which is why there are only two inks for the areas of enemy sprites that change colour.

So for the football game it would be possible to change and have different variations of skin colour for each individual player on the same team using this method?

[Axelay]

Took a quick look on youtube but will play it when I get home. The enemies bounce off the edges of the screen and also move off the screen on the bottom and top of the screen, The bullets however are clipped at the left and right side of the screen? Are the bullets a different type of sprite?
 

The normal player and enemy bullets are not clipped on the side of the screen either, but that's because the player bullets are only 1 byte wide anyway, and the enemy bullets, that was just lack of memory, as these are both normal banked sprites.  Although the bullet sprite data is page aligned and only 4-6 bytes per sprite, so they are reasonably fast, so I considered that the saving in cpu time for compiling them would have been too small for the cost in memory.

So for the football game it would be possible to change and have different variations of skin colour for each individual player on the same team using this method?

It is possible, but it will depend on how many colours you want to change, and the design of the sprites.  The problem is that a register holds not a pixel, but a byte, which is 2 pixels in mode 0.  So even to change just one colour can take several registers as it needs to hold the pixels you want to change the colour of in all the combinations they are used with other colours in a single byte pixel pair.

[sigh]

The normal player and enemy bullets are not clipped on the side of the screen either, but that's because the player bullets are only 1 byte wide anyway, and the enemy bullets, that was just lack of memory, as these are both normal banked sprites.  Although the bullet sprite data is page aligned and only 4-6 bytes per sprite, so they are reasonably fast, so I considered that the saving in cpu time for compiling them would have been too small for the cost in memory.


It is possible, but it will depend on how many colours you want to change, and the design of the sprites.  The problem is that a register holds not a pixel, but a byte, which is 2 pixels in mode 0.  So even to change just one colour can take several registers as it needs to hold the pixels you want to change the colour of in all the combinations they are used with other colours in a single byte pixel pair.

1 byte = 2 pixels. The actual sprites are 16x16.

The example sheet shows what I would like to do with the sprites in relation to changing skin and hair colours of players on the same team (if possible).

There would probably be a maximum of 16 pixels that would need to be recoloured which would be a total of 8 bytes for 1 sprite. This would be the arms, face, legs and hair. For hair colour it would be 1 byte as it is just 1 pixel. There would probably be 4 or 5 in each team that could do with a colour variant. So there would need to be an allocation of around 80 bytes that could be used for both teams for colour variants.

As you can see from this sheet, you can fit around 150 frames of animated sprites or more and I have 10 of these sheets filled with them and the backgrounds which includes both teams and their mirrored versions.

[sigh]

Hi guys!!

Thanks for all the help on this. I think we have worked out something achievable, realistic and fantastic that will work fine on a 128kb machine!
I'm going to be working hard again on the beat em up game sometime this week, but if anyone wants to give a hand in getting the football game engine running with the excellent instructions on this thread, then please let me know.

I will resume to work slowly on the front end this game, just to break up the time I spend on the beat em up as it's quite exhausting working flat out on just that one project.

[Gryzor]

Just a silly idea, if you did teams with player names you could make one with forum members

[Axelay]

1 byte = 2 pixels. The actual sprites are 16x16.

The example sheet shows what I would like to do with the sprites in relation to changing skin and hair colours of players on the same team (if possible).

There would probably be a maximum of 16 pixels that would need to be recoloured which would be a total of 8 bytes for 1 sprite. This would be the arms, face, legs and hair. For hair colour it would be 1 byte as it is just 1 pixel. There would probably be 4 or 5 in each team that could do with a colour variant. So there would need to be an allocation of around 80 bytes that could be used for both teams for colour variants.

As you can see from this sheet, you can fit around 150 frames of animated sprites or more and I have 10 of these sheets filled with them and the backgrounds which includes both teams and their mirrored versions.

I assume from the dimensions of your sprites that when you say 16x16, you mean 8 mode 0 pixels wide by 16 high.  With compiled sprites (or most other types on CPC), you are not dealing with individual pixels, but bytes.  So if you want to recolour a compiled sprite 'on the fly', you will need a register to store each unique byte combination that requires changing, and those bytes may be required to hold pixel colours you do not want to change.  These registers would be set up with different pixel colour information depending on the colours required, before going to a common routine for printing that particular frame.


I've attached a png of your example player frame showing the pixels as they would be separated into bytes on screen memory.  I dont know if you need the players to be able to move at one mode 0 pixel steps, but if so, you will need two versions of the compiled sprite, one offset by one mode 0 pixel from the other.


For both the frames in the image, the blue rectangles identify a byte of screen memory, and because the sprite is mode 0, each byte holds two pixels.  To change the hair and skin colour of the player, the bytes outlined in yellow will need to be changed.  Some of these contain colours that dont need to be changed, but they are still part of a byte that requires the other pixel's colour to change, so need to be considered.


To the right of each frame I have (hopefully) identified all the unique combinations of pixel pairs that require at least one change of pixel colour for that frame.  As you can see there are eight unique combinations of 2 pixels that require changing for the frame on the left, but only five for the one on the right.  Each combination of pixels requires a register, and eight is possibly starting to get a bit tricky or unwieldy, although there are things that could be done in the compiled sprite code to reduce the number of registers that are needed, as some of the combinations are only used once.  So for this particular frame at least, it looks like it should be possible to change the hair and skin colours of the players within the same compiled sprite routine.


[attachimg=1]

[TFM]

The one at the right looks better, except its legs, which look better at the left side.

[redbox]

That's a good explanation Axelay.

I have just been through something similar when trying to see what pixels/bytes I could change, but it was made worse by being in Mode 1.

So I cheated. But I still had enough memory left

[sigh]

I assume from the dimensions of your sprites that when you say 16x16, you mean 8 mode 0 pixels wide by 16 high.  With compiled sprites (or most other types on CPC), you are not dealing with individual pixels, but bytes.  So if you want to recolour a compiled sprite 'on the fly', you will need a register to store each unique byte combination that requires changing, and those bytes may be required to hold pixel colours you do not want to change.  These registers would be set up with different pixel colour information depending on the colours required, before going to a common routine for printing that particular frame.

Thank you so much for this information!

Yes, I meant 8 x 16. (I keep counting them as single mode 1 pixels )and I had no idea about the sprite combinations!

I dont know if you need the players to be able to move at one mode 0 pixel steps, but if so, you will need two versions of the compiled sprite, one offset by one mode 0 pixel from the other.

the 1 pixel step would only be used for the walks there are 5 directions, but the walk animations moving up and down the screen wont need the pixel steps. The walk cycles across, diagonal up and diagonal down would be nice with pixel steps, but I'm starting to think that these sprites cannot be duplicated because there are just far too many animation frames.

To the right of each frame I have (hopefully) identified all the unique combinations of pixel pairs that require at least one change of pixel colour for that frame.  As you can see there are eight unique combinations of 2 pixels that require changing for the frame on the left, but only five for the one on the right.  Each combination of pixels requires a register, and eight is possibly starting to get a bit tricky or unwieldy, although there are things that could be done in the compiled sprite code to reduce the number of registers that are needed, as some of the combinations are only used once.  So for this particular frame at least, it looks like it should be possible to change the hair and skin colours of the players within the same compiled sprite routine.

If this has to be done for each animaion frame - I have to be realistic and tell myself that it's just not going to happen. I already have 2 teams, one red and the other blue with both their mirrored counterparts and once again, 10 of these 160x200 sheets filled with hundreds of these tiny 8x16 sprites is not really feasible as the amount of mistakes that would happen would be all too easy.

I'm going to put this one onto the "Not to do" list

[TFM]

Just a silly idea, if you did teams with player names you could make one with forum members

And people could pay for that, so the next year of the wiki gets payd too

[sigh]

So if you want to recolour a compiled sprite 'on the fly', you will need a register to store each unique byte combination that requires changing, and those bytes may be required to hold pixel colours you do not want to change.  These registers would be set up with different pixel colour information depending on the colours required, before going to a common routine for printing that particular frame.

I'm an idiot! I read this differently and it was only when I woke up this morning that I realized. For some reason I forgot about the "storing" part and was thinking that I would have to recreate combinations for each frame, when it fact you just need 1 of every possible combination which is stored and then called up when needed.

Okay - I'm going to workout each colour combination because there are actually only 3 that needs changing:

1) Skin tone
2) Skin shadow
3) Hair

The pixel pairs that you have created are to be be used for the whole sprite sheet. There are a few missing such as a pair that has the dark pink next to the light pink and a light pink next to a dark pink, empty space next to white pixel etc.

I reckon that there wont be that many combinations (30 or so?)
So I will do these combinations and post them tonight.

It's now back on the "To do" list!

[sigh]

Here are the different colour combinations for one team with 3 sets of skin colours including left and right side:



So for 2 teams it's lookig at around 360 bytes.

Is this feasible?

[sigh]

After creating this set of skin variants, how would one deal with hair colour? Would I need to create another byte sheet?
It makes me wonder if Sensible World of Soccer had a special sprite colouring routine or whether they just created a new set of sprites with different hair/skin colouring.

[redbox]

It makes me wonder if Sensible World of Soccer had a special sprite colouring routine or whether they just created a new set of sprites with different hair/skin colouring.

If you mean on the Amiga/ST then the gfx memory is different so would have been easier to change the colours.  The CPC problems come from the 2 pixels in one byte problem (along with the fact that the 2 pixels or not stored in a linear fashion either).

But Kick Off and Sensible Soccer appear to have a LOT of sprites, so it's probably a combination of pre-storage and colour changes.

[Axelay]

After creating this set of skin variants, how would one deal with hair colour? Would I need to create another byte sheet?

The hair colour could be dealt with the same way, but really I think whoever codes the game for you is going to end up creating an automated process to translate the sprite frames into compiled sprites, and from that they'd work out how feasible the skin/hair colour changing might be for their approach to coding it, so I wouldnt produce another byte sheet unless they asked for it.

The CPC problems come from the 2 pixels in one byte problem (along with the fact that the 2 pixels or not stored in a linear fashion either).

I like the non linear pixels, only one bit shift at any resolution for a one pixel shift! 

[sigh]

If you mean on the Amiga/ST then the gfx memory is different so would have been easier to change the colours.  The CPC problems come from the 2 pixels in one byte problem (along with the fact that the 2 pixels or not stored in a linear fashion either).

But Kick Off and Sensible Soccer appear to have a LOT of sprites, so it's probably a combination of pre-storage and colour changes.

I had a look at Sensible Soccer which has 2 skin colours and 2 hair colours. I'm not too sure how many sprites the game had, but I think that FIFA 95 is probably the most heavily 2d animated football game I've seen.

The hair colour could be dealt with the same way, but really I think whoever codes the game for you is going to end up creating an automated process to translate the sprite frames into compiled sprites, and from that they'd work out how feasible the skin/hair colour changing might be for their approach to coding it, so I wouldnt produce another byte sheet unless they asked for it.

Okay. Thanks!

[redbox]

I like the non linear pixels, only one bit shift at any resolution for a one pixel shift! 

Yes, this is nice, but only good for certain circumstances (repeated backgrounds?).

If you're using it for a sprite, then you have to take shifted bits, move them into the next byte, mask it with what's already there etc, then repeat, repeat, repeat...!

There's a reason everyone uses pre-shifted 

[TFM]

Not everyone

[Axelay]

Yes, this is nice, but only good for certain circumstances (repeated backgrounds?).

If you're using it for a sprite, then you have to take shifted bits, move them into the next byte, mask it with what's already there etc, then repeat, repeat, repeat...!

There's a reason everyone uses pre-shifted 

I found it pretty convenient for the scroll buffer on a horizontal scroller, amongst other minor things, but I've never considered pixel shifting on the fly for a sprite routine.  I want to avoid too much processing in a sprite routine!  Not sure a linear bit arrangement would change things all that much?