News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_ivarf

Uridium on the CPC with hardwarescrolling

Started by ivarf, 14:33, 21 May 14

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

SyX

Those mini-tutorials bring me back to the middle of the 90s, when i discovered your site in andercheran, the first or second web page that i saw in my life, jejeje.

After the nostalgia moment, i feel those scroll examples are great for bringing knowledge to the community. While i have been researching special FXs in games for CPC-Power, i have seen a lot of patterns used by the best CPC games. At the same time, you can split companies in the number of techniques used and the evolution of their engines.

For example, the big Ocean licenses (Robocop, Batman, ...) only used double buffer and software scroll. If they had learnt about vertical splits, for splitting the game zone from the scoreboard (and made the scoreboard with 2 scanlines chars of course), they could have saved a lot of ram that it could well used for improving the sprites routines or adding more animation frames.

With respect to its software scroll, for example in Total Recall, the vertical scroll is in steps of a full tile (16 pixels) and the horizontal one is in byte steps (2 pixels). Even in software, with the RAM recovered by splitting the scoreboard in a 464 and making a better use of the double buffer, they could have improved the rate of the scroll to be 1 pixel in both axys and the screen size from 128 pixels to 144 or 160 pixels without losing speed.

The Ocean's sprite routines are very similar to the ones we have those days, using set and res for going down the scanlines and the stack for recovering the sprite graphics and skipping bytes in the clipping routines. Although the number of sprites in screen is not high, they used big ones and i always liked that.

And of course, make they lacks of the next step, the hardware scroll. Even if it means that we need to make new sprite routines and they are going to be slower, this will make a big difference in the general speed of the game.

We only need a general solution to the CRTC block reset scroll, for example, i have been testing using the CRTC Cursor NMI interrupt in the PlayCity for checking when a reset is visible in screen and signal it to the renderer.

Double buffer + Vertical rupture + Scroll hardware = CPC Ocean Engine in 2014

The next year, i want to work in a project using these techniques. Possible ideas are Lethal Weapon or Hook, two Ocean games without CPC version, but the C64 version of Total Recall has bigger and more involved maps than the CPC one, ... or maybe converting a film of those days to the Ocean's way, jejeje.

Joseman

Always wondered why ocean don't made a lethal weapon version for the cpc... I think that the CPC was a beloved machine for they...


Carnivius

I borrowed the Amiga version off a friend at school.   It wasn't one of Ocean's better games.   Very forgettable.  Crappy sprites too.
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

SyX

Quote from: Joseman on 19:53, 20 September 14
Always wondered why ocean don't made a lethal weapon version for the cpc... I think that the CPC was a beloved machine for they...
I always asked me about what would have happened if the best Ocean CPC coder, John Brandwood, had not  been promoted so soon to other machines (16 bits and consoles, and sent to USA for  Malibu Interactive, ...), we lost his evolution in the CPC...

TFM

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

arnoldemu

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

arnoldemu

A new example.

This example shows one way to detect if a sprite is over the "problem scroll area". This can be then used to choose between a faster or slower method for drawing a sprite.

The idea is:

1. We calculate an x,y sprite coordinate for the problem scroll area.
2. When we scroll we update the x,y allowing for screen wrapping
3. When we go to draw the sprite we check if the bad x,y is within the sprite rectangle by testing left, right, top and bottom.
4. In this example, sprite is drawn fully red for over the bad area and with lines for not over the bad area.

Files are attached.

I will go back and add more comments to these and upload them to my website soon.

So, in this there is a trade off between calculating this and the speed up given by the sprite routine compared to using the slower sprite routine all the time.

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

arnoldemu

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

TFM

#58
Quote from: arnoldemu on 11:11, 21 September 14
Renegade and gryzor.

Their GFX is very beautiful, the Sound/FX is great too. Also coding is nice. However Gryzor should scroll IMHO.

Quote from: arnoldemu on 13:44, 21 September 14And short circuit.

Just checked that out on youtube. GFX is ok, sound is ok, but it uses only a minor part of the screen. It's not really bad, but nothing special either IMHO.

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

andycadley

I've never been a fan of Uridium, I think the C64 original scrolls too fast for the amount of view ahead you have, it has those frustratingly stupid X homing things and it just looks plain ugly. However, it is one of those games where I think the CPC could do some interesting things if coded properly. Hard scrolling should be doable, but also with careful arrangement of the palette and some cunning bit manipulation I think you could also get a much better "shadow" effect for the ship without sacrificing much. It's one of those things where it could be a great tech demo (much as the C64 version was)

arnoldemu

I did an initial test. Pixel by pixel mode 1 moving sprite.
Gets to the left/right side which then causes a scroll of 5 chars movement (like the "not nice" push scroll).
But this time sprite is meant to move with it, but you can't tell.

So using this method it appears you can use pixel by pixel sprites, but when the sprite happens they now move faster.
It seems to work ok and it's probably exactly how Ghouls n Ghosts etc works, although I always thought there was some extra movement in there, like the sprite goes slightly faster than the scroll.

NOTE: The sprite flickers badly in this example. Please don't use it if it would cause you problems when you watch it.
Code works with Winape.
No dsk at the moment.

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

sigh

Great examples.

I want to check out the latest test but I forgot how to get the asm running in winape!!

What is very interesting is how smoothly the sprite scrolls vertically. I'm guessing that to keep consistency, you would need the vertical scroll to have the same speed and pixel timings as the horizontal?

TFM

DSK would be great, no WinApe at lab PCs sadly (but could sneak in Caprice, hehe).  :-\
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

sigh

Looking at a new topic asking about Gryzor and I was wondering what scrolling method is being used on the  Face Hugger demo.

http://www.pouet.net/prod.php?which=27794

The background catches up with the sprite when the it stops moving.

Powered by SMFPacks Menu Editor Mod