Homebrew coding on arcade hardware

ben76

Hunts Spies
Feedback
7 (100%)
Credits
1,136CR
Thanks for the reply mate
smiley20.gif
I was only wondering the scary thing is I understood most of what you wrote lol! Anyway, I'm not an ELC (CPC) fan so I have no idea if they were any good titles on it lol Rich/strykr or Eric would be you're best bet at a guess!
Also for the record the best version of Chuckie Egg was the 800xl one
smiley17.gif
(not chuckie egg 2 btw as it never appeared
smiley19.gif
)

Also keep going guys I can still see some awesome stuff appearing (even if you love the CPC Eric
smiley36.gif
smiley17.gif
)

- Ben
smiley1.gif
 

Hurray Banana

Moderator
Staff member
vacBacker
Feedback
8 (100%)
Credits
2,721CR
Ben you are a cheeky fecker
smiley1.gif


In Spindizzy on the amstrad (et el) the pixel level frame buffer allows you to draw a scene by drawing each object from front to back. This is aided by having a tranparent pixel colour which you skip drawing. This takes loads of cpu, which can be seen by the pause before each level is displayed. But it is a relatively straightforward process.

On tilemap hardware (pacman in my case) this is ridiculously complicated to achieve. You have a fixed set of graphic tiles (256) this cannot be written over each other with transparency, so you have to calculate what graphic tile should sit a certain location on the screen based on what has already been drawn at the location. This obviously changes depending on what tile graphic is going onto another and where the perceived transparency is. In my solution this involves a huge (800 bytes out of 16K available in total) composite lookup table to try and determine final render tile. this gets more complicated as you place tiles on top of composite tiles, there are basically lots of combinations.

Hopefully now that I'm back on this with Spin Pac-Dizzy i'll be able to show some progress over the next week or so. It's complicated but as Ade will tell you that's what makes doing this shizz fun.
 

backflipper

Active member
Feedback
4 (100%)
Credits
750CR
Nice stuff guys.
I remember asking my IT teacher back in 88 why we couldn't have arcade quality games on the ibm xt and he was unable to give me an answer.
It's why I got into electronics and programming.
 

Hurray Banana

Moderator
Staff member
vacBacker
Feedback
8 (100%)
Credits
2,721CR
backflipper said:
Nice stuff guys.
I remember asking my IT teacher back in 88 why we couldn't have arcade quality games on the ibm xt and he was unable to give me an answer.
It's why I got into electronics and programming.

This is why I'll always try to give my students an overview answer to questions like that and give them advice where to start looking to get further information if they are interested.
 

cmonkey

Active member
vacBacker
Feedback
4 (100%)
Credits
1,658CR
backflipper said:
Nice stuff guys.
I remember asking my IT teacher back in 88 why we couldn't have arcade quality games on the ibm xt and he was unable to give me an answer.
It's why I got into electronics and programming.

When can we expect to see some arcade homebrew from you then, if you're into programming?
smiley1.gif
 

ben76

Hunts Spies
Feedback
7 (100%)
Credits
1,136CR
Hurray Banana said:
Ben you are a cheeky fecker
smiley1.gif


In Spindizzy on the amstrad (et el) the pixel level frame buffer allows you to draw a scene by drawing each object from front to back. This is aided by having a tranparent pixel colour which you skip drawing. This takes loads of cpu, which can be seen by the pause before each level is displayed. But it is a relatively straightforward process.

On tilemap hardware (pacman in my case) this is ridiculously complicated to achieve. You have a fixed set of graphic tiles (256) this cannot be written over each other with transparency, so you have to calculate what graphic tile should sit a certain location on the screen based on what has already been drawn at the location. This obviously changes depending on what tile graphic is going onto another and where the perceived transparency is. In my solution this involves a huge (800 bytes out of 16K available in total) composite lookup table to try and determine final render tile. this gets more complicated as you place tiles on top of composite tiles, there are basically lots of combinations.

Hopefully now that I'm back on this with Spin Pac-Dizzy i'll be able to show some progress over the next week or so. It's complicated but as Ade will tell you that's what makes doing this shizz fun.
I sort of followed that and tbh again I am just amazed by how a load of 1's and 0's become a playable game!
The reason why I asked was the CPC didn't have colour clash did it? but both CPC and the Speccy use the same processor, also the fact if you have seen the Oliver Twins talk on Dizzy at the last Play Blackpool they programmed on a CPC and ported it over (can find you the link if needed was a great talk). I however only ever played once on a CPC and it had a fecking green screen so was sh*t and we all avoided that kid in school lmao

