3D Chess 2K18

The place for codemasters or beginners to talk about programming any language for the Spectrum.
Post Reply
User avatar
Einar Saukas
Bugaboo
Posts: 3070
Joined: Wed Nov 15, 2017 2:48 pm

Re: 3D Chess 2K18

Post by Einar Saukas »

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

Image
This is my favorite. Except the selected piece should be moving higher above the board to make it more visible.
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

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.
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

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!
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

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.
User avatar
Pegaz
Dynamite Dan
Posts: 1209
Joined: Mon Nov 13, 2017 1:44 pm

Re: 3D Chess 2K18

Post by Pegaz »

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/
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

This is absolute Dynamite!!!

Great explanations for how it was conceived and programmed, and enough detail about how it works for me to be reasonable happy that amazingly, many of the concepts and game mechanics I've coded so far are very close to his.

I'm astounded that I came to exactly the same conclusion regarding the off board testing, where there is a standard mechanism called 0x88 which checks if a square lies within the board boundaries. Without any online searching I came up with the same thing, but because of the alignment of my board, it won't work fully. I check top/ bottom and sideways moves with 0x48 and then there are 2 further checks for diagonal moves.

If I could adapt my board layout to be 128 byte, then perhaps this might be useful in other areas too.

The movement vectors and distances are almost the same as I came up with too. It's nice to know i'm on the right track!
User avatar
Pegaz
Dynamite Dan
Posts: 1209
Joined: Mon Nov 13, 2017 1:44 pm

Re: 3D Chess 2K18

Post by Pegaz »

Great, I'm really glad, to hear that.
I found it quite accidentally, I simply didnt believe it was possible to make a functional chess program in only 377 bytes.
The first thing I thought was that with this or similar engine, you can comfortably complete your chess within 1K.
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

It does miss a lot of functionality in 377 bytes, but its been written well enough to allow extra features to be fairly easily added.

Although I've only read through the code briefly, I can already see a few areas where some little improvements could be made to the size based upon the way I've achieved the same thing. But its written in a very careful way to align 2 x 256 aligned pieces of code so that switching between them works correctly. Any changes would probably break that.

I've managed to make my original display routine read through and display a 128 byte left aligned board with the addition of only 6 bytes so far, which isn't too bad. Using that layout might assist with many calculations later on.
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

One thing that puzzles me though is the reason for his numbering of the pieces, though that could be to do with their relative values in the game.

Pawn = 01
Knight = 02
Bishop = 03
Castle = 04
Queen = 05
King = 06

3D Chess 2k18 numbers as follows;

Pawn = 01
Castle = 02
Knight = 03
Bishop = 04
Queen = 05
King = 06

I guess it has to be a scoring thing.
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

the extended board architecture is now working with the addition of just +5 bytes to the original routine.

Reading, and checking the board and move legality just got a lot easier, so 5 bytes added there will hopefully save many more elsewhere.
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

Its all gone a bit mad with work, so not had a huge amount of time to dedicate to this lately. A few experiments have given reasonable results and the size of the main routine has just reduced by a further -1 byte courtesy of a nifty swap from ix-hl to do some searchy stuff. Once things get past Easter I expect I'll have a little more time.

Routine now at 492 bytes
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: 3D Chess 2K18

Post by Ast A. Moore »

If your job interferes with your Spectrum programming, I think it’s obvious you need to quit your job. :lol:
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
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

Probably uninteresting to many here, and I agree that I should really be concentrating on developing the GUI and game stuff, however, I've saved a further 2 bytes on the main display code, making it now 490 bytes

I'm sure its familiar to many, that sometimes when you're staring at the same piece of code and you mind isn't in gear, its nice to escape by faffing with something else instead! :lol:
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: 3D Chess 2K18

Post by Ast A. Moore »

