Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Magic Banana on June 07, 2010, 07:07:11 pm
-
Hey guys. Decided to try out Axe seeing as how I'm going to be taking some math classes at college. Anyway, I read Sir_Coding_Knight's tutorial, which was very helpful, along with some other things as well as the documentation so that I can jump into this.
The problem I'm having right now is that the collision for the tiles below and to the right work fine, but the tiles above and to the left are a little funky. The guy collides into them, but not before 1 pixel of him goes into the tile, and the only way he can moves is if he backs up, so he can't walk along the walls like the other ones. I've tried to change the offset (you'll see in the code) with a negative number, which would make sense, but that just makes things even worse.
My code is a little messy and not optimized, because I'm focused on getting the thing to work first. Any feedback would be appreciated.
:.TEST
:Full
:DiagnosticOff
:0→K+2→Z+22→X→Y
:[222222222222222222222222→GDB1
:[221111111111111111111122
:[221122000011110000221122
:[220000001122221100000022
:[220000001122221100000022
:[220022000000000000220022
:[220000000000000000000022
:[222222222222222222222222
:[40A0040A205002057EC3BDA5A5BDC37E54FCFCEFFF4A14362A3F3FF7FF52286C22373F777F32684C44ECFCEEFE4C16320040484002000000000202020000000000021202200000000040484004000000]→Pic1
:ClrDraw
:Repeat getKey=15
:If getKey(1)
:12→P:sub(C
:!If {{L1}}=2
:!If {{L1}+3}=2
:Y+1→Y:2→Z
:End:End:End
:If getKey(2)
:0→P:sub(C (<-Left it at zero because negatives mess it up more)
:!If {{L1}}=2
:!If {{L1}+1}=2
:X-1→X:5→Z
:End:End:End
:If getKey(3)
:1→P:sub(C
:!If {{L1}}=2
:!If {{L1}+1}=2
:X+1→X:4→Z
:End:End:End
:If getKey(4)
:0→P:sub(C (<-Left it at zero because negatives mess it up more)
:!If {{L1}}=2
:!If {{L1}+3}=2
:Y-1→Y:3→Z
:End:End:End
:For(S,0,11
:For(T,0,7
:{T*12+S+GDB1}→P
:P^16→Q:P/16→P
:If P
:Pt-On(S*8,T*8,P-1*8+Pic1:End
:If Q
:Pt-On(S*8,T*8,Q-1*8+Pic1:End
:End:End
:Fix 5
:Text(70,44,{{L1}}►Dec
:Text(80,44,{{L1}+3}►Dec
:Text(70,50,{{L1}+1}►Dec
:Text(80,50,{{L1}+2}►Dec
:Pt-On(X,Y,Z*8+Pic1
:Pt-Change(X,Y,(Z+4)*8+Pic1
:DispGraph
:ClrDraw
:End
:Fix 0:Fix 4
:ClrHome:Return
:
:Lbl C
:For(R,0,1
:{{L1}+1}→{{L1}+3}
:For(O,0,1
:(O*7+X)/8→S
:(R*7+Y)/8→T
:T*12+S+P→Q
:If Q^2
:{Q+GDB1}^16→{{L1}+O+R}
:Else
:{Q+GDB1}/16→{{L1}+O+R}
:End:End:End
Also, can anyone tell me how to attach images or the program itself so that they don't have to copy the whole code to test it out?
-
Hi, welcome to Omnimaga!
and for your problem, well, I can't help with Axe much since I haven't really done much Axe yet.
There will be other more experienced Axe users that can help you.
And you can start attaching images or programs once your post count hits 5.
-
Ah, well I better get my post count up then.
Yeah, Axe can be pretty crazy, but it makes more sense when you just keep at it. I've probably edited and recompiled this program over 100 times already, changing just a few things each time. Just wondering, is each compiled program supposed to be about 1.5x the size of the source? All of mine end up at about that size.
-
I don't understand why there are so many of these: {{L1}} a pointer in double brackets. If you really are using that as a pointer to a pointer, then you need to use the entire 16-bit pointer and not just read a single byte from it. But I don't think you're trying to double reference from what I see. Everywhere you have a {L1} should be just L1 I presume.
Also, it doesn't even look like L1 is initialized anywhere. You can't assume it starts out as all zeros, its usually random garbage.
-
Oh, didn't notice that. It looks like Cemetech slapped all those extra brackets in there when I parsed it. I'll post another without all those extras.
:.TEST
:Full
:DiagnosticOff
:0→K+2→Z+22→X→Y
:[222222222222222222222222→GDB1
:[221111111111111111111122
:[221122000011110000221122
:[220000001122221100000022
:[220000001122221100000022
:[220022000000000000220022
:[220000000000000000000022
:[222222222222222222222222
:[40A0040A205002057EC3BDA5A5BDC37E54FCFCEFFF4A14362A3F3FF7FF52286C22373F777F32684C44ECFCEEFE4C16320040484002000000000202020000000000021202200000000040484004000000]→Pic1
:ClrDraw
:Repeat getKey=15
:If getKey(1)
:12→P:sub(C
:!If {L1}=2
:!If {L1+3}=2
:Y+1→Y:2→Z
:End:End:End
:If getKey(2)
:0→P:sub(C
:!If {L1}=2
:!If {L1+1}=2
:X-1→X:5→Z
:End:End:End
:If getKey(3)
:1→P:sub(C
:!If {L1}=2
:!If {L1+1}=2
:X+1→X:4→Z
:End:End:End
:If getKey(4)
:0→P:sub(C
:!If {L1}=2
:!If {L1+3}=2
:Y-1→Y:3→Z
:End:End:End
:For(S,0,11
:For(T,0,7
:{T*12+S+GDB1}→P
:P^16→Q:P/16→P
:If P
:Pt-On(S*8,T*8,P-1*8+Pic1:End
:If Q
:Pt-On(S*8,T*8,Q-1*8+Pic1:End
:End:End
:Fix 5
:Text(70,44,{L1}►Dec
:Text(80,44,{L1+3}►Dec
:Text(70,50,{L1+1}►Dec
:Text(80,50,{L1+2}►Dec
:Pt-On(X,Y,Z*8+Pic1
:Pt-Change(X,Y,(Z+4)*8+Pic1
:DispGraph
:ClrDraw
:End
:Fix 0:Fix 4
:ClrHome:Return
:
:Lbl C
:For(R,0,1
:{L1+1}→{L1+3}
:For(W,0,1
:(W*7+X)/8→S
:(R*7+Y)/8→T
:T*12+S+P→Q
:If Q^2
:{Q+GDB1}^16→{L1+W+R}
:Else
:{Q+GDB1}/16→{L1+W+R}
:End:End:End
There, that should do it. It's initialized after running sub(C) for the first time,so it does start as garbage, but gets set to normal numbers after the first step in any direction.
EDIT:Attached the program.
-
Hmmm, interesting. I don't know if this would be an issue with part of it but could possibly some of the detection be off since front and back are 8*8 while the side views are 7*8? I haven't gone over your code to see what kind of collision detection you're using but that might be part of it but I don't know. Other than that though I don't know, still need to look at the code.
-
Hmmm, interesting. I don't know if this would be an issue with part of it but could possibly some of the detection be off since front and back are 8*8 while the side views are 7*8? I haven't gone over your code to see what kind of collision detection you're using but that might be part of it but I don't know. Other than that though I don't know, still need to look at the code.
Uh, I'm not sure what you mean by 7*8. The only time a 7 comes up is when I'm setting points on all four corners of the sprite. The original X,Y is pointing to the top left corner and the loops grab the other 3 corners of the same sprite. I'm pretty sure all of my sprites and collisions are 8*8, but there is still some reason why there's this strange error that I just can't put my finger on.
It's a lot easier to see what I mean if you test the program. I don't know how to make an animated gif, and I don't see any options for it in the TI Connect screen capture, just a single png.
-
Hmm... I can't tell if the locations for collision detection are accurate... I would try using the method I used in AXERPG. I was able to get collision detection there pretty easily even with a 8x16 sprite. You would have to adapt it to half byte compression, but that's really not that difficult since you would only have to modify that one subroutine and it looks like you already understand the math behind it.
-
To make a screen shot you need to have something like WabbitEmu (http://www.omnimaga.org/index.php?action=downloads;sa=view;down=488), which is in the Downloads (http://www.omnimaga.org/index.php?action=downloads) section.
What I'm saying about the 7*8 is that your side view displays 7*8 sprites instead of 8*8 like the front and back view.
1►███████
2►███████
3►███████
4►███████
5►███████
6►███████
7►███████
8►███████
▲▲▲▲▲▲▲▲
12345678
1►████████
2►████████
3►████████
4►████████
5►████████
6►████████
7►████████
8►████████
▲▲▲▲▲▲▲▲
12345678
I know you are using 8*8 hex, I'm just saying what is being displayed isn't 8*8.
-
To make a screen shot you need to have something like WabbitEmu (http://www.omnimaga.org/index.php?action=downloads;sa=view;down=488), which is in the Downloads (http://www.omnimaga.org/index.php?action=downloads) section.
What I'm saying about the 7*8 is that your side view displays 7*8 sprites instead of 8*8 like the front and back view.
I know you are using 8*8 hex, I'm just saying what is being displayed isn't 8*8.
OH, I see what you mean now. Yeah, I only took up 7 of the 8 columns for the side sprites, but all of the sprites were made in HEXPIC, so they are all in the 8*8 format (or should be, might have to make a test sprite that takes up every column to see if it makes a difference for sure).
@Quigibo:Sure, I'll take a look at that. Just making sure, grayscale doesn't affect collisions in any way, right? I don't think it would. I guess I'll look into half-byte compression. I know I saw a topic about it somewhere.
EDIT: Tested with an 8*8 box sprite, still no luck.
EDIT2: The collision looks great on yours, but the format is different. It really shows what Axe can do. I'll see if I can work something similar into my code, as I'd rather not just copy the whole thing and just paste my sprites over it. (how am I supposed to learn from that?)
EDIT3: AH! Finally got it right! The problem wasn't in the offset, but the pixels I told it to check themselves! It was checking 7 pixels behind where it was supposed to because I put the same coordinates that checked the right side for the left and the same for up and down.
Old code
:If getKey(2)
:0→P:sub(C
:!If {L1}=2
:!If {L1+1}=2
:X-1→X:5→Z
:End:End:End
...
:If getKey(4)
:0→P:sub(C
:!If {L1}=2
:!If {L1+3}=2
:Y-1→Y:3→Z
:End:End:End
New code
:If getKey(2)
:-1→P:sub(C
:!If {L1+2}=2
:!If {L1+3}=2
:X-1→X:5→Z
:End:End:End
...
:If getKey(4)
:-12→P:sub(C
:!If {L1+1}=2
:!If {L1+2}=2
:Y-1→Y:3→Z
:End:End:End
Now I've just got to optimize it.
-
I'm glad you got it to work!
I need to learn how to do the collision detection too :P
Hopefully these topics will help
-
mhmm nice that could eventually be helpful. I never thought about looking at Axe RPG for help. I wonder if it can run much faster without grayscale?
-
mhmm nice that could eventually be helpful. I never thought about looking at Axe RPG for help. I wonder if it can run much faster without grayscale?
Well, without grayscale, you can set it to Full, which would make it go about 2.5 times as fast. Also, I think that the Axe RPG is in grayscale-4, so putting it in grayscale-3 might make it speed up a bit as well.
EDIT: Just tested the demo in grayscale-4, grayscale-3, and monochrome. Surprisingly, they all seem to run at pretty much the same speed. They all took about the same amount of time to walk from one side to the other and back. Looks to me like the only noticeable thing between grayscale and monochrome is the support of Full. There might be a slight difference between each, but the program would have to be pretty big (graphics-wise) to notice.
-
Oh I mentionned about the grayscale removal because grayscale can slow down games a bit even in 6 MHz. I never tried 4 level myself, though.
One thing I wonder: is it possible to get decent speed off a smooth scrolling half-byte tilemapper with collision detection like in Axe RPG, assuming grayscale is removed and that when scrolling, only the edge of screen row/col of tiles are being updated?
-
Yeah, 4 seems to have more flicker, but I think that just may be the demo. It flickered when I took it down to 3 as well. I haven't had the time to work with grayscale in Axe yet, so I don't know for sure.
Oh man, that is a tough one. I spent many hours last night getting acquainted with half byte, and it sure loves to mix things up. So far I got static maps with semi-collision detection going. I haven't even gotten to scrolling it yet. I think it's still being worked on, and nobody has a definite solution to it yet.
-
I am sure the flicker can be reduced. Sometimes the grayscale just updates too fast and needs to be updated less often. It's because of the crappy LCD driver
EDIT: Nevermind. The reason why the RPG demo is so slow compared to stuff like Half Life 2D or Portal X is because he redraws the entire tilemap every frame
-
HL2D redraws every frame...
Also, I have a one-nibble per tile method that includes scrolling, I can post more about it later, probably in its own tutorial.
It doesn't do smooth scroll, but I'm sure I can figure it out.
-
really? Strange. I wonder why the Axe RPG demo framerate is so low then x.x
Did I miss a Pause command somewhere or sometthing or does 4 lv grayscale really slow things down this much??
-
4lv grayscale hasn't been too slow for me. I haven't placed it in a production quality game yet, but I haven't noticed a signifigant slow down. Someone should try disabling interrupts during a 4lv gs program and seeing what happens, that will give me a better idea of what's going on behind the scenes. (I don't have a calc this week)
-
I just tried running the RPG with no grayscale and it seemed about twice faster. My guess is that HL2 probably used some cool optimizations to make it run this fast
-
HL2 isn't in gray
-
I know. I was talking about the RPG map engine Quigibo included with Axe. It's considerably slower than HL2. That's what I was saying.
-
Oh, I see. I'll try and throw together an engine later today. I have an emulator to test it on, so I can try and post something later.
-
cool
-
When you draw sprites in grayscale, you are drawing twice as many sprites as monochrome since you need to draw to both the front and back buffer layers, and 4 times as many if you need to mask any of those sprites! Also, the flickeryness is my fault, I've already written a better looking routine with the help of calc84maniac.
-
aaah that explains the slow down x.x
When testing I forgot to remove the additional sprites display commands x.x
EDIT: THis is how fast it displays with no grayscale sprite storing
-
Also, you can run the grayscale like this if you want to have 15MHz as much as possible:
:Normal
:Dispgraph^r^r
:Full
-
Huh, I guess I just really didn't go in depth when I tested it. I basically just removed the 1 or 2 commands that draws the grayscale, but what you guys are saying makes sense. I was pretty tired when I tried it out so I guess I wasn't thinking too much about it.
Also, you can run the grayscale like this if you want to have 15MHz as much as possible:
:Normal
:Dispgraph^r^r
:Full
Oh, never thought about it like that. I was just thinking that if you used grayscale you couldn't use full, but it looks like it's only for those commands. I'll be sure to keep that in mind when I jump into grayscale.
-
I think that can slow things down a bit if all your loop does is refreshing grayscale, though. In that case it's best to put the normal command before the loop and the full one after
-
The normal and Full commands are negligible. I think they're 10-20 clock cycles whereas the grayscale drawing is in the order of tens of thousands of clock cycles. Also, all the drawing commands, both monochrome full speed, monochrome normal, 3-level grayscale, and 4-level grayscale take very close to the same amount of clock cycles since the LCD requires the same delay no matter what you're drawing. The ones that are currently slower are fixed in the next version. The only real slowdowns are going to be from drawing the sprites.
-
So, even if everything is drawn in monochrome, games that are graphic intensive will still take a whole lot of clock cycles, with or without Full? It will still run the rest of the program faster though if Full is used, but just not 2.5x fast, right?
-
No, just the opposite. Graphic intensive programs are going to be doing a lot of sprite drawing, especially when they have to draw to 2 layers, so those are going to be sped up and the screen is only updated at the end of all that. On the other hand, if you only draw a few sprites, but still update the screen constantly, you won't get much of a speed increase using Full since most of the cycles are being spent refreshing the screen which takes a fixed amount of time regardless of speed.
-
Ah, alright I think I got it now. So it's just when DispGraph is called a lot that programs slow down, because there is no way to speed that up. So, as long as DispGraph (or DispGraphr) is called only a few times, it doesn't really matter how many sprites you draw, because none of them are displayed until you tell it to display it on the LCD. So the only reason for slowdown on the grayscale graphics is (besides the obvious extra space) because of the extra calls to DispGraphr and DispGraphrr, right? This is making a lot more sense now. :)