- Ben
 

Hurray Banana

Moderator
Staff member
vacBacker
Feedback
8 (100%)
Credits
2,721CR
I may be wrong because never had a speccy or programmed for one but to me it looks like the spectrum has a separate 2 colour palette map which is set in 8x8 pixel regions. With a separate bit per pixel frame buffer (any bit set in frame buffer is pixel on in colour 1 and 0 set in frame buffer is pixel on in colour 2).

That's why you get colour clash because all graphics in an 8x8 region of the screen must use the same two colours as specified in the colour map. As you move sprites around on the speccy you need to update the palette map to travel along with that sprite.

On the Amstrad you had interleaved bit planes, 4 in lo-res mode (giving 16 colours), 2 in medium res mode (giving 4 colours) and 1 in hi-res mode giving 2 colours (mono chrome). Each pixel representing an individual colour selected from the palette in that mode. Uses more memory and can be a pain in the ass to write data to because of the interleaving. But no colour cllash as every pixel can have it's own colour from the palette.

As Ade said they olivers probably used the amstrad for development because it had a nicer keyboard to work on, they probably just had some cross assembler tools to port out the speccy versions. Obviously don't know for sure.
 

cmonkey

Active member
vacBacker
Feedback
4 (100%)
Credits
1,658CR
You got it pretty much bang on there Eric. Not bad for someone who's never coded for a Spectrum!

The Spectrum display is broken up into the display file and the attribute file. The display file runs from $4000-$57ff and represents a bitmap of size 256x192 (=6144/$1800 bytes). Each row is 32 bytes in width and each one of those 32 bytes represents 8 bits (or pixels, if you prefer to call them that!) (32x8=256 pixels wide). If a bit is set then that pixel is on, if a bit is clear then that pixel is off. The display file layout is non-linear and to a non-Spectrum programmer it would appear to be an extremely strange layout. It starts to make much more sense when you code in assembly language but I won't go into the complexities of it in this post. (simply put you can use INC H to move down 1 line in the display file and DEC H to move up 1 line in the display file, but it gets a little more complicated than that as the display file is actually comprised of three distinct segments).

The attribute file runs from $5800-$5aff and is a 32x24 grid of colour information for each 8x8 block (tile) of the display file. Each byte of the attribute file is comprised as follows :-

bits 0-2 = ink (pen) colour (8 possible colours from 3 bits)

bits 3-5 = paper colour (8 possible colours from 3 bits)

bit 6 = brightness level (on or off)

bit 7 = flash (on or off)

So, each 8x8 tile displayed on screen can contain a maximum of 2 colours (an ink colour and a paper colour) at any one time. To move a sprite you need to update the display file with the new position of the bitmap of the sprite and then update the attribute file to ensure that the colour information moves in tandem with the sprite bitmap data. Sprites were usually done in a pre-shifted fashion, moving 2 pixels at a time. Therefore you would need to define 4 sprites to move a character 8 pixels left or right. This technique consumed quite a fair amount of ram (especially if your game had many varieties of sprites) but allowed for smooth character movement. If the character moved 2 pixels per frame then it would cover the width of the screen in 128 frames (2.56 seconds for a 50Hz PAL Spectrum). This was considered too fast for many games so character movement was usually done every other frame or even every third frame to slow things down to a more playable speed.

The reason the Spectrum suffered from colour clash was because, as the sprites moved around the screen, they would move into areas where the attribute file contents for the 8x8 tile they were moving in to had different colours to the attribute file contents of the sprite and because each 8x8 attribute file tile can only contain a maximum of two colours at any one time something had to give. So either the sprite's colours got messed up or the background tile's colours got messed up, depending on the draw order of sprite vs other sprite or sprite vs background tile.

Colour clash is the reason why many Spectrum games ended up being monochromatic, after all, it's impossible to have colour clash if the entire screen only uses 2 colours!

As strange as it sounds, to me the colour clash was really a big part of the Spectrum's heart and soul and, IMHO, kind of helped to make it the machine that it was. To that end I'm even considering adding a special 'colour clash' mode in my CE2 remake on L System (toggle-able via dip switch). Hmm, maybe I should add that feature as paid DLC!
smiley36.gif


cmonkey2015-07-10 00:44:29
 

Hurray Banana