arkannoyed wrote: Fri Apr 12, 2019 4:48 pm I'm sure its familiar to many, that sometimes when you're staring at the same piece of code and you mind isn't in gear, its nice to escape by faffing with something else instead!
Absolutely. I do my best coding while smoking, cooking, pacing around the room, and running errands around town. Staring at my code for hours on end usually leads to frustration and not much progress overall.
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.
dfzx
Manic Miner
Posts: 673
Joined: Mon Nov 13, 2017 6:55 pm
Location: New Forest, UK
Contact:

Re: 3D Chess 2K18

Post by dfzx »

arkannoyed wrote: Fri Apr 12, 2019 4:48 pm Probably uninteresting to many here, and I agree that I should really be concentrating on developing the GUI and game stuff, however, I've saved a further 2 bytes on the main display code, making it now 490 bytes

I'm sure its familiar to many, that sometimes when you're staring at the same piece of code and you mind isn't in gear, its nice to escape by faffing with something else instead! :lol:
I'd ask that maybe you'd add another sentence or two explaining, at a high level, what you spotted and how you optimised it. And how you spotted it, if there's a pattern or something which others might learn from.

Not that I mean to be impudent, demanding what you should tell us. :) But you're clearly an expert on optimising Z80 code, and I for one, as a beginner/intermediate level Z80 coder, could learn a huge amount from you if you'd ever care to share it.
Derek Fountain, author of the ZX Spectrum C Programmer's Getting Started Guide and various open source games, hardware and other projects, including an IF1 and ZX Microdrive emulator.
User avatar
zack4mac
Drutt
Posts: 17
Joined: Sat Apr 13, 2019 1:20 pm

Re: 3D Chess 2K18

Post by zack4mac »

Extremely impressive what can be done in such a small amount of memory just goes to show how much is wasted within a PC.
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

dfzx wrote: Sun Apr 14, 2019 1:27 pm
arkannoyed wrote: Fri Apr 12, 2019 4:48 pm Probably uninteresting to many here, and I agree that I should really be concentrating on developing the GUI and game stuff, however, I've saved a further 2 bytes on the main display code, making it now 490 bytes

I'm sure its familiar to many, that sometimes when you're staring at the same piece of code and you mind isn't in gear, its nice to escape by faffing with something else instead! :lol:
I'd ask that maybe you'd add another sentence or two explaining, at a high level, what you spotted and how you optimised it. And how you spotted it, if there's a pattern or something which others might learn from.

Not that I mean to be impudent, demanding what you should tell us. :) But you're clearly an expert on optimising Z80 code, and I for one, as a beginner/intermediate level Z80 coder, could learn a huge amount from you if you'd ever care to share it.
I know, I’m trying my best to comment the source, then explanations will make sense. Maybe tomorrow!
User avatar
ZXDunny
Manic Miner
Posts: 498
Joined: Tue Nov 14, 2017 3:45 pm

Re: 3D Chess 2K18

Post by ZXDunny »

zack4mac wrote: Sun Apr 14, 2019 2:50 pm Extremely impressive what can be done in such a small amount of memory just goes to show how much is wasted within a PC.
Agreed! If iD had tried just a little bit harder, we could have had Quake in less then 32kb.
User avatar
Einar Saukas
Bugaboo
Posts: 3070
Joined: Wed Nov 15, 2017 2:48 pm

Re: 3D Chess 2K18

Post by Einar Saukas »

ZXDunny wrote: Mon Apr 15, 2019 11:11 am
zack4mac wrote: Sun Apr 14, 2019 2:50 pm Extremely impressive what can be done in such a small amount of memory just goes to show how much is wasted within a PC.
Agreed! If iD had tried just a little bit harder, we could have had Quake in less then 32kb.
https://en.wikipedia.org/wiki/.kkrieger
User avatar
ZXDunny
Manic Miner
Posts: 498
Joined: Tue Nov 14, 2017 3:45 pm

Re: 3D Chess 2K18

Post by ZXDunny »

