3D Chess 2K18

[arkannoyed]

And there is the possibly to save another byte by changing the first byte of the data to 96 instead of 9E so it can act as the jump vector for the loop.

Have to watch that though in case I save more bytes. I think I'll leave it for now.

Both routines now weigh in agonisingly at 257 bytes!

[arkannoyed]

And another byte saved.

Silly me, never noticed that the first byte of both the Standard line and data line routines was LD L,A. So now that can be placed before we enter either of those.

Now 482 bytes

[d2010]

And another byte saved.
Silly me, never noticed that the first byte of both the Standard line and data line routines was LD L,A. So now that can be placed before we enter either of those.
Now 482 bytes

You make animations with demos.Why the pieces don't- move in table 8x8?
https://youtu.be/3XMqizx-8RA
Please subscribe , please you click on like-on-youtube for more-fun.

[arkannoyed]

Substance abuse is a strange pastime!!

[arkannoyed]

Not had a great deal of time to dedicate to this lately, but a couple of quick changes I spotted were possible this afternoon.

The first is 3 bytes saved in the Graphics data, where they can be shared elsewhere with just the addition of an extra jump vector (2 bytes)

The second I've been puzzling over for a very long time, and now I've finally figured out the maths of it. Instead of the traditional next line up routine, I've replaced it and shared the correction part from the squares calculating routine with calculating the next line up on screen.

All bafflingly complicated, however, its saved 3 bytes, and also allowed me to move the (still not completely fixed) board initialising routine to just before the board data matrix. Now there are precisely ZERO free bytes wasted inbetween.

The main routine and data is now an impressive 479 bytes!

Thats actually only 7 bytes away from the ENTIRE project fitting snugly into 512 bytes (if you include the 40 byte initialise routine)

Thankfully there seems to be no drop in speed at all.

[arkannoyed]

Next line up changed from this;

Code: Select all

nxt_line_up:
           ld a,h                         ;fairly standard stuff
           dec h                          ;I'm sure we're all
           and 07h                        ;familiar with!
           jr nz,piece_loop               ;
           ld a,l                         ;
           add a,0e0h                     ;
           ld l,a                         ;
           sbc a,a                        ;
           and 08h                        ;
           add a,h                        ;
           ld h,a                         ;

to this;

Code: Select all

	   ld a,h                         ;adjust to the next line up
           sub 20h                        ;
           ld h,a                         ;
           jr nc,piece_loop               ;if theres no Carry, then skip the next bit
           ld de,0ffe0h                   ;this takes care of adjusting the line
           add hl,de                      ;and SCReen 1/3rd adjustment.

Then the shared correct routine is just;

Code: Select all

scr_crt:
           ld a,h                         ;correct the SCReen address
           rlca                           ;
           rlca                           ;
           rlca                           ;
           ld h,a                         ;HL=correct SCReen position

I realise that out of context it probably remains puzzing!

[arkannoyed]

Oh, and it also means no having to reset the screen address to the centre of the line before calculating next line up.

[arkannoyed]

Blimey, Friday afternoons!!

Because we no longer need to restore the screen address, the B register if freed up allowing the Left hand side bit placing routine to shrink by 1 byte and get a little quicker too;

from this;

Code: Select all

left_ovr:
           ex de,hl                          ;swap data into HL
           add hl,hl                         ;propagate MSB
           ex de,hl                          ;swap back to SCReen in HL, data in DE
           sbc a,a                           ;apply carry
           xor (hl)                          ;XOR screen contents
           and c                             ;mask current bit
           xor (hl)                          ;XOR screen again to write the bit
           ld (hl),a                         ;place byte
           ld a,d                            ;check if data finished
           or e                              ;
           jr nz,left                        ;loop if not
left_end:
           ld a,(hl)                         ;change the last bit to 0
           xor c                             ;
           ld (hl),a                         ;

           ld l,b                            ;restore SCReen address
           ret                               ;

to this;

Code: Select all

left:
           rlc c                             ;next left bit
           jr nc,left_ovr                    ;
           dec l                             ;move left screen address
left_ovr:
           ld a,(hl)                         ;get SCReen byte into A
           or c                              ;set the current bit
           ld b,a                            ;save result in B
           xor c                             ;reset the current bit
           ld (hl),a                         ;write the result back to (HL)
           ex de,hl                          ;
           adc hl,hl                         ;shift bit 7 of H into Carry
           ex de,hl                          ;
           ret z                             ;if the result of ADC HL,HL=0000 then end
           jr nc,left                        ;if no carry, then we've already reset that bit, so loop
           ld (hl),b                         ;otherwise write the bit set result to (HL)
           jr left                           ;loop