Moderator
Staff member
vacBacker
Feedback
8 (100%)
Credits
2,721CR
I love the way memory maps always look strange when you first look at them, then it all fits into place when you understand what the designer was thinking about when they organised it.
 

Sprint

Newbie
Credits
55CR
You could see the speccy frame buffer illustrated quite nicely when loading a game. Some games "hid" the screen loading in by setting the colour attributes to black ink on black paper, but other games just left it visible. The loading routines always loaded memory starting from the bottom increasing through RAM, so you can see the image slowly form.

The youtube vid below shows Underworlde loading, with the screen loading from around 50 seconds in. You can see it building the image in thirds of the screen, with the top pixel row of the first 8 lines, then the second pixel row, third etc. It then moves on to the second third of the screen, and then the last third; finally, the attributes load in which colours the previously monochromatic image.


The other thing this video reminds me of is how long things took to load! Not until five minutes into that youtube video can the game actually be played.

That said, I'm sure my laptop sometimes feels like it takes that long just to boot up...
smiley3.gif
perhaps things don't change so much after all!
 

backflipper

Active member
Feedback
4 (100%)
Credits
750CR
cmonkey said:
backflipper said:
Nice stuff guys.
I remember asking my IT teacher back in 88 why we couldn't have arcade quality games on the ibm xt and he was unable to give me an answer.
It's why I got into electronics and programming.

When can we expect to see some arcade homebrew from you then, if you're into programming? 
smiley1.gif

I have so many things on my list of things I woukd love ti do that I even though I woukd love to I can't see that happening just yet.

I love the stuff you guys are doing and I hope I can learn enough from you guys to do it when I do finally want to explore it.
 

joe34

Active member
Credits
448CR
eep off-topic again but....
I remember I always liked playing trap door on the spectrum, 1. because it was great fun working out the puzzles, and 2. I liked the way they did the 'anti-colour clash' gfx:

 

MysteryM

Newbie
Feedback
1 (100%)
Credits
1CR
I've been toying with learning writing some z80 assembler for the spectrum for quite a while now and was planning on picking it up during my holidays.

Back in the 80's I started (like everyone I guess) coding on the spectrum, always wanting to write a game and have it published but due to (a) being young and (b) not having an assembler (or any resources to point out how to write machine code and input it via a hex editor) - learing z80 had died a death. I really wish I had the access to the internet resources available now as I'm sure I'd have done something with the copious amount of spare time I had back then.

It was a love affair that's never really gone away as I program professionally now anyhow, but it remains an itch that I want to scratch and I'd googled it and its great to see modern editors which spit out tap files which can be immediately loaded into a spectrum emulator.

If I get some time to myself I'll make a start having a look - with the first aim to just get some sprites going. Its just curiosity to see how far away I really was since there is no commercial value in it.
 

cmonkey

Active member
vacBacker
Feedback
4 (100%)
Credits
1,658CR
Getting a little off topic here but I'm always happy to help fellow homebrew coders get started.

You should consider joining up at the World of Spectrum forums if you're interested in Spectrum dev as they have an entire sub-forum dedicated to development.

There's tons of books here to help you get started :-

http://wos.meulie.net/pub/sinclair/books/

And you should definitely read Jonathan Cauldwell's excellent "How to write Spectrum games" document after you've briefed yourself on the Z80 language and the basics of Spectrum coding in asm :-

https://www.sendspace.com/file/alhxcq

Good luck on your journey!
smiley20.gif
 

minwah

Active member
Feedback
3 (100%)
Credits
238CR
One game that is excellent on the CPC is 'Live and Let Die'. IMO it is better than both the C64 and Amiga versions.

That would be cool to see on arcade hardware...I imagine it to be visually similar to the arcade game 'Tropical Angel' which I believe runs on Z80.

I don't think it would straightforward to port it though...
 

caius

Active member
Feedback
7 (100%)
Credits
577CR
I would port the C64 version of Commando to some arcade system but don't know which is the most suitable.
I remember someone is doing the opposite, porting arcade game (Pac-Mania if I'm not wrong) to Atari ST.

caius2015-07-13 17:58:16
 

shrunkenmaster

Active member
vacBacker
Feedback
2 (100%)
Credits
162CR
caius said:
I would port the C64 version of Commando to some arcade system but don't know which is the most suitable.
I remember someone is doing the opposite, porting arcade game (Pac-Mania if I'm not wrong) to Atari ST.

The screen orientation may be a problem. Personally I would love arcade Commando with the C64 music - that would be ideal
smiley4.gif
 
Top