Author Topic: TI-2048 by Josiah W. (Read 20587 times)

Streetwalrus · « **Reply #30 on:** June 07, 2014, 06:50:15 pm »

I don't hate you.

Nah that aside, I kinda forgot about it because I play 2048 when bored and I don't bring my calcs everywhere.

So I play on my phone.
also undo button

JWinslow23 · « **Reply #31 on:** June 07, 2014, 07:23:13 pm »

Well, there's something different. I don't even HAVE a phone!

I said "Please don't hate me" because I thought that kinda sounded like "Hey, everyone! Notice me!", and I didn't wanna sound so much like I craved attention. If that makes sense.

Streetwalrus · « **Reply #32 on:** June 07, 2014, 08:06:31 pm »

I understood that.

I was just messing with you.

DJ Omnimaga · « **Reply #33 on:** June 08, 2014, 02:51:30 am »

I think the issue with this game is that the 2048 craze went on for shorter than Flappy Bird. You Flappy bird clone was not the first ever made for calcs, but Flappy Bird remained popular for long enough to allow your remake to thrive. However, your 2048 clone came out as the 2048 fad was dying. It's definitively one of the best looking for calcs, though (same for your Flappy clone).

Hayleia · « **Reply #34 on:** June 08, 2014, 03:28:56 am »

Well I expressed the two issues I had with that game. The first one was the graphics, and I helped you with that. The second one is the speed of animations. First of all they are not 1px per frame but 2px per frame, and most of all they are not at a constant speed (slower when more tiles are on the board).

So of course I don't hate you

But when I check that topic, either I see "that issue is fixed" or I don't see it. I am not expecting anything more, everything else is great.

DJ Omnimaga · « **Reply #35 on:** June 08, 2014, 09:46:44 am »

I actually thought the animations were fine. Some are less smooth than Nikitouzz version but the game looks nicer in overall. It's most likely due to grayscale, though (but again Reuben has perfect grayscale and still run fast

).

chickendude · « **Reply #36 on:** June 08, 2014, 10:50:31 am »

Reuben also just has one moving object on the screen

And at least the latest version runs perfectly fast, i think it jumps 4 pixels at a time and at that speed you can't really notice any slowdown.

JWinslow23 · « **Reply #37 on:** June 08, 2014, 09:00:07 pm »

Well, Flappy Bird was only so popular so long because because of the removal from the App Store, and remakes were highly sought after. Gabriele still has HIS on the app store, and even if he didn't, his official online version remains, leaving less demand for any remakes.

Anyways, glad to get more feedback. I guess I'll put it on ticalc now. Expect a release on ticalc within the week!

bb010g · « **Reply #38 on:** June 08, 2014, 09:09:25 pm »

Quote from: Streetwalrus on June 07, 2014, 06:50:15 pm

I don't hate you.
Nah that aside, I kinda forgot about it because I play 2048 when bored and I don't bring my calcs everywhere. So I play on my phone.
also undo button

UNDO BUTTON? UNDO BUTTON? WE DON'T NEED NO STINKIN' UNDO BUTTONS!

JWinslow23: You hit the end of the craze. Personally, I would use your version, but I don't have a 84.

DJ Omnimaga · « **Reply #39 on:** June 08, 2014, 10:42:40 pm »

If Omni ever allows new downloads again you should put a copy there too, or you could ask staff via ourl.ca/request to get the game added.

JWinslow23 · « **Reply #40 on:** June 09, 2014, 12:25:49 pm »

DJ Omnimaga: You mean added to the featured game list? That'd be cool.

(However, I believe that if anything of mine should've been featured, I'd prefer it to be Flappy Bird 84+.

)

bb010g: Well, thanks...oh, and an 84+ will be well worth the money.

Everyone who's complaining about the slow anims: This is why I need optimization.

I mean, I'm doing a lot of calculations when the moves occur. I'm using grayscale. I'm doing 3 byte scores. My graphics are 15x15 Bitmaps. There has to be a Game Over check and Win check after every move. There are probably some snippets of code I'm not sure I need, like a use of the abs() token somewhere in the animations. What do you expect in terms of instantaneosity?

Hayleia · « **Reply #41 on:** June 09, 2014, 01:24:54 pm »

Quote from: JWinslow23 on June 09, 2014, 12:25:49 pm

Everyone who's complaining about the slow anims: This is why I need optimization.
I mean, I'm doing a lot of calculations when the moves occur. I'm using grayscale. I'm doing 3 byte scores. My graphics are 15x15 Bitmaps. There has to be a Game Over check and Win check after every move. There are probably some snippets of code I'm not sure I need, like a use of the abs() token somewhere in the animations. What do you expect in terms of instantaneosity?

