Author Topic: Football Fever (aka - Games with smooth "1" pixel multi directional scrolling.)  (Read 75353 times)

0 Members and 1 Guest are viewing this topic.

Offline sigh

  • 6128 Plus
  • ******
  • Posts: 1.336
    • Awards
Okay I think I understand.

Layer 1 =1,3,5,7,9
Layer 2=  2,4,6,8,10

So all the inbetweens are filled giving the illusion of 1 pixel scrolling :) .

I'm quite sure that the animation demo I did on this top page is moving 1 pixel and not 1/2 pixel. I did a demo of both but can't remember which version I posted...
« Last Edit: 00:45, 26 April 13 by sigh »
like
0
No reactions

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.336
  • Country: gb
    • Unofficial Amstrad WWW Resource
    • Awards
No, I believe TFM is saying that you use 2 blocks of 16k.

One has an image shifted by 2 pixels compared to the other.

So to scroll you need to switch between these screens AND use CRTC R3 for the byte scroll AND use hardware scroll.

So the disadvantage here, it's 128k only if you want to double buffer.

If you can get away with using the border time to draw the sprites, then you don't need double buffer.

So:

R3 not-adjust && Unshifted
R3 not-adjust && Shifted
R3 adjust & unshifted && scrolled by one char
R3 adjust & shifted  && scrolled by one char
and loop.
like
0
No reactions
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Offline ralferoo

  • Supporter
  • 6128 Plus
  • *
  • Posts: 970
  • Country: gb
    • Awards
One thing I'd recommend though is actually not using the byte-wise 2-pixel scrolling trick. The problem is that it looks awful on most LCDs. The trick relies on changing the HSYNC length by 1 character so that the PLL adjusts by half a character. However, LCD displays tend to react to these changes quicker than CRTs and so the result is very jerky when viewed on an LCD. So, it's a good trick but you'll limit your audience to those that can run on a real machine...

With that in mind, I'd recommend either having 4 images each offset by a pixel and changing the CRTC address as TFM described. The other option is just to byte wise erase the almost vertical lines and redraw them each frame and just have normal double buffering.
like
0
No reactions

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
    • Awards
@Arnoldemu: Only ONE pixel (assume you did a type).
 
Four images?? No! That's what we want to omit!
 
How to scroll>
 
- show screen 0 (pixels start at pixel 0)
- show screen 1 (pixels start at pixel 1)
- show screen 0, but use R3 to shift a byte forward
- show screen 1, but use R3 to shift a byte forward
 
Next cycle...
- show screen 0, no R3, but CRTC address +1 (two bytes)
- show screen 1, no R3, but CRTC address +1 (two bytes)
... and so on...
 
« Last Edit: 20:15, 25 April 13 by TFM/FS »
like
0
No reactions
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline sigh

  • 6128 Plus
  • ******
  • Posts: 1.336
    • Awards
No, I believe TFM is saying that you use 2 blocks of 16k.

One has an image shifted by 2 pixels compared to the other.

So to scroll you need to switch between these screens AND use CRTC R3 for the byte scroll AND use hardware scroll.

So the disadvantage here, it's 128k only if you want to double buffer.

If you can get away with using the border time to draw the sprites, then you don't need double buffer.

So:

R3 not-adjust && Unshifted
R3 not-adjust && Shifted
R3 adjust & unshifted && scrolled by one char
R3 adjust & shifted  && scrolled by one char
and loop.


Yes - it's definitely 128kb. Are there any examples of this being done?

However, LCD displays tend to react to these changes quicker than CRTs and so the result is very jerky when viewed on an LCD. So, it's a good trick but you'll limit your audience to those that can run on a real machine...


Hmmm....that is something to think about.

@Arnoldemu: Only ONE pixel (assume you did a type).
 
Four images?? No! That's what we want to omit!
 
How to scroll>
 
- show screen 0 (pixels start at pixel 0)
- show screen 1 (pixels start at pixel 1)
- show screen 0, but use R3 to shift a byte forward
- show screen 1, but use R3 to shift a byte forward
 
Next cycle...
- show screen 0, no R3, but CRTC address +1 (two bytes)
- show screen 1, no R3, but CRTC address +1 (two bytes)
... and so on...
 


Are there any examples of programs using this method?

Here is "mode 0" 1 pixel scroll at 25fps



..and here it is at 18fps



