3D Chess 2K18

[arkannoyed]

This is stunning arkannoyed. If I could have two wishes, they would be:
1. Tie Peter Jennings 1k MicroChess to this beautiful interface.
2. tie the infamous 1k ZX chess to this beautiful interface.

I wish I wish.

KB

Peter Jennings talks about a program being a piece of art. I totally get that, that’s what I’m creating, it becomes more beautiful the smaller it gets. It’s approaching a very pure state now.

[Pegaz]

Fascinating read about Peter Jennings development of Microchess. The hand coding process is still alive in my case! I may well take a few pointers from the way it evaluates moves too.

I completely agree.
Today I've been testing a great KIM-1 emulator on c64 and Jennings Microchess on it.
It's not easy to make moves with his notation, it has its own shortcomings, but it's still an impressive piece of code.
Lots of information about this old MOS Technology computer, Microchess and other KIM-1 software, here:
https://www.floodgap.com/retrobits/kim-1/

[KayBee]

I love the purity of Microchess, but to me it's interface (notation) obfuscates the play. When I play it I have to mentally translate. It is much better with a VT-100 terminal.

As for moving the pieces up, I agree, at least 1 line. Really amazing.

KB

[KayBee]

I mentioned ZX chess because I love the way it cycles through the possible moves, and with actual pieces it would be a fascinating visualization of the engine at work.

KB

[Pegaz]

I love the purity of Microchess, but to me it's interface (notation) obfuscates the play. When I play it I have to mentally translate. It is much better with a VT-100 terminal.

As for moving the pieces up, I agree, at least 1 line. Really amazing.

KB

Yes, its very difficult to play that way, its literally necessary to have a code table and translate every move to its notation.
However, for a computer from 1976, this is a remarkable achievement.
I played Lander for KIM-1 yesterday, only 6 characters on display, but still pure fun.

[arkannoyed]

Though I had to add 1 byte, which I can tell you caused untold personal turmoil, I then saved one elsewhere, so still at 547 bytes, and now prints everything 1 line higher to show more of the square beneath thus;



Not a massive difference, but it'll make itself apparent more when the GUI is up and running. I'm looking at a few other areas of the code too so that additional functionality can be added in with less of an effort later.

[dfzx]

Not a massive difference...

Is that not identical to the image you posted on 15th Feb?

[dfzx]

Not a massive difference...

Is that not identical to the image you posted on 15th Feb?

Ah, you've reused the URL so the older image is in fact the new one as well.

Just looking at the line of black pawn bases, it looks like they alternate up and down a pixel. It looks slightly odd to my eye.

[arkannoyed]

Is that not identical to the image you posted on 15th Feb?

Ah, you've reused the URL so the older image is in fact the new one as well.

Just looking at the line of black pawn bases, it looks like they alternate up and down a pixel. It looks slightly odd to my eye.

Indeed, my mistake, I did reuse the url and replaced just the file. Silly me!!

The anomaly regarding the bases looking like that is just being on a black or white square. Also they’re masked so perhaps that gives an odd look too. I can assure you they’re the same level relative to the square.

Took over an hour to figure a way to move them up 1 line and not use an extra byte!!

[arkannoyed]

The code as it is now feels finally pretty much as optimised as it can be aside from any new ideas I manage to come up with to reduce it further. So at last I’ve begun looking at adding the functionality to select and move the pieces. At first this will be purely human input, but will allow for properly ironing out any potential difficulties with making an eventual computer evaluating system making moves for itself. Plenty to cram into 477 bytes!

I think it just about runs fast enough to allow for square and piece selection to be on-board rather than a keyboard input. Chances are the building will happen off screen and then it’ll be copied from a buffer. Otherwise animating certain things will look clumsy. Speed isn’t an essential ingredient and I think I can add in some easy to use functions without them being memory hungry. Need to leave a few hundred bytes to have some chess logic in there for a suitable playing experience I guess!

[arkannoyed]

Experimental Piece test no.1



A little slower than I'd hoped, but this is using very small copy and clear routines which could be unrolled a bit to speed up.

[arkannoyed]

Obviously you'll only get to choose from either Black or White pieces as available selection to move on a given turn, which will only give a maximum number of 16 pieces to cycle through. I have that working now and with a simple switch to select which colour. I also think to keep it as simple as possible, I'll just use maybe Space to scroll through and Enter to select the piece. Then it will keep the selected piece held up while the user selects the square to move to, again Space to move and Enter to select. Then a simple write 00 to the piece square and copy the piece to its newly selected position. Later there will be validation involved which will only allow you to select the squares that are possible to move to.

It does get a lot faster when there are fewer pieces on the board fortunately!

[arkannoyed]

I did have board rotation working quite a while ago, which will also hopefully be incorporated. I think that was about 30 bytes-ish. That will help with square selection when there are more pieces crowding certain areas. There will also be an undo function as thats fairly easy to add too with a simple move stack system.

[KayBee]

In an actual game, I would like to quickly choose the piece to move, may I suggest inverting the color of each piece as you go through your options? Once the piece is chosen, it rises, then I choose the destination square?

[arkannoyed]

I find that to be confusing, or is that just me? Inverting the colour surely makes it match the opposition? That’s actually not any quicker than raising the piece anyway. Still have to reconstruct the board for every change.

Once this gets a little further along I’ll release a demo to try then a decision can be made as to whether it’s ok to run with.

[arkannoyed]

In my ongoing quest to develop this into something meaningful, I've relented finally, and designed a new alternative and smaller set of pieces.