Einar Saukas wrote: Mon Apr 15, 2019 11:39 am
ZXDunny wrote: Mon Apr 15, 2019 11:11 am Agreed! If iD had tried just a little bit harder, we could have had Quake in less then 32kb.
https://en.wikipedia.org/wiki/.kkrieger
At the risk of going further off topic - Yeah, I had that when it came out. Quite an achievement, but nothing on the order of Quake as a game. And besides, that was four times bigger at 128k (compressed, with procedurally generated textures, levels and sounds).

It was more a jab at the idiocy of the zack4mac's assessment of the state of PC software.
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

Back on topic! :D

I’ve had a rather successful morning. I’ve been studiously tidying up source in order to try and make it suitable to post in snippets with explanations. Like a sort of mini series on what bits do what I suppose. Anyway, I have a few inspired moments, and I’ve only gone and saved 4 more bytes!! So the main code is now 486 bytes

Which is comprised of 260 code and 226 data

The initialise board routine had to sacrifice a byte as it was sharing the first byte (01 from ld BC) of the code as the terminating byte for its data. So that’s now back at 40 bytes. However, there’s a brand new method of calculating the screen address sort of cumulatively, whereas before it was done from a base address each time. This is obviously faster, though not noticeably. A few other tweeks here and there and voila!

Nearly there with tidying up source, even with the new bits, though it’s probably harder to understand now!!
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

.....and another byte saved!! That’s over 1% size reduction today alone!!

Amazing the things that happen when you’re in the right frame of mind, and perhaps caffeine fuelled!!

Now 485 bytes
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

Part 1: The Graphics format

Before I start to try and explain the decoding and how the board is displayed, its important to cover the format that the graphics data takes.

The data is quite simple, but incorporates control codes along the way that decide when to jump to different parts of the data stream according to which piece is currently being printed.

The data entry point is the same for all, as the bases are all common.

The pieces are numbered as follows;

2/3 = Pawns
4/5 = Rooks
6/7 = Knights
8/9 = Bishops
A/B = Queens
C/D = Kings

Obviously these are Hex values. 00 = empty square.

What happens when we perform a shirt right on the piece number is that we get the following;

1 = Pawn
2 = Rook
3 = Knight
4 = Bishop
5 = Queen
6 = King

BIT 0 was indication whether it was a White (0) or Black (1) piece.

Accessing the graphics data is identical whether its a Black or white piece, but the difference in appearance is all down to that BIT 0 being used to alter the data.

There are two separate routines used to print the board. One handles the screen addressing, and searching through the board, along with printing the board squares (only Black are printed to save time)

The other routine is then called if a piece occupies the square. This builds the specific line of the piece and prints it. It also handles all of the graphics data addressing and handling the control codes within it.

The Graphics Data

There are 5 distinct types to graphics data for the build routine to handle. It was a long task to find a good balance between compact graphics data and the procramming to decode it.

1. Standard lines.

For all lines, the data is built in the HL and DE register pairs.
Standard lines are 1 byte long, and indicated by bit 7 being set to 0.
There are 4 bits of data which according to that Black or White bit (BIT 0) are either left as is (White) or inverted (Black)
The rest of the line is created using that colour bit to fill in.
The lower 3 bits of the data byte hold a counter to create the correct line length.
Depending upon whether its a Black or White line, the registers are swapped (EX DE,HL) before printing which swaps the shading (the 4 bits of data) to either side.

2. Mini lines.

These are also 1 byte of data where the lower 4 bits create a symmetrical line which is the same whether Black or white

3. BWL-BWR lines.

These lines consist of 2 bytes of data where the second byte is the Right side data and the lower 5 bits of the 1st byte are XOR'd onto it to create the Left side data. Same line for Black or White.

4. BLR-WLR lines.

These are again 2 bytes of data. They create a version of each other where the colour bit is XOR'ed to alter the data.

5. Long lines.

These are 5 byte lines which allow for complex lines where Black and White are often very different to one another (see Knights for example). The 1st bytes lower 6 bits hold bits 8-10 for each side. The lines can be a maximum of 22 bits long.

The 4 bytes folowing are arranged as follows