Regarding the crowds in the background, maybe the screen can be split into 3 sections: The crowd, playing area and score. The crowd could just software scroll slowly at 2 mode 0 pixels though it may give some weird parallax effect, or alternatively I just get rid of them(though it would be shame to lose them)
The sprites are 16x16, so I'm wondering how much of a burden this would be on the CPC....

This is incredibly interesting! I would really like to see this method in action to assess it's feasibility.
like
0
No reactions

Offline redbox

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.793
  • Country: gb
    • redbox
    • Awards
With these mockups I'd be tempted not to scroll the screen, but to try out redrawing the tilemap to make it scroll, especially if you went for 25hz.  This technique was recently discussed in relation to Shinobi and also Kick Off on the RA podcast.

You don't have to redraw much of the green pitch, so really only the top and bottom rows and the white lines/goal have to be done.  The pitch tiles are simple too so could be highly optimised.
like
0
No reactions

Offline arnoldemu

  • Supporter
  • 6128 Plus
  • *
  • Posts: 5.336
  • Country: gb
    • Unofficial Amstrad WWW Resource
    • Awards
@Arnoldemu: Only ONE pixel (assume you did a type).
 
Four images?? No! That's what we want to omit!
 
4 screens if you want double buffer AND 1 pixel scroll in mode 0.
like
0
No reactions
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Offline sigh

  • 6128 Plus
  • ******
  • Posts: 1.336
    • Awards
With these mockups I'd be tempted not to scroll the screen, but to try out redrawing the tilemap to make it scroll, especially if you went for 25hz.  This technique was recently discussed in relation to Shinobi and also Kick Off on the RA podcast.

You don't have to redraw much of the green pitch, so really only the top and bottom rows and the white lines/goal have to be done.  The pitch tiles are simple too so could be highly optimised.

The green pitch wouldn't have to move as it would just be a static image.
So your saying to redraw the tilemap for the crowds?

4 screens if you want double buffer AND 1 pixel scroll in mode 0.


So how CPC intensive would this be and how difficult would this be to test?
like
0
No reactions

Offline redbox

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.793
  • Country: gb
    • redbox
    • Awards
The green pitch wouldn't have to move as it would just be a static image.
So your saying to redraw the tilemap for the crowds?

Yes, and the white lines on the pitch.

Interestingly, Dino Dini said this is how he did it for the ST version of Kick Off - it doesn't actually scroll, he redraws the white lines each frame (and also uses vertical scanline splits to draw the different shades of grass) - this is why there's no centre circle because his routine took too long...! 

I know your game is sideways and not top-down, but the principal is the same as you've got large areas of the screen where nothing really needs changing.
like
0
No reactions

Offline sigh

  • 6128 Plus
  • ******
  • Posts: 1.336
    • Awards
Okay. Just to clarify so that I dont get too confused, we now have these opitons to attain 1 pixel scrolling for this particular game:

1) 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. But R3 isn't compatible with all monitors so this could cause problems for those not playing on real hardware. (But isn't this a problem only if the sprites are drawn on top in a particular way and with double buffering?)

2) Use 4 images of the white lines each offset by 1 pixel and use the technique above to include double buffer and 1 pixel scroll.

3) ralferoo "Byte wise erase the almost vertical lines and redraw them each frame and just have normal double buffering."  I'm guessing that this is similar to redbox option with the added addition of redrawing the tilemaps of the crowds in the background?

4) My convoluted and not so viable option (which is looking pretty ridiculous compared to the other ideas)

So - which of these 4 options would produce the following with the best possible results:

1) The fastest!

2) Easy implementation

3) Cheap to use/less CPU strain

4) Double buffering (would people be okay with flicky sprites on smooth 1 pixel scrolling to save memory/cpu time or would the preference be to have both smooth sprites on smooth 1 pixel scrolling?)

5) Crowds in the background that doesn't impact on performance or create a complicated issue when in conjuction with the 1 pixel scroll.

Are there any other options with these ideas (replacing R3 with R5 or R9 etc)?

This is looking very promising indeed and I feel that were about to enter into something new :)
like
0
No reactions

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
    • Awards
4 screens if you want double buffer AND 1 pixel scroll in mode 0.

