2048 for NES/FC (includes source)

EDIT: Rev #5 (download): Fixed broken tile spawning and blinking on tile merge/spawn.

EDIT: Rev #3: Changed to NROM-128 and added out of moves notification.

EDIT: Rev #2: Should have the bugs fixed for NTSC.

EDIT: Attached screenshots.

Hi all,

This is a release of NES/FC version of the popular 2048 game. Download ROM here (from Bitbucket)

Font and number tile graphics were taken from Oerg866's Sega Mega Drive/Genesis version. The game also uses FamiTone2 by Shiru. Everything else (including music) was done by me. Many thanks to Shiru and Oerg866.

The game sources and all resources are in examples/2048/ directory of my neskit project:
https://bitbucket.org/tsone/neskit

Best way to build this from source is by cloning the above repo and running build.bat/.sh in the 2048 directory.

BTW. I only tested this on PAL system hardware. Could anyone help to test this on NTSC? Rev #2 was tested on NTSC HW and it should work.

Enjoy!

Let me guess: this is like Gravnic, right?

I used a hex editor and noticed a lot of blank space at $8910-$BFFF, $E4C0-$F7FF, and $FAA0-$FFF9. It looks like this could easily fit into 16 kilobytes with a bit of rearrangement.

Anyway, I tried it on a PowerPak on an NTSC NES, and tiles were corrupting themselves all over the place. Just from the artifacts that appeared on my NES, I guessed that your engine is taking more than 2270 cycles after vblank to update things. It appears that you're even running the music engine (!) before resetting the scroll position. Try running the game in FCEUX set to NTSC mode and new PPU to see what I mean.

But if you do fix it up, it could be a counterpart to NES15 on the next Action 53 multicart.

Beaten to the punch by temples, but I took a picture of it anyway.

Nice job with the music and color palette by the way. When I was imagining to myself a month or so ago how I would do this, I was giving myself the near impossible requirement of showing the complete movement transition like in the browser game. Good to see that the game can work without that.

I would be nice if the game can detect when no more moves are possible, so that it can tell you to press start to go start another game from the menu.

I second that motion!

Nice work on this so far. I have been wanting to make one myself after getting addicted to the game a couple months back. I really like the music too BTW.

Thanks for quick replies. I'll fix this ASAP. I didn't try this on the new PPU in FCEUX, so I missed that one. It's a stupid mistake, I didn't take account the NTSC's shorter VBLANK

