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 ... 33 34 [35] 36 37 ... 153
511
« on: October 07, 2013, 10:15:23 pm »
But those return completely different things..? I realize that in the context of a conditional like If I>1, dividing by 2 will result in the same conditional branch being followed, but people can use it in computations as well. If you want the optimization in the context of conditionals and understand the different return value, you can always do it manually.  Axe doesn't really have great capability to perform context-sensitive optimizations that only trigger in certain scenarios. I don't think the peephole optimizer's current state (the system that seems like would be responsible for such an optimization) could even support making this optimization only in if statements.
512
« on: October 07, 2013, 01:26:31 pm »
Can you clarify what you mean, perhaps showing it in code and how it should be optimized?
513
« on: October 05, 2013, 11:56:39 am »
This has always been a bit of a design issue with the current Axiom system. The .org $-1 in the REP_NEXT macro ensures that the program counter variable is correct for the rest of the command when the 1 byte from the .db $7F is removed during compilation. However, subtracting one from the program counter variable has the side effect that, at the end of the command, the program counter will be [# of REP_NEXT's used] less than the actual size of the command's source code, which includes .db $7F bytes from REP_NEXT instances. This means that the common way of including the size of the command in the header by just putting a label at the end of the command and using that as the size (provided you start the command with .org 0) will result in the size value being [# of REP_NEXT's used] too small.
Solution: The simple but dirty solution is to simply count the number of REP_NEXT's used in the command and add that to the size value in the header, which in your case would be .dw AXM_4_END+1. Also, if you ever use any OFS_NEXT(#) macros, make sure to add 2 for each of those used.
514
« on: October 04, 2013, 12:54:42 am »
Exch() seems to work as expected, with one level of indirection, for me.
515
« on: October 03, 2013, 08:03:49 pm »
Plop,
In Axe 1.2.1a, Exch() seems to use indirection twice. To exchange two bytes situated at for example L1 and L2, I had to do :
:L1->r1
:L2->r2
:Exch(°r1,°r2,2)
I don't believe anything has changed with Exch() in a long time, so I'm not sure why that behavior would occur. Can you supply a bit more background information, like the code around that and where it becomes clear that it has gone wrong?
516
« on: September 30, 2013, 02:15:34 am »
Thanks DJ, Sorunome, and Streetwalker! Here is video showing off the random level generator. The game will be in full resolution using 16 bit images.
Is the camera playing tricks on me, or are those maps appearing near instantaneously? The full maps appear to pop in much faster than I thought 320x240 pixels could be pushed. (somewhere from 1/3rd to 1/6th of a second?)
517
« on: September 27, 2013, 10:14:19 pm »
518
« on: September 26, 2013, 12:37:23 pm »
Using custom names for this might make your life easier, since your data is really just 1-byte variables and there's an easy way to access 1-byte variables: Nameʳ. Here's how it would look converted to use them, also with some other minor optimizations:
.TEST
1→X→Y
Fix 5
L₄→°X1+1→°Y1+1→°X2+1→°Y2
.Initialization of vars above not necessary, will be set in first loop iteration
ClrDraw
While 1
If getKey(1)
Y+1→Y
End
If getKey(2)
X-1→X
End
If getKey(3)
X+1→X
End
If getKey(4)
Y-1→Y
End
X→X1ʳ→Y2ʳ
Y→Y1ʳ→X2ʳ
Pt-On(X1ʳ/2,Y1ʳ/2,[FFFFFFFFFFFFFFFF])
Pt-On(X2ʳ/2,Y2ʳ/2,[FFFFFFFFFFFFFFFF])
DispGraphClrDraw .for speeds!
EndIf getKey(15)
519
« on: September 26, 2013, 02:21:39 am »
Can you provide the code in question?
Also, it makes me cringe a bit inside when people refer to arbitrary data in Axe as "GDB's". The GDBX tokens are just a particular set of many equally allowable symbols in named pointers to any kind of data! You can call a pointer to any type of data whatever you want, whether it be GDB1, Str1XY, Pic789, °Stuff12345, or whatever.
Note: this isn't a personal thing, I'd just be happy to see a misleading and unfortunately common misconception due to archaic Axe syntax be made less common. (maybe even eradicated eventually?)
520
« on: September 22, 2013, 08:38:47 pm »
IMPORTANT PREFACE: Strings used by the OS are all strings of tokens, not characters. This means that my first example below would not work if I used "Hello", because although the 'H' character and token codes are the same (all letters, numbers, and some symbols have this characteristic), lowercase letters are two-byte tokens and not equal to their one-byte character codes.
Now that that's out of the way, here's a quick example of how you could store the string "HELLO" to Ans:
Copy("HELLO",GetCalc([04720000],5),5)
And here's a slightly less simple example I made for fun that would convert an 8x8 sprite pointed to by S into a hex string in Str0:
If GetCalc("Str0",16)
→O
S
For(8)
Select(,{{}►Hex+2}ʳ→{O}ʳ+1→O)+1
End
End
521
« on: September 22, 2013, 04:36:26 am »
Well actually it doesn't matter what you have in the last pixels as the Bitmap( command will crop it anyway. 
It does matter. For efficiency reasons the routine only keeps track of the byte width (pixel width/8) of the sprite when drawing it, so really it always draws sprites that are some multiple of 8 pixels wide, meaning all 8 bits of the final byte are drawn. That's why the documentation says that the end of each row should be padded with 0 bits, as drawing the extra 0 bits with OR or XOR logic doesn't actually change anything. The fact that the width specifier in the sprite data is in pixels really just for convenience purposes, although I see how it could be misleading.
522
« on: September 21, 2013, 11:15:24 pm »
The OS solves this by reprinting the character that was under the cursor when it moves or blinks off. Is there a reason why this isn't feasible here? This can either be done the OS way by looking up what character was under the cursor and reprinting it, or you can use Axe's pt-Get() command to copy the 8*8 "sprite" under where the cursor is about to be drawn to memory, draw the cursor, and then redraw the copied sprite later to erase the cursor.
523
« on: September 21, 2013, 07:24:39 pm »
Drawing triangles (and other arbitrary shapes) is pretty tough. I think such a routine would be cool too, but I can't see it fitting (literally) into Axe for now. Perhaps this Axiom by Matrefeytontias could help? The triangle drawing command is only intended for use in 3D rendering as far as I can tell, but perhaps that's what you wanted it for anyways and it's an extra bonus?
524
« on: September 21, 2013, 03:31:18 am »
All my stuff has been addressed! Awesome!  The MathPrint toggle should actually be pretty useful if I'm ever doing serious math on my calculator. I played with it for a bit and noticed a few things: - Changing from Classic mode to MathPrint mode leaves the entry history intact, but changing in the other direction does not. Why is this? The entry history seems to stay intact when changing modes the old-fasioned way from the mode screen.
- Changing from Classic mode to MathPrint mode sometimes doesn't return the cursor to the top left corner of the screen, and sometimes that happens as well as text being left over from Classic mode. The first case is definitely a bug, and the second case is probably two bugs in one, although it's actually pretty cool when the second bug happens. It seems like switching modes almost invisibly.
- Regarding the shortcut to enable MathPrint not working unless it has already been enabled once: perhaps the above bug is somehow related to it? If not or you otherwise can't easily see how to fix it, can you do something sneaky to always let MathPrint load up on RAM clears, but after it has been enabled, immediately switch to Classic mode if that default is set?
Also, another thought popped into my mind. You know how a while ago I mentioned that Omnicalc's quick apps menu doesn't register a context change until after any executed app returns to the OS? That may be a hard Omnicalc issue to fix, but I realized there are other issues with Omnicalc that might be (perhaps more easily) fixable. For instance, enforcing that parentheses assistant, the entries menu, and RAM recovery are disabled when MathPrint mode is enabled, and returning them to their original settings when Classic mode is enabled. It also may or may not be feasible to kill the partial line clear functionality when MathPrint mode is enabled. (I got the impression that you try to keep your key hook fast by only having ON+___ shortcuts so you can abort if ON is not pressed, but this check would need to occur before that)
525
« on: September 19, 2013, 12:09:40 pm »
An computer Axe Interpreter would just be awesome!
didn't jacobly start on one?
* Runer112 looks at the topic we're in Although I think this isn't an interpreter, I believe it compiles Axe straight into x86 assembly. The latest version is here.
Pages: 1 ... 33 34 [35] 36 37 ... 153
|
Show Posts