3D Chess 2K18
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Now then! Important decisions to be made. Its looking like this final initial version will be added to ZXDB, however, I've not actually ever decided upon a name for it. I've gone along with Chess 2k19 (or 2k18) for some time, simply as a development name.
Some time ago I thought it might be something like 1K 3D Ultra Chess or something similar. I think it needs the ability to add a suffix like 16k version or Display, or Screen Resident to reflect various branches that might follow.
Any thoughts?
Some time ago I thought it might be something like 1K 3D Ultra Chess or something similar. I think it needs the ability to add a suffix like 16k version or Display, or Screen Resident to reflect various branches that might follow.
Any thoughts?
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Just came across one of the original development +D Disc image images. Below was an early attempt at some sort of GUI, though that was about 1994, way way before the idea of the small size version was conceived.
See, the graphics have remained very true to the original designs.
See, the graphics have remained very true to the original designs.
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
And this is how fast it could be displayed when using conventional masked sprites, though this was hand encoded with no assembler over 25 years ago, when I first learned to program in Z80, so fairly simple concepts with little effort dedicated to speeding it up.
Re: 3D Chess 2K18
How much RAM does your current 512b version take up at runtime?
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Do you mean any buffering? If so, none, only the stack for 4 or 5 pushes/pops. Everything calculated and placed directly on screen.
The 512 bytes is unaltered, untouched. Everything done in-registers really.
The 512 bytes is unaltered, untouched. Everything done in-registers really.
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
How about
3D Chess 512 or 3D Chess 200 (200 hex is 512!)
3D Ultra Chess 512?
Half K Chess 3D
Nothing sounds very catchy!
3D Chess 512 or 3D Chess 200 (200 hex is 512!)
3D Ultra Chess 512?
Half K Chess 3D
Nothing sounds very catchy!
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Oh Bugger!
Thats messed the naming up now! Saved another byte, so now its 3D Chess 511!
It was another one of those annoyingly obvious situations where saving a byte was very easy.
The Initialise board routine is just plonked in front of the start of the main routine, therefore getting rid of the need for a RET, as in most cases you'd call the display routine straight after anyway. If no reset needed, just skip the initialise part.
Thats messed the naming up now! Saved another byte, so now its 3D Chess 511!
It was another one of those annoyingly obvious situations where saving a byte was very easy.
The Initialise board routine is just plonked in front of the start of the main routine, therefore getting rid of the need for a RET, as in most cases you'd call the display routine straight after anyway. If no reset needed, just skip the initialise part.
Re: 3D Chess 2K18
I was trying to write a board starting routine that I could use. It's 38 bytes. Maybe you can use it with minor changes. I use the beloved 128 board, and pieces color goes in bit4 intstead of bit 1. Both yours and mine can discount 1B for the 'ret'. Tell me if it gives you any idea.arkannoyed wrote: ↑Mon Apr 29, 2019 3:58 pm ...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
Code: Select all
org 30000
; preps, 5B
ld hl, $8060 ; point at black pawns start in board
push hl ; copy HL to DE for later use in loop
pop de ;
; fill in white pawns, 7B
loopaw ld (hl), $11 ; set black pawn
inc l ; next square
bit 3, l ; loop until L=70
jr z, loopaw ;
; copy black pieces to white, 9B
ld l, $17 ; point at white pawn start
loocop ld a, (de) ; copy black piece
and $0F ; "blacken" piece
ld (hl), a ; place it on the white side
inc e ; next black square
dec l ; next white square
jp p, loocop ; loop down to square cero
; switch $8003 <-> $8004 for mirror symmetry, 6B
ld hl, $0508 ; black queen, black king
ld ($8003), hl ; load in black squares
; alternative
;ld l, $03 ; H =80 now
;ld (hl), $05 ;
;inc l ;
;ld (hl), $08 ;
ret
; white pieces, 8B
org $8070
piesta defb $14, $12, $13, $15, $18, $13, $12, $14
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
I don't understand entirely what its doing?
I know your 128 byte board layout is different to mine, but I can only see that it sets the Pawns and the black King and Queen?
Mine is 'technically' 38 bytes, as the routine is now 20 as the RET has been dropped from the end, and 2 bytes of the data are shared as code with the routine.
I am still working on some rather abstract ideas to come up with a smaller solution.
I know your 128 byte board layout is different to mine, but I can only see that it sets the Pawns and the black King and Queen?
Mine is 'technically' 38 bytes, as the routine is now 20 as the RET has been dropped from the end, and 2 bytes of the data are shared as code with the routine.
I am still working on some rather abstract ideas to come up with a smaller solution.
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
I have now officially begun writing and re-writing some of the key routines that will be incorporated.
The core build/ display routine will unhook from some internal routines such as the calculations for square addresses and screen handling, which it will call external routines for. This will slow it a little, however, those routines are to be shared elsewhere. Instead of clearing the entire 6144 bytes of the buffer after every action takes place, an intelligent routine will just clear the 2 squares and a fixed number of lines upwards in a super quick, but compact block clear. This can be done in about a quarter of the time and doesn't take many more bytes really.
Therefore, the actually build routines will shrink in size as parts move elsewhere.
If I were to have a second buffer, then the board could be created upon initialisation and stored as a large bitmap then just copied. That would make it possible to remove the square routines from the build and reduce it to one, more compact piece of code that just cycles through the board matrix and prints the pieces as and when they are found. This would make the whole thing bigger, but might give better speed for the game play point of view in terms of animation etc. A possibility to be considered perhaps.
The core build/ display routine will unhook from some internal routines such as the calculations for square addresses and screen handling, which it will call external routines for. This will slow it a little, however, those routines are to be shared elsewhere. Instead of clearing the entire 6144 bytes of the buffer after every action takes place, an intelligent routine will just clear the 2 squares and a fixed number of lines upwards in a super quick, but compact block clear. This can be done in about a quarter of the time and doesn't take many more bytes really.
Therefore, the actually build routines will shrink in size as parts move elsewhere.
If I were to have a second buffer, then the board could be created upon initialisation and stored as a large bitmap then just copied. That would make it possible to remove the square routines from the build and reduce it to one, more compact piece of code that just cycles through the board matrix and prints the pieces as and when they are found. This would make the whole thing bigger, but might give better speed for the game play point of view in terms of animation etc. A possibility to be considered perhaps.
- Einar Saukas
- Bugaboo
- Posts: 3070
- Joined: Wed Nov 15, 2017 2:48 pm
Re: 3D Chess 2K18
The first loop sets white pawns. The other white pieces were already set using DEFB. The second loop copies pieces white to black, then finally there's an explicit LD to switch King and Queen positions.
The initialization only works once, and it's assuming that any position not explicitly assigned will be zero. But under these assumptions, why not simply use DEFB to set all 32 pieces, thus only requiring 32 bytes?
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
A DEFB is all ok from an assembler point of view for a one off game, but to copy 32 bytes of data and clearing the board would still be bigger. As its going to be replayable, it needs a board reset routine.
- Einar Saukas
- Bugaboo
- Posts: 3070
- Joined: Wed Nov 15, 2017 2:48 pm
Re: 3D Chess 2K18
I know.arkannoyed wrote: ↑Fri May 03, 2019 12:20 pm A DEFB is all ok from an assembler point of view for a one off game, but to copy 32 bytes of data and clearing the board would still be bigger. As its going to be replayable, it needs a board reset routine.
I was suggesting DEFB for chesSkelet only, since it doesn't clear the board and it's not replayable.
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Oh I see, sorry!
We we're just discussing the possibility of making it replayable, perhaps in one of the larger fuller versions, and whether some sort of board setting/ resetting routine could work for both of us.
We we're just discussing the possibility of making it replayable, perhaps in one of the larger fuller versions, and whether some sort of board setting/ resetting routine could work for both of us.
-
- Manic Miner
- Posts: 205
- Joined: Thu Feb 22, 2018 3:27 pm
- Location: virginias eastern shore
- Contact:
Re: 3D Chess 2K18
[/quote]
It was more a jab at the idiocy of the zack4mac's assessment of the state of PC software.
[/quote]
Hey Dunny? Please excuse my probable idiocy but why did you say zack4mac's comment about the state of PC software was idiotic?
I'm constantly annoyed by bloatware. The difference in functionality versus size came up yesterday when I went looking for an RTF to HTML conversion utility. Some of them were several megs in size, the one I eventually chose was around 700k and works just fine (not sure if I got that size right but there was a huge difference between the various examples)
It was more a jab at the idiocy of the zack4mac's assessment of the state of PC software.
[/quote]
Hey Dunny? Please excuse my probable idiocy but why did you say zack4mac's comment about the state of PC software was idiotic?
I'm constantly annoyed by bloatware. The difference in functionality versus size came up yesterday when I went looking for an RTF to HTML conversion utility. Some of them were several megs in size, the one I eventually chose was around 700k and works just fine (not sure if I got that size right but there was a huge difference between the various examples)
Re: 3D Chess 2K18
There is a prevailing view that PC software is becoming bloated which, although true to an extent, is not as due to poor programming as you might think. Spectrums use 1Bpp graphics, beeper or AY code to produce sound etc - none of which is really viable on a PC as things are these days. 32Bpp graphics, high resolution textures, intricate control routines for moveable objects (such as enemies etc) and enormous, detailed level designs not to mention the fact the nearly everything is now 3D accounts for most of the bloat in games these days.llewelyn wrote: ↑Fri May 03, 2019 3:14 pm Hey Dunny? Please excuse my probable idiocy but why did you say zack4mac's comment about the state of PC software was idiotic?
I'm constantly annoyed by bloatware. The difference in functionality versus size came up yesterday when I went looking for an RTF to HTML conversion utility. Some of them were several megs in size, the one I eventually chose was around 700k and works just fine (not sure if I got that size right but there was a huge difference between the various examples)
Poor programming (or at least a poor choice of tools) does have an impact - your RTF->HTML converters could probably done in raw C in just a couple of Kb - if you don't want to handle things like Unicode, and only a small subset of the RTF standard for example. Add to this that the author might be using a scripted language with included runtime libraries embedded means that you quickly bloat to MBs. Of course a 32bit architecture may mean a 4x bloat in code size alone, double that for 64bit possibly. So 700Kb is considered a pretty light application nowadays.
As a quick example, take my own SpecBAS. The executable is 16MB in size! But that's including the interpreter, the editor, all the runtime code for the myriad routines you might or might use. And then there's debug information. Without the debug info, it's 5MB. And it ain't gonna be any smaller. Why? Despite looking retro, SpecBAS runs 32bpp graphics with alpha blending and is not hardware accelerated aside from actually getting the graphics on the screen. The default font is 64KB as opposed to the same font occupying 767 bytes on the Speccy - the font is 32bit. There's masses of tables used to get things done quicker than you could on a Speccy. And of course, it's a win32/64 executable built with a modern compiler so there's runtime support libs built-in.
I'd love to get things down to less than a meg, but it's not gonna happen. And never will anymore, aside from demo coding contests where really small stuff can be built but is useless for anything other than showing off an effect.
I might have been a tad insulting back there, but you tend to get really tired of these people that can't code on modern platforms complaining that all their bytes have gone missing and you could do so much more with 16Kb back then.
Now back to your scheduled chess shenanigans.
- Einar Saukas
- Bugaboo
- Posts: 3070
- Joined: Wed Nov 15, 2017 2:48 pm
Re: 3D Chess 2K18
On another subject...
The classic 1K Chess by David Horne was never intended to be the SMALLEST POSSIBLE chess. It was the opposite. The author was trying to PUT AS MUCH CONTENT AS POSSIBLE (full chess rules, good AI, etc) within the memory limitations of the original 1K ZX81.
David Horne wasn't saving bytes to make his program smaller. He was doing it so he could have enough room to improve AI logic, for instance.
Nowadays there are several even smaller chess programs (I mentioned a few here at the time). They are all certainly impressive, but their AI is typically so bad they are not fun to play.
Your 3D chess will never be smaller than those existing 2D versions anyway. Therefore I see no point in just adding a simplistic AI to the code you already have. Instead, I suggest your goal should be achieving the BEST POSSIBLE chess game in exactly 1K. Which means supporting 100% of chess rules, and the smartest possible AI you can fit.
It seems both chesSkelet and David Horne's 1K chess play better than others. I would first play a few rounds between them to compare AIs, then use the best players as starting point to implement yours...
The classic 1K Chess by David Horne was never intended to be the SMALLEST POSSIBLE chess. It was the opposite. The author was trying to PUT AS MUCH CONTENT AS POSSIBLE (full chess rules, good AI, etc) within the memory limitations of the original 1K ZX81.
David Horne wasn't saving bytes to make his program smaller. He was doing it so he could have enough room to improve AI logic, for instance.
Nowadays there are several even smaller chess programs (I mentioned a few here at the time). They are all certainly impressive, but their AI is typically so bad they are not fun to play.
Your 3D chess will never be smaller than those existing 2D versions anyway. Therefore I see no point in just adding a simplistic AI to the code you already have. Instead, I suggest your goal should be achieving the BEST POSSIBLE chess game in exactly 1K. Which means supporting 100% of chess rules, and the smartest possible AI you can fit.
It seems both chesSkelet and David Horne's 1K chess play better than others. I would first play a few rounds between them to compare AIs, then use the best players as starting point to implement yours...
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
I agree regarding the 1k issue. I’ve exactly 513 bytes left to play with and intend using them all. Even when it gets to the point where it works well, if it’s left any spare space then I’ll unroll some of the key routines to get better speed. Some interesting tests were performed yesterday to try different methods of updating the display. Moving forwards from the tiny version, the game variant will require the board to be built in a buffer at C000h and then copied to the screen. This will give more fluid animation. I used block clear and copy routines that just update the 2 squares that are being swapped (piece moved from to etc). This gave much better results than straight full buffer copy and actually wasn’t much bigger to do. Once all of the shared routines are removed from the main display code then I think the result should still achieve good speed. Doesn’t sound fast but 2 frames per second is achievable. After all, Chess isn’t generally considered to be a fast game! Once these routines are all in, then I’ll re-integrate some of the GUI elements and optimise them.
Re: 3D Chess 2K18
Been reading your posts since the beginning because i found the optimisation interesting,did not understand it all but did enjoy reading.
Can't wait for a release so can play it and appreciate it.
Can't wait for a release so can play it and appreciate it.
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
One day, and hopefully it’ll live up to expectations!
As I’ve said before, if any aspect of the system or the mechanics of it is of particular interest and you want to know more, just ask. I’m always happy to expand upon anything. A good example is that when I posted the breakdown of the source here, I then spotted a few improvements. Sometimes examining or explaining a system in more detail bears fruit!
As I’ve said before, if any aspect of the system or the mechanics of it is of particular interest and you want to know more, just ask. I’m always happy to expand upon anything. A good example is that when I posted the breakdown of the source here, I then spotted a few improvements. Sometimes examining or explaining a system in more detail bears fruit!
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Some movement, in realtime;
I like the way it speeds up when there are fewer pieces on the board, like Space Invaders!
This isn't speed optimised in terms of the copy routines. Interestingly, because the original builds straight to the screen, and contention plays its part, building to a buffer, then copying to the screen hardly adds any extra time at all!
This is using a combined copy and clear routine thats fairly efficient. It copies a byte of the buffer to the screen and then writes a '00' to the buffer for when the board is build next.
Using the optimised block copy/clear routines is bigger and more complex, and actually not much faster. If space allows, this method could be unrolled to increase the speed a little more. Currently only uses 38 bytes.
I like the way it speeds up when there are fewer pieces on the board, like Space Invaders!
This isn't speed optimised in terms of the copy routines. Interestingly, because the original builds straight to the screen, and contention plays its part, building to a buffer, then copying to the screen hardly adds any extra time at all!
This is using a combined copy and clear routine thats fairly efficient. It copies a byte of the buffer to the screen and then writes a '00' to the buffer for when the board is build next.
Using the optimised block copy/clear routines is bigger and more complex, and actually not much faster. If space allows, this method could be unrolled to increase the speed a little more. Currently only uses 38 bytes.
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
In case anyones interested, below is the flexible Copy/ Clear routine. By just altering the number of LDD/ LD (BC),A instructions to fill a sensible amount of free space, the routine has the ability to speed up if there are free bytes still available. Nothing complicated. BC trails one byte behind whats being copied from the buffer to the screen, so it can be cleared afterwards.
Could be anywhere from 18 bytes up to a whopping 18447, which there would still be room for if I allowed buffering besides the screen too. I have some code that builds it to whatever length you choose, and thats only 27 bytes.
Code: Select all
copy_clear:
xor a
ld de,57ffh
ld hl,0d7ffh
ld bc,0d800h
cc_lp:
ldd
ld (bc),a
ldd
ld (bc),a
ldd
ld (bc),a
ldd
ld (bc),a
bit 6,h
jr nz,cc_lp
ret
Last edited by arkannoyed on Wed May 08, 2019 10:15 am, edited 1 time in total.
Re: 3D Chess 2K18
Oh nice, that's pretty clever. Great way to make use of the normally useless BC register during LDI/LDD copies.
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
I know, the BC register just gets wasted in most cases. Nice to make it work for a change. I actually tried the routine fully unrolled to 18k and its quite fast!
- arkannoyed
- Manic Miner
- Posts: 435
- Joined: Mon Feb 05, 2018 9:56 am
- Location: Northamptonshire
Re: 3D Chess 2K18
Well I guess I must've been inspired by Liverpools epic comeback last night. I have just saved a further...
7 bytes
Making my little beauty just 505 bytes!
Thats a 1.37% saving
Actually I spotted a stupid repetition and a way of sharing a byte in the graphics data. I can't recall saving a full 7 bytes in one go for a very long time
No graphics changes in appearance whatsoever. I guess that now brings it perilously close to another milestone of 500 bytes, though it might as well be 100 bytes away, as I don't know where I can save any more. I do find myself uttering those very words far too often though, and proving myself wrong again and again!
Graphics data is now just 210 bytes!
7 bytes
Making my little beauty just 505 bytes!
Thats a 1.37% saving
Actually I spotted a stupid repetition and a way of sharing a byte in the graphics data. I can't recall saving a full 7 bytes in one go for a very long time
No graphics changes in appearance whatsoever. I guess that now brings it perilously close to another milestone of 500 bytes, though it might as well be 100 bytes away, as I don't know where I can save any more. I do find myself uttering those very words far too often though, and proving myself wrong again and again!
Graphics data is now just 210 bytes!
Last edited by arkannoyed on Wed May 08, 2019 11:57 am, edited 1 time in total.