Why double buffer? There's no need for that. Just use two screens in 50 fps. That's not a problem since you cn scroll and most of the screen stays static. Green stays green. It would be a bad idea to redraw screens btw. The only thing you have to do is to draw some very little player sprites and that can be done in 50 fps. The point here is: IT'S NOT OVERSCAN - SO IT'S QUICK :)
like
0
No reactions
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline sigh

  • 6128 Plus
  • ******
  • Posts: 1.336
    • Awards

Why double buffer? There's no need for that. Just use two screens in 50 fps. That's not a problem since you cn scroll and most of the screen stays static. Green stays green. It would be a bad idea to redraw screens btw. The only thing you have to do is to draw some very little player sprites and that can be done in 50 fps. The point here is: IT'S NOT OVERSCAN - SO IT'S QUICK :)

So what option are you referring too out of the 4?



And can we really achieve a frame rate of 50fps with around 16 sprites and the ball on screen? I opted for 25fps in the demo posted, as I thought that it would be better to have a lesser frame rate that is constant, rather than a higher frame rate that keeps dropping in and out and isn't stable. The 18fps is looking rather choppy and I would like to avoid using that one if possible.

Though the sprites are only 16x16, there's going to have to be at least around 16 on field at one time:

Ref
Linesman
ball
6 players on each side
Goal keeper.
like
0
No reactions

Offline TFM

  • Visit the mysteries of the CPC at www.futureos.de
  • Supporter
  • 6128 Plus
  • *
  • Posts: 9.899
  • Country: aq
  • Space Chicken for FutureOS is free!
    • index.php?action=treasury
    • FutureOS - The revolution on CPC!
    • Awards
4 screens if you want double buffer AND 1 pixel scroll in mode 0.
No only two screens for smooth 1 pixel scrolling, at least that's the way I do it. (At least as long as one screen is not bigger than 16 KB). How? See one of my previous posts.
 
 
And can we really achieve a frame rate of 50fps with around 16 sprites and the ball on screen? I opted for 25fps in the demo posted
Ok, depends heavily on the sprite routines. If you use masked sprites which conserve the background you may have to use 25 fps, but for sprites without masking and backgrouns preservation (just redraw the lines f.e) you can make it with 50 fps. However, you will see at the end.
 
« Last Edit: 20:29, 27 April 13 by TFM/FS »
like
0
No reactions
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 17.175
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
    • Awards
No idea about the technical aspects sorry, but the screenshots look really good. I hope you can get this finished.



^^what he said.
like
0
No reactions

Offline sigh

  • 6128 Plus
  • ******
  • Posts: 1.336
    • Awards
No only two screens for smooth 1 pixel scrolling, at least that's the way I do it. (At least as long as one screen is not bigger than 16 KB). How? See one of my previous posts.
 
 Ok, depends heavily on the sprite routines. If you use masked sprites which conserve the background you may have to use 25 fps, but for sprites without masking and backgrouns preservation (just redraw the lines f.e) you can make it with 50 fps. However, you will see at the end.

There's no masking involved with the sprites as they will just sit on top of the background. One of the things that I forgot to mention was that the ball will need a shadow which will be just a tiny black oval shape.
As long as the frame rate is consistent, I dont mind whether it's 50fps or 25fps.

It's looking like option 1 as I'm gettin gthe impression that it's seems simpler and lets cpu intensive.
So how would the goal posts be handled? It's different from the lines, but maybe it could use the method that redbox suggested of somehow redrawing the tilemaps like you would with the crowd.

Yes, and the white lines on the pitch.

Interestingly, Dino Dini said this is how he did it for the ST version of Kick Off - it doesn't actually scroll, he redraws the white lines each frame (and also uses vertical scanline splits to draw the different shades of grass) - this is why there's no centre circle because his routine took too long...! 

I know your game is sideways and not top-down, but the principal is the same as you've got large areas of the screen where nothing really needs changing.

I was looking at the St version of Sensible Soccer which has the centre circle and also the semi circle for the goal. It makes me wonder what they did to get that working.
« Last Edit: 23:27, 27 April 13 by sigh »
like
0
No reactions

Offline Puresox

  • 6128 Plus
  • ******
  • Posts: 1.290
  • Country: 00
    • Awards
Are the extra sprites really necessary-The linesmen etc , will this consume fluidity etc? I have zero knowledge on programming but was interested to know.
It's Looking lovely btw and I look forward to its release.
like
0
No reactions

