Isometric Chess display engine

[arkannoyed]

By the way, perhaps obvious to only me, but its upside-down because the sprites are drawn from the bottom up, so it was just easier to read it like that for me.

As you might be able to see, the White and Black pieces are the same width for each line, and symmetrical about the center line, except for when we get to the Knight.

As you can see, there are several leading (reading from the left) or trailing RED bits. These are balancing bits, which the sprite drawing routine ignores as actual sprite data, but interprets them as just an instruction to move the print position to the next pixel right. This allows the sprites to all be symmetrical without actually having to conform to that restriction in all cases.

The clever bit with this (well I thought so anyway!) is that these are no extra switch bits or whatever needed. The routine switches from mask to print mode. All of this is done in a rather memory hungry way by using the stack.

[Nomad]

Ah I see so the red bits are position data for the drawing routine. That is very slick. Kind of like how the 32 byte demos use the UGL to encode commands.

So if you just use a colour you know you will not need, you can encode the bits with data and not have it display. That is very nice. I had a tile draw routine I was trying to figure out a way to encode attribute data to the tiles without extra data structures this would be a good method I think.

[arkannoyed]

The data is actually inverted due to the way the XOR/ AND/ XOR bit placing works.

So, for instance for the top line (the bottom line of the base, which is common to all the pieces), it is 8 x 0 bits for both the Black and White pieces.
its encoded as;

11111111

There is a separate index that gives the line lengths. Lines are either all data, or a mix of data and a standard infill (different whether Black or White)

The infill for Black is: 1111111110, where the leading '1's can be any length up to 16 bits and will always be on the Right, after the data has finished being placed.

The infill for White is:0100000000, where the trailing '0's can be any length up to 16 bits and will always be on the Left, and placed before the Data.

Sorry if I've lost anyone so far!!

The index of line data is constructed as follows;

Bit 7 indicates whether it is line data(0), or a reference to another line (1)

Bits 6-4 indicate the standard infill length

Bits 3-0 indicate the data length.

The line length is then made by adding the infill+data x 2

To find the print position to start from we take infill+data and move the position left from the center until we find it, which is a bit of a bottleneck in some on of the longer lines.

So, the index for the bottom line of the base is;

0 000 0100 (04h)

Before I move on, any questions?

[Nomad]

Just one, how did you come to use this technique it was something you discovered from another program or it was a technique you cooked up? I like the way that the repeated graphics data gets copied across the chessmen.

I had seen isometric chess before on the spectrum but nothing like this. Haha its voodoo. so what gave you the insperation to try the project in the first place. Was it a way to showcase the technique or did the techniques grow out of the project requirements?

It seems the knight was the real headache If it were checkers no doubt you could have done it in a few hundred bytes.

[arkannoyed]

Inspiration...well I can't actually remember that far back!

I designed the original sprites in about 1992 on a real Speccy. The board was just a huge 4096 bytes screen block and the sprites along with masks were 4000 bytes exactly.

Then there were data tables for the Print position for each square on the board, sprite address+size.

Many years later after rescuing it by using SAM disk on my old +D disks, I one day began looking at trying to make it a little less...huge?!

To begin with I made use of the fact that both Black and White used the same masks, that saved quite a chunk. Then the more I examined the sprite data, the more it became apparent that with very few alterations, there was the possibility to re-use many of the lines in other places within the sprite as a whole.

The standard infill data was then identified, which got the graphics data smaller again. Then I wondered if it was possible to make some sort of intelligent masking system. By actually just printing the pixels needed, there isn't any need to mask at all. as you retain the background anyway.

In the case of the Knight, it actually didn't take much to come up with the idea of 'balancing bits', and initially the stack was a quick and dirty way of doing it. However, the more I optimised everything else, the more I realised that no matter how hard I tried, I couldn't find a better way of doing it.

The DATA for the index and sprites continued to shrink along with the actual code to decode it. To the point that the Graphics now actually only occupy
145 bytes for the lines index, 19 bytes for the piece sizes and index positions, and 232 bytes for Sprite BMPs, giving a total of 396 bytes, which is less than 10% of the original 'circa 1992' size.

The board was examined and I decided that I liked the idea of building it procedurally, and in actual fact, why do we need to print the White squares? So there is a small routine to calculate the line length based upon the current overall line number (always beginning with 00), followed by a simple offset finder and line plotter together 39 bytes.

If the current line is above where the square would need to be drawn (if it were a Black square) then that routine is skipped.

Now, instead of the Print positions address table, we have a routine that calculates it by just being given the current square number (00-3fh, 0-63)
That routine is 27 bytes.

...and breathe!!.

[arkannoyed]

The other very important part is the board builder that sets the positions for the start of a new game.

Its actually a routine the Einar mainly contributed to, and has changed little since.

It consists of a 23 byte routine and 17 bytes of data to set the 64 positions of the board.

The routine currently resides in an empty space created amongst the Sprite data with 1 annoying spare byte at the end!

The data is plonked between the 2 main routines.

I've not given this routine much attention, but I'm fairly sure that with some clever processing I could make it all routine and no data, and probably smaller than 40 bytes.

The actual board map therefore isn't part of the overall size, as its built when needed, and can actually be located elsewhere if needed.

[arkannoyed]

So, once you've digested that, I'll try and clear up anything that I've not explained clearly enough, which is probably most of it, before I move on to some other aspects.

[arkannoyed]

Just one, how did you come to use this technique it was something you discovered from another program or it was a technique you cooked up? I like the way that the repeated graphics data gets copied across the chessmen.

I had seen isometric chess before on the spectrum but nothing like this. Haha its voodoo. so what gave you the insperation to try the project in the first place. Was it a way to showcase the technique or did the techniques grow out of the project requirements?

It seems the knight was the real headache If it were checkers no doubt you could have done it in a few hundred bytes.

The Knight was a headache, and if I did without the whole masking thing, it would be faster and save 18 bytes too. But, I wanted from the outset to ensure that the sprites remained as true to the original design as was possible.

[Nomad]

It's so fast that is some nice work. I can't pretend to understand what voodoo your working to get it to be that way lol. It will be fun figuring out exactly what its doing. Are you planning on adding the coordinates as isometric fonts?

[arkannoyed]

One day, when I get as far as some control method and indication of state etc, I'll try to make it text free, and perhaps just graphically based. I did do some work towards that last year before moving on to other Speccy projects.

[arkannoyed]

Theres definately on Voodoo involved. I'd really like to find a way to explain it clearly enough so that it de-mystifies it. Its not really so complex once you get to understand whats going on. I started to write a sprite designer in Basic on the Speccy that can encode the sprites as they need to be for the display routine. I could also write some sort of demonstration with annotations that could show step by step whats going on I suppose.

[Nomad]

Lol its just me being a potato, I am sure once I sit down and work through it following the comments it will become clear. Don't let me put you out with extra work