Chess

[NostAlgae37]

I think that yours still looks better.  j/k but it's not a fair comparison by any standard, what you've accomplished with the 2600's limited graphics capabilities is more impressive in my opinion.

[+D Train]

10 hours ago, Andrew Davie said:

TRS-80

Man, I had a TRS-80.  played a lot of scott adams adventure games and machine language graphics games by leo christpherson.

 

always wished I had progressed past basic but when I was 10, there wasn't really anyone around who could teach assembly.

 

good times.

[+Andrew Davie]

Back in the '80s when I wanted to convert graphics data into source code for assembling, I had to write a tool to grab the data from something like a .gif file, or a .psp file more likely. And that was usually written in C. That would be fine, but for the fact that I had no libraries to help me, so it was off to the library to find information about the file format. And then write some code to actually interpret/decode that format. And I had to get all that working before I could read a single pixel from the graphics data.  It was all very cumbersome and hard work. These days, particularly in Python which makes things sooooo easy... it's essentially a two-liner to get access to the pixels as an array.

So, the past few days when I've found the time, I've written the tool to grab the piece data from the graphics file and convert each of them into a stand-alone .asm file.  The concept is, by having a single .asm file for each piece, then I can assemble them easily in the code, and put them in different banks, wherever, without having to edit.  Now I've named the .asm files pretty intuitively, for example "WHITE_PAWN_on_BLACK_SQUARE_0.asm".  Now that last digit refers to the shifted position. Consider that the '2600 has 3 playfield bytes (PF0,PF1,PF2) and these are repeated across the screen. I've already determined that I only need to define shapes for one half because they will be the dame drawn on the other PF0-2 half. There are 4 squares in each half, so I define 4 shapes for each piece/square combination.  Each of those I decided to simply include ALL 20 bits and just shift the shape within those bits (according to the wonky '2600 playfield bit ordering).  So when I get to drawing the shapes, it will simply be 24 scanlines (8 ICC pixels) of load/or/store, using the correct shifted shape. The draw will modify all 3 of the PF bytes and I won't need to muck around with mid-line positions, shifting, masking, etc.  Should be well worth the trade-off in the slightly extra byte cost of the shape definitions. ROM space is not a concern to me at this point.

So, this does run and does produce seemingly OK-looking output. I am yet to test that, of course, but I can always come back and fix bugs. Well some of it looks dodgy but the fundamentals are there. Not far off, anyway. I'll whack a call to this in the makefile, so that whenever I change the "pieces.gif" file, I will automatically get changes in the appropriate piece displayed on the screen. I've attached the python code just to show how concise and easy to read it can be.

Whereas in the '80s I would have been looking at literally weeks of coding and thousands of lines of C-code to get a functional graphics-file-reading library and tool, today in Python I can do it in under a hundred lines of code (for the whole thing, output and all) and in just an hour or two of programming. That's how much easier it has become.

 

# ConvertChessPieces.py
# Andrew Davie andrew@taswegian.com

# This tool grabs chess piece definitions from a source image and converts to .asm source code
# The pieces are 5 pixels wide x 8 pixels deep.
# The source image is defined as (horizontally) blank / pawn / knight / bishop / rook / queen / king
# with the following structure:
# line 1: white pieces on black squares
# line 2: white pieces on white squares
# line 3: black pieces on black squares
# line 4: black pieces on white squares
# thus it's a 7 x 4 chessboard grid, with pieces on top
# The board is drawn with an 8-colour palette - colour 0 being black, and colours 1 2 and 4
# are the colours of three successive scanlines on the '2600. Groups of 3 scanlines form an
# 'interleaved chronocolour' (ICC) pixel.  This tool reads the pixel values and converts the palette
# colour into on/off pixels for three successive ICC sub-lines - forming the colour pixel.
# The upshot of this, you can't actually change the colours 3,5,6,7 - they are a result of mixing
# of colours 1, 2, 4
# The utility produces source .asm code in the form of 3 bytes per scanline x 24 scanlines per
# piece. The three bytes directly correspond to PF0 PF1 and PF2 on the '2600, so no shifting is
# required - they can be directly OR'd in to existing bitmap data for display.
# The shifting 'across' to put the piece in the correct horizontal square is done by the tool,
# but again, the shifting is within the 3 PF bytes, so it's just a direct OR'd in draw
# Piece definitions are written to individual files so that they can easily be located in
# multiple banks.