Offline fano

  • Supporter
  • 6128 Plus
  • *
  • Posts: 836
  • Country: fr
  • Easter Egg Programmer
    • Easter Egg
    • Awards

My 2 technical cents after seeing this  ;D
I think using 3 splits screen would be interesting.One for the upper image that have a lot details but that is small.Here you can use for example R9=
3 to have 4 lines characters so 4*2K for theses graphics that covers all the field with 1 pixel offset.For main area, i think some software stuff would be enough as there are simple graphics you can compile easily to get more speed, especially if you use 128K (i'd say some specialised tiles engine like R-Type's one would be able to).For score , a fixed split would suffice.With 16*16 sprites (7*16 mode 0) , i think that would be enough to reach 25fps.To be honnest , using some "parallax" effet on white line would be possible too at 25fps but maybe a problem for gameplay (and maybe not visualy interesting)


Depends what "pixel" you're talking about.
The R-Type scrolling is "one pixel" in mode0, which is still 4 pixels in mode2. :laugh: 

wasn't C64 able to scroll at "fine pixels" with large pixels ?
I missed this one , so one year later :P
One pixel is one pixel , I know you still need to improve your CPC knowledge so you need to know CPC/Plus is not able to get subpixel move  :-*  (maybe some will find objection)
« Last Edit: 07:52, 28 April 13 by fano »
like
0
No reactions
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Offline Gryzor

  • Administrator
  • 6128 Plus
  • *****
  • Posts: 17.175
  • Country: gr
  • CPC-Wiki maintainer
    • CPCWiki
    • Awards
Wot, no AMSTRAD or CPCWiki banners in the background? :D
like
0
No reactions

Offline sigh

  • 6128 Plus
  • ******
  • Posts: 1.336
    • Awards
Are the extra sprites really necessary-The linesmen etc , will this consume fluidity etc? I have zero knowledge on programming but was interested to know.
It's Looking lovely btw and I look forward to its release.

Having a linesman and ref, really does give a much more "football" feeling which I felt a lot of CPC footy games were missing. For instance, though Emlyn Hughes International Soccer, plays much nicer than Matchday 2, the atmosphere of MD2 with the crowds in the background along with the crowd noises, creates a much more realistic feeling of a football match than EHIS.
I think that adding a linesman and ref would further enhance the football experience, as well as trying something that hadn't been seen much in an 8 bit footy game. I'm also wanting to implement things like handballs and diving in the game.

My 2 technical cents after seeing this  ;D
I think using 3 splits screen would be interesting.One for the upper image that have a lot details but that is small.Here you can use for example R9=
3 to have 4 lines characters so 4*2K for theses graphics that covers all the field with 1 pixel offset.For main area, i think some software stuff would be enough as there are simple graphics you can compile easily to get more speed, especially if you use 128K (i'd say some specialised tiles engine like R-Type's one would be able to).For score , a fixed split would suffice.With 16*16 sprites (7*16 mode 0) , i think that would be enough to reach 25fps.To be honnest , using some "parallax" effet on white line would be possible too at 25fps but maybe a problem for gameplay (and maybe not visualy interesting)


Yeah - I dont think that the parallaxing lines would offer anything to the game.

On the demo the lines are an actual graphic, but I'm wondering if this is something that would make sense to be drawn within the code itself, or maybe even combine the two principles. For instance, maybe we could have 1 layer of graphic lines and the other as lines drawn by the code?

Would this offer more control as well as being faster and consuming less CPU time?
like
0
No reactions

Offline fano

  • Supporter
  • 6128 Plus
  • *
  • Posts: 836
  • Country: fr
  • Easter Egg Programmer
    • Easter Egg
    • Awards
Would this offer more control as well as being faster and consuming less CPU time?
I'd say drawing directly raw data is faster than drawing lines when your data structures are well done.
« Last Edit: 14:30, 28 April 13 by fano »
like
0
No reactions
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Offline sigh

  • 6128 Plus
  • ******
  • Posts: 1.336
    • Awards
I'd say drawing directly raw data is faster than drawing lines when your data structures are well done.

Sorry, I'm going to ask a really silly question here :-[ .

Drawing directly raw data = lines drawn by the code

Drawing lines = Using lines I created in the art package.

Is this correct? Sorry, I don't know which one it is that your referring too.
like
0
No reactions

Offline MacDeath

  • Chaotic post writer and mock-up specialist
  • Supporter
  • 6128 Plus
  • *
  • Posts: 4.076
  • Country: fr
    • Awards
