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

Quote from: TFM/FS on 19:58, 01 May 12
Ok, I don't lack the answer any longer...

Yes, CPC has one game using 1 pel (abbrv. for pixel) scroll. It's Side Arms:
http://www.cpc-power.com/index.php?page=detail&num=1933

Tada  :laugh:

Heh heh!! No it's not! It's not multi directional either:)

I looked at a bunch of mutli directional scrolling on Xyphoes A-Z of football games - but they were choppy.
So far the best multi directional scrolling I have seen is Dynamite Dux and Skate Crazy.


TFM

Ahhh. Ok! You got me  :o  I continue searching then... (hmm... and I thought in later levels it also scrolls up, but I probably mixed that...).

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 01:11, 02 May 12
Ahhh. Ok! You got me  :o  I continue searching then... (hmm... and I thought in later levels it also scrolls up, but I probably mixed that...).

It does indeed scroll down, but it's more of a Mr Heli fashion in where there are no diagonals.

MacDeath

QuoteSide Arms
yurk, the graphics would need a serious re-job.

QuoteHeh heh!! No it's not! It's not multi directional either
also, "rail shooter" or "rail scrolling" (continuous, automatic, whatever) is not exactly the same as a scrolling "on demand"... I guess...

TFM

Quote from: MacDeath on 13:54, 02 May 12
yurk, the graphics would need a serious re-job.
True this, especially the "hero". Well the old damn-speccy-port problem.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

MacDeath


[AMSTRAD CPC] Side Arms Longplay
quite slow anyway...
some sprites like the powerups, don't seem to move that smootjly.
And the small screen is qutie reminiscent of speccy portage.
Let's compare...

Speccy :

Side Arms ZX Spectrum © 1988 Go!

C64 :

C64 Longplay - Side Arms (last levels)

Dating from 1987... many graphics weren't as good as CPC could, and they couldn't code shit without a speccy obviously.
I suspect that for once they had a proper Graphic artist, but obviously the guy had no access to the original arcade game.

not even to the C64 graphics.
they probably gave him the Speccy graphics and then he had to do something over this... erf...

even the palette is quite badly used sometimes...


just look at first boss...(well, obviously, this is the only boss lol)
what is this shitty gradient ?
orange, dark green, dark red, dark yellow and grey ? wtf ???

the weapons choice (bottom) use exactly the same pixelisation as the speccy... but as it is mode0 instead, it is the full screen wide (well, speccy sized screen anyway)

also the blue frame keeps some inspirations from the speccy one (twisted thing) yet also twice larger (mode0)


ouch, it hurts my eyes, this grey is so badly used it hurts...


Damn you US Gold (more like "us-Shit stealing our-gold", but a few exceptions though), you ruined my life and my beloved CPC !!!!!

Those games don't even have a proper end, because they are so shitty nobody never play them to the end.


Now let's cry a bit more :

Hyper Dyne Sidearms arcade 1 coin clear

ouch, its reminds me when i heard Xain sleen'a was actually ported on CPC as soldier of light...


Xain'D sleenA / Solar Warrior / Soldier of Light arcade coin-op MAME HD

Soldier Of Light (Xain'd Sleena) per Amstrad CPC - Gameplay by Ataru'75 [078]

Soldier Of Light - ZX Spectrum - The Quiet Video Game Nerd (QVGN)

Those guys couldn't handle the CPC palette, and emulating speccy with Mode0 graphics does not often make a good game...

The shooter part is not that slow though, and to be fair, this port is not too far from the arcade...

TFM

So true!!!

Well, and usually GO made good CPC Games, but in this case they were screwed obviously.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

ivarf

Quote from: sigh on 20:43, 01 May 12
I looked at a bunch of mutli directional scrolling on Xyphoes A-Z of football games - but they were choppy.
So far the best multi directional scrolling I have seen is Dynamite Dux and Skate Crazy.
If you want the best multidirectional scrolling, I suggest you take a look at TLL (Tornado Low Level) from Vortex

arnoldemu

I have written some example code to show off vertical pixel by pixel scroll.
I will add horizontal to it, then we can get an idea of what works well and how much cpu/ram it all takes.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

TFM

Quote from: ivarf on 10:05, 04 May 12
If you want the best multidirectional scrolling, I suggest you take a look at TLL (Tornado Low Level) from Vortex
Well, that's what I pray since decades ;-) However, it has not a 1-pixel scroll, therefore I didn't mention it here.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

ivarf

Quote from: TFM/FS on 16:48, 04 May 12
Well, that's what I pray since decades ;-) However, it has not a 1-pixel scroll, therefore I didn't mention it here.


I know it isn't a 1-pixel scroller, but as sigh wrote "So far the best multi directional scrolling I have seen is" I thought it was about time to mention it again. How important is 1-bit scrolling when you can have a scroll so fast and smooth fullscreen on the CPC? Most of the other diagonal scrollers mentioned in this thread are just rubbish in my humble opinion

TFM

Totally agreed! (Since my prods haven't been mentioned  :laugh::)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

TFM

Quote from: fgbrain on 17:11, 30 April 12
For old generation CPC, I believe the smoothest scroll in 8 directions is in a PD game called "Burning Wheels" by T. M. SCHMIDT :

http://www.cpc-power.com/index.php?page=detail&num=635

Almost impossible for me to play  :'( ...
Sorry, offtopic:

Pressing Fire 1 works as break, took me some time to see...
However it's a nice game and it also runs under FutureOS. I gave it an icon and prepared a DSK (see FutureOS - The revolutionary UltraOS for the CPC6128 and CPCPlus).
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

sigh

Quote from: arnoldemu on 13:08, 04 May 12
I have written some example code to show off vertical pixel by pixel scroll.
I will add horizontal to it, then we can get an idea of what works well and how much cpu/ram it all takes.

This would be fantastic! The results would be very interesting.

Quote from: ivarf on 22:45, 04 May 12

I know it isn't a 1-pixel scroller, but as sigh wrote "So far the best multi directional scrolling I have seen is" I thought it was about time to mention it again. How important is 1-bit scrolling when you can have a scroll so fast and smooth fullscreen on the CPC? Most of the other diagonal scrollers mentioned in this thread are just rubbish in my humble opinion

1 pixel scrolling is definitely important (in my opinion) when it comes to sports games or some scrolling shooters which may need a tighter control when it comes to movement and feedback. Many football games suffered on the CPC due to some choppy scrolling, ruining the overall experience.

TotO

Quote from: sigh on 11:33, 05 May 121 pixel scrolling is definitely important (in my opinion) when it comes to sports games or some scrolling shooters which may need a tighter control when it comes to movement and feedback. Many football games suffered on the CPC due to some choppy scrolling, ruining the overall experience.
1 pixel scrolling is important for games that required slow map moves (r-type/gauntlet/...). If the scrolling is fast or if your display is not 50Hz (but 25Hz or less), half or full char scrolling is fine.


"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

sigh

Quote from: TotO on 14:54, 05 May 12
1 pixel scrolling is important for games that required slow map moves (r-type/gauntlet/...). If the scrolling is fast or if your display is not 50Hz (but 25Hz or less), half or full char scrolling is fine.

Yes. It definitely depends on the type of game.

arnoldemu

Quote from: arnoldemu on 13:08, 04 May 12
I have written some example code to show off vertical pixel by pixel scroll.
I will add horizontal to it, then we can get an idea of what works well and how much cpu/ram it all takes.

Standard scroll, char by char, very fast(!) and smooth(!):
8 pixels vertically , 16 pixels in mode 2 horizontally each frame.
http://www.cpctech.org.uk/source/vscroll1.asm

Vertical scroll using R5, horizontal scroll using R3, very smooth (!):
1 pixel vertically, 8 pixels in mode 2 horizontally (2 in mode 0, 4 in mode 1) each frame.
Both working together.
http://www.cpctech.org.uk/source/vscroll2.asm

Vertically it is as smooth as Mission Genocide.

Vertical scroll using R5, horizontal scroll 2 screens each offset by 1 byte:
1 pixel vertically, 8 pixels in mode 2 horizontally (2 in mode 0, 4 in mode 1) each frame.
Both working together.
http://www.cpctech.org.uk/source/vscroll3.asm

Tests run on CPC6128 with crtc type 1, cpc plus cm14 monitor.

All are smooth.

test 3 uses 2 times as much ram (32k) because we need to store a version that is not offset and one that is offset.
For this the scrolling must be continuous. No changes to hsync, vsync so compatible with all monitors.

Others use normal amount (16k), scroll can stop and start. R3 scroll not compatible with all monitors/televisions/modulators.

If you want double buffered double this up.

So it shows that R5 and R3 scrolling can be used together.

It's not pixel by pixel yet, that is the next step, also it doesn't draw any new graphics.. it shifts the existing graphics it draws at the start.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Puresox


sigh

Quote from: arnoldemu on 13:26, 07 May 12
Standard scroll, char by char, very fast(!) and smooth(!):
8 pixels vertically , 16 pixels in mode 2 horizontally each frame.
http://www.cpctech.org.uk/source/vscroll1.asm

Vertical scroll using R5, horizontal scroll using R3, very smooth (!):
1 pixel vertically, 8 pixels in mode 2 horizontally (2 in mode 0, 4 in mode 1) each frame.
Both working together.
http://www.cpctech.org.uk/source/vscroll2.asm

Vertically it is as smooth as Mission Genocide.

Vertical scroll using R5, horizontal scroll 2 screens each offset by 1 byte:
1 pixel vertically, 8 pixels in mode 2 horizontally (2 in mode 0, 4 in mode 1) each frame.
Both working together.
http://www.cpctech.org.uk/source/vscroll3.asm

Tests run on CPC6128 with crtc type 1, cpc plus cm14 monitor.

All are smooth.

test 3 uses 2 times as much ram (32k) because we need to store a version that is not offset and one that is offset.
For this the scrolling must be continuous. No changes to hsync, vsync so compatible with all monitors.

Others use normal amount (16k), scroll can stop and start. R3 scroll not compatible with all monitors/televisions/modulators.

If you want double buffered double this up.

So it shows that R5 and R3 scrolling can be used together.

It's not pixel by pixel yet, that is the next step, also it doesn't draw any new graphics.. it shifts the existing graphics it draws at the start.

These results are incredibly interesting! (thank you very much!)

It'm guessing that "Burning Wheels" is using the "R3" scroll method in conjuction with the 1 pixel vertical scroll as it looks very much like your example. It seems that the shaking in the diagonal movement is due to the horizontal scroll moving 2 pixels instead of 1; meaning that it's always shifting an extra horizontal pixel against the single pixel vertical?

(Though both the 2nd and 3rd examples looked very similar in terms of the diagonals)

So to achieve the 1 pixel scroll in both directions (which would sort out the shaking) the R5 method would have to be used? This would mean that a game must continuosly scroll, so how could it be done so that the scroll could stop, start and go backwards? etc.

TFM

@Arnoldemu: That was a great idea to provide source of scrolling. Let my suggest one thing. You could give an example of vertical scrolling (w/o horizontal scrolling), that may be good for people who are "new" to scrolling. (Just an idea).  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Executioner

Quote from: sigh on 16:44, 07 May 12
So to achieve the 1 pixel scroll in both directions (which would sort out the shaking) the R5 method would have to be used? This would mean that a game must continuosly scroll, so how could it be done so that the scroll could stop, start and go backwards? etc.

Using R5 scrolling should enable the scroll to stop, start, go backwards, whatever you want. The same applies to using R3 for scrolling so long as your sprites and other updates are NOT double-buffered in such a way that they're always drawn on the 1 byte offset screen. Not using the offset screen for a double buffer effectively reduces the amount of time you have to erase and draw sprites and may complicate the timing to handle them. It also means that you must be able to do everything in a single 50Hz frame, whereas a double-buffered offset screen can be updated at 25Hz or slower if you like.

arnoldemu

Quote from: TFM/FS on 19:58, 07 May 12
@Arnoldemu: That was a great idea to provide source of scrolling. Let my suggest one thing. You could give an example of vertical scrolling (w/o horizontal scrolling), that may be good for people who are "new" to scrolling. (Just an idea).  :)
I will, these are early examples :)
final ones will not have a repeating background.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