Calculations should occur before the move, so you just have to move afterwards. 3 bytes score and Win/Loss checks have nothing to do with animations. The only things that can slow down are the grayscale and the 15x15 bitmaps (which could be replaced with 4x 8x8 sprites).
And once again, what I complain about isn't the general slowness, which your two arguments could explain, but the fact it is slower when more tiles move, which is very annoying and this is probably an algorithmic problem, not an Axe optimisation one. In other words, I don't care if it runs at 1 FPS as long as it is a constant 1 FPS, and not 60 FPS first then 1 FPS when I played more.

And I'd gladly help you if I didn't have enough to do with school projects -.-
Seriously, I envy those people in French high schools who only have the Bac and have plenty of free time compared to what I have.

JWinslow23 · « **Reply #42 on:** June 09, 2014, 05:04:49 pm »

Here, then, is the algorithm for animation.

1. Initialize X and Y positions (stored in GDB1, copied and manipulated to L1).
2. Calculate how many squares a tile has moved in any direction.
3. Repeat this 4 times:
3a. For every tile, adjust the X and Y values of each tile animated 4 pixels in the direction you slid (determined by K).
3b. Draw the tiles.
3c. End Repeat

And the subroutine code (GDB1 is the X values of every tile, then the Y values):

Code: [Select]

.Just so we're clear, GDB1 is:
.0,16,32,48,0,16,32,48,0,16,32,48,0,16,32,48,0,0,0,0,16,16,16,16,32,32,32,32,48,48,48,48
.That should clear some stuff up.
.
Lbl ANIM
Copy(GDB1,L1+48,32)
0->[r3]
For(16)^^r
abs([r3]-{[r3]+32+L1})->{[r3]+32+L1}
[r3]++
End
For(4)^^r
15
For(16)^^r
Rect(->[r3]^4*16,[r3]/4*16,15,)^^r
[r3]-1
End
For(16)^^r
[r3]+48+L1->[r4]
[r4]+16->[r5]
If {[r3]+16+L1}
WRect({[r4]},{[r5]},15,)^^r
Bitmap({[r4]},{[r5]},{[r3]+16+L1}-1*32+Pic1)
End
!If K
{[r5]}+({[r3]+32+L1})->{[r5]}
Else!If K-1
{[r4]}-({[r3]+32+L1}*4)->{[r4]}
Else!If K-2
{[r4]}+({[r3]+32+L1}*4)->{[r4]}
Else
{[r5]}-({[r3]+32+L1})->{[r5]}
End
[r3]++
End
DispGraph^^r
WRect(0,,63,)
End

There are definitely stuff I could improve upon, but I don't believe that a full algorithm rewrite is absolutely necessary.

If you need anything else, just tell me.

Streetwalrus · « **Reply #43 on:** June 09, 2014, 05:55:28 pm »

Quote from: bb010g on June 08, 2014, 09:09:25 pm

Quote from: Streetwalrus on June 07, 2014, 06:50:15 pm
I don't hate you.
Nah that aside, I kinda forgot about it because I play 2048 when bored and I don't bring my calcs everywhere. So I play on my phone.
also undo button
UNDO BUTTON? UNDO BUTTON? WE DON'T NEED NO STINKIN' UNDO BUTTONS!

JWinslow23: You hit the end of the craze. Personally, I would use your version, but I don't have a 84.

Welp I managed to reach 131072 (the max tile) with the undo button but it was still challenging and it took forever. Fwiw, that's 64x2048.

JWinslow23 · « **Reply #44 on:** June 18, 2014, 03:06:06 pm »

Bump.

Two things:
1. The "inconstant speed" Hayleia's talking about is actually a main feature of my animation algorithm. It's not running any slower or faster in terms of speed; the TILES are.
How my code works is: tiles move a certain speed towards their targets depending on their distance (a la the original). Therefore, it makes sense that the less tiles on the screen, the faster it seems; that means tiles may move a greater distance, and with a greater "speed". And this also stands with the more tiles on the screen, the less of a distance the tiles move, the slower it seems to go.
2. I've been tinkering with an AI (I don't think this will be developed any further than it is, however) that basically makes the move that merges the most tiles. Download attached (LIB3BYTE not included). Use the STO key to make a move with the AI.

Author Topic: TI-2048 by Josiah W. (Read 20587 times)

Streetwalrus

Re: TI-2048 by Josiah W.

JWinslow23

Re: TI-2048 by Josiah W.

Streetwalrus

Re: TI-2048 by Josiah W.

DJ Omnimaga

Re: TI-2048 by Josiah W.

Hayleia

Re: TI-2048 by Josiah W.

DJ Omnimaga

Re: TI-2048 by Josiah W.

chickendude

Re: TI-2048 by Josiah W.

JWinslow23

Re: TI-2048 by Josiah W.

bb010g

Re: TI-2048 by Josiah W.

DJ Omnimaga

Re: TI-2048 by Josiah W.

JWinslow23

Re: TI-2048 by Josiah W.

Hayleia

Re: TI-2048 by Josiah W.

JWinslow23

Re: TI-2048 by Josiah W.

Streetwalrus

Re: TI-2048 by Josiah W.

JWinslow23

Re: TI-2048 by Josiah W.