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

Started by sigh, 14:48, 23 April 12

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

sigh

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...

arnoldemu

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.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

ralferoo

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.

TFM

@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...
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

sigh

Quote from: arnoldemu on 17:54, 25 April 13
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?

Quote from: ralferoo on 17:57, 25 April 13
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.

Quote from: TFM/FS on 18:10, 25 April 13
@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.

redbox

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.

arnoldemu

Quote from: TFM/FS on 18:10, 25 April 13
@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.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

sigh

Quote from: redbox on 23:48, 25 April 13
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?

Quote from: arnoldemu on 09:24, 26 April 13
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?

redbox

Quote from: sigh on 09:39, 26 April 13
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.

sigh

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 :)

TFM

Quote from: arnoldemu on 09:24, 26 April 13
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 :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

sigh

Quote from: TFM/FS on 17:11, 26 April 13

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.

TFM

Quote from: arnoldemu on 09:24, 26 April 13
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.


Quote from: sigh on 22:12, 26 April 13
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.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Gryzor

Quote from: EgoTrip on 14:39, 25 April 13
No idea about the technical aspects sorry, but the screenshots look really good. I hope you can get this finished.


^^what he said.

sigh

Quote from: TFM/FS on 18:25, 27 April 13
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.

Quote from: redbox on 10:07, 26 April 13
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.

Puresox

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.

fano

Quote from: sigh on 23:05, 25 April 13
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)

Quote from: MacDeath on 13:37, 30 April 12
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)
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Gryzor

Wot, no AMSTRAD or CPCWiki banners in the background? :D

sigh

Quote from: Puresox on 23:24, 27 April 13
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.

Quote from: fano on 05:37, 28 April 13
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?

fano

Quote from: sigh on 12:23, 28 April 13Would 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.
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

sigh

Quote from: fano on 12:28, 28 April 13
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.

MacDeath

QuoteOne 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.

fano

Quote from: sigh on 12:46, 28 April 13
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 ;)
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

redbox

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.

sigh

Quote from: fano on 14:27, 28 April 13
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

Quote from: redbox on 14:48, 28 April 13
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?

Powered by SMFPacks Menu Editor Mod