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 - Runer112
Pages: 1 ... 136 137 [138] 139 140 ... 153
2056
« on: August 15, 2010, 06:13:36 pm »
The best place to start is the official documentation that comes with Axe. I realize normally everybody just says screw lengthy documentations and doesn't bother with it, but it gives a very good introduction to the basics of Axe. It is well-suited for programmers who are used to TI-BASIC. Although it may look long and hard to read, it isn't all that difficult. Just read it, and trust me, stuff will make a lot more sense. (Maybe not complete sense, but a lot more)
2057
« on: August 15, 2010, 04:03:26 pm »
Using things like !If M-28 is a sort of cheap, smaller (byte-wise) way of saying If M=28. However, the problem with these types of statements is that they often will not work when trying to combine statements. If you want I can explain it, just trust me, it doesn't work. You either need to do it the right way, like: If M=28 and (X=0)Or nest the two, like: !If X
!If M-28 By the way, the easiest way to split up your menu processing would be not to check individually at each value of M for the X value, but instead put an !If X in front of the whole menu handler and put all the menu 0 checks in there, and after it use Else to handle all the menu 1 checks.
2058
« on: August 14, 2010, 07:34:46 pm »
C is not only being stored to, look at the end of the lines with C in it. As for M>N-(M<N)+N→N, there are three things being combining to get a new value of N. First, M>N will be 1 if M (destination) is greater than N (current position), so the expression will be 1 so far. Second is -(M<N), which will evaluate to -1 if M is less than N, so this subtracts 1 in this case. This can only be true if the first expression is false, so the expression will now equal 1 if M>N, -1 if M<N, or 0 is neither are true (M=N). This offset is then applied to N, either moving N in the appropriate direction towards M or, if N already equals M, not changing it at all.
Now, to address ┼({B*2+Z}r∙D). The loop this is in handles the logo part of the screen, and at this point in the calculation, is currently a completely white logo and rain on a black background. Inside of the parentheses, Z is the sandstorm offset, so {B*2+Z}r simple grabs the random sandstorm data. The next step is AND D. If you look back in the code, the line starts with {B*2+Pic1}→D, so D will contain the original, black logo on white background data. Combining these too with AND logic means that anything outside the logo, which is white (0) in D, will always be unaffected by the sandstorm data. The inside of the logo is black (1) in D, so the result of pixels inside the logo data will just be random according to the sandstorm. The final resulting image inside the parentheses will be a randomized sandstorm logo and a white background. This is then OR'ed onto everything else we have (a completely white logo and rain on a black background), so the white logo (before this) and the randomized logo (resulting from this) will combine to form a randomized logo, and the black background + white rain (before this) and the white background (resulting from this) will combine to form a black background + white rain. Final result: randomized logo with a black background and white rain on top of the background.
2059
« on: August 14, 2010, 06:17:12 pm »
Is there anything wrong with having the play menu be exactly like the main menu, with the rain and logo with sandstorm? If so, you don't even need to make a new menu loop or anything else fancy, you just need to redraw the menu items to the back buffer, invert it, and re-enter the menu loop that's already there. No new cursor position variables or new anything else needed. You will, however, need a new variable to keep track of which menu you're in, because both menus will bring you to the same menu handler system and you'll need to split that up based on what menu is currently active.
I still don't see why you need the select game mode text. If the user hits play and enters a menu with options like "timed mode" and "classic mode," I think they'll probably realize they're in the game mode selection menu.
2060
« on: August 14, 2010, 01:39:34 pm »
If it could be implemented into a game, that would be sick. But I'm pretty sure that it couldn't, because this is very processor intensive and needs to be constantly running (much more quickly than any interrupt would allow).
2061
« on: August 14, 2010, 01:34:15 pm »
The easiest thing to do would be to simply reuse the menu code that already exists. To do that, you'd want to have a label before the menu loop so you can just jump to it from the play option. That menu system uses four entries, so you'd probably want to get rid of the "SELECT GAME MODE" item (since it's not an actual option anyways) and just display the actual entries (3 game modes, 1 return to main menu). To actually display the new entries, you'd have to use a modified version of the "STORE MENU TO BACK BUFFER" code with the different string pointers before entering the menu loop. You would now need more than one menu handler, so I suggest designating another variable to hold which menu you're in (just assign different menus arbitrary numbers) and simply check which menu you're in at the menu handler so it can be processed appropriately.
EDIT: By the way, this has always bugged me. Why does the banner in your signature say both "Windows 7 User" and "Think Different - Apple"
2062
« on: August 14, 2010, 01:17:23 pm »
No, I'm not planning that. What I'm working on isn't a game and could never be implemented into one.
2063
« on: August 14, 2010, 01:15:35 pm »
I don't know what's going on, I just copied the code you posted line for line, fixed the symbols so the calculator would accept it, and it runs fine. Here's the SourceCoder code:
:.SNAKEX
:
:.<DATA>
:.LOGO
:[07C0000000000000000000001FE0000000000000000000001FF0000000780000000000003FF0000000FC0000000001F87FF7CF0000FC0000000787F87FF7DF87E0FC0000001F87F07BF7FF8FF0FC0000003F87E079E7FF8FF8FC0000003FC7C07F07FF9FFCFC1000001FEF807FE7FF8FFCFC7C00000FFF807FF7FF8FFCFDFE1E0007FF807FF7FF8FFEFDFE3FC003FF001FF7FF9FFEFFFC7FC001FE0001F7FF9FFEFFF8FFC001FF0039F7EF9FFEFFE0FFC000FF8079F7EFDFFEFFC1FBC001FFC0FFF7EFDFFEFFE1FFC003FFF0FFF7C30FFEFFE1FFC003FFFC7FE3C00FDFFFF1FF8007E7FC1F0000000EFDFFFDE00FC3FC00000000007CFEFBE01F83F80000000000187EFFE03F83F80000000000003E7FE03F8040000000000000003FC03F00000000000000000000000E]→Pic1
:
:.MENU RAIN
:[8080808000000000]→Pic2
:
:.MENU ARROW
:[0010181C18100000]→Pic3
:
:.MENU ITEMS
:"PLAY"→Str1
:"HELP"→Str2
:"SCORES"→Str3
:"QUIT"→Str4
:"SELECT GAME MODE"→Str5
:"X MODE"→Str6
:"TIMED MODE"→Str7
:"CLASSIC MODE"→Str8
:"MAIN MENU"→Str9
:
:
:.<INITIALIZING>
:DiagnosticOff
:ClrDraw
:ClrDraw{^r}
:
:.STORE MENU TO BACK BUFFER
:Fix 1
:Fix 5
:Text(30,28→M→N,Str1)
:Text(30,36,Str2)
:Text(30,44,Str3)
:Text(30,52,Str4)
:DrawInv
:StorePic
:ClrDraw
:
:.INTRO EFFECT
:For(A,0,63)
: Line(0,A,95,63-A)
: DispGraph
:End
:For(A,0,95)
: Line(A,0,95-A,63)
: DispGraph
:End
:
:1→A→Z
:
:
:.<MENU LOOP>
:Repeat getKey→K=9 and (M=N) or (K=15)
:
: .MOVE CURSOR
: .Update the cursor destination and current position, although does not draw cursor
: min(max(K=1-(K=4)*8+M,28),52)→M>N-(M<N)+N→N
:
: .ADD RAIN
: .Add a new rain sprite every 5 iterations of the menu loop
: DS<(A,5)
: Pt-Change(rand^96,1,Pic2)
: End
:
: .DRAW LOGO AND MENU
: .Shift sandstorm
: Z+1→Z
: .Move rain down
: Vertical +
: .Backup rain image
: conj({L6},{L1},708)
: .Draw logo, sandstorm, menu, and cursor
: sub(DM)
: .Update screen
: DispGraph
: .Restore rain image
: conj({L1},{L6},708)
:
:End
:
:
:.<MENU HANDLER>
:Fix 1
:Fix 5
:ClrHome
:
:.If user did not quit
:If K-15 and (M-52)
:
: .If PLAY
: !If M-28
: .ADD RAIN
:
:Repeat getKey→X=15 or (X=9)
: DS<(A,5)
: Pt-Change(rand^96,1,Pic2)
: End
:
: Vertical +
: DispGraph
:End
:Text(30,18,Str5)
:Text(30,28→O→P,Str6)
:Text(30,36,Str7)
:Text(30,44,Str8)
:Text(30,52,Str9)
:
:Repeat getKey→Y=9 and (O=P) or (K=15)
: min(max(Y=1-(Y=4)*8+O,28),52)→O>P-(O<P)+P→P
:
: For(B,168,353)
: .Menu image - End state: White text on black bg
: .AND Rain image - If either is white (0 - menu text and rain droplets), result will be white (0) - End state: White menu items and rain on black bg
: .→ Buffer
: {B*2+{L3}}{^r}{dot}{B*2+{L6}→C}{^r}→{C}{^r}
: End
: Pt-On(22,P,Pic3)
: Pt-Change(22,P,Pic3)
:End
:.<MENU HANDLER>
:!If O-28
:sub(X
:End
:!If O-36
:sub(TM
:End
:!If O-44
:sub(CL
:End
:!If O-52
:End
:End
: .If HELP
: !If M-36
: .<code>
: End
:
: .If SCORES
: !If M-44
: .<code>
: End
:
:.If QUIT
:Else
: Disp Str4
:End
:Return
:
:
:.<SUBROUTINES>
:.DRAW MENU
:Lbl DM
:
: .DRAW LOGO AND SANDSTORM
: .Loop through the logo, 2 bytes at a time
: For(B,0,148)
: .Logo data - End state: Black logo image on white bg
: .XOR 65535 - Inverts logo data - End state: White logo image on black bg
: .AND Rain image - If either is white (0), output is white, so logo and rain remain white - End state: White logo image and white rain on black bg
: .OR *Must wait for data in parentheses to be parsed* :
: .Sandstorm garbage
: .AND Logo data - This is the original, black on white logo. For the outside of the logo text, which is white (0), all ANDs will result in staying white (no change, so outside of logo text is unaffected) - The black text of the logo is all black (1), so the end state will be determined by the random data of the sandstorm - End state: Random black/white image on white bg
: .OR ^ - The only areas of ^ which can be black are the logo text, so everything outside the logo text will be unaffected, while areas inside (previously white) will take on the random sandstorm image - End state: Sandstorm logo image and white rain on black bg
: .→ Buffer
: {B*2+Pic1}{^r}→D{box}65535{dot}{B*2+{L6}→C}{^r}{cross}({B*2+Z}{^r}{dot}D)→{C}{^r}
: End
:
: .DRAW MENU ITEMS
: .Loop through the menu image, 2 bytes at a time
: For(B,168,353)
: .Menu image - End state: White text on black bg
: .AND Rain image - If either is white (0 - menu text and rain droplets), result will be white (0) - End state: White menu items and rain on black bg
: .→ Buffer
: {B*2+{L3}}{^r}{dot}{B*2+{L6}→C}{^r}→{C}{^r}
: End
:
: .DRAW CURSOR
: .Draw black cursor, turning any rain that might have been there black
: Pt-On(22,N,Pic3)
: .Invert cursor, turning cursor white
: Pt-Change(22,N,Pic3)
:
:Return
:
:Lbl X
:Return
:Lbl TM
:Return
:Lbl CL
:Return
:
:.<VARIABLES>
:.A=Counter to add rain
:.B=Temp loop variable for Lbl DM
:.C=Temp
:.D=Temp
:.K=getKey
:.M=Menu cursor destination
:.N=Menu cursor current display position
:.Z=Sandstorm offset
:.L1=Rain image backup
:.L3=Menu items image
:.L6=Rain image
Or were you referring to a problem with new code?
2064
« on: August 14, 2010, 01:00:53 pm »
I'm a little confused. Is there any good or "right" way to access a variable entry of a jump table (or a vector table, I don't really care which I use)? The only thing I can think of so far is cheating by calculating the address you want to jump to, pushing it onto the stack, and then using a return.
2065
« on: August 14, 2010, 12:49:18 pm »
Oh, yeah, for macros you definitely want to use $. Using reusable labels can cause problems in such a circumstance.
What are you writing, btw?
It's nothing new, but I'm still trying to keep it under wraps a bit. 
2066
« on: August 14, 2010, 12:44:16 am »
The easiest way to do hit detection is a simple pixel test. This would cover both the walls and your tail, although you'd have to make sure to filter out collisions with dots so they can be handled differently.
2067
« on: August 13, 2010, 03:28:10 pm »
Oh, well I don't have to worry about the number of bytes changing or anything, because these are fixed macros. That's the main reason I wanted to steer clear from labels, just so I wouldn't have to worry about weird things like label names in macros or name conflicts or anything.
2068
« on: August 13, 2010, 04:26:45 am »
Alright, thanks for the cofirmation. After trying it like 3 years ago and failing horribly, I've come back to take another stab at z80 assembly. I think having used Axe for a while kind of helped to step me into it (a great thing about Axe, it's a wonderful stepping stone to assembly). This time I tried to teach myself it, I knew a lot more and, instead of having to grasp both the whole new syntax and new concepts at once, I already had a lot of the concepts down. Perhaps in a short while I could even start helping with routines.
2069
« on: August 13, 2010, 01:40:04 am »
I believe that the symbol "$" when used alone represents a pointer to the current location in a program. However, I am not sure exactly how it would work in the middle of a line. Take the following code as a simple example:
loop:
dec c
jr nz, loop
If I wanted to replace loop with $ and an offset (so I can use this loop as a macro), would the "$" not account for the size of anything on the current line, in which case (I believe) I would need $ - 1? So the following code would be identical?
dec c
jr nz, $ - 1
2070
« on: August 12, 2010, 04:05:25 pm »
Pages: 1 ... 136 137 [138] 139 140 ... 153
|
Show Posts
Holy crap that deserves an A+ Imho. Thanks for that. So now I can continue making the game and There is a lot I don't know about. I'll edit this when i reach another problem.. (probably soon knowing me 
)