Is it possible to make the following code smaller?
If A=11:Then 10→A:X+1→X End
i think this is better
Correct me if im wrong
If A=11 10→A:X+1→X
This doesn't do the same thing. Regardless on if A is equal to 11 or not, X will be incremented. We want X to be incremented only if A is 11.
how about this
otherwise you will just need to keep it as it is
if you take out the Then and the End you will get an X that is larger than you want it
That's actually three bytes larger.
Using the methods I know directly, I cannot compress it.
EDIT2: Must have been tired or dumbfounded at the time. The code wouldn't have worked anyway.
A person asks for an orange, another delivers a grapefruit, and no one seems to take notice…
Not one of the snippets posted in this thread retains the function of the original. Why are we adding to A? What can we expect from our attempt to alter X if A has already been changed? Dare I ask, why is there a lack of testing our own work for correctness? There's no perceivable harm in doing so, and mistakes are made only in not trying.
Here's an orangelo:
This works closer to what you had in mind. Now trouble is caused only if A is coming in from the positive direction.
No, I don't have to explain that.
For true optimization purposes, it would help to see the context of this code as it appears in the main program. I have a sneaking suspicion that one of those variables isn't even necessary.
A is used for player location and X is used for scrolling the map. Here's my code:
repeat 0 getkey→K real(2,0,X,Y,12,8,0,12,0,8,0,0,8,0 real(1,8A,8B,1,8,0,1,0,0,0,1 A-(K=24)+(K=26→C B-(K=25)+(K=24→D If not([A](D+1+Y,C+1+X)):Then C→A:D→B End If B=7:Then 6→B:Y+1→Y End If B=0:Then 1→B:Y-1→Y //These lines detect need for scrolling End If A=11:Then 10→A:X+1→X End If A=0:Then 1→A:X-1→X End If fPart([A](D+1+y,C+1+X))!=0:Then //special space collision detection fPart([A](D+1+y,C+1+X))→Z ∟MAP(Z10→L prgmθCHK End End
So, there's code to go the other 3 directions as well. Good to know.
Thanks alot! Your code works except there is no down. When I press down nothing happens, but when I press left the person goes down and left one.
For 0≤B≤7, 1+int(Blog(7 brings the ends closer to the median without afflicting 1 through 6, and the distance from this expression to B is the expected step of Y. Same story for X, but with the appropriate factor for contraction. I believe you typed it in wrong.
The actual usage of either
depends on what you want. The first one is smaller but slightly, very very slightly slower whereas the second is bigger but faster. Since the original question was about how to compress it I assume you'd be better of by taking Weregoose's method.
Speaking of Weregoose, you really are the master of optimizations are'nt you?
As established, the second of those doesn't work, and the first works for A≤10 and A=11.
I honestly can not see the mistake in the second one…
The first one is smaller but slightly, very very slightly slower whereas the second is bigger but faster.
Output: 70 seconds.
Output: 75 seconds.
These results remain when 11→A replaces 0→A.
Hmm that is weird I ran 500 iterations and came around 3 seconds for the first one and 3.23 for the second. I did however test it on a emulator but It shouldnt really matter…