How about this?

Here is a pretty small method for pixel-based sprite collision checking. Whereas your previous combination of 22 hard-coded pxl-Test() checks weighs in at a whopping 620 bytes, this routine is 99 bytes. As you might expect from this loop-based approach, though, it trades size for speed. Whereas your previous method would take about 9,000 cycles, this method will take about 26,000 cycles for your sprite.

Another great thing about this approach is that it, instead of using a large list of X and Y offsets for each pixel that you want to check, it simply reads from a sprite. This means that this routine can be adapted to any sprite by simply changing the Pic0 reference to point to your 8x8 sprite. However, this also means that is slowed down additionally by checking pixels inside of the sprite, which you may not need to check. You can get rid of these unnecessary checks by having this routine read from an 8x8 sprite only containing the collision points (probably the border). If you added another 8x8 sprite containing the 22 collision points you used in your hardcoded method, you would be adding 8 bytes for the sprite but subtracting about 6,000 cycles from the collision checking.

Code: (99 bytes, ~26,000 cycles if no collision (based on Scout's helicopter sprite)) [Select]

8
While 1
  -1→T    .that's a subtraction sign
  {+Pic0}→U
  8
  While 1
    -1→S
    If U^2
      If pxl-Test(X+S,Y+T)
        Goto COL
      End
    End
    U/2→U
  End!If S
End!If T


I voted yes in the poll. I have seen numerous examples of people having a bug in their program because of unclosed parentheses. However, because they think it's okay to leave parentheses open, rarely do they find their bug. It only turns out that after they post their source code in a help thread, someone else who closes their parentheses discovers the bug. And even then, it's an elusive bug to find for people who do know that closing parentheses is important. In my experience, all it produces is messier code and more errors.

Just a wild guess, are you trying to send Pokemon over a mini-USB cable? If so, there's some odd bug that prevents you from successfully sending Pokemon over USB. Try using a serial cable if you have one, or if not, try a different game.

You would want to have this code execute when your sprite is not currently on screen, so before you draw it. Note that if a collision is detected, this routine would jump to a Lbl COL, so you would need to add this as your collision handler.

A base 10 logarithm routine should be a piece of cake. This takes 57 cycles in the best case scenario (result=4) and 143 cycles in the worst case scenario (result=1). It's 32 bytes.

Log10:
ld de,4
ld bc,-10000
add hl,bc
jr c,Log10End
dec e
ld bc,-1000-(-10000)
add hl,bc
jr c,Log10End
dec e
ld bc,-100-(-1000)
add hl,bc
jr c,Log10End
dec e
ld a,l
add -10-(-100)
jr c,Log10End
dec e
Log10End:
ex de,hl
ret


It works fine for me. Is the Axiom on your calculator, and does your program contain #Axiom(LCDKIT)?

To flip the LCD:

R►Pr()            Turns horizontal and vertical flipping off; only works on newer calculators
P►Rx()            Turns horizontal flipping on and vertical flipping off; only works on newer calculators
P►Ry()            Turns horizontal flipping off and vertical flipping on; only works on newer calculators
R►Pθ()            Turns horizontal and vertical flipping on (rotate screen 180 degrees); only works on newer calculators

LCD flipping is only supported on fairly new calculators. Older calculators' LCD drivers did not have this flipping feature.


Z-addressing changes how LCD RAM is mapped to the screen. The z-address can be a number from 0 to 63, and is normally set to 0. This means that normally, row 0 of a buffer image would be displayed at row 0 on the screen. However, the output on the screen can be shifted vertically by changing the z-address. The value of the z-address determines which row in the buffer image would be displayed at row 0 on the screen. For instance, if you set a z-address value of 8, the screen would effectively be shifted up 8 pixels because row 8 of the buffer image would be mapped to row 0 of the screen. Rows 8-63 would be shifted up 8 pixels and rows 0-7 would appear at the bottom of the screen, having wrapped around from the top. Z-addressing could be used for something like an earthquake effect by changing the z-address between 1 and 63, which would shift the screen 1 pixel up and 1 pixel down, respectively.

To set the z-address (this token is found under VARS > Statistics... > TEST):

→z                  Sets the z-address

Quote from: Compynerd255 on April 26, 2011, 10:29:02 am

Quote from: Freyaday on April 26, 2011, 10:42:15 am

As an addition to the signed For Loop, Could there be a loop that automatically increments negatively or positively so that the loop always runs?
Like, say,
For(Q,A,B,C)^rr
where C>0, would increment by -C if A>B and C if A<B

This doesn't seem like a loop structure that would be widely used, especially since modern programming languages don't have loops like this. This is the kind of thing that you would best build a custom loop for.

Why shouldn't Axe be the first, then?

Because, in all fairness, that's not a very practical loop structure. Quigibo doesn't want to bog Axe down with commands that will rarely be used or can easily be otherwise produced with the existing features. Technically both For() loop feature addition suggestions qualify as being able to otherwise be produced, but the For() loop with a variable increment is a fairly widely used loop structure in many programming languages and I think would make sense to add.