Quote
One pixel is one pixel , I know you still need to improve your CPC knowledge so you need to know CPC/Plus is not able to get subpixel move  (maybe some will find objection)
I knew it. also old post is old, oops.
like
0
No reactions

Offline fano

  • Supporter
  • 6128 Plus
  • *
  • Posts: 836
  • Country: fr
  • Easter Egg Programmer
    • Easter Egg
    • Awards
Sorry, I'm going to ask a really silly question here :-[ .

Drawing directly raw data = lines drawn by the code

Drawing lines = Using lines I created in the art package.

Is this correct? Sorry, I don't know which one it is that your referring too.
Well, that's maybe me who was not clear enough.I meant the reverse you said , as raw data i meant drawing byte per byte as any graphics, sprites (that does not mean there are not optimisations).Drawing lines stands for procedural graphics like using plot and draw basic commands ;)
like
0
No reactions
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Offline redbox

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.793
  • Country: gb
    • redbox
    • Awards
One more thing to support the redrawing tilemap method is the amount of sprites you want on the screen.

If you start scrolling with the CRTC then the sprite routines will me much slower as you have to check for boundary overlaps every line.  If the screen remains unscrolled, the sprite routines will be much faster.

I think it would work using a super fast tile print routine (pushing bytes from stack to screen) and then using compiled sprites for the players etc.  This would still be reasonable memory usage because its a football game and therefore there is only one 'level' (i.e. the ptich) and no need for loads of tiles to be stored for different 'levels' as is usually the case.
like
0
No reactions

Offline sigh

  • 6128 Plus
  • ******
  • Posts: 1.336
    • Awards
Well, that's maybe me who was not clear enough.I meant the reverse you said , as raw data i meant drawing byte per byte as any graphics, sprites (that does not mean there are not optimisations).Drawing lines stands for procedural graphics like using plot and draw basic commands ;)

I see. I'm actually a little surprised that the importation of graphics would be faster than the internal plot and drawn commands coming from the CPC itself. I was thinking of maybe having those functions used for simple 1 colour graphics like the lines, ball and the shadow. Bang goes that theory!!! :D

One more thing to support the redrawing tilemap method is the amount of sprites you want on the screen.

If you start scrolling with the CRTC then the sprite routines will me much slower as you have to check for boundary overlaps every line.  If the screen remains unscrolled, the sprite routines will be much faster.

I think it would work using a super fast tile print routine (pushing bytes from stack to screen) and then using compiled sprites for the players etc.  This would still be reasonable memory usage because its a football game and therefore there is only one 'level' (i.e. the ptich) and no need for loads of tiles to be stored for different 'levels' as is usually the case.


There needs to be around 16 sprites on screen so using compiled would be great for their speed, but how would you handle the clipping/wrapping around the screen?
Also, there are around 6 160x200 sheets with the sprites and background graphics which comes to around 48kb when stored. There are lot's of empty areas around the sprites so it would take up less space, but on reading some information about compiled sprites, it seems that they need to be stored 3 times? But with the sprites only being 16x16 I have no idea how much kb 1 frame would take up.

As an example (leaving the ball out of this example for now) we could have the linesman and ref could be normal sprites as they are not interactive or playable and that the playable sprites, goalkeeper and football are compiled sprites. Let's imagine a playable scene of 12 playable sprites, 6 on each side running around the pitch.
I'll mix in a wild random guess and say that 1 frame of animation from a 16x16 sprite is 2kb. This will turn into 6kb when it finally is displayed on screen. For all the 12 playable sprites on the pitch, you would be looking at 72kb, plus 32kb for the scrolling with the remaining memory used for code/sound etc.

If this was the case, then I'm guessing that it would work okay(?)

OR have I totally got this all wrong??

Edit:
Graphics Programming: Compiled Sprites
Allegro Manual: Compiled sprites

"Hint: if not being able to clip compiled sprites is a problem, a neat trick is to set up a work surface (memory bitmap, mode-X virtual screen, or whatever) a bit bigger than you really need, and use the middle of it as your screen. That way you can draw slightly off the edge without any trouble..."

One more thing...

With compiled sprites, is it possible to change the colour or mirror an individual sprite through the machine code that it is being stored as?
« Last Edit: 19:15, 28 April 13 by sigh »
like
0
No reactions