from PIL import Image
from enum import Enum

SQUARE_WIDTH = 5
SQUARE_HEIGHT = 8


class PieceColours(Enum):
    WHITE = 0
    BLACK = 1


class SquareColours(Enum):
    WHITE = 1
    BLACK = 0


class PieceTypes(Enum):
    BLANK = 0
    PAWN = 1
    KNIGHT = 2
    BISHOP = 3
    ROOK = 4
    QUEEN = 5
    KING = 6


pixel_no_to_bit_position = [
    1 << 20,
    1 << 21,
    1 << 22,
    1 << 23,

    1 << 15,
    1 << 14,
    1 << 13,
    1 << 12,
    1 << 11,
    1 << 10,
    1 << 9,
    1 << 8,

    1 << 0,
    1 << 1,
    1 << 2,
    1 << 3,
    1 << 4,
    1 << 5,
    1 << 6,
    1 << 7
]


def grab(pieces_bitmap, side_colour, square_colour, piece_type):

    y_start = (side_colour.value * 2 + square_colour.value) * SQUARE_HEIGHT
    x_start = piece_type.value * SQUARE_WIDTH

    for square_offset in range(0, 4):

        name = side_colour.name + "_" + piece_type.name + "_on_" + square_colour.name + "_SQUARE_" + str(square_offset)
        f = open(name + '.asm', 'w')
        f.write(name + "\n")

        for y_bitmap in range(0, SQUARE_HEIGHT):

            icc_scanline = [0, 0, 0]

            for x_bitmap in range(0, SQUARE_WIDTH):

                pixel_icc_colour = pieces_bitmap[x_start + x_bitmap, y_start + y_bitmap]
                x_pf_pixel = x_bitmap + square_offset * SQUARE_WIDTH

                if (pixel_icc_colour & 4) != 0:
                    icc_scanline[0] |= pixel_no_to_bit_position[x_pf_pixel]
                if (pixel_icc_colour & 2) != 0:
                    icc_scanline[1] |= pixel_no_to_bit_position[x_pf_pixel]
                if (pixel_icc_colour & 1) != 0:
                    icc_scanline[2] |= pixel_no_to_bit_position[x_pf_pixel]

            # Now output the three scanlines' playfield bytes
            # we are not worrying about minimising ROM here - just 3 bytes/definition

            for scanline in range(0, 3):

                pf0 = (icc_scanline[scanline] >> 16) & 0xFF
                pf1 = (icc_scanline[scanline] >> 8) & 0xFF
                pf2 = (icc_scanline[scanline]) & 0xFF

                f.write(" .byte " + str(pf0) + ", " + str(pf1) + ", " + str(pf2) + "\n")

        f.close()


im = Image.open("pieces.gif")
pix = im.load()

for side in PieceColours:
    for square in SquareColours:
        for piece in PieceTypes:
            grab(pix, side, square, piece)

Next, I might start on including these output graphics .asm files and starting to draw them individually on the screen to see how they look.

 

 

 

ConvertChessPieces.py

Edited December 16, 2019 by Andrew Davie
forgot the rook

[iesposta]

I think I would draw the pawns with a double line base and a single line at the top. (But that’s just me.)

||-|•

 

I like your display a lot. I can recognize each piece easily. 

 

I can’t wait to try it out displayed from my Heavy Sixer RF on a CRT Tv. 

[+Random Terrain]

