3D Chess 2K18

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

[arkannoyed]

Well, not quite there, but this was a new approach thats managed 41 bytes

Code: Select all

init3:
          ld de,0ffbfh
          ld hl,data2s
lp13:
          ld c,(hl)
          xor a
          rrd
lp23:
          inc e
          ret z
          ld (de),a
          dec (hl)
          jr nz,lp23
          ld (hl),c
          inc l
          jr lp13
data2s:
          db 15h,17h,19h,1bh,1dh,19h,17h,15h
          db 83h,0f0h,0f0h,20h,82h
          db 14h,16h,18h,1ah,1ch,18h,16h,14h

The data is held in the lower 4 bits, and the counter (how many repeats of it to write) is in the upper 4 bits.

PLUS, it constructs the board correctly. Just that annoying 1 byte over!! Grrrrrrrrrrrrr!!!!!

[arkannoyed]

...And another version, a bit faster, but sadly still 41 bytes!

Code: Select all

init2:
          ld de,0ffc0h
          ld hl,data2s
lp1:
          xor a
          ld c,(hl)
          rrd
          ld b,(hl)
          ld (hl),c
lp2:
          ld (de),a
          inc e
          djnz lp2
          inc hl
          jr nz,lp1
          ret

[arkannoyed]

...However, that data is now conveniently ending with 06h,04h, which also reads to the Z80 as LD B,04h. I'm sure I've spotted that somewhere near the beginning of the Main Build Routine?! Oh yes, there it is!! So if I place the data just before it, adjust the address of everything down a bit, then we save 2 bytes.

So, the shiny new Initialise routine is 1 byte bigger overall, however, sharing 2 bytes lets us save 1 byte. Not the most helpful in terms of flexibility when it comes to adding functionality later, but, it works, and it gets to within 1 byte of the Holy Grail of 512!

So, total size now at 513 bytes

But more importantly, the board setup is now correct!

[Einar Saukas]

...However, that data is now conveniently ending with 06h,04h, which also reads to the Z80 as LD B,04h. I'm sure I've spotted that somewhere near the beginning of the Main Build Routine?! Oh yes, there it is!! So if I place the data just before it, adjust the address of everything down a bit, then we save 2 bytes.

So, the shiny new Initialise routine is 1 byte bigger overall, however, sharing 2 bytes lets us save 1 byte. Not the most helpful in terms of flexibility when it comes to adding functionality later, but, it works, and it gets to within 1 byte of the Holy Grail of 512!

So, total size now at 513 bytes

But more importantly, the board setup is now correct!

I think you skipped a step in your explanation

You added INC B in order to reduce 1 byte in data2s, right?

[arkannoyed]

Correct, yes! Sorry, so focused on saving the byte and re-arranging the code that I omitted that fact.

[Einar Saukas]

At least you know we are paying attention

[arkannoyed]

Perhaps I should pay more attention!

[d2010]

Perhaps I should pay more attention!

I work 12hours-in-continuu(non-stop), is very hard (i cannot fix the colours of pieces,i can not inverse colours of pieces..
Perhaps, your pieces can be more dynamically, not static.
Believe me, is very , very hard,very hard (many bugs and crash,rewrite the some-code-sources.
some).
https://youtu.be/bpnSDqa2QNs

[arkannoyed]

still confused!!

[Morkin]

...You'll probably be at a wedding when the registrar asks if anyone objects

...Or at a footy match during a 1 minute silence

...Or at a funeral

...And suddenly work out how to save that last byte....

I suspect you won't be able to contain yourself...

[ZXDunny]

Perhaps I should pay more attention!

I work 12hours-in-continuu(non-stop), is very hard (i cannot fix the colours of pieces,i can not inverse colours of pieces..
Perhaps, your pieces can be more dynamically, not static.
Believe me, is very , very hard,very hard (many bugs and crash,rewrite the some-code-sources.
some).
https://youtu.be/bpnSDqa2QNs

But why?

[arkannoyed]

...You'll probably be at a wedding when the registrar asks if anyone objects

...Or at a footy match during a 1 minute silence

...Or at a funeral

...And suddenly work out how to save that last byte....

I suspect you won't be able to contain yourself...

Hehe! Hopefully none of those events will come along before I find it!

[arkannoyed]

I work 12hours-in-continuu(non-stop), is very hard (i cannot fix the colours of pieces,i can not inverse colours of pieces..
Perhaps, your pieces can be more dynamically, not static.
Believe me, is very , very hard,very hard (many bugs and crash,rewrite the some-code-sources.
some).
https://youtu.be/bpnSDqa2QNs

But why?

My thoughts exactly! Sometimes best not to ask!

[reeagbo]

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?

Correct. I was looking at old code for board generation, I now I remember why I gave up on generating the board with code, it never gets small enough to replace the 32 bytes of data I'm using at the moment. I have the feeling that there is a way to do it, but I´m not focused into that at the moment.

[arkannoyed]

I agree that 32 bytes would be incredible!

Its not that I think it isn't possible, but it would take some kind of genius algorithm to create the populated board like that.

There is of course using the UNDO method, though again, I doubt that could be added in a small enough form to be useful.

Basically, every move is stored, perhaps on a dedicated stack or something. Then at the end of the game you simply take each move and perform it in reverse until you reach the end of the stack. At which point the board is reset.

I have tried many algorithmic solutions, but the smallest I managed was 46 bytes so far I believe.