Code:
gets you the empty cell condition. Getting the "can anything be moved condition" probably requires 8
Code:
, which is slow, but not horrifying.

Well, it's not fast, but it shifts and combines perfectly, and it uses a single section of code for all four directions. I believe that using simpler graphics or xLIBC would speed it up a bit more, as these sprites would require 1/4 the data with half-res xLIBC. I love Celtic II CSE being used, though, so perhaps we can stick with the two versions we had planned? I'll email you back the source, which now has TokenIDE/SC3 comments scattered throughout.



Edit: Actually, I take that back, the speed (if not fast) is actually bearable. I noticed two bugs, and I came up with one idea.
A) Bug 1: An existing tile can be combined with a new tiles creating from the combination of two other existing tiles, in the same move. The original does not allow this. My code's design allows a simple one-line fix for this.
B) Bug 2: The game will give you another tile if you press a direction that does not change anything. Fixing this is as easy as tracking whether anything was changed during the sliding/combining code.
C) Thought: game-over code: If there is any blank space, ie, prod([A]) == 0, then the game is definitely not over. If there are no blank spaces, ie, prod([A]) != 0, then check left and down from each tile in rows 1-3 and columns 1-3. If any tiles match, the game is not over. If none match, the game is over.

Edit #2: Implemented fixes for those two bugs. Good night.

I looked the code over a bit before leaving this morning. Some complex stuff up in there, I'd have never thought of a good portion of it.

And yeah, we can keep both versions going, of course. No reason to throw away the work that was completed. I'm still wanting to try to get myself to figure out where I was screwing up. I'd like to be able to say I figured it out and all that :p

Sounds like a plan. Perhaps it would help if I explain in sentences how my code is supposed to work, and you explain how your code is/was supposed to work, we can find the logical flaw? If we can find no flaw, then it is/was just a problem of a coding bug.

*bump* I threw together some sprites and xLIBC coding tonight, and here's what the same backend looks like with an xLIBC frontend. I also have game management and game-over detection and win detection and all that fun stuff implemented. Just needs scoring and a bit of testing and spiffing.

Fibonacci version next?

How does that one work? How many tiles does it require? I'm considering creating a Doge tileset, but that follows the original 2048 rules, and I suspect a Fibonacci version would require more tiles than I have room in my spritesheet for (16, to be exact, 32 if I use a full-sized spritesheet, and 64 if I use two spritesheets, the limit of what xLIBC can handle with any speed).

That looks loads faster than the Celtic version, very nicely done

http://www.crazygames.com/game/2584-fibonacci

The game ends at 2584, which is F_18, but you could probably get away with 17 tiles, since F_1 = F_2 = 1. Or you could cheat and start with 2 and 3 to make the game a little easier and cram it into 16 tiles.

[edit]

A special kind of painful:

Only because xLIBC sprites stay loaded in extra RAM, while Celtic II sprites must be pulled out of the AppVar each time they are used. The sprite routines themselves are luckily about the same speed.

Elfprince: That looks to be a special brand of painful indeed. I'll have to give myself a mental break to do some of my work-work before attempting a version of that.

Someone shared a 3d version, which seemed vaguely interesting, until I remembered the connectivity goes up as 2^n:

http://imgur.com/2OI1ZfL

1st try, only used 5/6 available directions.

I beat it on the first go as well, and made it 95% of the way to 4096 before losing. I'm interested that a 3x3x3 version is so much easier than a 4x4 version.

By the way, in case anyone missed it, I released my color 2048 for Doors CSE:
2048 Color

Well...you get twice as much space and twice as much connectivity.

Here's a 4-D version, but they were clever and shrunk the board down to 2x2x2x2.
http://huonw.github.io/2048-4D/

Hmm, also an interesting concept. Got to 512 on that one before I got stuck.

I get to 1024 on the first try and then had to go back to hw, but as far as I can tell, it's still easier in the sense of having a lower chance of getting screwed/isolated by the RNG, it just requires paying a little more attention and learning the buttons. The mean connectivity is 4 (since everything is a corner, there are sadly no interior-cube/exterior-cube/face/edge cells), but that's still 33% easier than the normal version which has a mean connectivity of 3=(4*4+8*3+4*2)/16