I'm new to the thread. When I look at the old Atari version, I can instantly recognize the pieces. I can't do that with your version (the pieces kind of look like wild mushrooms to me).

[+Andrew Davie]

3 hours ago, Random Terrain said:

I'm new to the thread. When I look at the old Atari version, I can instantly recognize the pieces. I can't do that with your version (the pieces kind of look like wild mushrooms to me).

Interesting how some like it, think it works, and some hate it. Like many Atari games, looks better the smaller the screen you view on. Thanks for your feedback.

 

[+Nathan Strum]

5 hours ago, Andrew Davie said:

Interesting how some like it, think it works, and some hate it. Like many Atari games, looks better the smaller the screen you view on. Thanks for your feedback.

Looks great here!

 

[+Andrew Davie]

1 hour ago, Nathan Strum said:

Looks great here!

 

 

Thanks. Proves my point, I think.

Either you use a mini TV or sit about 20 m from your big one.

 

[Keatah]

Space 1999!

[+Andrew Davie]

Brazil (the movie)...

[+Nathan Strum]

4 hours ago, Keatah said:

Space 1999!

Yep! The giveaway is that my fingernails aren't that long.  

 

Weird to think that Space 1999 "happened" 20 years ago.

 

Anyway - back to the topic at hand. I bought a 9" Sharp TV back in '82 and did most of my 2600 and 7800 gaming on it for many years. Everything looked great on it, and I'd still use it if the picture tube weren't starting to go. I'd love to get it fixed, but I don't know if it's even possible (and probably not worth the expense, save for the nostalgia of it). We still have a ton of old production CRTs at work, so I could always pick up a used one there if I wanted one badly enough. Mostly Sony PVM-14M2U's. Perfect for the 2600.

[NostAlgae37]

On ‎12‎/‎16‎/‎2019 at 8:06 PM, iesposta said:

I think I would draw the pawns with a double line base and a single line at the top. (But that’s just me.)

Hmm, I wonder if that is worth trying out, just to see if it looks better or worse.    I know that when I make sprites, I go through several iterations until I settle upon what I think looks most harmonious to the eyes (one pixel here or there is particularly impactful at these extremely low resolutions).

[+Andrew Davie]

On 12/17/2019 at 11:06 AM, iesposta said:

I think I would draw the pawns with a double line base and a single line at the top. (But that’s just me.)

||-|•

 

I like your display a lot. I can recognize each piece easily. 

 

I can’t wait to try it out displayed from my Heavy Sixer RF on a CRT Tv. 

Here's a test of your suggestion. The pawns above queen and king are thus drawn.

[+Andrew Davie]

Another completely different pawn... new above queen/king, old above the bishops.

[+Random Terrain]

29 minutes ago, Andrew Davie said:

Another completely different pawn... new above queen/king, old above the bishops.

 

That's the best one.

[NostAlgae37]

23 hours ago, Andrew Davie said:

Here's a test of your suggestion. The pawns above queen and king are thus drawn.

I'm a bit torn about this one...  I think that the new ones in the middle look better and less like barbells, but it does make the pawns have a significantly higher base than the other pieces on the board.  Also, the right side of the cap of the pawn above the king blends in with the board square that it is overlaid upon.

[+nanochess]

Hi Andrew.

 

Interesting looking board. Feel free to use the code of my chess engine Atomchess-6502 for your project if you like:

 

https://github.com/nanochess/Atomchess-6502

https://github.com/nanochess/Atomchess-6502/blob/master/toledo_atomchess_6502.asm

 

It would need some adaptation to keep drawing the screen while doing calculations. Currently it simply ceases to update display whenever the chess engine is working.

[+Andrew Davie]

1 hour ago, nanochess said:

Hi Andrew.

 

Interesting looking board. Feel free to use the code of my chess engine Atomchess-6502 for your project if you like:

 

https://github.com/nanochess/Atomchess-6502

https://github.com/nanochess/Atomchess-6502/blob/master/toledo_atomchess_6502.asm

 

