Spectrum Computing

Good to hear. The idea wasn't actually to make the whole thing smaller, but to give a better feeling of separation between the bases to give a less cluttered look. When the square selection process happens, hopefully that will give a clearer view of whats going on.

Shall I stick with these as they are then? How about the tops of the Bishop? The much earlier version looked much nicer. I just don't want to add a load to the size thats all. There is a graphics encoding alteration possibly happening, which might allow a small size reduction though.

The bishop looks fine to me. The top of the rook is a little weird. Some of the battlement ridges look too spiky. And the white knight’s mouth still looks a little cartoony. The black knight looks okay.

The difficulty is that the White and Black are in many cases variations, or mirrored inversions of one another. I am of course perfectly happy to consider encoding any suggestions to see how they look. The Knights are the biggest pain of all the pieces as they're not symmetrical. They are the reason that printing is a longer process than it perhaps needs to be. But if you try to design one thats symmetrical, they look very odd. Thats part of the fun/ frustration of the process, trying to code around these restrictions.

The head of the Knight almost needs to be wider, bigger to be a more impressive grand piece.

Does this work as a compromise? Gets us down to 494 bytes if so.

I think it looks better now than ever, I really like it and I think you found the right balance.

Great, I agree. I'm feeling happier with them now. Just trying to address a few other issues, like the Cartoon-ish mouth of the Knight amongst other things. Might be able to save a little more. The Sprite data is incredibly now just 200 bytes

Upon conception, the very first version of the sprite data had masks, whereas they're auto calculated here, but they were exactly 4000 bytes. So currently they're only 5% of the original size.

I think the problem with the knight is it looks like she's tilting her head way over.
I tried a paintover, where I moved the eye, add a bit more brow, added a nostril instead of a mouth, and added an ear.
It might be a little too cartoony though...

The set looks great and it's amazingly efficient, but... some of the pieces are obscured - basically the white pawns behind the white king and king's bishop, which might make it difficult to play. Options, in descending order of difficulty

1) A different angle of rotation of the board instead of 45 degrees
2) Thinner pieces, maybe offset the pawns a little to the right
3) An in game option to switch view by 180 degrees
4) Ignore me

Rotation is included

Should the white knights (Edit: and the black bishops) be flipped to be 'facing' their opponents? I.e. 'into' the board?

Yes, as discussed before, this is an issue with the board initialising routine. That will be eventually resolved.

I am in the process of redesigning the knight head, it is a tricky one, as several factors have to be considered to be able to achieve a small data set. The current iteration top part is about 72 bytes. The redesign is 98, and though it looks nice, that’s too big, so I’m fettling it.

There are situations where pieces are obscured, and for that reason, the game version will have a rotate feature. It’s actually not that hard to implement. There are two ways to achieve it.

1. Using a small 20 byte routine to rotate the board data and change one byte in the display engine to print the alternate squares of the board.

2. Read the board data in a different order which involves uncoupling the routine from its current read loop. This method is actually more efficient.

Some indication needs to be added to point to which is the current view orientation. Compass or similar I suppose.
I’ve deliberately not tried to gain any insight from other chess games so that I’m not influenced in a particular direction.

In progress musings. For the knights, see on the right.

DouglasReynholm wrote: ↑Sat Mar 09, 2019 2:17 am Should the white knights (Edit: and the black bishops) be flipped to be 'facing' their opponents? I.e. 'into' the board?

To have facing pieces would be nice. Possible with the bishops, but not with the knights. The graphics format and the current piece design won’t allow it. If the piece was reduced in width to 16 bits then it could happen.

Having said that, my early morning brain has just thought of an obscure work around that could be implemented so that it could be done. It would be a small routine placed carefully to check the current piece and do a simple buffer swap if needed.

DouglasReynholm wrote: ↑Sat Mar 09, 2019 2:17 am Should the white knights (Edit: and the black bishops) be flipped to be 'facing' their opponents? I.e. 'into' the board?

I have a very quick and dirty fix in 10 bytes to take care of reversing the head of the White Knight so he faces towards the opposition. The problem is, that if its the case that they always need to face inwards, then we'd need 2 versions of the sprite data and logic to pick the appropriate one.

Would it be good enough to have the Knights and Bishops heads just facing the other way to its opposing piece?

If so, then it can be implemented maybe in a branched version, or the eventual game version at the expense of only a few bytes.

arkannoyed wrote: ↑Mon Mar 11, 2019 9:49 am

DouglasReynholm wrote: ↑Sat Mar 09, 2019 2:17 am Should the white knights (Edit: and the black bishops) be flipped to be 'facing' their opponents? I.e. 'into' the board?

