_4.png.be8cfcfa6293fa37fd3b7886fe82e2da.png)
THREE∙S (was: 2^11 (2048))
Entry posted by Thomas Jentzsch
6,562 views
Getting first aware of the new hype around 2048 by this link, I started playing the game and immediately found myself wasting my time.
Since it is obvious that the 2600 could pretty easily support this game, I soon started wonder how it could be presented on the Atari. There are little bells and whistles to the game. Besides some nice animation effects when moving and merging the numbers, there are only colors. For me these colors, combined with the very reduced and clean graphics and fonts define the look of the game.
The arrangement of the numbers was pretty easy. Both NUSIZx registers are set to %010101 (three copies med, double width missiles). The missiles are used to draw the vertical gaps between the numbers (and 1 pixel left and right). Since the numbers are drawn in black, the third copy is not visible (except for a 1 pixel black line at the very right).
Then came the colors. Originally those should only come from the playfield. Since there are only 2 pixel gaps between the different number background colors, the color writes have to be timed precisely.
This lead to a problem. Not only the colors but also the player graphics have to be updated within very little time. I decided to VDEL player 0, which means that I can preload the first 3 number graphics before getting into the timing critical section. There I only have to write once to GRP1.
Still this did not work. After displaying the 2nd number I would have had to write to COLUBK and GRP1 within too little time. The COLUBK write had to happen at an exact cycle in the middle between number 2 and 3. So the write to GRP1 had to be done either before this write or after it. And there are only 1-2 cycles.
To overcome this problem, now the background color is used too (for the 3rd number)! This allows me to write to COLUBK while still displaying the 2nd number. So that I have enough time for the GRP1 write now. The critical timing requires some inefficient code, so the kernel is now running at exactly 76 cycles (75 required) without WSYNC.
Here is the code for it:
ldy #DIGIT_H-1 ; 2.loopDigit: sty.w .tmpY ; 4 = 4 @73;--------------------------------------- lda (ptrGRP0a),y ; 5 sta GRP0 ; 3 lda (ptrGRP1a),y ; 5 sta GRP1 ; 3 lda (ptrGRP0b),y ; 5 sta GRP0 ; 3 lax (ptrGRP1b),y ; 5 = 29 lda colLst+0 ; 3 ldy colLst+2 ; 3 sta COLUPF ; 3 (>=@34) lda colLst+1 ; 3 sty COLUBK ; 3 (<=@50) sta COLUPF ; 3 @44 (@44!) lda colLst+3 ; 3 stx GRP1 ; 3 sta COLUPF ; 3 = 27 (<=@55) lda #0 ; 2 sta COLUBK ; 3 sta COLUPF ; 3 ldy .tmpY ; 3 dey ; 2 bpl .loopDigit ; 2/3=15/16
Since I do not like to squeeze tiny multi digit numbers into just 8 pixel, I decided to display the numbers as 2^X (with only the X displayed). Also this adds a bit of a nerd factor to the game. 
And this is how the result looks like:
Note: Rules for my Threes! variant (called THREE∙S = 3 dots):
- A new game starts with RESET
- Move the joystick to shift the tiles by one
- Press fire for undo (once!)
- '.' can only merged with ':'; resulting into a 0
- Digits with the same number can be merged, resulting into the next higher digit
- Whenever tiles are moved a new tile is created
- The new tile appears at an empty space in the column/row opposite to the move direction
- Initially the new tile can only be a '.', ':' or '0'
- After you reached a '4' you will sometimes get a higher bonus tile, which is between '1' and your highest tile number / 4.
- You get points for merging tiles, scores tripple for each higher number
- The game ends when no tile can be moved
3 Dots v0.1.bin Three.s v0.2.bin Three.s v0.3.bin Three.s v0.9.bin Three.s (v0.92).bin Three.s (v1.02).bin
-
6
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
15 Comments
Recommended Comments