It would need some adaptation to keep drawing the screen while doing calculations. Currently it simply ceases to update display whenever the chess engine is working.

 

Thank you. I'm quite tempted.
Actually I'm thinking it would be cool to have 3 options...
1) 6502 chess. In other words, a "pure" version that could have run in the 1980s.
2) ARM chess, running on the arm coprocessor
3) stockfish chess, running on PlusCart - sending moves to a chess engine running online.

[Keatah]

I personally like options 1 and/or 2. I'm not excited about 3 because of the fleeting nature of such things. Online stuff can go away at any time or be changed enough to become unworkable.

 

The VCS had some staying power as far as consoles go because it doesn't depend on anything online. In another sense, "things online" like AA and new development efforts conducted through forums HAVE enhanced its staying power.

 

 

 

[R. Jones]

On 12/23/2019 at 3:57 PM, NostAlgae37 said:

I'm a bit torn about this one...  I think that the new ones in the middle look better and less like barbells, but it does make the pawns have a significantly higher base than the other pieces on the board.  Also, the right side of the cap of the pawn above the king blends in with the board square that it is overlaid upon.

^ And that would absolutely kill the suspension of disbelief, just ruin the realism ?

 

It's always really dope to see strange visuals on the 2600. There's a kind of default hieroglyphic style that even a lot of nice-looking games will lapse into.

 

I'm also thinking that my console's fuzzy output will probably blur those lines together somewhat, so I might not have to sit so far away to get the effect to click.

[+Karl G]

I like the newer pawns, too. They are definitely more visually distinct from the other pieces. 

[+Karl G]

On 12/23/2019 at 7:00 PM, Andrew Davie said:

Actually I'm thinking it would be cool to have 3 options...
1) 6502 chess. In other words, a "pure" version that could have run in the 1980s.
2) ARM chess, running on the arm coprocessor
3) stockfish chess, running on PlusCart - sending moves to a chess engine running online.

I'm personally interested in options 1 and 3, but with 3 being the possibility of running against a human opponent rather than an AI. In reality, I would be happy with just option 1. 

 

I certainly don't have anything against ARM games, and I enjoy a number of them, but if you are going to go that route, why not also take advantage of the ARM to enhance the display? Right now you have a nice engine that pushes the limits of the original hardware, so I think it would be more fitting to have the chess engine also be 6502 code. 

[mos6507]

Just stumbled on this thread.

 

I'm not a big fan of the fringe effect on the right hand side.  I know it's an attempt at doing fake shading and to create more of a boundary between pieces but with only 5 wide pixels to work with it doesn't really sell the effect.  This is especially true with pawns and rooks that look asymmetrical this way.

 

If you went with evenly shaded pieces could you possibly use 1-pixel wide sprites colored blue to paint over the sprites and hence create a border?  Can you get enough sprite copies to draw?

 

 

[+Andrew Davie]

Here's the first released binary of the chessboard display.

Rather than a mockup, as shown earlier - which was basically just a static title-screen and a lot of screenshots... this binary is building the board piece by piece, square by square running on the 2600. So, given any chessboard definition, in the appropriate "Chessboard" variable/array, then it will draw the pieces properly. All the piece graphics are included. It's not far now from having (say) a simple joystick move-piece routine in there.  There are a few glitches on the right side of the screen, but overall it's pretty clean.
I'm including all the source code and utilities and source graphics so anyone who wants to have a play with things, or just to have a look at how it's done... can do so.

This is an NTSC-only binary.

chess_20200111.zip chess_20200111.bin

[+Andrew Davie]

On 1/4/2020 at 4:39 AM, mos6507 said:

If you went with evenly shaded pieces could you possibly use 1-pixel wide sprites colored blue to paint over the sprites and hence create a border?  Can you get enough sprite copies to draw?

Well, never say never. But... not on my dolist at the moment. Perhaps someone else can have a go.