Quote from: sigh on 16:44, 07 May 12
These results are incredibly interesting! (thank you very much!)

It'm guessing that "Burning Wheels" is using the "R3" scroll method in conjuction with the 1 pixel vertical scroll as it looks very much like your example. It seems that the shaking in the diagonal movement is due to the horizontal scroll moving 2 pixels instead of 1; meaning that it's always shifting an extra horizontal pixel against the single pixel vertical?
I didn't see any shaking when using a plus monitor and cpc with type 1. It is possible that for other crtcs other values are needed.
Or do you mean down the sides?
There will always be some flickering down the sides when using r3 scroll method.
With r5 vertically it can be reduced, but still it can be there.

Quote from: sigh on 16:44, 07 May 12
(Though both the 2nd and 3rd examples looked very similar in terms of the diagonals)
the scrolling rate is the same. The difference is that example 3 doesn't use r3, it uses a screen that is moved by 1 byte horizontally.

Quote from: sigh on 16:44, 07 May 12
So to achieve the 1 pixel scroll in both directions (which would sort out the shaking) the R5 method would have to be used? This would mean that a game must continuosly scroll, so how could it be done so that the scroll could stop, start and go backwards? etc.
to use 1 pixel in vertical, r5 is used and there is no limit, you can start/stop as you want.
I will show this in another example.

