ZX Collection Vol #1

[Qube]

No title, no idea what game I'm going to do yet but thought I'd document my progress. Well I do have some game ideas but that's for later down the line

I'll be using AGK for this comp entry and tonight I wanted to find out how AGK handles drawing lots of 2D sprites with mathematical positioning. Bit of a bizarre test you may be thinking but my initial goal is to do a ZX Spectrum game and build in colour clash and the odd screen flicker, so it'll require a lot of under the hood stuff. I don't know shaders so if I can figure out how to do it via coding alone it's going to be pretty busy behind the scenes, hence this weird test. I might have to ditch the colour clash idea but for now it's on the cards. It all depends on how performant it is but priority goes to the game itself first.

For a quick test I whipped up an over the top old school sinus scroller with a bit of funky extras. Turning off vsync it runs at 700+fps so I'm happy at this stage in that AGK can handle loads of 2D with math at the same time.

Exciting video below which uses an Amiga bitmap font ( so not even speccy related  - Oh, ignore the mouse, that's just there because it helps me be retro ) :

[Xerra]

Reminds me of the C64 warez days and all those game intro's before decompressing :-)

[STEVIE G]

Is it not just a case of drawing everything in full white and having an colour overlay of 8x8pixel squares which are multiply blended?  The overlay can be dynamic to handle all your sprites.  Might only work for a black background right enough.

[Qube]

Is it not just a case of drawing everything in full white and having an colour overlay of 8x8pixel squares which are multiply blended?  The overlay can be dynamic to handle all your sprites.  Might only work for a black background right enough.

It’s easier to do if as you say the background is black but if not then it becomes a little more tricky. Probably just spend the weekend on this as the game is more important in the end

[Qube]

Today I fixed up my basic tile map editor to be all speccy. I can now select tiles and choose what colour I want them to be out of the glorious zx palette.

I then moved on to creating a sprite routine to deal with colour clash. 4 hours later it was up and running \o/ - I then looked at the result and went "Huh, what a twat!, that's doing colour clash in the extreme reverse".

So I present to you the completely wrong and highly dumb of me colour clash routine - Waste of a few hours but made me giggle in the end - Will do it the proper way tomorrow *slap*

[iWasAdam]

Can't see what's wrong there 

Painting the pixels (with a color attribute) and the color overrides the color underneath it - it goes yellow - yep looks exactly right

[blinkok]

Is transparency counted as a colour?

[STEVIE G]

Can't see what's wrong there 

Painting the pixels (with a color attribute) and the color overrides the color underneath it - it goes yellow - yep looks exactly right

My thoughts too.  What exactly is wrong?

[Qube]

( Jedi voice ) “This is not the effect you’re looking for”

I thought it was right too for a while. Then realised what should be happening is as the smiley face enters the couloured bars it begins to become the same colour, line by line, pixel by pixel.

If you watch some YouTube videos you’ll see what I’ve done is the reverse extreme version

[Qube]

Is transparency counted as a colour?

Yes, black ( transparency ) is a colour in computer land.

[iWasAdam]

so you were wanting to update the bit field without affecting the color attribute field ?

[Qube]

so you were wanting to update the bit field without affecting the color attribute field ?

When a sprite enters an 8x8 block which has a different colour it takes on that colour pixel by pixel as it goes in.

[Qube]

Although there are some Spectrum games that do colour clash as per the video above. I wanted to do the other method which turns out was harder to do but luckily managed to get it sorted. Faking this stuff is madness on modern tech

Colour clash test 2 - The correct way, go speccy go

[Xerra]

Looking at this it's actually technically possible that the Vic could have had the same problem if it hadn't resorted to using poke commands for manipulating graphics. Out of the box it had no draw commands so you just poked a value into a screen memory location (22 * 23) and the 8 * 8 pixel character appeared there. To actually colour it you had to poke a value into another memory location which set the colour for that block on screen. To simulate movement of the character you would then poke it with 32 to put a blank space where it was and then poke it in the new location, so current location - 22, for example, to make it look like it had moved one space to the north.

One space would be 8 pixels due to the size of the char graphics. So, if you wanted to animate the movement by pixel (which was possible but very tricky) you had to use a bit operation of that byte to move the pixels left or right within each of the 8 lines of that char graphic. If you wanted to animate it going up and down then you'd had to look at the next or prev line of that char graphic and poke that number into the previous location. Then, every 8th time you did this you would just reset it back to the original image and move the block.

Very, very few games did this on the Vic because it would involve a fair bit of code which the memory just wasn't there for. But, assuming the Spectrum drew its graphics using internal routines so they could move a pixel at a time, then I'm guessing it's colour map worked the same way as the Vic and could only have one colour every 8 pixel square area.

It was probably a memory limitation that made them take a short cut with the Spectrums graphics operation if it was like this. The irony is that the Vic programmers just made everything work with poke and peek direct to memory because they didn't have time to create proper graphic commands. If they had then the computer probably would have got as much flack as the Spectrum for colour clashing because they'd tried to make it work better.

[col]

@Qube
Interesting competition

Both of your colour clash routines are correct, the clash was usually based on 'colour priority' of the sprite (in the attribute table) which would be programmer coded.

One space would be 8 pixels due to the size of the char graphics. So, if you wanted to animate the movement by pixel (which was possible but very tricky) you had to use a bit operation of that byte to move the pixels left or right within each of the 8 lines of that char graphic.

This was the same for the Speccy.

If you wanted to animate it going up and down then you'd had to look at the next or prev line of that char graphic and poke that number into the previous location. Then, every 8th time you did this you would just reset it back to the original image and move the block.

If only that were the case for the Speccy too, but it soooo wasn't that easy


The screen pixel and colour (attribute) data was made up of 6912 bytes of data starting at address 16384.
The pixel data was 6144 bytes folowed by 768 bytes of attribute data for a 256x192 pixel display.

Each attribute square was made of 8x8 pixels with just 2 of the 16 colours allowed in each attribute square - 1 byte per square - 32 squares by 24 squares - 768 bytes.
It would have been nice to have the pixel data for those squares layed out in sequentially in memory but it wasn't. It was made of 3 sections of horizontal blocks, with each block being pixel data for 32 square by 8 squares. So you had 8 blocks by 3 sections to give 24 blocks (192 pixels) high.

To make matters even worse the sequential memory access of the pixel data area would work as follows:

the first 32 bytes would be for line 1 of the 1st row of 8x8 pixels,
the next 32 bytes would be for line 1 of the 2nd row,
the next 32 for line 1 of row 3,
the next 32 for line 1 of row 4,
the next 32 for line 1 of row 5,
the next 32 for line 1 of row 6,
the next 32 for line 1 of row 7,
the next 32 for line 1 of row 8 of the first 3 horizontal section.

the next 32 for line 2 of the 1st row,
the next 32 for line 2 of the 2nd row,
the next 32 for line 2 of row 3,
the next 32 for line 2 of row 4,
the next 32 for line 2 of row 5,
the next 32 for line 2 of row 6,
the next 32 for line 2 of row 7,
the next 32 for line 2 of row 8 of the first 3 horizontal section.

At the end of the 32nd byte of row 8, the next byte would be line 1 of row 1 of section 2 and the previous pattern continued, until the end of section 2 then the same pattern occurred for section 3. Immediately after the pixel data memory follows the 768 bytes attribute table.

Ahh the good ole days

I'm sure that description was as confusing as hell itself so here's a loading screen on Youtube showing the data being loaded sequentially straight into the screen memory location.