CPCWiki forum

General Category => Programming => Topic started by: fano on 23:11, 02 May 10

Title: Software pixel scrolling
Post by: fano on 23:11, 02 May 10
As i am working on a solution to optimise R-Type scrolling and to allow it to work on full mode 1 and mode 0, i am wondering if someone here had already tried this type of challenge.

The original code scroll only 1 bit per pixel so it is not suffisant.It does it in 11nops.Its works with a 32 char width screen.

This is the critical part of the code that scroll a pixel from a byte to the one of its left.It is repeated thousand times each frame.

If someone has an idea about how to get this faster or another faster method , i'll be very interested   ;)

HL = screen adress


sla (HL)
dec L
jr nc,skip
set 3,(HL)
.skip


I found an equal solution with 11nops using 2 aligned lookup tables and it works for full mode 1 (and for mode 0 with adapted tables)

pixel lookup tables (N means replaced with 0):
table 1 : 1234|1234 --> 234N|234N
table 2 : 1234|1234 --> NNN1|NNN1

DE = screen , HL = table 1 , BC = table 2


ld A,(DE)
ld C,A
ld A,(BC)
or (HL)
ld (DE),A
ld L,C
dec E


I attached the original code for scrolling in R-Type.



Title: Re: Software pixel scrolling
Post by: Grim on 00:43, 03 May 10
If you're after speed so badly, I would suggest to drop the slow byte-shift-thing and directly redraw the complete background using pre-shifted tiles/bitmaps in memory (a 128K machine is obviously required, esp. for mode 1). This way, you can also take care of special cases (eg. skip empty tiles) to get even more speed. Not sure this can be easily done in R-Type tho...
Title: Re: Software pixel scrolling
Post by: fano on 08:43, 03 May 10
It is a good solution as it is perfected adapted to the already existing rendering code.Problem is i already converted all graphics to 2bits so they inflate a lot.Level 1 tiles are already 4K so it would use 32K (some levels would use more).Sprites graphics already takes more than 16K and i'd like to add music and sfx so that would be a bit short in memory.

I didn't add precisions about the rendering process : All is charater based.The code scan an array , if it finds a part of a sprite, it will draw it directly.
If it finds a part of the map , it will check to find the dimensions of the strip of map to scroll (that what it the attached code does from ".l882b" label to get char count in B)
Title: Re: Software pixel scrolling
Post by: Leonie on 17:22, 14 May 10
Could somebody tell me details about the scrolling-routine of "Zynaps"?
Is this a hardware-scroll?
Very fast and steady, but not as smooth as "Star Sabre".





Title: Re: Software pixel scrolling
Post by: arnoldemu on 18:35, 14 May 10
Quote from: Leonie on 17:22, 14 May 10
Could somebody tell me details about the scrolling-routine of "Zynaps"?
Is this a hardware-scroll?
Very fast and steady, but not as smooth as "Star Sabre".
It's not a hardware scroll from what I can see.

But also it's not a scroll using LDI either.

The code is quite confusing at this time.
Title: Re: Software pixel scrolling
Post by: Capper on 23:16, 14 May 10
I don't claim to be an Amstrad coder, but the Spectrum version of R-Type does not scroll the entire screen, that would be just too slow, and why bother scrolling big tracts of empty nothing?

Think of one horizonatal line with nothing in it but space, a quick left to right character scan against a collision map tells you that there's nothing there to scroll - so it doesn't.

Now imagine that line with some background scenery in it, say somewhere in the middle, with empty spaces to the left and right of it. Scanning from left to right reads something like this...xx characters of empty space...yy characters of background...zz characters of empty space. You only need to scroll the yy characters and not the xx and zz spaces (since obviously pixel scrolling a space gives you....a space)

Of course, as you're scanning left to right and find a block of characters to scroll (and scrolled them) you need to keep scanning  until you reach the end of the line just in case there's another block. Which is often the case on the more organic looking levels where there are very few contiguous horizontal background characters.

This is what the Spectrum version does. It goes down the screen character line by character line and only scrolls data it finds that's background. And it only ever scrolls it a single character-high at a time, since that's all there is in a character line.

