Chess

[+Andrew Davie]

Last update for a while.

I took a break from the AI stuff and did a bit of housekeeping in the UI.

In particular, the light-coloured marker to show where a piece comes from - used to be placed on the square before the piece to move started flashing. I now place it after the piece has finished flashing and started moving. I like the change a lot - it's quite subtle sometimes, you don't even realise it's being put on the board, and it makes the flashing piece much easier to see - more contrast.

The second change was to slow down the animation of the pieces moving so that the "snail trail" is more evident. I like this, too.

Short video showing piece movement with these two changes... stella@100%

 

[Gray Defender]

It's the subtle details that make all the difference.  When I look back at Video Chess, it looks primitive compared to what you have here.  Great job!

[Keatah]

I have one tiny suggestion. And it's like a personal preference. I want to see the "possible-move" dots made smaller. Maybe by about half or so. For better visibility and contrast in busy areas of the board.

[AW127]

14 hours ago, Andrew Davie said:

Last update for a while.

I took a break from the AI stuff and did a bit of housekeeping in the UI.

In particular, the light-coloured marker to show where a piece comes from - used to be placed on the square before the piece to move started flashing. I now place it after the piece has finished flashing and started moving. I like the change a lot - it's quite subtle sometimes, you don't even realise it's being put on the board, and it makes the flashing piece much easier to see - more contrast.

The second change was to slow down the animation of the pieces moving so that the "snail trail" is more evident. I like this, too.

 

 

Great. I like these two changes too. And thanks for returning to normal squares for the playing-field so quickly, it improves the overview alot.

Edited May 15, 2020 by AW127

[+Andrew Davie]

Quote

“And hast thou slain the Jabberwock?
Come to my arms, my beamish boy!
O frabjous day! Callooh! Callay!”
He chortled in his joy.

 

OK, I found the bug. I never would have found it, ever, searching for it.

I just decided to go through the code in its entirety and make sure everything looked efficient, and I found a tiny optimisation that became invalid when I switched to 3E+.  In particular here it the culprit...

 

    ;   adjust the positional value  (originX12 --> fromX12)

                    ldy toX12                      ; already loaded
                    lda fromPiece
                    jsr AddPiecePositionValue       ; add pos value for new position

That line commented "already loaded" was disabled, because the code before it had the correct value in the y -register.

That code happened to move elsewhere during the conversion - and... there you go.

 

Anyway, I think it's OK now. I've been a bit fearful to play it at higher levels... it's always beating me.  
So, I know I said "last update for a while" but I've been struggling with this one for sooo long, happy to do a release version to see if I have indeed squashed the bug. 3PQ6, 4PQ6 and 5PQ6 attached.

Also, some updated stats on the speedup, now that it appears to be playing properly.

 

P-K4.  124032 vs 97417 (speedup 27%)

P-Q4.  123413 vs 56475 (speedup 118%)

P-KR4. 141036 vs 107457 (speedup 31%)

 

Average speedup 59%.  These figures seem ballpark/consistent with earlier measurements, but now that quiescence is working and the game is playing reasonable moves I'm much more confident that these are good.  So, much faster.  In any case, the timings are inconsequential. The switchover from 3E to 3E+ now appears to be working. And now the fun begins. I have space to do stuff. That stuff is going to make the game much faster, and much much stronger.

 

Remember: I still have that crash on pawn promotion so don't be surprised.

 

 

 

 

chess3E+20200515_5PQ6.bin chess3E+20200515_4PQ6.bin chess3E+20200515_3PQ6.bin

[+Andrew Davie]

19 hours ago, Keatah said:

I have one tiny suggestion. And it's like a personal preference. I want to see the "possible-move" dots made smaller. Maybe by about half or so. For better visibility and contrast in busy areas of the board.

I've been through lots of variations. The dots are 3 pixels wide. To make them smaller and keep them centered, then next option is one pixel. I've put the one-pixel version in the latest binary just for you to see what it looks like.

[Keatah]

After a side by side comparison and more thought I found I liked the original larger "penny-sized & shaped" dots better.

 

The larger size seems more homogeneous and in-style with the rest of the pieces and board color. The smaller single-pixel dots turned out to be a little harsh.

[AW127]

"Andrew", one thing i wanted to suggest, but i don't know if possible, because of the shapes from the chess-figures.

 

Some of those figures are as wide as the square, on which they stand and this then means, that those figures, when standing on two adjacent squares, then also touch each others on the outside. This is not 100 percent ideal in my opinion, but it's also clear, why the figures are that big, cause the Atari-2600 has not a high resolution and to make figures look good, then needs some space.

 

But nevertheless i wanted to ask - would it be possible, to make those of the figures, which are as wide as the square, two pixels smaller in the wide, that there would be one pixel free on each side? It must be searched for those two pixels in the line then, which could be deleted best, that the shape of a figure still is recognisable. Could be a problem, i know. Especially when on pixel is as big as this

 

 

