Pac man video game drawing2/27/2024 ![]() …versus just reading a decimal value… READ V But reading those would require some extra code which might negate the savings: READ A$:V=VAL("&H"+A$) …which gives us 11 bytes, matching the two decimal values. ![]() Hex values could be written as a string without the &H, and that could be added by the READ routine: 1000 DATA FF,FF,FF,F0 Even worse when 1 has to be three times larger as &H1. That gets us down to 12 bytes so it looks like needing that &H at the start loses out - 65535 versus &HFFFF. Doubling up to 16 bit values results in: 1000 DATA &HFFFF,&HFFF0 While that would be better than ASCII, it would be worse than two decimal values. The 4K CoCo BASIC did not have hexadecimal numbers, but on Extended BASIC machines we could convert to HEX: 1000 DATA &HFF,&HFF,&HFF,&HF0 That brings us down to 11 bytes to represent the 28 block row. I suppose we could use numbers representing 16-bit values (0-65535) and have only two numbers to represent that line: 1000 DATA 65535,65520 The storage space for “255,255,255,240” is 15 bytes which is less than the 28 string characters (plus quotes, if needed - like if the line started with spaces or had special characters in it like a comma or ‘ REM abbreviation, which this won’t). In a DATA statement with numbers, the top row would look like: 1000 DATA 255,255,255,240 Each number could represent a byte (0-255) and each byte contains 8 bits, therefore each number could represent 8 character blocks. If we tried to use numeric DATA statements to represent the screen blocks, it would be 4 times longer since every entry would be a three digit number with a comma: DATA 175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175,175īut, if we were just using blocks and spaces, we could have a number represent eight of them. Here’s the ASCII DATA: 1000 DATA "XXXXXXXXXXXXXXXXXXXXXXXXXXXX" (The highest resolution graphics screen on a CoCo 1/2 takes up 6144 bytes, compared to the 512 bytes of the text screen.) Imagine trying to do that on a 4K Color Computer or a 5K Commodore VIC-20. But storing 28 x 26 characters is 1008 bytes of memory. This would make creating new mazes and levels as easy as typing. The maze data could be represented as ASCII strings, either directly PRINTed on the screen, or read from DATA statements to be PRINTed or POKEd: Pac-Maze DATA statements. That’s more better, but it looks more reminiscent of blocky Atari VCS games like Adventure.īy taking advantage of the 64×32 resolution semigraphics, the corners could be at least “rounded” a bit (if round meant “still square”), and the centers of the areas could be opened up like the arcade original: Pac-Man maze in 64×32 semigraphics.Īt this resolution, I’m not sure if we can really do any better than that -) The background could at least be made black: Pac-Man maze in 32×16 with black background. Using CHR$(175) for a blue block looks like this: Pac-Man maze in 32×16. There are elements of Pac-Man that couldn’t really be recreated with this low resolution (such as the way Pac can hug to corners to go around them faster), but at least the maze layout could be accurate.īut ASCII is ugly, so we’d probably want to use the semigraphics characters (128-255). Though it wouldn’t look like the arcade, this is an accurate representation of the 28×36 tiles of the original game (well, 28×16 seen any any time). I also removed the top and bottom rows that showed score and such, so this will be using only 31 of the games original 36 rows.Ī portion displayed in ASCII text would look like this: Pac-Man maze in ASCII (Pac-Man used a monitor mounted sideways to get this aspect ratio.) My solution was to scroll the maze up and down. With the CoCo 1/2s text screen being 32×16, this means we could fit 28 tiles horizontally with room to space, but we’d be 20 tiles short vertically. In the arcade original, each tile is 8×8 pixels. But basically, the game screen is a grid of 28 x 36 tiles. And you can learn a ton about how the game works on the Pac-Man Dosier website.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |