Spectrum Computing

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.

This test really does fit nicely into the code, adding the fewest number of bytes so far.

The alternating line effect is possible by repeatedly calling the routine, or to save even more space just a static version can be achieved, much faster and using fewer bytes.



Static version;

It still seems to me, that the arrow method is the most appropriate here.
We can discuss, how the arrow will look and how big will be, but I would keep that method.
btw, would it also be possible to make moves, by typing anotation eg. c2-c4 on keyboard?
Even the simplest chess programs can be used in this way...

Pegaz wrote: ↑Fri Mar 15, 2019 9:50 am It still seems to me, that the arrow method is the most appropriate here.
We can discuss, how the arrow will look and how big will be, but I would keep that method.
btw, would it also be possible to make moves, by typing anotation eg. c2-c4 on keyboard?
Even the simplest chess programs can be used in this way...

That method might be a consideration, but a modern implementation should surely take the graphical approach if possible?

I've not so far investigated this route, however, aside from using the ROM routine to read the keyboard, surely it would and up a little heavy on extra code?

Remember that the aim is to achieve something fitting into 1024 bytes.

arkannoyed wrote: ↑Fri Mar 15, 2019 9:35 am

Static version;

I like the effect, but it renders the piece unreadable if there is anything behind it. Out of the options tested, I reckon the arrow is still the best possibility...however, i think an effect on the selected piece would be the best option likecwhat you’re trying with the alternate lines. Course, what that is, I’m not quite sure yet!

The effect is one of those quick and easy things to implement, that if it works is a great bonus. If push came to shove and it had to stay because of the size restrictions, then it wouldn't be so bad.

The Arrow is ok, but might add over +40 bytes in the end, as there are quite a few alterations needed to make it work properly. I'm still keen on altering the piece somehow though.

If speedier building was possible, then it opens up further possibilities to make all kinds of things work.

arkannoyed wrote: ↑Thu Mar 14, 2019 4:25 pm Mmmmmm....Hovering is a bit too slow to be practical;

This is my favorite. Except the selected piece should be moving higher above the board to make it more visible.

I agree Einar, this is the effect I find the easiest to spot whats going on, and actually the one I first came up with some time ago. Achieving it isn't difficult either. The piece can go up to 12 lines higher than standard, whereas in this demo, its only 4 lines.

Although I had said earlier that I've deliberately not looked at other Chess games to not be influenced in any direction, thats no longer true, as I have been playing a few to get a feel of how it needs to run to be comfortable.

Raised pieces is common and perfectly ok. Also, colouring or shading the square or available squares to move to is mostly how its done, which is what I have working currently.

Something I'm working on at the moment is what to use the spare upper 4 bits available in each of the squares in the board data.

So far;
Currently selected piece
Pawn has its first move available still
King in Check

Can't think of anything else at the mo, but I'm sure there are further possibilities.

I've just realised that I must be an idiot!

I just spotted the most ridiculous sequence of instructions and saved a byte without any effort at all. Got the main thing down to 493 bytes now.

Work and experiments are still progressing on the game version.

I now have some rudimentary move options displayed. i.e. which squares the selected piece can move to. Surprisingly easy actually. All to do with offsets!

I thought this bit might be tricky!

I've (almost) got the piece movement logic working and its 91 bytes, which actually doesn't feel too heavy.

Only 46 bytes of movement vector data tables, which are quite repetitive, so may well get smaller yet.

The piece selected then has all of its available squares that it can move to shaded, which can be scrolled through to select which move to perform, or select the piece and cancel that move.

The maths involved in checking which moves are legal is mostly quite easy, but from a few HUGE irritations.

So far En Passant and promotion aren't integrated, but should be quite simple to add. The initial state of the Pawns with their extra move availability works, but will interfere in other areas, so I need to alter that still.

Castling, maybe. Not sure on that one yet.

It is starting to take shape finally.

Yesterday I came across this great chess program ChesSkelet, some tribute to the famous zx81 1K chess, but even smaller in just 377 bytes!
The program doesnt support some of chess rules (castling, stalemates, repetitions draw) but is generally quite functional.
I think it can be useful as a reference for creating a "3D Chess 2K18" chess engine.
Alex Garcia has developed a program on the ZX-Spin emulator, assembly code is available as well as online emulation.
I also think that the program should be added to the ZXDB database, as another very valuable new title.

http://chesskelet.x10host.com/