Nice! and also saves yet another valuable byte, and in a very intensive routine too!

Now at 478 bytes

[d2010]

Please , you do no more reduce size of tap/z80.You insert more animations between
the pieces.If can not insert chess-role-game, then you insert first move.
Other you play the Chess with other game.z80, you save all moves(.Eg. A4-A6.C3-C7..)
The 3DChess-2K18 read all moves.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Oh, and it also means no having to reset the screen address to the centre of the line before calculating next line up.

[arkannoyed]

But its size is eventually intended to be below 1k, so all this reducing is still of great importance.

[hitm4n]

Hi there, i know you may sometimes post some stuff and then get a lack of replies, but if many are like me, we sit and lurk and keep tabs on things. I'm quite keenly following your progress, i check in daily to see whats new here, and i have to say its astounding what you have squeezed into under 500 teeny itty bitty bytes.

We all know of the age old 1k chess that exists, ascii gfx, poor rule set and slow. But without doubt a marvelous achievement.
Is your ultimate goal to create a 1k chess game but with a 3d board and full rule set? If so, then that would be an even wilder achievement.

Anyway, back to lurking

[hitm4n]

Sheesh, and your last message before mine states exactly that...

Well, good luck, i'm keeping tabs.

[arkannoyed]

Yes, the ultimate goal is to create a chess game that’s as fully featured as will fit into the 1k limit. So although all this squeezing of the core display code might sometimes seem somewhat pointless, actually every byte saved allows more space to include more functionality. I already have the legal move checking etc pretty much done, and the method that the gui will adopt is between 2 options, both easy to implement within the structure of the display code.

As far as the code squeezing goes, I saved a further 2 bytes last night, both in key areas too, which is where it gives the biggest improvement results too.

The next line up routine is now a byte smaller, though perhaps a few clicks slower, but nothing significant.

Then I managed to save another byte with some nifty code recycling in the print the left part of the line routine. That came down from 24 to 22 bytes yesterday, which even I was astounded by.

Interestingly (well to me anyway!) the total size, which only a few months ago I thought would be impossible to get near 512 bytes, is now at just 516 bytes. I’ve managed to save 36 bytes in about 3 months.

I do STILL need to rewrite the board initialising routine, and attempts so far have not managed smaller than 41 bytes. I’m favouring a recursive approach where it’s created algorithmically. I have a version that dies that in 48 bytes, but that was an early attempt. I’m sure sub 40 is possible.

So far all this continual development has fortunately not made the code any harder to add the GUI functions into, which is lucky.

[uglifruit]

I'm going to chip in and also state I'm a (gobsmacked) lurker in here too, and massively appreciated the time and effort you're putting into this, not only to code it, but also to share the process with the forum. My meagre z80 assembly efforts make me aware of his monumental a task you are setting yourself here. So on behalf of the silent onlookers I just wanted to say thanks, and say I'd welcome any further up updates as they come.

[arkannoyed]

Very kind, thank you. I appreciate that this is very much a personal crusade so far, and perhaps not something everyone might even understand the point of. But it good to know people are still looking at any updates that trickle through. I must confess, my z80 skills have improved a whole heap since I started this process. Although I still have a lot of areas of the Speccy that I’m not entirely familiar with, I’d like to think that the screen handling is now one thing I understand pretty well.

Anyway, another 2 bytes saved yesterday evening.

Incredibly, the left side print routine managed to shrink by another byte, so that’s 3 in as many days!!

I also moved the piece heights table to FF80h to take advantage of using the carry always being set prior to finding the current piece height for the print loop.

I’ll have to re-comment the altered source before I can post any details as it’s got a bit messy with all the changes.

Main routines are now only 249 bytes
Including the data 474 bytes

Total size 514 bytes

Maybe, just maybe development might move on to the next stage once those final 2 bytes can be saved.

[Pegaz]

Maybe, just maybe development might move on to the next stage once those final 2 bytes can be saved.

I totally agree with that.

[arkannoyed]

Changed the left print routine now to this at 21 bytes;

Code: Select all

get_lhs:
           ex de,hl                          ;swap addressing SCReen to DE
           pop hl                            ;LHS data retrieve from stack
           ld c,80h                          ;left bit mask set +1 right so that DEC L happens
