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.

TFM

Quote from: arnoldemu on 09:00, 08 May 12
I will, these are early examples :)
final ones will not have a repeating background.
That really doesn't matter. In contrast, I think (IMHO) it's better to keep code simple, so people got a chance to understand it.
I thought about releasing a kind of skeleton of my game engines scroll code too, nothing special, but since it need also a screen at &0000 it will be of no interrest to most people. But I guess in your examples it's shown how it works.
Now, let's hope that some more people pick up your examples and learn how to scroll smooth ;-)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

TFM

About R9: I was able (real CPC, not emu) to work with R9=1 (2 scanlines per character-line), which has quite some advantages. But did ever somebody manage it to work with R9=0 (just one scanline per line) ??? That would be a "good to have", the screen would be much more easy to use.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

fano

The problem is R9=0 is not compatible with CRTC 2 is my memory is good.Playing with R9 values on a character based rendering is good idea anyway.If i remember well , X-Out used R9=5 for example.

A personal thought about linear addressing for lines maybe not more optimised than the actual one , it is actually faster to set or res one or two bits to reach next line than doing a 16bits addition.
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

arnoldemu

Quote from: TFM/FS on 16:49, 08 May 12
That really doesn't matter. In contrast, I think (IMHO) it's better to keep code simple, so people got a chance to understand it.
I thought about releasing a kind of skeleton of my game engines scroll code too, nothing special, but since it need also a screen at &0000 it will be of no interrest to most people. But I guess in your examples it's shown how it works.
Now, let's hope that some more people pick up your examples and learn how to scroll smooth ;-)
I would like to see your "crossfire" scrolling code.
Does it use rupture and split the screen into 2 sections each of which are scrolled?
You then clip sprites if they cross the 2 areas?

Back to the 1 pixel scrolling:

I am updating the examples so you can control them with the keyboard.

I will add plus scroll too for comparison and to show how it's done.

After I am done showing various scrolling, I'll then move onto the scrolls used in games (push scroll etc so we can compare the merits of these).


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

sigh

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.

Okay - it must be my laptop as the screen doesn't have a very high refresh rate that's causing shaky screen syndrome; it has a very old graphics card! So R9 can 1 pixel scroll vertical? Or is it limited to 2 pixels?


Quote from: arnoldemu on 17:40, 08 May 12
I would like to see your "crossfire" scrolling code.
Does it use rupture and split the screen into 2 sections each of which are scrolled?
You then clip sprites if they cross the 2 areas?

Back to the 1 pixel scrolling:

I am updating the examples so you can control them with the keyboard.

I will add plus scroll too for comparison and to show how it's done.

After I am done showing various scrolling, I'll then move onto the scrolls used in games (push scroll etc so we can compare the merits of these).




Excellent! I'm really looking forward to seeing multi directional 1 pixel scroliing  on a CPC for the very first time!

TFM

Quote from: fano on 17:28, 08 May 12
The problem is R9=0 is not compatible with CRTC 2 is my memory is good.Playing with R9 values on a character based rendering is good idea anyway.If i remember well , X-Out used R9=5 for example.

A personal thought about linear addressing for lines maybe not more optimised than the actual one , it is actually faster to set or res one or two bits to reach next line than doing a 16bits addition.
Agreed! That's the idea :-) And btw. ... my CPCs are CRTC 2  :-X

EDIT: Never tried on Plus, because there you have other stuff to play with. Maybe I should give it a try there.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

TFM

