Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Hayleia on June 19, 2014, 04:12:05 pm
-
Basically, I wanted a 2048 that was as fast as nikitouzz's (or at least with a constant speed) and as beautiful as JWinslow's, but I can't understand anything in JWinslow's code o.o
So here's mine. It lacks a lot of features (like score saving for example) but it's not bad for something made in one day :P
2705 bytes when compiled for Ion.
Plus, Streetwalrus is going to be happy since I plan on adding an undo button :P
edit yeah, those are the same graphics as in JWinslow's version and I have the permission to use them as I was the author and gave them to JWinslow :P
-
I was waiting for this one actually. :P
Also yeah, undo button. I'm at 131072 now. <_<
-
I like this! Good work :)
-
Nice! :thumbsup: Maybe I should add better graphics to my 2048 clone. ::)
-
...I can't understand anything in JWinslow's code o.o
Rude! :P
But yeah, this is good. Maybe I might release a new version of mine with that new animation! (as soon as I figure out how you did that XD )
However, I would like to clear some stuff up, as far as my animation algorithm goes. Here is my animation subroutine with comments as to the exact details as to what everything does.
.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)
.This copies the X values and Y values of the tiles to a memory location where they can be changed, but still remain somewhere in its original form.
.(overwriting GDBs overwrites the program code itself)
0->[r3]
For(16)^^r
abs([r3]-{[r3]+32+L1})->{[r3]+32+L1}
[r3]++
End
.The preceding code puts the distance in tiles that any tile will move in any direction in {L1+32} to {L1+47}.
For(4)^^r
.(as we are moving 4 pxls/frame, and 16/4=4 :p)
15
For(16)^^r
Rect(->[r3]^4*16,[r3]/4*16,15,)^^r
[r3]-1
End
.That whole loop was to redraw the gray squares in the background, as they are erased when the tiles are moving.
For(16)^^r
.Loop for every tile
[r3]+48+L1->[r4]
[r4]+16->[r5]
.X and Y positions of the currently looped tile
If {[r3]+16+L1}
.If the tile being moved is not 0
WRect({[r4]},{[r5]},15,)^^r
Bitmap({[r4]},{[r5]},{[r3]+16+L1}-1*32+Pic1)
.Erase the gray area behind the tile, and draw it at the X and Y positions it is now supposed to be in on the screen.
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
.That whole If/Else statement is supposed to update the X and/or Y positions of the tiles.
.(I'd've done it smaller, but Z-Test() in a subroutine causes the compiler to choke :p)
[r3]++
End
DispGraph^^r
.Draw the current iteration to the screen.
WRect(and 0,,63,)
.Erase every tile now drawn on the screen, so we can redraw it in a later iteration.
EndAnd that inconsistency with speed you're talking about? It's actually intentional, but not in the way anyone has percieved it.
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.
I'm not saying my animation is perfect. It isn't, by any means. I'm just saying, there's less wrong with it than you think there is. You did very good with yours! (Although it could be a bit faster... :P )yeah, those are the same graphics as in JWinslow's version and I have the permission to use them as I was the author and gave them to JWinslow :P
She (she? he?)'s not wrong. :P
-
Dat grayscale when moving, though O.O
-
Thanks all :D
Dat grayscale when moving, though O.O
That's just Wabbitemu, I recorded with weird settings with a low number of shades. But on calc you don't see anything weird like that ;)
...I can't understand anything in JWinslow's code o.o
Rude! :P
Lol, I didn't mean "he codes like his foot" but just "I can never understand people's code since I don't know which RAM area is used for what" ;)
I even have to comment my code to understand what I did sometimes :P
And that inconsistency with speed you're talking about? It's actually intentional, but not in the way anyone has percieved it.
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.
Well I did that too but for some reason I had the impression that I had to wait longer when more tiles moved, not just that they moved slower.
You did very good with yours! (Although it could be a bit faster... :P )
Thanks, and yeah, I think I'll make them move twice as fast. When tiles have to move great distance it might be visible that they skip pixels but on small distances they still won't skip any pixel and they'll still be faster.
Just something about my code, there's some Action Replay during the animation, as in "you can't see shit when tiles are moving so I am not drawing properly and you can't tell the difference" :P
-
Ooooooh you cheater. :P
-
Good job :D. Also Jwinslow maybe your code being unreadable actually means it's too good, as in runer11fic2? :P (I didn't check tho)
-
I was joking about the "Rude!" thing. That's why I added a :P face.
And I will add a practice mode, complete with undo button, as soon as I know that the current version is good enough to be released on ticalc.
-
Good job :D. Also Jwinslow maybe your code being unreadable actually means it's too good, as in runer11fic2? :P (I didn't check tho)
Lol yeah. Never read Runer's code tho. :P
-
JWinslow23, your version seems like it's already ready for ticalc. It's the version i've got on my calc, at least.
Hayleia, yours looks nice, too, though i think skipping a pixel or two would be nice.
-
@DJ_O: Thanks, and it's unreadable as in "I don't know what this part does", I can't even know if it's good or not :P
@JWinslow23: I know you were joking, but still, I don't want to have any misunderstanding. And as chickendude said, I think yours can go on ticalc already. At worst, if you change anything, you still can update your archive.
@chickendude: Thanks. And there's already some kind of pixel skipping. If a tile moves to an adjacent tile, it doesn't skip pixels. If it goes one tile further, it still doesn't skip pixels, but for the two remaining distances, there is pixel skipping. I just didn't want the animation to look kind of laggy. It is also faster on calc ;)
-
Well, thanks, everyone.
Hold on, lemme make a readme and upload it... :D