left:
           rlc c                             ;next left bit
           jr nc,left_ovr                    ;
           dec e                             ;next left screen address
left_ovr:
           ld a,(de)                         ;get the SCReen byte in A
           or c                              ;set bit to 1
           xor c                             ;reset bit to 0
           adc hl,hl                         ;propagate data in HL to get MSB
left_set:
           ld (de),a
           ret z                             ;if result of shift gave zero then RET
           jr nc,left                        ;if no carry then loop
           or c
           jr left_set                       ;write result by looping back and as OR has cleared carry
                                             ;and the result will not be zero then we can continue
                                             ;the loop

First time I've really had an opportunity to use ADC HL,HL, but its 2 bytes smaller than doing individual register shifts, and it affects the Zero flag too, which in this case is a big help!

Also, as the next line up routine that follows once we RET has to POP the previous screen vector as a pre-corrected address, theres no need to restore the screen address when we exit here either.

[reeagbo]

Hi there,

Here Alex, the chesSkelet author. I just found this post accidentally and it's nice to see that we get to similar conclusions when thinking about this crazy thing. I need to dig into the details of your 3D Chess. I´m pretty curious at the moment.

FYI, I´m about to release a new version of the code, which is 370 bytes. It has many coding improvements and additional "strategy" improvements, particularly for the king under check, escaping and not being left uncovered. The big size version now will also include an option for castling. Let me know if you have any doubts on the current code (0.802c).
http://chesskelet.x10host.com/snapshots/

I saw the question on the pieces value, the thing is that those values are used for both pointing them for display, for move list generation and also the piece value during valuation. I have changed the king value to 8, so the I can identify it easily on the board through bit 3, (hl) whenever i need to.

I'm wondering if it would be worth opening a thread discussion details on chesSkelet...maybe later.

Alex

[arkannoyed]

Hi Alex,

I've not yet been back to your code to investigate the workings any further, but its an impressive achievement. The numbering of the pieces was of interest as far as any scoring or strength calculating thats done to decide upon the most suitable move to perform. Mine are simply numbered 1-6 (actually 2/3, 4/5, 6/7, 8/9, A/B, C/D when their Black or White identifier bit is added in) which is very very for indexing graphics data. Doesn't have to be, and they could be in any order actually.

I did begin to look at the possibility of a simple interpreter to scan through your board and piece format and display it using my 3D engine. You use a 128 byte board, whereas mine is 64 bytes. I can quite easily adapt to the larger format, which is easier to use for various legal move checks. Only adds about 5 bytes.

I'm now at the point where for my own sanity I need to save the final 2 bytes just to give me that satisfying 512 bytes total size. 1 disk sector!

Once thats done and I've fixed the board setting/ resetting routine, then it will be in its final release state. Then development and integration of the GUI aspects can be done, tested and finalised so that I can then move onto the game logic, some of which follows a similar route that you've taken evidently.

I'll be interested to see how you achieve castling, as I've not figured that one out yet.

Keep up the great development, really impressive effort!

[arkannoyed]

I think you would get a lot of interest in a thread detailing Chesskelet. Chess still remains a fascinating subject in terms of programming etc.

If you do want to delve deeper into the 3D display routines, then I'm happy to send you the source, though I've posted it earlier in this thread. It has changed a bit since though.

[reeagbo]

Hi, On your comments...

I've not yet been back to your code to investigate the workings any further, but its an impressive achievement. The numbering of the pieces was of interest as far as any scoring or strength calculating thats done to decide upon the most suitable move to perform. Mine are simply numbered 1-6 (actually 2/3, 4/5, 6/7, 8/9, A/B, C/D when their Black or White identifier bit is added in) which is very very for indexing graphics data. Doesn't have to be, and they could be in any order actually.

>>>> you´ll need to figure that out when your start looking at evaluation. My method is not standard. As you may now most valuations look like P=1, N=2,5, K=3, R=5, Q=8, K= inf. (more or mess). In my case, I'm not doing tree search, therefore no need to analyze multiple captures, only need to know which is more valuable.

I did begin to look at the possibility of a simple interpreter to scan through your board and piece format and display it using my 3D engine. You use a 128 byte board, whereas mine is 64 bytes. I can quite easily adapt to the larger format, which is easier to use for various legal move checks. Only adds about 5 bytes.