I guess this is one pixel, right? Then it's really problematic to make the figures smaller.

 

Tried around in a painting-program a little bit and it's not easy to delete two pixels and still let the whole shape of a figure still look good, while on the other side, it is definately good for the whole overview, when figures don't touch each other. So it would be a compromise, cause then maybe some figures looks not as good as now. What you think? Or is then the whole shape of those figures are not really identifiable anymore, in your opinion?

 

 

And a second thing i wanted to ask. Yesterday i played a match against your program and it was noticable to me, that, when the program makes a move, after this move, the moved enemy-figure blinks as long as i touch the controller and steer in a direction one time. Then these blinking ends. I could not find out the sense of these long-time blinking and why i, as the human player, must steer one time in a direction after every move, to stop this blinking of the enemy-figure. Is the thing with this blinking meant to be this way and if yes, where is the sense of it? When a human player thinks about his next move, a blinking enemy-chessfigure can disturb a little bit, therefore the human player now must steer two times after every move. First one time to stop the blinking of the enemy-figure, which was last moved and the second time later, to make the own move. But why? Should the blinking not stop by itself, after the program had made a move, without that the human player must steer in one direction every time?

 

 

Edited May 15, 2020 by AW127

[+Andrew Davie]

36 minutes ago, AW127 said:

Some of those figures are as wide as the square, on which they stand and this then means, that those figures, when standing on two adjacent squares, then also touch each others on the outside. This is not 100 percent ideal in my opinion, but it's also clear, why the figures are that big, cause the Atari-2600 has not a high resolution and to make figures look good, then needs some space.

In fact, resolution is so low that there are only 5 pixels width for each piece. Just 5.  Here is an expanded view of all the piece shapes...

 

 

There's not a lot to play with there, in terms of reducing width. I think it's remarkably good already, given the constraints.

 

36 minutes ago, AW127 said:

But nevertheless i wanted to ask - would it be possible, to make those of the figures, which are as wide as the square, two pixels smaller in the wide, that there would be one pixel free on each side?

From the above, clearly... no. One pixel free on each side would make the pieces just 3 pixels wide, with 2-pixel gaps between pieces.

I'm not even going to try drawing 3-pixel wide pieces

 

36 minutes ago, AW127 said:

Tried around in a painting-program a little bit and it's not easy to delete two pixels and still let the whole shape of a figure still look good, while on the other side, it is definately good for the whole overview, when figures don't touch each other. So it would be a compromise, cause then maybe some figures looks not as good as now. What you think? Or is then the whole shape of those figures are not really identifiable anymore, in your opinion?

Not identifyable. And later in the game, anyway, the pieces are not all aligned side by side so there are generally blank squares beside many pieces. And in the opening position you generally know what's what anyway.

 

36 minutes ago, AW127 said:

 

And a second thing i wanted to ask. Yesterday i played a match against your program and it was noticable to me, that, when the program makes a move, after this move, the moved enemy-figure blinks as long as i touch the controller and steer in a direction one time. Then these blinking ends. I could not find out the sense of these long-time blinking and why i, as the human player, must steer one time in a direction after every move, to stop this blinking of the enemy-figure. Is the thing with this blinking meant to be this way and if yes, where is the sense of it? When a human player thinks about his next move, a blinking enemy-chessfigure can disturb a little bit, therefore the human player now must steer two times after every move. First one time to stop the blinking of the enemy-figure, which was last moved and the second time later, to make the own move. But why? Should the blinking not stop by itself, after the program had made a move, without that the human player must steer in one direction every time?

 

This "double tap" is intentional, and how I think it should work.

The reasoning is that if you go away and come back - how do you know what the computer has done?  The light coloured "from" square and the blinking piece clearly show the move. I don't think it's too much to ask the player to push a direction if she wants to stop the blinking.

 

 

[Mr SQL]

@Al_Nafuur how can I update the Uno Cart for the new BS scheme or get it to auto-recognize, like you were able to do with the wireless version of the cart? 

[+Al_Nafuur]

4 minutes ago, Mr SQL said:

@Al_Nafuur how can I update the Uno Cart for the new BS scheme or get it to auto-recognize, like you were able to do with the wireless version of the cart? 

you have to put the emulate_3EPlus_cartridge function into the UnoCart main.c file and put some <<8 and >>8 to the DATA_OUT and DATA_IN values, because the UnoCart uses the upper part of the GPIO port and the PlusCart uses the lower, so i could get rid of these shifts. To see how this is done by the UnoCart take a look at the other emulate_XXX_cartridge functions.

 