I'm pretty certain you're not compensating for the "DPCM causes bit deletions" bug. (I'm getting spurious presses of Right in Nestopia)

I think I remember someone saying Nintendo'd fixed it in the 2A07, so it's another NTSC-only problem.

You are right. Thanks for pointing this out. I also noticed this just moments ago when testing new fixes on Nintendulator. I assumed earlier no DPCM will be used, so the input routine was broken... I'll fix this one also ASAP.

I'll add this to the next revision. Thanks for the feedback!

That would be great!

It appears working on my NTSC NES. But $8000-$8909 still isn't relocated up into $E580-$F7FF. Do you plan on doing that soon? It'd be nice to have the entire bottom half blank so that I can stick another NROM-128 game in its place.

Gameplay bug please: If there are two pairs one one row or column, should they be allowed to collapse in one press? They appear not to on this version. Try getting something like this and pressing left or right:

If I press left or right in the popular version, I get two 4's, each created from one pair of 2's.

Can be logically and visually simulated by having the game repeat the direction until it detects that more tiles can merge that direction, then the random tile is added.

The behavior I saw in the web app is to slide, merge ONCE, and then slide further. [2 2 2 2] should merge right to [_ 4 _ 4] and then slide. They should not merge recursively to [_ _ _ 8] in one keypress. Nor should [16 4 2 2] merge to [_ _ 16 8] in one keypress.

I was just now attempting to read the source code to make sure my words where accurate, and I got it wrong.

Thanks for pointing that out.

Good to hear! Thanks for testing. Is it considered safe to have 16K PRG ROM when using iNES mapper #2? Like you said, the second bank is not necessary. This game just needs CHR RAM from this mapper to decompress graphics.



Thanks for noticing, but it's not a bug - it's a feature. I took this merging mechanic from Veewo's version. The Cirulli's version indeed has a different mechanic. I assumed these were identical, but they are not. I also thought Cirulli made the original, but seems I was wrong again. Reportedly, original is by Saming, and this game has yet another merging mechanic. See for yourself. I'll stick with the current one.

Yes.


I'd try it to confirm, but why does 1024 for Android require access to my tablet's "precise location" (that is, GPS)?

In that case it's easy to do. I'll have this in the next revision (#3).

I don't think using 16kb PRG ROM + mapper #2 makes any sense. Use mapper #0 instead if you're not bankswitching PRG-ROM.

From the wiki, "Because the board needs to be rewired slightly for CHR RAM, a few emulators do not emulate iNES Mapper 000 (NROM) with CHR RAM."

I just leave my own programs NROM even if I'm using CHR RAM if I'm not bank switching and leave it to the player to change it to BNROM or something if they find their emulators fusses over NROM with CHR RAM, and at least FCEUX and most emulators I've played with don't seem to mind.

The point it so get it in a form that makes it easy to include in the action53 multicart.

If the ROM is 16384 bytes of PRG ROM and no CHR ROM, mappers 0, 2, and 34 are equivalent.

That and it continues the "double" theme of the rest: it's volume 2, it has Double Action Blaster Guys, and now a game where the tiles collapse and double in value. Finally, it gives me a way to call it a "2048 game multicart" without getting a big phallic nose.

The NROM (mapper #0) wiki page was a source of confusion to me. It isn't explicit about CHR RAM. However this page is far more specific... Just set iNES header CHR ROM banks to zero and you should get CHR RAM with mapper #0.

Has anyone else with 2048 experience find this version a bit easier than the original? Not, that I'm complaining, I do like to win

Very cool! I found it easier too... even tho I didnt win

I noticed a bug which made the game more easier. Because of the bug, new tiles got frequently placed in the same position. The player could use this bug to anticipate the next tile position.

I have fixed this in rev #5. As a result the game should be a bit harder

My version of 2048 is just about done and better than the one you have posted. I will post it in 2 weeks.

Humility 101.

Lol, I was going to say the same thing. Maybe something got lost in translation...

Here's my graphical suggestion — a less ugly Q and a slightly modified set of tiles.

I used sprites instead of background tiles. That way, the animations are far smoother. The only trade-off is tile size. Mine was designed to be as close to the Android game as possible in color and presentation.

There are ways to make smoother animations even with the 32-pixel tiles. For example, Yoshi's Cookie for NES moves things 8 pixels at a time, which is smoother than 16. With 8-pixel movement, you'll have to avoid attribute clash somehow; that can be done by leaving an 8-pixel gap between tiles when moving them.

The attribute clash would be very very hard to overcome and it would surely come at a price at some point.

Redesigned the interface to look more like the Android game.

Perhaps it might be easier if I demonstrate with an animated GIF.

This movement is unrealistic to the original game. In the GIF, the blocks are separating for a short time before coming together. Also, blocks travel at different velocities.

The "original" is in a nearly unrestricted environment, There's almost certainly going to be compromises when porting to NES wherever it be small tile size, or additional gaps in the group movement. The question is which compromise is more desirable.

I personally believe that a tile size of 32x32 is a must have, and I'm intrigued in tepples's idea of showing a tile velocity of 8px per frame. Also the gaps actually do look more natural to me, especially once the tiles slide underneath when merging, but I'm wondering how to deal with the vblank time limitation. In the worst case, 208 nametable entries has to be updated in a frame. I guess the options are

• threat the two nametables as a double buffered video frame and take two vblanks of times to update the other nametable
• 60/50hz update by interleaving the tiles to be updated in some visually acceptable way
• maybe some forced blank trickery can extend the vblank time to write 208 tiles?

Also I think there needs to be some sort of option switch (hidden or otherwise) that switches to the current color set and merging rule, to a color set and merging rule that matches the popular browser game. Because I actually like both.

EDIT: spelling

Updating half the grid in each frame should be acceptable. Consider Tetris for NES: it took about five frames to redraw the matrix after a line was cleared, and nobody gave a $#!+.

There's a goofy option to increase the total bandwidth: fully unrolled loops of PLA/STA $2007 with stack haxery and using zeropage LDA $80/STA $2007/LDA $81[...] to store the entire tilemap. Since you're not using sprites (right?), this gives you enough off-screen time to schedule 324 writes during vblank, and you "only" need 312 ((16+2)×16 (nametables) +(4+2)×4 (attribute tables)) to update the entire display every frame. Using both techniques to update the entirety in a single vblank will take 272 bytes of RAM from zero page and stack, 1592-1800 (depending on how much is store in the stack and how much is stored in zero page) bytes of ROM and will complete the entire set of writes in 2144 cycles (out of ≈2260).

In my opinion, the animations should not be compromised for tile size in this game. I slowed down on an emulator the other version of the game being made that was posted and I found it had a lot of clunky, blinky animations.

Perhaps you could use sprites (with same color of background) for animations of tiles movement? You could use background where sprites aren't needed, and then it might fit in 8 sprites per scanline

I'm going to agree with the bigger 32x32 tile size, on the grounds that it seems a bit wasteful to have such a tiny playfield with such a huge amount of wasted space surrounding it. I'm sure you can dig up examples of wasted screen estate and nobody caring, but I still stand by opinion. I also like Tepples's animation, which is probably the most practical way to mitigate attribute clash without being able to have each tile be a sprite.

Tiles sliding at different velocities would be doable. If you used Tepples's animation as your basis, each tile would need to slide at 1/4 increments between its starting position and destination. Since the board is 4x4, there are only three options: The tile moves 3 spaces, 2 spaces, or only 1 space. This could easily be implemented with a lookup table.

To mitigate attribute clash like Tepples is doing, you assign a start-delay to each tile that has to move. If you press left for example, the leftmost movable tile starts its slide animation in the first frame, and any tiles to the right of it wait a frame. Then in the next frame, the next tile right starts moving, and the third tile (if any) waits until the next frame.

Of course, this means the board can vary between taking 4-6 animation steps before it's finished animating. If this is a problem, you can stretch the animation out by scaling the start delays so the animation always takes 6 steps. For instance, if two tiles can move, the first one starts in the first frame, and the second one waits two frames instead of one. If one tile can move, it can wait two frames or move immediately, up to you. Or you can "force" the animation to only be 4 steps by accepting player input after the 4th step, which can interrupt the animation (the tiles just jump to place, they wouldn't be too far off anyway) if the player chooses to move again before it finishes.

So there's lots of options for the bigger tile size to work, and I think that the only way we can tell if this is faithful to the gameplay or not is to try it out and see how it feels, though I'm pretty sure the game is still going to be 2048 regardless of what you guys bicker over. And even if all you guys disagree and we wind up with 5 different versions of this 2048 game, 'tis the spirit of mobile games anyway.

Obviously it is a case of preference. Having my sprite-based game working well and having a familiar feel makes me believe that the sprite based approach is better. The smaller game block size is not bad. I can prove that there could be no larger game block background-tile based game that could be appropriated to accommodate smoother animations. It would be possible to use the occasional background sprite to aid in particular tasks to avoid the "too many sprites on a scanline" problem but even that is only a very minor problem.

Given how you're a relatively recent newcomer to programming for the NES, I am very skeptical that any such "proof" exists.

In fact, I'd bet very good odds that the MMC3 or anything else with 1k banking could be used in combination with sprites to hide the attribute clash such that single-pixel accuracy were possible in the animations.

If a person wants to use 9 background tiles (each game block 3x3), then there will need to be 3 leading sprites, 3 trailing sprites, and at least one sprite in the middle of each game block to show the score. That's 7 sprites to get the animation correct for one game block. There are scenarios where 12 game blocks would need to move simulaneously creating a demand for 84 sprites, which cannot happen. If that is not a proof I don't know what is. The next size smaller is 2x2 game blocks, which I achieved fluid animation using lots of sprites. Any 3x3 or higher background tile method cannot achieve the proper fluidity of animation.

Q.E.D.

Updating 208 tiles plus attributes in one vblank is possible with early-off or late-on.

In 32x32, it's possible to animate 12 or 16 tiles at once using scroll splits, where the background represents two columns of tiles moving at the same velocity and the sprites represent tiles that aren't moving at the same velocity. Do I need to illustrate this with another animation?

But in practice, did people who played Dr. Mario care that everything moved in 8-pixel jumps? If not, lack of "proper fluidity of animation" is no deal-killer.

I'm not trying to say that there's no place for a game using 16x16 pixel tiles. But something simulating desk accessories is probably better in a faux-windowed environment, like Windows 98 for NES, not in a traditional full-screen environment.

I think I would have to see the animation of a scroll split. I do believe that the animation can be compromised but I'm not willing to do that. Since I'm not familiar with a scroll split, it would be good to understand how it works.

Have you ever played Super Mario Bros. 3? Play World 1 until you beat the first fortress, then move Mario on the World 1 map onto the spade icon and press A. Look at the huge honkin' mushroom, flower, and star "sprites", except they're not really sprites but actually background elements.

Have you played any of the later Mega Man games? Look at the huge minibosses and how they move around at a different rate from the ground. They're backgrounds too.

Do you still not understand? If not, it may take me a while (possibly days with my other obligations) to produce an animation that shows dozens of frames of both the screen and the video memory in parallel.

EDIT: Is this how smooth it must be?

This is how smooth it should be but what options does this give you for the color palette? Does this mean that you will have a much more limited choice of colors for the game blocks? My other concern is what will happen when game blocks get joined together. Won't there be problems with the attributes?

I'd be more concerned about the inevitability of running into the 8 sprite/scanline limit.

@raydempsey
What's happening in the animation is that the middle portion is being scrolled as a strip of background, and the 16x16 color areas are scrolling with it. It means the area to the left and right side of the grid has to be a solid color. Do I need to make you a second animation showing what's going on in the video memory?

@Drag
There are only three velocities: 2, 4, and 6. I'd like to see what situation you think would require three blocks to be drawn as sprites instead of as a background (static images OK; you don't have to animate it).

That totally reminds me of when you converted Driar to NROM, and also now I see I miscounted updating requirements.

I see that that animation has one problem that I caught myself doing when mocking things out. The movement is very linear, whereas the originals has some nice ease in movements (at least the browser).

If I were to have the time to work on the code base now using only my current working knowledge, I would use the method of updating the off-screen nameable at 30/25hz. I would also consider what Drag mention about tiles taking different steps each frame and my own observation of linear movement, and this is what it would look like.I can try out other configurations to see if the way I did this would still work.

If I'm off base please ignore me. This post was kind of ninja'd 5 times over 2 days.

Sorry for the late post, but I have a question.

In Tepple's example, I can see what he's trying to do. My question is, how will it be possible to have the white outline to be completely solid when the background scrolls? In most situations, this would make the background scroll upwards as well, since you're just moving a 'slice' of the image. How can you have a background scroll in the middle of something without the white moving around? I'm assuming you're going to try to create "embedded" scrolling, which might have some artifacts that can be hidden with sprites. About the best way I can describe it would be the segments where you're walking around in bushes in Ultima IV; the entire screen is blackened except for a small area, and that area has black squares potentially hiding the artifacting. This is a contrast from SMB3's or Metal Gear's method of "walking in the shadows", since those just have the character move in a fixed screen, while Ultima IV has the entire screen scroll.

If my question doesn't make sense, it's because I don't know how to word it.

The same way a playfield scrolls without the status bar moving around: timed writes to the scrolling registers. But then I acknowledge that Drag's counterexample makes this technique slightly less reliable.

Thanks for all the comments and suggestions! I've been recently very busy with work.

I initially considered smoother animation (also with sprites), but when I got the first 32px animation version working (almost same as now), I really liked how fast the gameplay was compared to Cirulli's and Veewo's originals. The 32px move animations can take as low as 1-4 frames depending how far tiles move. This short animation delay really accelerates the game and makes overall playtime shorter.

Interesting idea. Notice that the current code already has following trick to draw a single 128x8 tiles "slice" with only 4 reads:



This works because the tile graphics are pre-arranged. This means we'd only need 25% of RAM you calculated -- so we can even attempt to unroll everything into RAM! The above 128x8 slice code would become:



The unrolling would need 4*4*78=1248 bytes total which *might* work... Hmm, however, I think the 'PLA/STA $2007' idea is better since it'd only need 16*4=64 bytes of stack, and the code could be in ROM:



...I however have no plan to implement this -- conside this just an intellectual exercise

EDIT: If you wish to try this, the code is in bitbucket...

Thanks for the comment, but I will not make changes right now.

EDIT: If you wish, you can clone the repo from bitbucket and change the graphics to your liking...

I made a video of me playing the version accepted for Double Action 53. Poorly.

Come on, winning at this game is very simple. Just use only down and left keys, if you can't because you're blocked, use right, and if you really can't use up (but prey so that a '2' won't show up at the place you don't want it to).

Then it requires a lot of luck and that's it.

Thanks Damian for the gameplay video. I forgot to make one myself

There may be multiple good strategies in the game, but I use similar as Bregalad. I try position the biggest tile to any of the corners. Then I merge the tiles on either of its sides in ascending order, so as to create kind of "merging pipeline". Worst case is when a new tile pops in the wrong place and I'm forced to move the tiles in an unwanted direction, breaking the "pipeline". This however makes the puzzle aspect of the game to stand out, as the "pipeline" or tile positioning must be redone.

Based on my observations after getting '1024' you really need good luck to win as a single tile can ruin the game. This is one of the reasons why I wanted to make the gameplay faster, as then you can retry (and lose ) faster.

Has anyone got '4096' yet? I was quite close once.


PS. Probability for "4" tile in the game is around 10% (as in the original by Cerulli). More precisely it's floor(255/10)/255 = 9.8%.

This still seems to result in "4 2 2", which seems wrong to me, though I haven't played the original, but as the only way to free a square is to get multiple matches in one slide, and two horizontal pairs would otherwise still make two matches. (8 8 4 4 only seems to do one match, similarly annoyingly)

Very relaxing, nice music; graphics smooth.

Feels a trifle odd that you still get "New game/Continue" after you're stuck and press start. Perhaps relabel Continue when the fail-state is reached?

You're not the first person to complain about this. Check my earlier reply. I modeled the merging behavior based on Veewo's 1024 which I have played the most. The game reportedly predates both Cirulli's and Saming's 2048. However since Cirulli's version is probably the most popular one, it would make sense to have that merging behavior.


Thank you very much! I'm happy to hear you enjoy it


Good idea. I think it would be best (=easiest) to hide 'Continue' option when the player gets stuck.

It would be nice to add the above improvements, but I don't want to promise anything.

Don't feel rushed. You have at least a couple years to get an upgraded version into the remix compo.