3D Chess 2K18

The place for codemasters or beginners to talk about programming any language for the Spectrum.
User avatar
ZXDunny
Dizzy
Posts: 75
Joined: Tue Nov 14, 2017 3:45 pm

Re: 3D Chess 2K18

Post by ZXDunny » Fri Jul 13, 2018 2:52 pm

Following like a madman here too, this is fascinating. Bit more of a write-up of what optimisations you make as you make them (with sources so we can follow along) would be gratefully received by the whole community, I'm sure.
2 x

User avatar
arkannoyed
Microbot
Posts: 111
Joined: Mon Feb 05, 2018 9:56 am

Re: 3D Chess 2K18

Post by arkannoyed » Fri Jul 13, 2018 3:00 pm

I agree, more detailed info on what gets changed is always a bonus, however, I tend to program in such a haphazard way, that its sometimes tricky. For instance, I've just spotted a way that I can save 1 byte. It would involve reversing all of the data. That may seem like a ridiculous thing to do to save 1 byte, however, the smaller it gets, the more significant that 1 byte becomes.

I've also saved an obvious byte in the main BIT placing routine, which is called to place every BIT of the sprite, so every pass is now -4TS too.

I am actively tidying up the source as I go. I've just actually found a neat optimisation thats saved another byte, so we're down to 595 bytes now.
:)
5 x

Kweepa
Microbot
Posts: 163
Joined: Sat Feb 03, 2018 6:14 pm

Re: 3D Chess 2K18

Post by Kweepa » Sun Jul 15, 2018 2:03 am

The manager in me is saying "quit mucking around and write the chess logic".
The programmer in me is saying "go for 512 bytes!"
3 x

User avatar
arkannoyed
Microbot
Posts: 111
Joined: Mon Feb 05, 2018 9:56 am

Re: 3D Chess 2K18

Post by arkannoyed » Sun Jul 15, 2018 8:06 am

Actually I have been increasingly frequent thoughts regarding 512 myself. I’ve no idea how I might achieve that though as we’re at 593, which is 81 bytes too big! :(
0 x

User avatar
Ast A. Moore
Manic Miner
Posts: 673
Joined: Mon Nov 13, 2017 3:16 pm

Re: 3D Chess 2K18

Post by Ast A. Moore » Sun Jul 15, 2018 8:13 am

arkannoyed wrote:
Sun Jul 15, 2018 8:06 am
I’ve no idea how I might achieve that though as we’re at 593, which is 81 bytes too big! :(
Reduce the pieces’ dimensions. ;)
1 x
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.

User avatar
arkannoyed
Microbot
Posts: 111
Joined: Mon Feb 05, 2018 9:56 am

Re: 3D Chess 2K18

Post by arkannoyed » Sun Jul 15, 2018 8:59 am

The one thing sacred is stayed true to the original design, so though that may save a few bytes, it’s not ethical! :D Also, the structure of the data means that the pieces would have to reduce to max 16 bits wide (from 22) and the height be probably 1/3rd. That would make them a bit tiddly looking really. Part of the challenge is maintaining the basic footprint of the pieces whilst reducing their size and the code to decipher and print them. I do have many tweeks and ideas still to implement, so the size should steadily reduce. 512 bytes might be possible if I were to not include the initialise the board routine in the overall size, which knocks 40 bytes off straight away. If the data is to get smaller, it’s going to have to do far more algorithm based graphics building, just maybe using the line number and a component to form a line of graphics data. The Standard line model already does that, with 3 bits for length, 4 bits of Pixel data, then puts it all together. Some of the data lines are also constructed in various ways from several components. So far there are 5 distinct line types of 1,1,2,2 or 5 bytes. 5 bytes are obviously the longest and more complex lines, but there are actually only 22 of those anyway. There are patterns even in those which could allow further data reduction, but at the expense of more program code, so currently no point pursuing that avenue.
0 x

User avatar
arkannoyed
Microbot
Posts: 111
Joined: Mon Feb 05, 2018 9:56 am

Re: 3D Chess 2K18

Post by arkannoyed » Wed Jul 18, 2018 1:30 pm

A lot of re-organising to achieve a bit more size reduction. Also a neat way to store the pieces vector table position, which saved 5 bytes alone.

Now at 588 bytes

Still plenty to do and I really am making good progress on commenting the source at last!
0 x

User avatar
arkannoyed
Microbot
Posts: 111
Joined: Mon Feb 05, 2018 9:56 am

Re: 3D Chess 2K18

Post by arkannoyed » Thu Jul 19, 2018 9:35 am

Some decent changes this morning, and now at 586 bytes

I'm now struggling to find any further improvements :?

If I'm going to achieve that 512 bytes magic number, (586 -40 bytes (initialise board routine and data) = 546 - 512 =34 bytes)

Then I still need to save a further 34 bytes, which is looking rather far away.
0 x

User avatar
Pegaz
Microbot
Posts: 144
Joined: Mon Nov 13, 2017 1:44 pm

Re: 3D Chess 2K18

Post by Pegaz » Thu Jul 19, 2018 10:30 am

I think you've done a great job so far and maybe it's time to start adding a decent (also a memory-efficient) chess engine.
I guess the optimization of board routines is possible later if you find more space for that.
1 x

User avatar
arkannoyed
Microbot
Posts: 111
Joined: Mon Feb 05, 2018 9:56 am

Re: 3D Chess 2K18

Post by arkannoyed » Thu Jul 19, 2018 11:47 am

Optimization has to always be done keeping in mind the fact that somehow, some kind of GUI will have to be integrated into it at some point. Once I achieve the best balance of speed and size (hopefully very small!) the routine will then start to grow in size again incorporating several elements such as piece and square selection. once that all works as efficiently as it can, then it will be time to add some kind of logic and error checking into the mix. Fortunately, this iteration seems to allow a lot more flexibility to add new features without it getting all grumpy about it. Thats more by luck than design!
I still intend another redesign of the graphics, as I think there are a few areas that might benefit from alterations, helping a more crowded board appear less cluttered. Certain formations of graphics print faster than others, and can be encoded in less space. The bases of the pieces are all common, but look a little heavy. Shaving just 1 line off them could save 5 bytes! Not huge, but maybe significant in the end.

The nice thing about it is that it all feels very stable as it is, not using registers that it shouldn't, and not creating any huge buffers in memory. Its so efficient now that its even almost relocatable.

..And now 585 bytes! :P
0 x

Post Reply