3D Chess 2K18

[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!

[Bizzley]

The smaller it is, the more space there is left for the actual game in the end.

Then I will offer the suggestion that once you have worked out this new optimisation you step away from the graphics and take a week or two working on the rest of the necessary code. The idea is not to come up with finished routines but to at least get a rough idea of the size of code you will need to implement a finished game.

Since you are aiming for a <1K game and (if) you already know that the AI and GUI code will be just slightly over 512 bytes in size then of course it make sense for you to continue hammering away at the graphics. If however the figure is a lot more than 512 bytes then you need to shift over to optimizing that instead. If you do not have an estimated size for this code yet then really, the last thing you want to happen is to discover in a few months time that due to the eventual size of the code required all these years spent shaving bytes has been in vain. Unless you end up creating a >1K game in which case, as I said before, saving a few bytes here and there won't really matter.

[arkannoyed]

The GUI test version including all the keyboard reading etc, added around 140 bytes, but that was in no way optimised. Any control system is going to add a fair bit, but its just exactly what method that ends up being, and how it integrates with the display routine. Fortunately, the smaller it gets, it seems to be more stable and allow a much greater degree of input as far as changes go. Thats quite unusual I would think, but there again, the earlier versions were complicated as hell!

Early move legality ideas involve each piece having sort of a self contained algorithm that when called with registers holding the piece and its position and where its to be moved to, it can quickly check if that is in fact a legal move or not. Certain situations like the Pawn initial moves will obviously complicate things a little, but its certainly a challenge!

[arkannoyed]

Phase one of the re-designed pieces involves trying to make the bases look less chunky, but still retain a compatibility with the original upper parts.

Any thoughts? I kind of like it...sort of?!



bit short perhaps, maybe I'll encode an additional line, hang on...

[arkannoyed]

for comparison with a line added;



Only reduces the code size by one lousy byte, but it does give a slightly softer look don't you think?

We're also now down at a mere 0.7 seconds to build the entire board, with the full set of pieces. only a few days ago, it was 1.1 seconds. Thats nearly 1/3rd faster! I'm quite pleased with that to say the least. perhaps I'll integrate the GUI again in this version at some point to see how much better it works.

[Ast A. Moore]

I kind of want the base outline to be a tad more solid. The dotted line look just doesn’t work for me.

[arkannoyed]

fast;

[arkannoyed]

I kind of want the base outline to be a tad more solid. The dotted line look just doesn’t work for me.

Ok, give me a little more info, what would you alter? I'll try anything if it fits!

I think I get what you mean, but that adds another 4 bytes, which just isn't Cricket!

[arkannoyed]

Spotted an encoding mistake where the new base design should be 4 bytes smaller, so if this alteration were to stay, or at least a variant of it, the size now stands at 498 bytes

[Bizzley]

I agree with Ast A. Moore in that these new diddly base pixels don't work for me either. To be specific what you have now appears for all the world to look to me like inconsistent highlighting, especially on the black pieces i.e.if the light is coming from the left then why is there a highlight on the right? Please don't fall into the all too-common trap that coders make that just because you understand what things are meant to represent everyone else will understand also. To you it's a bevelled ridge, to me it's a highlight.

I have difficuly understanding why you won't even approach getting a rough idea of how much the code will take other than working on an assumption that a byte saved on the graphics is one that can be used for game code. Have you considered that if the completed game code comes in under 512 bytes then you don't need to bother shaving bytes from the graphics and that you'll be able to go back to the better looking ones from several weeks ago rather than ones that "don't quite look as nice as before" - your words.

So blunt question to you. If the current code does not include any of the following then what is your total estimated non-optimised code size for handling: intial pawn 1 or 2 square movement, en passant, castling, piece promotion, logic of duplicate pieces because of promotion, testing for being in check, testing for invalid movements due to being in check, testing for mate, conceding the game, the GUI and the computer AI routines?

This 1K chess program program has the capability of being something truly unique, something that would transcend this Forum and make an impact outside the narrow field of Spectrum coding. But if you think what I've written is negative in any way or you feel I'm not being constructive in these replies then just say so and I'll bow out and leave you to carry on without any more interruptions.

[arkannoyed]

To be honest, in logic and gameplay terms, I think you’re ahead of me!

[Ast A. Moore]

Hey, buddy, as a programmer myself, I know how you feel. I too have struggled with making a decision that would neat up the code at the expense of the game itself. One way of avoiding that trap is to move onto another aspect of the code, which is, in your case, the actual game logic. When you have the game basically finished, you can get back to fine tuning the graphics, drawing routines, et cetera. I know I’m stating the obvious, but it’s easy to forget those things when you’re deep inside the coding world.

Also, the white knight looks like a camel now.

[Pegaz]

@Bizzley

I hope you stay on this topic, because I think your approach is more than constructive.
This project is one of the most exciting things on the Spectrum scene for a long time and I'm always looking forward to every new post.
As a chess fan (not as a programmer), I can only say that I really enjoy this discussion.

[Einar Saukas]

If you are still enjoying the challenge of reducing code size, by all means keep doing it! This is a hobby, not a commercial project, so you don't have to make sacrifices to meet a deadline.

However I must confess I also prefer the old design with larger pieces. I don't think it's worth it to gain a few bytes, if it makes the board look less impressive.

[arkannoyed]

Thanks for the support. I'm not sure its the most impressive thing out there, but I do enjoy seeing it develop and on a personal level, finding new ways to approach a problem and do it more efficiently/ faster is always pleasing.

I've added a line, so they're currently only 1 line shorter than before and only 1 byte less;



I think the bases look more balanced, not as heavy as before. They're only 2 px narrower too. Remember, the graphics are a result of a very restricted set of parameters. Only a finite amount of possibilities exist for their design really, so you I have to be creative, otherwise, they could look a lot nicer. Take the top of the bishop for example. A long time ago, he looked much nicer. Now its a bit odd really. But that might change soon.

From a coding point of view and to improve the eventual experience there are 2 key areas I'm working on before I'll be happy to leave it and move to the next stage.
1. The board printing. That is bit-wise. Needs to be byte-wise to speed it up. Efforts so far have not managed to get close to the 39 bytes it currently takes up. I think 46 is my best effort so far.

2. Printing of the Left side of the pieces is also still bit-wise, as the buffer is mirrored due to restrictions in the way its formed. To flip it, auto mask and print is no easy task and currently happens in 23 bytes. I do have a version that is faster but is 24 bytes. Needs more work and a new approach.

So, when both those aspects have been addressed, then the speed should be good enough to achieve some better gameplay results. A GUI has to be responsive, and even though its small size doesn't allow for all bells and whistles, there has to be a satisfactory feel to it for me to be happy.

I'm glad I never worked in the software industry, I'm too picky to be any use to anyone!

[Ast A. Moore]

The bases definitely look better now.

[arkannoyed]

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.

[Ast A. Moore]

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.

[arkannoyed]

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.

[arkannoyed]

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

[Pegaz]

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