>>>>> I´ve found 16x8 byte board very helpful for OOD detection, and also end of rank and end of board loop detection. Also it allows managing the board coordinates in a single byte with this format (0rrr0ccc), r=rank (0...7), c=col (0...7), which simplifies the tasks above.

I'm now at the point where for my own sanity I need to save the final 2 bytes just to give me that satisfying 512 bytes total size. 1 disk sector!

>>>>> That is awesome for a 3D interface.

Once thats done and I've fixed the board setting/ resetting routine, then it will be in its final release state. Then development and integration of the GUI aspects can be done, tested and finalised so that I can then move onto the game logic, some of which follows a similar route that you've taken evidently.

I'll be interested to see how you achieve castling, as I've not figured that one out yet.

>>>> you can find castling code in the code I shared (it's split in two places). Actually my code is a bit of a cheat, since it does not check for validity, only checks that the king is in the right place. For the rest it trusts the human player. Checking full castling validity involves keeping track of the king and rooks never having been moved, the king not being under check and none of the squares in between attacked. That would need me to re-write the whole thing. And only for the human player to use it. The "AI" in my program would never use it, it's not smart enough...

Keep up the great development, really impressive effort!

>>>> for the 3D interface, I´m not planning to make mine more complex, I would reduce it further if I could. Feel free to use any of my code in your program if that helps. I'd like to hear on any improvement, I think you mentioned something about that in other posts.

[arkannoyed]

I'm so far hitting a wall with finding a method of saving these last 2 bytes. One of those days when no matter how hard I look at it, I can't find anywhere that could be optimised. Even looking for a cheat where I might be able to use any handy ROM routines in part yielded nothing.

There are 2 things that have remained pretty much unaltered since some very early versions. First is the routine that draws the lines of the board squares. No matter what method I've attempted, its bigger in bytes. For the playable version I do have a 5 byte longer version thats almost twice as fast, and is a bit easier to add-in the masking to give the squares a greyed-out shaded effect indicating that they're selected. What it does, it does fairly efficiently though.

The second is the board initialising/ resetting routine. Does ChessKelet do that, as I can't find reset routine in the source, or maybe I'm missing it? Einar kindly came up with the code for it a few years ago, and I've just left it there, not really changing it even though it has a bug where it reverses the Black and White King/ Queen positions. Every now and then I have a go at a new version, but usually give up after only managing to get to a larger than 40 byte size. I'm convinced there must be a way of achieving smaller, but so far its eluded me.

[reeagbo]

I used to include a reset routine to re-create the board in earlier version, but historically, other colleagues producing mini chess games under 500 bytes (total) did not make it replayable, I decided to remove it. However, at the time I thought of two solutions:

(1) placing the "initial" board somewhere else and copying it to the playing board (LDI or other solution). In my case that would cost around 40B-45B, including the "initial" board bytes. Not sure if this solution would apply in your case.

(2) a routine that creates the board from nothing. I was thinking of an array including which pieces and how many of them are needed to fill in the board. This array would be read by a routine that would fill in the board from the beginning to the middle and from the end backards to the middle. Never dug much into that, but I'm sure there is an affordable way to do it, but less than (1)? The nice thing is that with this option the game would be replayable at no cost, since this routine would be used to create the first game board too.

I'm thinking that, at the level you are coding at this point, my comments are worth nothing to you.

Alex

[arkannoyed]

The board setting routine I use is as follows and simply copies some data, then adds +1 to those data bytes for pieces of the opposite colour.

Very simplistic, but flawed obviously.

I've written so, so many variations addressing in so many ways, that I've lost count. I WILL GET IT DONE!!!

As this will eventually be (hopefully) a fully game in under 1k, I have to include something that sets up the board, but I've noticed that many mini versions don't allow for this, which is fair I suppose.

The 64 byte board I use is aligned to FFC0h, so the end is and easy zero check.

Code: Select all

init_board:
           ld de,0ffc0h
           ld b,d
           ld c,d
           ld hl,data_17
ib_loop1:
           ld a,(hl)
           dec a
           ld (bc),a
           ldi
           jr nz,ib_loop1
           dec e
           ld b,20h
ib_loop2:
           ld (de),a
           inc e
           djnz ib_loop2

           ret                   ;23 bytes
data_17:
           db 05h,07h,09h,0bh,0dh,09h,07h,05h
           db 03h,03h,03h,03h,03h,03h,03h,03h,01h

[arkannoyed]

Theoretically then if you were to use an initialising routine, your total size should become smaller, as currently its fixed by the size of the board data?