Using a constant pointer like Str1 instead of a variable pointer like A is an optimization technique. Both methods will produce the same end results. But if you use a constant, your code will be smaller and faster.

The issue is the line with the inline conditional. It's not treated as TI-BASIC experience may suggest, like this:
(K?-1,9)→{I+2}

It's treated like this:
K?(-1),(9→{I+2})

So with your current code, P=0 will select Pic0, but no other values of P have any effect because the store statement is not executed. To fix this, add the parentheses as shown in the first line of code. Alternatively, use the code I suggested in my previous post since it's more optimized anyway.

Here's a simple, fairly optimized way to do what you are trying to achieve. I have detailed most of the optimizations in comments in the code, but I did not comment about the biggest optimization. This optimization is to draw sprites from a variable pointer, instead of requiring four different copies of the whole loop just for facing in different directions. For instance, here's the line I used to initialize the player sprite to the right-facing sprite:

:2*8+Pic1→S

If you're familiar with how this works, then go ahead and skip to looking at the code to see the final product with the rest of my suggested simple optimizations. If you're not familiar with how this works, I'll give a quick explanation. Because of how Axe includes data like sprites, the order in which you list data (like sprites) is exactly the order it will assume in the compiled program. Since each sprite is 8 bytes, that means that each successive sprite is found in memory 8 bytes after the previous sprite. Pic1 points to the start of the block of 4 sprites, so it points to the first one, the down-facing sprite. 2*8+Pic1 would point to the data 16 bytes after the down-facing sprite, which we know is the right-facing sprite because it's 2 sprites (remember, a sprite is 8 bytes) after the down-facing sprite. This offset from Pic1 logic is used to draw the proper sprite for facing in all 4 directions.


So here's my suggested fairly optimized and hopefully easy-to-understand solution:

:.AXETEST
:identity(3FFC3FFC30CF30CF300C300C0C300C303FFC3FFC330C330C3FFC3FFCF00FF00F)
:
:[]→Pic1
:[7E665A247EC37EC3] .DOWN
:[7ED242247E4A7EC3] .LEFT
:[7E4B42247E527EC3] .RIGHT
:[7E7E42247EC37EC3] .UP
:
:.START FACING RIGHT AT (0,56):
:2*8+Pic1→S
:0→X
:56→Y
:.THIS DOESN'T NEED TO BE INSIDE THE LOOP:
:StorePic
:
:While 1
: Pt-On(X,Y,S)
: DispGraph
: .ERASING WITH Pt-Change() UNNECESSARY BECAUSE:
: RecallPic
: If getKey(1)
:  Y+2→Y
:  0*8+Pic1→S
: End
: If getKey(2)
:  X-2→X
:  1*8+Pic1→S
: End
: If getKey(3)
:  X+2→X
:  2*8+Pic1→S
: End
: If getKey(4)
:  Y-2→Y
:  3*8+Pic1→S
: End
:.OPTIMIZED POST-CHECK LOOP:
:End!If getKey(15)


---

Now, if you want really optimized code... That can be arranged. I'll leave figuring out how it works as an exercise.

:.AXETEST
:identity(3FFC3FFC30CF30CF300C300C0C300C303FFC3FFC330C330C3FFC3FFCF00FF00F)
:
:[]→Pic1
:[7ED242247E4A7EC3] .LEFT
:[7E7E42247EC37EC3] .UP
:[7E4B42247E527EC3] .RIGHT
:[7E665A247EC37EC3] .DOWN
:
:56→Y
: and 0→X
:→S
:
:While 1
: ClrDraw
: Pt-On(X,Y,S*8+16+Pic1)
: DispGraph
: If getKey(1)-getKey(4)
:  →S
:  *2+Y→Y
: End
: If getKey(3)-getKey(2)
:  -1→S+1
:  *2+X→X
: End
:EndIf getKey(15)


Or, a much simpler and prettier way:

:"AB"[22]"DE"→Str1

 

Whenever variables are rearranged in RAM (for instance, deleting any variable that's not the last variable in RAM), the pointers at these two locations are adjusted according to where the variable they point to/into has moved. asm_sym_ptr1 and asm_sym_ptr2 act similarly, except they track VAT entries.

What Eiyeron discovered isn't so much of an Axe bug as it is a lack of a feature that Axe really should have. The issue is that, in the process of deleting or recreating an OS variable, other variables in RAM may be shifted. A common instance of this would occur if your program creates a variable, and later deletes or recreates an OS variable that existed before your program started, then the pointer to the variable you originally created would be invalid.

This is not an issue that an Axe user should need to debug/solve. My identification of the issue required a knowledge of assembly and how the OS structures RAM, and my formulation of the proper solution required a knowledge of an OS feature only exposed to assembly programmers. The behavior Eiyeron saw would most certainly appear to be a bug without this knowledge, thus I do not believe that he should be penalized in any way for asking for assistance with a problem that is not his fault.

---

Here is my suggested solution for anyone having this issue. For up to two OS variables that you keep a pointer to for the duration of the program, the OS can automatically update the pointer if it moves. To take advantage of this feature, I would suggest putting the following one or two variable definitions in your program:

ᴇ84EB→°V1
ᴇ84ED→°V2
The names can be whatever you like, they don't have to be V1 and V2. And if you only need to keep track of one OS variable, you only need one of these definitions. In the body of your program, use these variables instead of standard variables to hold pointers to OS variables that you need to keep track of through possible deletions/recreations of other OS variables.

Quote from: Deep Thought on March 23, 2012, 12:39:09 am

Thanks! This is my first time playing with raycasting. I learned it from http://www.permadi.com/tutorial/raycast/index.html (top Google search result, anyway) and I really recommend it if you want to learn.

Exactly how I learned, too. I think this is a magic tutorial.

Take a guess where my knowledge for YAAR came from.

In retrospect, maybe it would have been better to make Fix # turn an option on and Fix #^r turn the option off. But that would definitely break compatibility now

What if the old syntax was left in for compatibility, but a new syntax of Fix LETTER / Fix LETTER^r was added? Letters might be easier to remember than numbers anyways.