Spectrum Computing

So, after a year or so of pretty much ignoring this, I've decided to have another go at it. Roughly 2 weeks of fiddling around with a few ideas has resulted in very slightly re-designed graphics that allow better compression. An all new core routine and a totally new data structure allowing for a lot more innovation and customisation to come hopefully.

Anyway, version 1 bottomed out at 722 bytes, which I was actually fairly happy with, but just had a constant feeling that I could do considerably better.

So, version 2 pops its head up weighing in at a miserly 667 bytes!

Not only is it 55 bytes smaller so far, but its over twice as fast!

Feast you eyes on this;

That looks fantastic! What is the goal, to have an actual game?

Aren't black queen and king switched in places?

Perhaps they should be. Fortunately an easy fix!

I promise it will one day become a fully playable game, somehow!

Looks nice. Keep up the good work!

This fantastic 3D chess set deserves to get its own engine and become a full chess game.
Amazing programming skills, you really did a great job arkannoyed, well done!
Due to the low memory consumption, I recommend keeping this style and that the full version remains compatible with Spectrum 16k.

It is pretty much just a display engine, that in theory with very little alteration, could display the board from any chess playing game.

As has been discussed in detail before, partly on WOS, the control and piece selection is always going to be something that makes or breaks any system. I did get some way into a system in version 1, but because it was such a slow beast, it never really worked. This however is a lot faster, and just might allow for some more slick and responsive control. Being isometric, I'm favoring some system where the board alters to indicate what piece/ square is selected.

But, before any of that, I've much work to do to decrease the size of this, add extra compression and speed and tidy it up generally.

As for 16k compatibility, that was always my intention. This version runs almost anywhere and though not fully relocatable, can be compiled to run from a lot of locations. Also, it doesn't use any additional memory for storing anything other than creating a 64 byte chess board table, which again can be put in may different locations, even in the lower part of the screen if the ATTRs were to hide it for instance.

Oh my! Its now 666 bytes, that can't be good!

Edit: Phew 665 now!

Are you able to display an image with the pieces in different places, as if it was half way through a game?

Yes, any placement suggestions?

Not really, I'm not a chess player, was just interested to see some other configuration

Something like this;

Unfair odds?

Superb! Hurry up and make the game engine now

Patience my friend! I've a lot of minimalising (if thats a thing!?) to do on the display engine yet.

This looks great indeed. But another thought also occurred to me: We don't have Battle Chess on the Speccy.

No, we dont need chess like arcade game.
We need a classic 3d chess, optimized to the maximum (16k compatible), with a good and fast engine.
Spectrum already has one such chess set - the Fig Chess from Magnetic Magazine, without the engine, but also without such a great memory optimization like arkannoyed version.
The second alternative is a Psi chess, with an excellent Staunton set, but a very bad engine and a very weak game play.

I agree, though Battle Chess would be fun!

More optimisation has been done, now achieving a graphics data size of 293 bytes. I've discovered that using a few tricks, actually I don't need to read the data BIT-wise, which is always going to be slow. Instead, we can read whole bytes, and just place them on screen bit by bit. Obviously as you can imagine, this does indeed make it even quicker. Not fully operational yet, but initial tests look even quicker, and the size should be around.....638 bytes!

Actually looks like about 20% faster.

You are a magician, there's no other explanation.

Perhaps I'll feel more magical when it works. Having real trouble figuring out whats wrong with it at the moment. Individual routines seems fine, but as a whole, its not doing what it should. It'll be something trivial I'm sure. Sometimes a little time away from it helps make it appear clearer when you go back to it.

arkannoyed wrote: ↑Thu Jun 21, 2018 4:37 pm Something like this;

Oh nice, Reti - Alekhine, Baden Baden, 1925, after ...Rxe3!

Indeed it is, very well spotted sir! It shows that the graphics are clear enough to see whats going on when the board is well populated.

I don't know whether its the heat this week, but other that squeezing the data down to 289 bytes, everything else I try and improve or fix just fails miserably. I can usually visualise the mechanics of a system pretty well, and with some fiddling, get a routine that does what it needs to. However, I'm trying to improve things on 3 fronts all at once, which is perhaps a mistake.

1. The standard line Model builder is 38 bytes but I've a version that so nearly works at about 28 bytes.
2. The Get Data routine builds each line bytewise from the graphics data as opposed to BIT-wise previously, however, the addressing just isn't doing what it should in all instances....Frustrating!!!
3. I've very nearly figured out an auto-masking system that will get rid of the need to place each bit from a line separately on screen. Obviously that would give a quite spiffing speed improvement, and early indications are that it would be smaller too.

If everything comes together as intended, it would almost qualify as a version 3 as its so dramatically different. Size could be anywhere from 620-650 bytes.

The graphics look really good, but I'm no chess nut, and I struggle to make out what's going on in that crowd shot.
What I'd suggest for clarity is a simple 8x8 aerial view in the top-left corner of the screen. This would also solve the user-interface problem as moves could be entered on the smaller character-based grid. I don't think it would detract from the aesthetic, and anyone playing the game seriously would probably prefer to see an overview as well.

Also, I think the Kings and Queens are swapped in the above image. The king for either colour is the piece with a + at the top. The pieces on c4 and c7 look like the kings, but they are supposed to be the queens (which are sitting on g1 and g8, where the kings should be).

You are correct Mike, I'll alter that in the next update hopefully!

In the meantime, progress!!

It is mostly working. Just a small hitch to sort out with addressing, which just involves swapping a few things in the data. The data for the graphics is having to be re-compiled by hand to take account of a change made to allow even better compression, and making it simpler for the interpreter to read. This isn't a particularly quick process, but the Graphics data has now dropped to 279 bytes. Considering Version 1s graphics data was 382 bytes, its quite a remarkable slimming down!

I do have the irritatingly complex data reading routine down to a more sensible size at 55 bytes, though it still has a considerable scope to be smaller I think by over 15 bytes.

So currently, Version 2 is coming in at around 648 bytes!

As soon as its all operating nicely, I'll post pics