The number of such scrolls varies as it's going along, Level 1 has no background right at the start....so no data is scrolled. When some simple floor graphics appear it may be doing 3 or 4 scrolls per frame, and later when you start getting irregular ceiling and floors the number increases quite a bit. It may sound silly that at times only one single character of data is being scrolled because there's an empty space to the left and right of it but the miniscule amount of time it takes to do that makes it worthwhile.

Hope this can be of use.
Title: Re: Software pixel scrolling
Post by: fano on 00:01, 15 May 10
Quote from: Capper on 23:16, 14 May 10This is what the Spectrum version does. It goes down the screen character line by character line and only scrolls data it finds that's background. And it only ever scrolls it a single character-high at a time, since that's all there is in a character line.
Sorry , my english language is not especially good so what i wrote may be not easy to understand but Amstrad code does exactly what you describe.
Title: Re: Software pixel scrolling
Post by: Capper on 00:47, 15 May 10
Sorry, my mistake not yours. I wasn't aware the Amstrad screen scroll was done the same way as the Spectrum. D'oh!

And I seem to have jumped over and missed your breakdown of the scroll\screen update where you stated what I said - only much more succinctly. That'll teach me to read things properly first!

BTW the Spectrum Code uses 30 iterations of

rl (hl)
dec l

to scroll a complete horizontal pixel line

rather than the 60+ of

sla (HL)
dec L
jr nc,skip
set 3,(HL)
.skip
when it comes to scrolling.
Title: Re: Software pixel scrolling
Post by: Devilmarkus on 00:52, 15 May 10
Hi Capper,
welcome here in our forum.
Feel free to register.
So you can always see what you post, without need of approving your postings ;)

Cheers,
Markus
Title: Re: Software pixel scrolling
Post by: Leonie on 00:54, 15 May 10
Quote from: Devilmarkus on 00:52, 15 May 10
Hi Capper,
welcome here in our forum.
Feel free to register.
So you can always see what you post, without need of approving your postings ;)

Cheers,
Markus