I have a very quick and dirty fix in 10 bytes to take care of reversing the head of the White Knight so he faces towards the opposition. The problem is, that if its the case that they always need to face inwards, then we'd need 2 versions of the sprite data and logic to pick the appropriate one.

Would it be good enough to have the Knights and Bishops heads just facing the other way to its opposing piece?

If so, then it can be implemented maybe in a branched version, or the eventual game version at the expense of only a few bytes.

Oh dear I feel like I've lit the touchpaper and run off.. I mean it is only an aesthetic decision really isn't it, secondary to the quality of game it plays.. I should think out loud less. If the size of the code is still a priority then maybe leave as-is, but as ever seeing you think about solutions is also entertaining.

I like input. If there are ideas that need to be tried, then I'm always happy to have a go. In the case of the reversed facing, it was something I thought about a long time ago, but dismissed it as it looked at the time to be too difficult to implement. However, now the code is far friendlier it seems to be quite easy to put in at only the expense of a few bytes. If it improved the aesthetics of the game then I'm sure it could eventually make an appearance. In fact, if I get several other things working too and smaller then I might leave it in just to make it look more natural, less like its procedural if that makes sense.

Just trying to get the squares to draw byte-wise. The existing routine is 23 bytes with 16 to calculate the line length at a given height position up the square. Currently it basically has to draw 1.5 lines as it starts at the centre and works its way left to find the end, then doubles the counter to fill all the pixels going right.

Not very fast, but then again, not bad. But to do it byte-wise is more complex and so far I've only got down to 29 bytes. It does make building the populated board happen 0.1 seconds faster though.

Development of several User Interface options are well underway. Options include;

1. Piece selection is shown by the piece being raised as its selected. Now the whole thing runs much faster, its not too bad actually.
1a.Then, once Enter is pressed, the square to move to is selected by pressing Space. Basic legality of selection is currently nearly working as far as allowing movement to an empty square, or that of an opposing piece. The square currently selected is greyed out (AA/55 mask)

2. Piece selection is indicated by an arrow above the 'head' of the piece, movable with space and selectable with Enter.
2a. Then, again, the target square is greyed out until selected.

3. The piece selected is masked to give a shaded look. This doesn't always look very pleasing to the eye as it sometimes interferes with the automasking functionality.
3a. Same square selection as above.

Basic algorithmic checking of moves available is under development. This would involve the selected piece being given all the move options available to it by them being shown as greyed squares that can be scrolled through (flashing on/off when selected).

This approach might be better to run with, as then legal move checking is just done per piece once its selected and shouldn't take too long in processor terms.

Once the many bugs and irritations are ironed out a bit, I'll post some sort of Demos of the various systems possible.

Any further suggestions kindly welcomed.

Oh, and as per an earlier suggestion, the Knight and Bishop opposing pieces will face inwards, towards one another. Unfortunately, they won't face each other if they move to the opposite side they started from, as that would need extra sprite data, which there won't be room for I don't think.

This is using the arrow above head method. Not optimised, so a bit slower than possible, but gives an idea. The arrow could go bigger.

The problem using that arrow at its current size is the difficulty in seeing it when it’s above the front row as it gets lost against the back row. I’d try a bigger sized arrow and maybe even a thicker outline.

Yeah, it's a bit small. I'd try to forgo masking all together and simply have a slightly bigger rectangle with the arrow inside.

Yeah, the arrow was just a proof of concept actually. It can go bigger, and even inside a box. I'm actually not that keen on this method, and prefer the raised pieces, which is a much clearer indication of the piece selected.

With an extra bit of code twiddling, the piece could give the appearance of hovering, gradually moving up/ down whilst the square target selection is in progress. Just needs a simple sine type table to cycle through to change the height offset.

That way, it'll always appear active. Visually, movement always helps identify whats going on.

Both methods actually take about the same amount of extra code to achieve.

Mmmmmm....Hovering is a bit too slow to be practical;

How about a 50% dither to mask everything except the piece you're selecting?

Thats a lot of dithering!

That would interfere with the automasking probably too much, causing all sorts of out of place pixels and weird artifacts to appear.

I did try some basic piece masking to dither the selected piece, but that looks a bit odd too.

I'll try and re-create that and show you.

In fact, there are so many ways that it could be done, but as always, the final decision will probably have to be based upon which is easiest and smallest to integrate into the system.

A few more ideas;

skip printing alternate lines of the piece, or swap upon each update of the frame to give a fuzzy sort of effect.
Alternately skip printing the piece altogether every other frame to make it flash.