3D Chess 2K18

The place for codemasters or beginners to talk about programming any language for the Spectrum.
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

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

Re: 3D Chess 2K18

Post by arkannoyed »

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.

Image

See, the graphics have remained very true to the original designs.
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 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.

Image
User avatar
ZXDunny
Manic Miner
Posts: 498
Joined: Tue Nov 14, 2017 3:45 pm

Re: 3D Chess 2K18

Post by ZXDunny »

How much RAM does your current 512b version take up at runtime?
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

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

Re: 3D Chess 2K18

Post by arkannoyed »

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

Re: 3D Chess 2K18

Post by arkannoyed »

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.
reeagbo
Dizzy
Posts: 61
Joined: Mon Apr 29, 2019 9:11 am

Re: 3D Chess 2K18

Post by reeagbo »

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
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.

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
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 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.
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 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.
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: Fri May 03, 2019 8:37 amI don't understand entirely what its doing?
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?
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

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.
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: 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 know.

I was suggesting DEFB for chesSkelet only, since it doesn't clear the board and it's not replayable.
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

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.
llewelyn
Manic Miner
Posts: 205
Joined: Thu Feb 22, 2018 3:27 pm
Location: virginias eastern shore
Contact:

Re: 3D Chess 2K18

Post by llewelyn »

[/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)
User avatar
ZXDunny
Manic Miner
Posts: 498
Joined: Tue Nov 14, 2017 3:45 pm

Re: 3D Chess 2K18

Post by ZXDunny »

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)
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.

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.
User avatar
Einar Saukas
Bugaboo
Posts: 3070
Joined: Wed Nov 15, 2017 2:48 pm

Re: 3D Chess 2K18

Post by Einar Saukas »

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...
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 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.
DarkTrancer

Re: 3D Chess 2K18

Post by DarkTrancer »

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

Re: 3D Chess 2K18

Post by arkannoyed »

Some movement, in realtime;

Image

I like the way it speeds up when there are fewer pieces on the board, like Space Invaders! :D

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

Re: 3D Chess 2K18

Post by arkannoyed »

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.

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
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.
Last edited by arkannoyed on Wed May 08, 2019 10:15 am, edited 1 time in total.
User avatar
djnzx48
Manic Miner
Posts: 729
Joined: Wed Dec 06, 2017 2:13 am
Location: New Zealand

Re: 3D Chess 2K18

Post by djnzx48 »

Oh nice, that's pretty clever. Great way to make use of the normally useless BC register during LDI/LDD copies.
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 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!
User avatar
arkannoyed
Manic Miner
Posts: 435
Joined: Mon Feb 05, 2018 9:56 am
Location: Northamptonshire

Re: 3D Chess 2K18

Post by arkannoyed »

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 :lol:

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.
Post Reply