You also need the detection function in UnoCarts main.c:
https://gitlab.com/firmaplus/atari-2600-pluscart/-/blob/master/source/STM32firmware/PlusCart/Src/cartridge_detection.c#L145

 

then you need to copy the call to the detection in "identify_cartridge" and the call to the emulate_3EPlus_cartridge function in "emulate_cartridge" (all in main.c of PlusCart and UnoCart).

 

then compile and flash the UnoCart and it should work..

good luck

 

 

 

[+Andrew Davie]

I was looking at draw by repetition. I thought it would be a tough thing to program. Particularly because I thought the rule was that if you have three repetitions of the same moves, then it's a draw. But in fact the rule is slightly different to that.  "a player can claim a draw if the same position occurs three times, or will occur after their next move, with the same player to move. The repeated positions do not need to occur in succession."  What's really interesting about this is that there can be any number of different positions between each - the rule is purely based on the board position being the same (with same player to move, and same en-passant and castling rights for both sides).

Most older chess engines do not implement this rule, AFAIK.

 

But think about it - if I could create a reliable hash on the board position + whose turn it is + en-passant flag + castling rights, say a 32 bit value (which is well documented in examples of opening book lookups, for example - there was a fascinating one I read about recently)... well anyway, then I'd just need a list of the hash positions for the whole game, and I could scan (backwards, from the current move/position) and look for a triplicate of the current position hash. It wouldn't be too onerous.

Now, the fascinating hashing function... it is called "Zobrist hashing" and is really quite interesting... https://en.wikipedia.org/wiki/Zobrist_hashing

 

[+Andrew Davie]

I have posted a request in the UnoCart thread requesting an update to support 3E+

 

[+Al_Nafuur]

8 minutes ago, Andrew Davie said:

I have posted a request in the UnoCart thread requesting an update to support 3E+

 

I have already send a PM to @DirtyHairy with detailed information for the 3E+ implementation on the UnoCart, unfortunately he is currently very busy. I don't have a UnoCart to test the changes, but it's just a copy/paste job, so maybe a pull request, from someone who also tested the new BS on the UnoCart, will help him.

[NostAlgae37]

3 hours ago, AW127 said:

 

 

I guess this is one pixel, right? Then it's really problematic to make the figures smaller.

 

Tried around in a painting-program a little bit and it's not easy to delete two pixels and still let the whole shape of a figure still look good, while on the other side, it is definately good for the whole overview, when figures don't touch each other. So it would be a compromise, cause then maybe some figures looks not as good as now. What you think? Or is then the whole shape of those figures are not really identifiable anymore, in your opinion?

 

I think that Andrew's reply to your question was sufficient, but I just wanted to point out that the offending piece that was bothering you has already been redesigned to be less vexatious in the manner that you described.  The screenshot that you posted was from an outdated version of the rom, the current version has the white pawns looking nearly identical in their design to the "black" pawns so that there is more uniformity in the shape of the pieces.  This was intentional and I hope that you like the way that they look better now. 

[+Andrew Davie]

52 minutes ago, NostAlgae37 said:

I think that Andrew's reply to your question was sufficient, but I just wanted to point out that the offending piece that was bothering you has already been redesigned to be less vexatious in the manner that you described.  The screenshot that you posted was from an outdated version of the rom, the current version has the white pawns looking nearly identical in their design to the "black" pawns so that there is more uniformity in the shape of the pieces.  This was intentional and I hope that you like the way that they look better now. 

 

I think he was using the top of the pawn as an indicator of "a single pixel" rather than being bothered by the shape of the pawn. He specifically mentioned the edges of the pieces touching each other. In any case, no guarantee that the pawns will be uniform in shape. They are really really difficult to distinguish sometimes and I still feel that a visible difference, other than colour, may be needed.

Edited May 16, 2020 by Andrew Davie

[AW127]

4 hours ago, Andrew Davie said:

In fact, resolution is so low that there are only 5 pixels width for each piece. Just 5.  Here is an expanded view of all the piece shapes...

There's not a lot to play with there

 

Yes, that's true. Then really one pixel is as big as i showed it in my posted screenshot and then nothing can be done here, to have a space between some figures, cause when only 5 pixels possible in the width, there is no chance deleting two and still have a good shape for a figure. Okay, then this point is clear and we must live with it. It's tolerable, because like you said, later in the game, the figures are spread over the field and then it's not a real "problem" anymore.

 

4 hours ago, Andrew Davie said:

This "double tap" is intentional, and how I think it should work.

The reasoning is that if you go away and come back - how do you know what the computer has done?  The light coloured "from" square and the blinking piece clearly show the move. I don't think it's too much to ask the player to push a direction if she wants to stop the blinking.

 

