This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - JWinslow23
Pages: 1 ... 18 19 [20] 21 22 ... 40
286
« on: June 20, 2014, 01:03:10 pm »
I was joking about the "Rude!" thing. That's why I added a  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.
287
« on: June 19, 2014, 10:19:29 pm »
Nice to see another 2048 clone. At least this way, the 2048 craze is living, somehow...
And here is the code you want for creating the appvar (it even stores the pointer in M):
UnArchive "appvHS2048"
!If GetCalc("appvHS2048")->M
0->{GetCalc("appvHS2048",2)->M}^^r
EndThis code loads the appvar whether or not it is in RAM or archive.
You can adapt this code for different appvar names, different variables to store the pointer to, and different appvar sizes. And I like to store the appvar in Archive when the program ends, just in case the calc crashes and a RAM clear is performed.
288
« on: June 19, 2014, 09:59:41 pm »
...I can't understand anything in JWinslow's code o.o Rude! 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  ) 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... ) 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 She (she? he?)'s not wrong.
289
« 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.
290
« on: June 10, 2014, 07:11:05 pm »
291
« 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):
.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.
292
« 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?
293
« 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!
294
« 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. 
295
« on: June 07, 2014, 06:41:35 pm »
Bump. I'm really surprised that not many people are paying attention to this as much as they did Flappy Bird. It's like everybody that looked at this just said "Oh, he finished, that's nice" and disregarded this. I worked for months on this (much less than I did Flappy Bird), and am kinda surprised how bad this game is doing. 21 all-time downloads for any version of either of the 2048 source files, and 15 downloads for any version of the Noshell compiled result, as compared to 44 all-time downloads for the Flappy source and 82 downloads for any version of the Noshell compiled result (which doesn't include any versions prior to v1.10), not to mention 204 Flappy DLs on ticalc. Don't take any of the above the wrong way, though. It's nice to have the people that commented and looked say the things they said and do the things they did, but for some reason, this isn't as popular now as I thought it'd be. Please don't hate me.  I'll release the file to ticalc as soon as I am certain that this program is at its fastest and/or smallest. There are some spots that I'm unsure of whether or not to optimize.
296
« on: June 02, 2014, 11:51:46 am »
Nice work, as always, LD. Times like this when I kinda wish I had an nSpire...
297
« on: June 01, 2014, 04:10:11 pm »
I fixed a score display bug! When you win (or make a merge right before a GAME OVER), it doesn't update the score display until you continue (or if GAME OVER, not at all). I would really appreciate it if I could get help with optimization, though. Cause really, I'm getting nowhere.  Download in the attachments. A2048 and LIB3BYTE must be present on your calc to compile.
298
« on: June 01, 2014, 11:47:17 am »
Pressing the carrot (^) key makes the text all small in the new OS. Don't 'upgrade' to 2.55MP if you find this bug annoying.
I usually just use CLASSIC mode instead of MATHPRINT.
299
« on: May 31, 2014, 08:17:53 pm »
And if you press 2nd+ALPHA, the cursor might turn into this weird "A" symbol...
300
« on: May 29, 2014, 03:10:53 pm »
He's right. You could just tore the score and stuff to a GDB. I just like Appvars; that way, scores and boards could be transferred between calcs without a different program file. chickendude, I'm glad for you! The highest number I ever got was 4096. I'm still working on getting an actual 3-byte score.
Pages: 1 ... 18 19 [20] 21 22 ... 40
|
Show Posts