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 - nemo
Pages: 1 ... 63 64 [65] 66 67 ... 82
961
« on: July 19, 2010, 04:16:35 pm »
Darl181 has a neat idea in the Your Projects Post and Critique thread. his idea is to have the statement ReturnIf (and presumably Return!If) automatically set Fix # statements to their defaults. So if in a program you had Fix 1 at the beginning, if you had a ReturnIf statement, the program would automatically set Fix 1 (large sized fonts) back to Fix 0 (small sized fonts). this way you wouldn't need to use If (EXP):Fix 0:Return:End. ninja'd by himself.
962
« on: July 19, 2010, 04:11:35 pm »
No, ReturnIf does not take care of Fix tokens. you may want to post that in feature wishlists though, because that sounds like a good idea.
rather than
ReturnIf getKey(15)
you could always do the following:
If getKey(15)
Fix 2
Fix 4
Return
End
963
« on: July 19, 2010, 03:57:45 pm »
the commands list is your friend. print it out. keep it. read it. love it. cherish it. have it. always.
yes, you can nest as many subroutines as you want, practically. i think there's a limit but it's impractical to need to call that many subroutines. for example, this piece of code is entirely allowed:
0->X
Disp Sub(C)>Dec
Lbl M .Multiply
X*2->X
Return
Lbl A .Add
X+1->X
Return
Lbl S .Subtract
X-1->X
Return
Lbl MA .Multiply then Add
Sub(M)
Sub(A)
Return
Lbl C .Compute X*2, then X+2, then X*2, then X-3.
Sub(MA)
Sub(A)
Sub(M)
Sub(S)
Sub(S)
Sub(S)
Return .This return is unnecessary, because it's the end of the program.
Edit: i feel like optimizing.
Disp 1->X>Dec
964
« on: July 19, 2010, 03:45:16 pm »
Quigibo already explained this a few pages back, imPersonator. it'll be fixed in v4.0
965
« on: July 19, 2010, 03:41:47 pm »
Darl181, "return" is the statement that does two things. it a) exits the subroutine it's currently in or b) if not in a subroutine, exits the program.
so if you have an If statement that jumps to a subroutine at the end of the program and expect the program to end, it won't, because they program is in a subroutine. so after the If statement becomes true, the program will jump to the subroutine (lbl E in this case) and then notice it's at the end of the program, so it'll assume "Return" has been placed there. from there, it will exit the subroutine, not the program. just the subroutine. so if you want to exit the program on an If statement, try this.
ReturnIf (EXP)
so if you wanted to exit the program when a user presses clear you could use
ReturnIf getKey(15)
966
« on: July 19, 2010, 03:01:56 pm »
well since i figure i'm going to need a lot of speed to correctly make the game, i'm not going to do grayscale. i'll just have to throw in a different prefix before unicorn attack (: and music's a no, because i really don't care about music from my calc when i can get it fine from elsewhere.
967
« on: July 19, 2010, 02:32:50 am »
quigibo, are you talking about robot unicorn attack? because that's why i want the pixel art (: i'm trying it in axe but i'd love to see an ASM version if anyone's up for it (thepenguin77?) magic banana, those sprites look AMAZING. i'm going to use them, most likely. thank you very much!
968
« on: July 19, 2010, 12:12:34 am »
the unicorn is the main one i want, too (: though currently i have the engine set up for the car (a car and a unicorn do not jump the same way.) if you want, you could make jumping sprites. just one position for ascending, and one for descending would be fine.
969
« on: July 18, 2010, 10:51:22 pm »
i think the code would really help... happybobjr, i'm assuming your etch-a-sketch draws 1 pixel at a time, right? in that case, you can always toggle gray on/off, and then have a flag variable to decide to draw a gray pixel or a black pixel.. you don't need to storepic or recallpic, i don't think.
0->G . No gray
If getKey(54) . If they press [2nd]
1->G . Start drawing gray pixels
End
[your movement code here]
.when you draw the pixels to the screen:
If G
Pxl-On(X,Y)^r
Else
Pxl-On(X,Y
End
970
« on: July 18, 2010, 10:41:59 pm »
well. i guess i'm opening the unicorn and ram to 16x16. since the game is mainly speed, i would prefer 8x16 so i only have to draw 2 sprites. but i could try it with four.
971
« on: July 18, 2010, 10:37:10 pm »
yunhua, how many more pixels high would the sprites need to be to make an adequate unicorn? i'm especially interested in the unicorn, or the ram. can you specify some dimensions? 8x16 are simply preferred.
972
« on: July 18, 2010, 10:21:56 pm »
forgot to mention: animated sprites should have 3-4 frames. please avoid greater than four, unless it's absolutely necessary and looks spectacular. that looks nice yunhua, thanks (:
973
« on: July 18, 2010, 09:13:43 pm »
first, these are monochrome 8x16 (8 pixels high, 16 wide) sprites with a side-view facing to the right. second, i'm only going to use one of these, whichever one looks best. if you're going to make one, please don't spend your time making 5 average sprites. perfect one of them, as i'll only pick one (or perfect all of them, if you want). lastly, if you can make a cycle for movement (preferably with it running), that would make my day (: - ram/mountain goat. (make it 16x16 pixels if 8x16 isn't enough room) - hare/bunny - kangaroo rat- sports car. - unicorn! (make it 16x16 pixels if 8x16 isn't enough room) tl;dr: 8x16 monochrome sideview to the right. pick one, perfect it. give it a run cycle for extra points.
974
« on: July 17, 2010, 10:12:07 pm »
let's rotate some sprites, shall we? [AAAAAAAAAAAAAAFF->Pic1 .your sprite!
Pt-On(0,0,Pic1
For(Y,0,7
For(X,0,7
If pxl-Test(X,Y
Pxl-On(Y+9,7-X
End:End:End
DispGraph
currently trying to figure out how to not use any graphics commands and rotate the sprite's data... i'm having very minimal luck with this, though. and some cool trickery with flipping: [0102040810204080->Pic1 . your sprite data.
Pt-On(0,0,Pic1
For(A,0,3
Exch(Pic1+A,Pic1+8-A,1
End
Pt-On(9,0,Pic1
DispGraph
EDIT: this is a triumph, i'm making a note here: huge success. i can rotate sprites 90 degrees... by just rotating their data (: of course my routine requires 8 bytes of memory to store the rotated sprite. Observe  .YYYEAHHH
[4875038562839462->Pic1 . This data doesn't matter, cause this routine will rotate any sprite (:
ClrDraw
For(A,0,7
{Pic1+A}->T
For(B,0,1
If B
T^16->D
Else
T/16->D
End
If D>7
e^(A)->C+{4*B->E+L1}->{E+L1}
End
If D>3 and (D<8) or (D>11)
C+{E+L1+1}->{E+L1+1}
End
If D!=1 and (D!=4) and (D!=5) and (D!=8) and (D!=9) and (D!=12) and (D!=13) and (D!=0)
C+{E+L1+2}->{E+L1+2}
End
If D^2
C+{E+L1+3}->{E+L1+3}
End
End
End
memory efficient? No. it's 750 bytes or so, i believe. i'm sure there is a vast field of optimizations to make. for instance, that long conditional that draws the 3rd and 7th row of the translated sprite. and since you save to a byte L1+(num), you can probably substitute that for A with some tricky logic... i'm lazy to optimize this right now, though. edit: optimized a bit. it's now 520 ish bytes.
975
« on: July 16, 2010, 07:09:59 pm »
no problem. what exactly are you trying to make?
Pages: 1 ... 63 64 [65] 66 67 ... 82
|
Show Posts