Aaaah, good point.    I had not thought about something like that, which especially makes sense, when playing a chess game on the real console, because an emulator can be speeded-up to warp-mode, but on the real console this is not possible and then waiting times can be really long. And enough space for showing the last move in letters is also not on the screen, therefore, it makes definately sense like you solved it. Good idea actually, when i now think about it, that players maybe leave the screen.

 

 

"NostAlgae37N", it's exactly like "Andrew" wrote here

1 hour ago, Andrew Davie said:

 

I think he was using the top of the pawn as an indicator of "a single pixel" rather than being bothered by the shape of the pawn. He specifically mentioned the edges of the pieces touching each other. In any case, no guarantee that the pawns will be uniform in shape. They are really really difficult to distinguish sometimes and I still feel that a visible difference, other than colour, may be needed.

I just used that screenshot, for asking, if one pixel really is that big in that used resolution. Just coincidence, that i took exactly this pixel. 

Edited May 16, 2020 by AW127

[Mr SQL]

2 hours ago, Andrew Davie said:

I have posted a request in the UnoCart thread requesting an update to support 3E+

 

 

2 hours ago, Al_Nafuur said:

I have already send a PM to @DirtyHairy with detailed information for the 3E+ implementation on the UnoCart, unfortunately he is currently very busy. I don't have a UnoCart to test the changes, but it's just a copy/paste job, so maybe a pull request, from someone who also tested the new BS on the UnoCart, will help him.

Thanks guys I'm looking forward to playing this on the real hardware again!

 

Al thanks for the low level merge instructions, hoping there will be a new Uno BIOS released presently so I don't have to do the rebuild.

[+Al_Nafuur]

11 hours ago, Mr SQL said:

 

Thanks guys I'm looking forward to playing this on the real hardware again!

 

Al thanks for the low level merge instructions, hoping there will be a new Uno BIOS released presently so I don't have to do the rebuild.

v14 in my UnoCart fork with 3E+, for those who dare:

https://github.com/Al-Nafuur/UnoCart-2600/releases

 

Because i don't have an UnoCart, not tested on real hardware and without any warranty!!! So only try, if you know how to reflash v13 with ST-Link

[DirtyHairy]

3 hours ago, Al_Nafuur said:

v14 in my UnoCart fork with 3E+, for those who dare:

https://github.com/Al-Nafuur/UnoCart-2600/releases

 

Because i don't have an UnoCart, not tested on real hardware and without any warranty!!! So only try, if you know how to reflash v13 with ST-Link

Awesome! Just open a pull request, I'll check whether it works correctly and do a flashable build.

[NostAlgae37]

16 hours ago, Andrew Davie said:

 

I think he was using the top of the pawn as an indicator of "a single pixel" rather than being bothered by the shape of the pawn. He specifically mentioned the edges of the pieces touching each other.

 

Oh I see, but did he mean all of the higher level pieces (which touch each other at the sides when they are next to one another), or was he pointing out how the top of the bishop's hat protrudes (or at least appears to) beyond the confines of the lined space that it occupies into the black one above?  (You can see this clearly with the bottom left white bishop in the screenshot that he supplied.)  Because it might be possible to shorten the bishop by 1 pixel, but I think that the result would look considerably worse.

 

As for the new pawn design, I'd be curious to see how both colors look on a CRT before deciding whether to scrap it or not.  Maybe someone here can take a photo of their TV screen while running one of the 20200515 releases?  Thanks in advance to anyone who is willing or able. 

 

[+Al_Nafuur]

33 minutes ago, DirtyHairy said:

Awesome! Just open a pull request, I'll check whether it works correctly and do a flashable build.

pull request (for master branch ? ) send

[AW127]

3 hours ago, NostAlgae37 said:

Oh I see, but did he mean all of the higher level pieces (which touch each other at the sides when they are next to one another), or was he pointing out how the top of the bishop's hat protrudes (or at least appears to) beyond the confines of the lined space that it occupies into the black one above?

 

I meant it in the way, that those chess-figures which are as wide as the square on which they stand, the pixels then touch each other, when on the square besides, also such a broad figure stands. Look here the marked areas:

 

 

But as we know now, there can be done nothing, because we only have 5 pixels width for each piece.

 

Later in the game fortunately, when all the figures are spread over the playing-field, it's not a real problem anymore, because then such figures don't stand side by side often. Therefore it is tolerable and better than making the figures smaller, because then some of them would look stupid with only 3 possible pixels in the broad. For the pawns this work, but for the other figures this definitely would cause problems and would let some of them look stupid then, i guess.

[+Karl G]

Unlike video chess, this uses the whole screen with no flicker, so I think it's well worth the trade-off of the chunky pixels. 

[AW127]

2 minutes ago, Karl G said:

Unlike video chess, this uses the whole board with no flicker, so I think it's well worth the trade-off of the chunky pixels. 

Yes, i definately also prefer the look of this chess here over the look in video chess.