1 = Black data Right
2 = Black data Left
3 = White data Right
4 = White data Left

The Black data has the colour byte (FF=Black, 00=White) applied (AND) as a mask. Then the White data is XOR'ed onto it. This might seem odd, but in programming terms, it gives a simple (ish) cycle to get which data we need and keep the addressing simple. The Black data needs to be the XOR'ed result with White. Mindbending to hand encode I can confirm!

Black and White pieces are both the same size, so the same data is used and just changed according to some simple transforms to give the correct final resulting piece.

Originally the sprites and board were designed circa 1994-95. The data at that time was in the form of simple masked sprites at a size of 4000 bytes. The board again was a straight bitmap of 6144 bytes. Then there was a print routine and tables of all the piece print addresses and sizes and graphics data address too. All in it was about 11k.

Now nearly 25 years later its 485 bytes!

I'm not really sure what drove me to want to squash the size so dramatically, but its become quite a pleasing excercise in both encoding and programming, where my Z80 skills have really had to improve a lot.

Part 2 will examine the first part of the routine that handles creating the screen address of the squares and setting up the piece height for the print loop.

Hopefully as I go through the various parts, the process might become clearer to some. It has become far simpler as the routine has developed fortunately, and is now a very solid reliable thing. No nasty registers (IY, R, I etc) or any use of EXX that might interfere with things. Its also quite simple to add-in extra things as in what will need to be there to create the functionality of the GUI in the eventual playable entity.
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

Part 2: The Beginning

So, swiftly on to the second part, and now for some actual code!!

This is the start of the routine, and a few parameters are set up.

The Board is stored as a simple 64 byte array at address FFC0h (65472). For easy end checking, when the end is reached, the lo byte address counter will reach 00.

Code: Select all

chess_build:
           ld hl,0c9c0h                   ;initial value to calculate squares SCReen addr.
           ld c,l
main_loop:
           ld a,c                         ;current square into A
           and 07h                        ;check row
           ld de,0ff30h                   ;DE=next row add value
           ld b,d                         ;B=FF
           jr z,ovr_main                  ;if were still on the same row
           ld de,0022h                    ;then add to go to the next square
ovr_main:
           add hl,de                      ;add
           push hl                        ;save cumulative square address
scr_crt:
           sla h                          ;correct to create SCReen address
           jr c,scr_crt                   ;loop 3 times
                                          ;square 00 address = 4810h
The Screen address is calculated from a base value, then just incremented with each pass, taking into account when we need to reset it to the start of a row.

+0022 to go to the next square
+ff30 to reset to next row, square 0

then after the calculation we save that value on the stack for the next pass and correct it to give a valid screen address.
This involves 3 shifts left of the H register, done in a loop by setting the top 3 bits previously to '110' and checking for no Carry to end. simple!

Within the routine, B is set to FF for addressing the board. D is the line counter, used in a few places later in the routine.

HL now points to the bottom line of the square. The squares are all based upon 4 bytes width, and we're pointing to the 3rd byte along (second from the right).
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

Part 2a:How High?

Next up is the little routine that checks which piece is occupying the current square and sets its height into the counter B. We also initialise IX with the entry point for the Graphics data.

Code: Select all

get_height:
           ld d,c                         ;save C
           ld a,(bc)                      ;A=piece occupying the current square
           ld e,a                         ;into E for use later on
           rra                            ;/2 to get rid of BIT 0 (B/W bit)
           ld c,a                         ;adjust address to point to piece heights table
           ld a,(bc)                      ;get height
           ld c,d                         ;restore C
           ld d,b                         ;D=FF reset line counter
           ld b,a                         ;B=height
           ld ix,0fe44h                   ;IX = Graphics data entry address
The table of height vectors is stored at FF00h, so by altering the Lo byte to be the piece code, we can easily find the number we need.

The piece occupying the square is also placed into E for use a little later on in the routine, where the main check takes place to either leave the square empty or print a piece on it.
Post Reply