if you want 1 pixel horizontally you need to make decisions to sacrifice ram or it working on all monitors.
I will do more examples to show this.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Axelay

Quote from: sigh on 16:44, 07 May 12

It'm guessing that "Burning Wheels" is using the "R3" scroll method in conjuction with the 1 pixel vertical scroll as it looks very much like your example. It seems that the shaking in the diagonal movement is due to the horizontal scroll moving 2 pixels instead of 1; meaning that it's always shifting an extra horizontal pixel against the single pixel vertical?



I was interested to see what "Burning Wheels" was doing so I've had a bit of a look.  The horizontal scrolling is R3 with two screens offset by one pixel, working together to produce a 1 mode 0 pixel step horizontal scroll.  The vertical scroll is interesting though, it does not use R5, but uses R9 to set the character height to 4 pixels high rather than the normal 8 pixels.  So now the 'course' vertical hardware scroll is 4 pixels instead of 8, and it then uses a further 2 screens that mirror the first 2 but are vertically offset by 2 pixels.  So it can use this combination of 4 screens and R3 to scroll horizontally by 1 mode 0 pixel and vertically by 2 pixels.

I dont see any reason why this approach should have an issue with diagonal scrolling, and slowing down an emulator I can see when moving diagonally the screen sometimes shifts both vertically and horizontally, but sometimes not, so that is why it's not smooth sometimes.  I would take a guess that this is only occurring because of the way it's calculating the multi directional movement, which is not fixed to 8 directions but is a full 360 degree movement, or at least something close to it.

arnoldemu

Quote from: Axelay on 10:36, 08 May 12

I was interested to see what "Burning Wheels" was doing so I've had a bit of a look.  The horizontal scrolling is R3 with two screens offset by one pixel, working together to produce a 1 mode 0 pixel step horizontal scroll.  The vertical scroll is interesting though, it does not use R5, but uses R9 to set the character height to 4 pixels high rather than the normal 8 pixels.  So now the 'course' vertical hardware scroll is 4 pixels instead of 8, and it then uses a further 2 screens that mirror the first 2 but are vertically offset by 2 pixels.  So it can use this combination of 4 screens and R3 to scroll horizontally by 1 mode 0 pixel and vertically by 2 pixels.

I dont see any reason why this approach should have an issue with diagonal scrolling, and slowing down an emulator I can see when moving diagonally the screen sometimes shifts both vertically and horizontally, but sometimes not, so that is why it's not smooth sometimes.  I would take a guess that this is only occurring because of the way it's calculating the multi directional movement, which is not fixed to 8 directions but is a full 360 degree movement, or at least something close to it.
I have seen this 4 pixels R9 setting used before. It is a good way to have 2 screens together which can be switched and which use the same 16k block of ram.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Powered by SMFPacks Menu Editor Mod