Quote from: arnoldemu on 17:40, 08 May 12
I would like to see your "crossfire" scrolling code.
Does it use rupture and split the screen into 2 sections each of which are scrolled?
You then clip sprites if they cross the 2 areas?
Using two screens of 16 KB each, in the middle of the screen they must be switched (in realtime, means at least close to one interrupt which occurs short before, but not at ys level, so it's convenient).
Yes the sprite is more often divided for the two screen RAM blocks, but the transfer is easy just reset or set the two high-bytes of the V-RAM address. Yes, the start-address of both screens must be choosen wisly, but only once, then just treat both screens equal. (If you like parallax scrolling, it get's a bit nasty though).

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Executioner

Quote from: fano on 17:28, 08 May 12
The problem is R9=0 is not compatible with CRTC 2 is my memory is good.

I didn't know about this one. Lots of demos use R9=0, and yes, most emulators do support it as far as I know. The problem with R9=0 is you can only use 1/8th of memory for the screen, and it's always the first 2K of each 16K block. Even using a 32K addressing trick and 64 byte screen width you're limited to a 64 line screen (or 128 if you do a split in the middle and use 8K of memory, one lot of 2K in each 16K block). It can be done if you're using Interrupt Mode 2.

arnoldemu

Quote from: TFM/FS on 19:41, 08 May 12
Using two screens of 16 KB each, in the middle of the screen they must be switched (in realtime, means at least close to one interrupt which occurs short before, but not at ys level, so it's convenient).
Yes the sprite is more often divided for the two screen RAM blocks, but the transfer is easy just reset or set the two high-bytes of the V-RAM address. Yes, the start-address of both screens must be choosen wisly, but only once, then just treat both screens equal. (If you like parallax scrolling, it get's a bit nasty though).
Ok, I will try to make my own crossfire now ;)
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

Updated sources:


Controls:

number pad 4 left, 8 up, 6 right, 2 down. The following keys do diagonals: 7 up-left, 9 is up-right, 1 is down-left, 3 is down-right. I did it this way so we can see diagonals working perfect (pressing up/left, right/down is not possible with this code.)

Normal scroll, use the keys to control it:
http://www.cpctech.org.uk/source/vscroll1.asm

Smooth vertical (R5) and horizontal R3 byte-by-byte:
http://www.cpctech.org.uk/source/vscroll2.asm

Plus hardware scrolling. Setup for mode 0 (4 "mode 2" pixels in horizonal, 1 in vertical).
http://www.cpctech.org.uk/source/vscroll1p.asm

Next stage I will let user choose mode so we can work out perfect increments for each mode (especially for plus).

I will also add r3 and screen offset by 1 pixel for smooth mode 0 scroll this way, and update example 3 to use 4 screens.

I started an example to show what happens with overscan screen (using r12/r13 overscan method).

Watch out for a crossfire example soon  :P

(I also need to add better comments and descriptions to the code)
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

sigh

At work and really looking forward to downloading these examples when I get home; I just can't wait to see the results!

So have you finally cracked the 1 pixel multi scroll?(sorry - I don't have winape at work) How much memory does it use and what were the main difficulties?



arnoldemu

Quote from: sigh on 11:25, 10 May 12
At work and really looking forward to downloading these examples when I get home; I just can't wait to see the results!

So have you finally cracked the 1 pixel multi scroll?(sorry - I don't have winape at work) How much memory does it use and what were the main difficulties?
no sorry, I just added keys so it can be controlled.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

sigh

Quote from: arnoldemu on 13:48, 10 May 12
no sorry, I just added keys so it can be controlled.

Okay, cool.

Quick question - How many frames per second is it scrolling?

arnoldemu

Quote from: sigh on 14:33, 10 May 12
Okay, cool.

Quick question - How many frames per second is it scrolling?
50 fps.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

sigh

Quote from: arnoldemu on 17:54, 10 May 12
50 fps.

I managed to get the first and last example working and they look great - but I didn't manage to get the second example to run. It just stayed on the screen with all the symbols and letters even though I pressed all the keys on my laptop. (I have to hold down alt to use numberpad keys...)

The last example with the plus is EXACTLY the smooth motion I'm looking for on the CPC. It's just one big drool of lovliness!!!

arnoldemu

Quote from: sigh on 20:42, 10 May 12
I managed to get the first and last example working and they look great - but I didn't manage to get the second example to run. It just stayed on the screen with all the symbols and letters even though I pressed all the keys on my laptop. (I have to hold down alt to use numberpad keys...)

The last example with the plus is EXACTLY the smooth motion I'm looking for on the CPC. It's just one big drool of lovliness!!!
On winape i think you have to press num lock first to activate f keys?

I'll have another example to show soon.

To give correct speed in left/right and up/down on mode 0, you need to move 1 pixel in x and 2 pixels in y.
I will upload it tonight to show.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

sigh

Just tried the num lock and got the second example working. Very smooth in vertical.

Xyphoe

Just another perhaps daft one to throw in the mix that does things a little differently is COMMANDO, it achieves very smooth 1 px scrolling vertically, but it's not scrolling the whole screen but just the background objects (eg trees, sandbags, trenches, etc) as tiles I guess. Whilst it can look a little wobbly and when there's a large section to move things can slow down (eg a bridge and tunnel, and especially later on with landing strips which are AWFUL), I like that the programmer 'thought out the box' (I hate that phrase btw!) a bit - and we ended up with a very fast and smooth playing arcade conversion that's great fun. It's nice to see something taking a different approach for scrolling, if not entirely successful. Hopefully it might throw up a few ideas.



[AMSTRAD CPC] Commando - Review & Longplay(*)

Bryce

Quote from: Xyphoe on 21:24, 14 May 12
I like that the programmer 'thought out the box' (I hate that phrase btw!) a bit

Then try using the real phrase "Thought outside of the box" :D but I hate that phrase too though.

Bryce.

sigh

Quote from: Xyphoe on 21:24, 14 May 12
Just another perhaps daft one to throw in the mix that does things a little differently is COMMANDO, it achieves very smooth 1 px scrolling vertically, but it's not scrolling the whole screen but just the background objects (eg trees, sandbags, trenches, etc) as tiles I guess. Whilst it can look a little wobbly and when there's a large section to move things can slow down (eg a bridge and tunnel, and especially later on with landing strips which are AWFUL), I like that the programmer 'thought out the box' (I hate that phrase btw!) a bit - and we ended up with a very fast and smooth playing arcade conversion that's great fun. It's nice to see something taking a different approach for scrolling, if not entirely successful. Hopefully it might throw up a few ideas.

Yes - I was also thinking about this method too. Maybe with commando, I wonder if it would of been possible to switch to a vertical scroll for the more complicated bits, then switch back to the tile scroll when those complicated sections had finished scrolling pass the screen....

MacDeath

QuoteI like that the programmer 'thought out the box' (I hate that phrase btw!) a bit
QuoteThen try using the real phrase "Thought outside of the box"  but I hate that phrase too though.


Chancellor Puddinghead thinks outside the box (inside the chimney)

:laugh:

But yeah, it's like registering outside the CPU.
Or addressing outside the main RAM.

sigh

Okay guys and gals - here's the reason for this thread :)

Around a year ago I promised to work on a "heavily animated football game" along with completing the beat em up. The beat em up is starting again from next month as I haven't touched it since last year, being back at fulltime work amongst other things, which means I'm having to try harder to juggle my hours more efficiently. The beat em up is one a helluva task, so I had put it aside to attempt something a little simpler; the "Football" game - not a favourite sport of mine, but as an animator I enjoy watching the movement:

Rough example (please ignore the sliding sprites!)





All the sprites, animation and graphics are finished!! The backgrounds are also done, but I have feeling that I may have far too many sprites. It's taken around 72KB and that includes both teams and the frames mirrored, pitch, referee and linesman. The goal keeper ended up having it's own sheet as I got far to excited and animated him rolling on the ground and performing allsorts of nonsense, but I'm thinking that his diving could just be compressed and then uncompressed when it needs to happen. Otherwise, he'll just skip around the field like anybody else.






As you can see, unfortunately the pitch isn't vertically long enough which may limit the experience when performing set ups, passing and tactical play, though I'm not to sure how other people feel about this. I think that multi directional scrolling through horizontal and vertical would solve the problem, but more importantly; it would be interesting to experiment with this sort of scrolling.

The examples shown are moving at 1 pixel at 25 frames per second. The screen is 320 x 200 with the pitch being 320 x 194.
The sprites are 16 x 16, though some are are much smaller due to sliding tackles, diving headers, bicycle kicks etc. The locomotion of the sprites which are the walk, jog, run, sprint and skipping, take the most space on the sprite sheet.  With these different locomotions, it would give a better sense of realism rather than having just one run cycle.
One more thing I would like to see is different nationalities/races within a team. For instance, with UK football having it's fair share of black and asian players, it would be nice to have this reflected if possible in the teams. :)



ivarf


Xyphoe

Quote from: Bryce on 21:28, 14 May 12
Then try using the real phrase "Thought outside of the box" :D but I hate that phrase too though.

Bryce.

Goddamn pedants!



(ps the phrase is actually "Thinking outside the box"  :P :P :P )

Xyphoe

Quote from: sigh on 22:33, 17 May 12




WOW! WOW! WOW! YESSSSSSSSSS!!!!

Like x 1000000000

This has made me so happy and excited!!! Basically I LOVE arcade soccer games (of the 80s to early 90s era) and have always been bitterly disappointed that none of the Amstrad footie games come up to scratch. Sure I love Emlyn Hughes, but it's slow and more of a sim.  People seem to rate Italy 1990 highly due to it's speed and colours, but it plays a crap game of football. The fact that the C64 had the amazing Microprose Soccer and even the ancient International Soccer just makes me want to cry more bitterly!

But my god... if you manage to finish this and have it looking/moving anything like the above I will love you all forever!!!

It seems like it might be heading in the direction of a cross between ...

The old International Soccer on the C64 -


C64 Longplay - International Soccer (HQ)

And Tecmo World Cup 90 (the best coin-op!) -


[ARCADE/COIN-OP] Tecmo World Cup '90 (MAME) - Speed Run : one credit, hardest difficulty, least time

Something in the middle of that would be awesome! And guys... if it helps, don't be afraid to make it a Plus game with hardware sprites and scrolling ... soccer games should be fast, smooth and fun - ignoring Italy 1990 which fails on the basics of soccer this is where the Amstrad has failed time and time again.

Heck ... anything I can do to help out let me know! I'm no coder, but maybe I'll get back into my soundtrakker and write some music ... or I could do the box art, instructions, website and hosting for it, whatever!! I want this completed! LOL! xxx  :P :-*

Powered by SMFPacks Menu Editor Mod