Be quick about it!  >:(
Title: Re: Software pixel scrolling
Post by: Capper on 03:09, 15 May 10
Thanks for the invitation to register, but I only stopped by in passing because I found out Keith Goodyer had posted a message and, as he said, we never met and only spoke on the phone so it's good to see he's still around. Not being an Amstrad coder I wouldn't be able to contribute much anyway - as the contents of my previous two messages have amply demonstrated!

Good Luck with the project fano, R-Type coding has a habit of getting under your skin and taking over if you let it, after 22 years and three different versions (four if you count the PC demo) I think it's not quite done with me yet - so be careful.

I'm off now before that Leonie shouts at me again. She's scary.

Capper
(it's an anagram, but not a very good one. Sorry)
Title: Re: Software pixel scrolling
Post by: fano on 08:34, 15 May 10
Robert C. "Bob" Pape ! welcome on board , omg , this board is a dream lol

That's funny, as we were working on the R-Type yesterday evening, we were wondering if you still own the source code of the speccy version.Sadly , the CPC version was lost as Keith A Goodyer said so we hoped extracting gameplay part from speccy version.

It is interesting so see the Speccy code of this game and to speak about, especially with you.

Quote from: Capper on 00:47, 15 May 10
BTW the Spectrum Code uses 30 iterations of

rl (hl)
dec l

to scroll a complete horizontal pixel line

rather than the 60+ of

sla (HL)
dec L
jr nc,skip
set 3,(HL)
.skip
when it comes to scrolling.

Yes , there are 2 differences in the problem between CPC and Speccy.First , as the game uses 4 colors mode, you have 2 bytes for 8 pixels where Speccy have only 1 so CPC have already twice data to process.
Second, I suppose Spectrum pixels are stored from left to right like that : 01234567 (like CPC in mode 2) but for CPC they are stored like that 1234|1234 so you need a bit more tricky code like this one to scroll only 1 bit.
Title: Re: Software pixel scrolling
Post by: fano on 09:01, 15 May 10
Quote from: Capper on 03:09, 15 May 10Good Luck with the project fano, R-Type coding has a habit of getting under your skin and taking over if you let it, after 22 years and three different versions (four if you count the PC demo) I think it's not quite done with me yet - so be careful.
Thanks a lot ! love this game and long time i'd like to put my noise in its code  :P
I saw you've been credited too on r-type DX , what was this PC demo ?
Title: Re: Software pixel scrolling
Post by: Leonie on 17:02, 15 May 10
Quote from: Capper on 03:09, 15 May 10
I'm off now before that Leonie shouts at me again.
She's scary.

I like human flesh as well as guts.
Please send me one or several parts of your body.
I`ll pay you 10 Euro for a good pound flesh, and 5 US-Dollars for a good pound guts.
Please note: The flesh & guts should be properly packed.
Thank you.
Kind regards.

Title: Re: Software pixel scrolling
Post by: MacDeath on 21:07, 15 May 10
QuoteI like human flesh as well as guts.
Please send me one or several   parts of your body.
I`ll pay you 10 Euro for a good pound flesh, and 5   US-Dollars for a good pound guts.
Please note: The flesh & guts   should be properly packed.
Thank you.
Kind regards.
Please don't scare him : this guy actually did the best Speccy Game ever... :o
And some CPCwikier may like to interview him a bit perhaps, concerning the 8bit gamemaking industry of the 80's...

Also...well...Will you marry me too ? (intended to scare you...)
You must listen to Heavy Metal and dress like a Goth I suppose... And if you like Guts and Flesh, we have a lot of cul-inary dishes in France that you may like... :laugh:


Back to topic : This is Awesome, we had 2 guest stars on CPCwiki concerning the good old R-Type on CPC...

The administrators should put a new account category : "Prestigious Guest Stars"...


I suppose this is a sign : we shall not fail ! :angel:


Fano got all the Blessing needed and probably came into his pants... :P


Err...yeah, what was this PC demo ?
I suppose it was a prototype for an unreleased PC version ?
If it dates back from 1987 era, it's probably done with CGA-EGA Graphic support, I would be quite interested to have a look at it if so...
This could be quite usefull for my job on the proper Mode1 CPC Graphics ... as well as TotO's job on the Mode0 version (EGA was 16 colours too).
Title: Re: Software pixel scrolling
Post by: Leonie on 21:53, 15 May 10
Quote from: MacDeath on 21:07, 15 May 10
Also...well...Will you marry me too ?
You must listen to Heavy Metal and dress like a Goth I suppose...

I am the queen of the damned.
Dressed in black.
I wanna be your baby!
I´m open and ready!  :P



Back to topic:

On computers like AMIGA or ATARI ST, you can display more than the normal amount of colours.
Are there any "tricks" like these on the Amstrad?
I mean, is it possible to display all 27 colours in Mode0 ?
Or 8 colours in Mode1 ?
Title: Re: Software pixel scrolling
Post by: Devilmarkus on 22:39, 15 May 10
Quote from: Leonie on 21:53, 15 May 10
I mean, is it possible to display all 27 colours in Mode0 ?
Or 8 colours in Mode1 ?

Why not?
When you use rasters, you can increase the number of colours.
(http://cpc-live.com/elvira_raster.png)

But the result is not "pixel-perfect"
Title: Re: Software pixel scrolling
Post by: Capper on 23:01, 15 May 10
Leonie - unfortunately I'll have to pass on your offer, I sold my body and soul a long time ago.....and look at the good it did me.

Fano - Yes I still have the original source code, but terchnically Activision own it - it's why they could give mine to Keith and Karl's to Manfred Trenz without having to pay us. Unfortunately as Keith found out it's not commented all that much and is a mess of self-modifying code and multiple entry points in order to save memory.

Yes I am credited on R-Type DX, I wrote the original mono Gameboy version of R-Type 2 and Jase Austin the mono Gameboy R-Type years ago. We were asked to  port our games over to the Colour Gameboy, add a bit of colour and stick the two of them together to make the DX version. It was a hack job really.

MacDeath - The PC Demo was created around 1995 and was just a calling card really, I got Mark Jones to send me some of the original ST graphics and built Level 1.
A friend of mine was working for IREM in Osaka and he showed it to them, while they couldn't acknowledge it officially I was told it was OK as long as I was just using it for myself. The screen ratio was wrong and the sound effects weren't from the original, the twist was it was completely written in Visual Basic. Bearing in mind that it was designed to be compatible with Windows 3.1 I thought it looked and played pretty good, and I did get a couple of PC projects off the back of it.
Title: Re: Software pixel scrolling
Post by: ukmarkh on 01:34, 16 May 10
Hi Capper  :)

Would you be interested in doing a short interview for the upcoming CPC Book? Would love to have you on board, Keith has already agreed to one, as have many others. I've just finished an interview with Kevin Toms, great guy and quite an interesting interview. 
Title: Re: Software pixel scrolling
Post by: Capper on 02:06, 16 May 10
Quote from: ukmarkh on 01:34, 16 May 10
Hi Capper  :)

Would you be interested in doing a short interview for the upcoming CPC Book? Would love to have you on board, Keith has already agreed to one, as have many others. I've just finished an interview with Kevin Toms, great guy and quite an interesting interview.

I spent a day Go-Karting with Kevin Toms, Anita Sinclair and a few others in Andover once, I wonder if he remembers that.

I don't know what I can bring to your book, I never really had any interraction with the Amstrad machines, my code was just given away and I was told it was being converted. But if there's anything else you want to know then sure, I'd be happy to answer any questions.

But best to take it out of this Thread, I don't want to hijack what should be technical talk about coding.
Title: Re: Software pixel scrolling
Post by: MacDeath on 02:52, 19 May 10
(http://www.crashonline.org.uk/55/images/a_sinc.jpg)

THIS Anita Sinclair ?

Lucky guy... :P


More seriously, i would be interested in some details concerning the Graphics port for the Speccy R-Type.
From what I saw, they seem ported mostly from the Atari version (redimensionned sometimes... or re-composed/re-Tiles), but i wonder how the 1bit monochrome was achieved ?

Also how was the  Grapists and Coders relation in those games ? worked in the same room or never saw them ? how many time it took them ?
Title: Re: Software pixel scrolling
Post by: Capper on 21:29, 19 May 10
Yes......THAT Anita Sinclair.

Mark Jones did the graphics for all the versions (except the C64 Rainbow Arts version). Since he was doing multiple versions he decided it would be easier - and more accurate for the final result - if he did the 16 colour ST graphics first and then converted them down to lower resolutions. Mark showed me how he did it once, it was a combination of colour reduction and dithering and then building back up. The colour depth was reduced to 1 bit on the ST in several stages, by reducing\merging colours down from 16 and then dithering - you get a slightly different look if you dither down from 4 colours instead of 16. The raw 1 bit graphics were converted to Spectrum SCREEN$ files then loaded into Melbourne Draw and then Mark would then go in and clean up the result, putting Spectrum-specific attribute colour back into the graphics and making sure there weren't silly things like characters with only 1 or 2 pixels in. Some specific sprites like the Player Ship and Weapons were drawn completely from scratch, that way he could make sure on exact sizing and proper colour placement. I had written some custom sprite-editing\grabbing software for the Spectrum so Mark or I could take the SCREEN$ and turn the contents into individual sprites - handy for seeing animations - and I also wrote some level-mapping software for Mark to build the Levels. ST Level graphics were just a bit too big, and long, for the Spectrum so character strips would often be taken off the bottom of the tiles (or the top if the the ceiling) to give more space in the middle of the screen and I would sometimes have to take out small sections of the map as well so that the game flowed properly, the game proportions and timings would have been wrong if I hadn't. When I was ready I could use the PDS system to transfer the Spectrum sprite and map data to the PC and into the source code.

Unless you were working for a software house with a specific graphics department then you never really saw the graphic artists. I tried to make it a habit when working with Mark Jones to meet up with him before we started and talk over what we were going to do; colour and size requirements, map layouts, tiles, animation cycles that sort of thing. I'd find out if he needed some custom written software from me or if there was an easier way to do things. It was very much a collaboration on our part, I would ask him what he could give me rather than tell him what I wanted because I knew I could trust him to supply top class graphics. There was never any need to look over his shoulder and check up on what he was doing, and he trusted me to take his work and show it off in the best light. With regard to time, there was no need for me to have everything right from the very start so I'd just ask for what I wanted when I needed it. It's actually a bad move to start with everything since you may discover that what you planned is wrong and everything needs to be redrawn, which if you've only done a few sprites and a Level is not that hard a thing to sort out. Generally I'd phone Mark and say that I needed certain sprites or map data in a week or two's time, talk over any possible problems or colours and leave it up to him. I'd get a cassette tape of SCREEN$ in the post and there was usually everything I'd asked for. Even when I moved down to Fareham for a while I seldom saw Mark, and he lived just a few miles away.
Title: Re: Software pixel scrolling
Post by: MacDeath on 19:33, 20 May 10
Wow... Thx a lot for this complete answer...

I'm just a bit disapointed that the CPC version wasn't really planned a few time before so he could have made the 2bit graphics first hand. :'(

Yet I'm starting from Mark Jones Datas to re-draw completely them in real  un-attributed 4 colour mode...
I respect exactly the tiles and global shapes, also the dithering is a good starting base...
Yet instead of Black and White/colour (with attributes added on this) I put the dithering from White, Colours and White... in 3 gradients...
But of course some part remains in Black and white to add some colours feeling.

So those speccy Graphics are like a Raw which helps me a lot actually.

It's perhaps easier for me today as I work on a modern PC with all the GUI environment and lots of inspiring sources... 8)

But another guy is helping us, doing a wide pixel 16 colour mode.
He told me he starts from other source, like Arcade/Atari ST sprites/tiles, re-size them so it roughly fit the Speccy/CPC tiles/sprites characters...
And convert in wide pixels.

Not an easy way in my opinion... :-\
For me it's easier because the 4 colour mode pixels are square too...

But my result may be far different from the original too.
I often completely redraw or add details, and re-do the ditherings...

But also as many sprites are smaller, it's quite difficult to have those actually looking like something...

The Babies from last level per exemple...ouch...

Title: Re: Software pixel scrolling
Post by: kgoodyer on 03:09, 14 June 10
This is bizzar!  Hiya Bob - long time no speek - about 21 years by my reconing. LOL

Keith
Title: Re: Software pixel scrolling
Post by: Capper on 23:30, 14 June 10
Hi Keith,

We can't go on meeting like this, people are beginning to talk!

Nice to see you're still around, as I said I only popped in here coz I saw you'd been posting. All those games so long ago and it looks like it's only you and me left...hehe....just looked you up in an old address book of mine, for some reason I wrote the initials M.S.U. next to your name, any idea what that meant? Sorry to hear you lost a load of source code, I though I'd done the same but I found a lot of it on an old ZIP disk in the attic unfortunately a lot of the R-Type graphics are on microdrive and I can't touch them.

Hope you're keeping well....don't wait another 21 years getting in touch :-)

Bob
Title: Re: Software pixel scrolling
Post by: Gryzor on 15:48, 15 June 10
Are these standard Speccy microdrives then? I do bet there's an army of speccy nerds out there willing to pull them apart :D
Title: Re: Software pixel scrolling
Post by: robcfg on 16:26, 15 June 10
I'll be getting a QL sometime near in the future and it shouldn't be too difficult to copy the microdrives to a 3.5" disk and then creating a dsk file for our pleasure.
Title: Re: Software pixel scrolling
Post by: Gryzor on 10:44, 16 June 10
Hey, I just realised I *do* have a QL :D
Title: Re: Software pixel scrolling
Post by: fano on 00:11, 25 September 10
Quote from: Grim on 00:43, 03 May 10
If you're after speed so badly, I would suggest to drop the slow byte-shift-thing and directly redraw the complete background using pre-shifted tiles/bitmaps in memory
That was the good solution , thank you for the hint  ;)
Powered by SMFPacks Menu Editor Mod