Whereas previously they maxed out at 22 bits wide, these conveniently nestle within 2 bytes at 16 bits max width. This gives rise to the opportunity to make building and printing them much faster than is currently possible. The size of the data is hardly any smaller actually, but every little gained is a bonus. I've developed a new super quick print routine that prints each line of the piece in just over 300 t-states for all lines, as opposed to the old one that took at least 305 even for the shortest line possible and over 2300 for the longest lines. That should make animating the GUI parts of the selecting process much more visually pleasing. Also the width of the old pieces caused too much overlapping particularly of the bases. This meant that even with some intelligent updating of the board of just selected pieces, it wasn't possible. Now just vertical lines (diagonals) on the board can be re-drawn, saving a lot of time.

It's not easy re-writing most of the graphics engine, but its the only way to get where it needs to be. Projections so far point to the display engine alone probably weighing in at well under 475 bytes hopefully and possible to display the entire populated board in under 0.5 seconds.

They don't quite look as nice as before, but its how it has to be

[arkannoyed]

So, here is an early un-optimised test version, minus the piece shading, as thats being worked on still. This does however show the speed increase (around 60%) and the sizing of the alternative set. They will look a lot better with the shading artifacts, but I'm having to rewrite that subroutine from scratch and it was a right bugger the first time!



In fact, the main bottleneck now is actually the routine that calculates and prints the board squares. That for simplicity and size does it bit-wise which for the longer lines around the middle can slow it down. When you build it with an empty board, it still takes 0.3 seconds for display, whereas fully populated its only around 0.45 seconds.

I could change it to work byte-wise instead, which will add around 8 bytes, but the speed increase would be lovely.

Currently the graphics data has actually only shrunk by 4 bytes, though a few optimisations might reduce that by a few more. Also, I've free'd up HL for perhaps now addressing for gfx data instead of IX, which if used properly, could not only gain more speed, but lose a few bytes also.

Currently the routine and graphics weigh in at 482 bytes, but the shader is only partially working, so even with a few savings elsewhere, it will creep up towards 500 again no doubt.

The advantage as I mentioned before is that now there are no overlaps between the pieces to the left and right of a diagonal (vertical on screen), which allows updating to just focus on 1 line at a time, not re-constructing the whole board. That said, if 0.45 seconds per frame is possible anyway, then maybe its unimportant now.

The more I look at them on the board, I can't help thinking that the Knight looks to have lost some of its majesty. It looks a bit sad now. Maybe I need to re-design him?

[arkannoyed]

It’s always surprising to me that when you take a different approach to something, you often find something that was perhaps staring you in the face before, but never noticed. Whilst playing around with the mini version, which I still dislike, due to the sprites looking crap, I discovered a way of using fewer bytes to create jumps within the sprite data, allowing parts to be used more than once. Recycling? Anyway, it’s so far saved -3 bytes and might allow for a few other changes to be made which could save yet more.

My dislike for the new smaller pieces is such that I’ve spent some time designing a new set that’s closer to the originals, but with a much classier look. A new algorithm to procedurally produce the columns might be possible too.

Anyone fed up of hearing about this yet?

[DouglasReynholm]

Anyone fed up of hearing about this yet?

Not me, it's been fascinating so far. Quite looking forward to you marrying it to a chess engine, but the current pursuit is a noble one!

[Ast A. Moore]

Anyone fed up of hearing about this yet?

No, but I like the original graphics better. Sorry, man.

[arkannoyed]

Anyone fed up of hearing about this yet?

No, but I like the original graphics better. Sorry, man.

Me too! I just can't seem to get the same feel with the smaller ones. I am in the process of designing a new set, which takes advantage of some new graphics ideas and is almost the same scale as the original. The new format should allow better compression though hopefully.

[Ast A. Moore]

I am in the process of designing a new set, which takes advantage of some new graphics ideas and is almost the same scale as the original.

Here’s hoping!

[Bizzley]

The new format should allow better compression though hopefully.

Why? You've already achieved <512 bytes in previous versions. If this is going to end up as a 1K\2K\4K version of chess, fully working, then I can see (and applaud) the point of what you're doing since every last byte will be important. If however you're going to marry this to a full-blown chess engine with a fancy GUI running in 48K then saving those bytes is hardly going to matter is it?

Are you going to write your own AI chess routines or use an existing engine?
How big are you aiming the completed fully-working chess program to be?
When will you consider the display routine finished and start coding the rest of the game?

[arkannoyed]

Just when I think I can't possibly save any more bytes from the current version, or make it any faster, along comes that lightening bolt again!

I've half implemented a rather exciting speed improvement, which began only as a test to write the Right side of the buffer to the screen bytewise, as I'd managed to do in the new small piece test version. I knew the speed improvement would happen, which it did, and by over 0.25 seconds, which is nice. But the bonus came with the realisation that I'd saved 2 bytes in the process!

So currently the basic routine including the graphics data and minus the board initialising routine is 503 bytes

To answer the question of my intentions for its eventual size, it will need to be sub 1k. No exception! The engine is already something I'm playing with ideas for, and its actually not too tricky to get basic move legality checking working partially. What I still want is an integrated GUI where the pieces move/ change or whatever to indicate that they are active. Thats still something I'm not entirely sure about despite the tests looking ok. The speed increase will certainly help a lot. Obviously now being so close to 500 bytes, I have to get down below that, rude not to really!

I may make a few further graphical changes to give that a helping hand, and if I can get the Left side of the piece printing byte-wise as I've managed on the right, then who knows, maybe a few more bytes will disappear, and the speed increase again.

It is difficult to know when to stop optimising it when I keep finding more ways to do it. The smaller it is, the more space there is left for the actual game in the end.

[arkannoyed]

I have already had it running on a 16k machine, and over a year ago I created a version which ran within the screen, hidden behind some carefully placed attributes

That might now be an even easier prospect as its a lot smaller and much more flexible that it was back then.

Imagine loading a SCREEN$ and it then runs a Chess game, maybe interesting!