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 - Quigibo
Pages: 1 2 3 [4] 5 6 ... 135
46
« on: February 05, 2012, 03:46:21 pm »
Oh... Perhaps you should change the commands list description of Pt-Mask()r then:
"Areas clear on both layers are transparent and the other combinations are black, white, and invert."
That says to me that 00 is transparent, and then the logical conclusion is that the other combinations are listed in ascending order.
Yeah, maybe. I just put them in an arbitrary order because I though since I had said it was masked, the masking combinations would just be regular masking (00 01 and 11) with the extra combination an invert. I guess I'll change the order I show in the commands list, but its hardly more logical. Just because you were thinking of binary ascending order, doesn't mean someone else will.
47
« on: February 05, 2012, 06:07:03 am »
For Pt-Mask()r, actually:
00 = transparent
01 = white
10 = xor
11 = black
48
« on: February 03, 2012, 04:56:19 am »
Hmm, you bring up a good point, I was only testing it on the homescreen before. I will try to make this look cleaner at a low byte cost.
49
« on: February 02, 2012, 11:24:04 pm »
So the main thing I wanted to talk about in the new release is the new "Axe Fusion" compile option. I was previously calling this "Axe Framework" but fusion is more literal to what is going on, implies that it requires Axe, and sounds cooler. To reiterate, what this option does is not add ANY built-in Axe routine to your program. These include things like All DispGraphs, all Sprite commands, all drawing, advanced math, etc. Instead there is a tiny routine routine added to the start of the program that finds the Axe app and steals the routines from there (like a shell). The header in Fusion files is literally identical to the Ion header and it should still work in all major shells. In the end, this reduces code size a lot, usually over 10% sometimes higher than 20%. Keep in mind that this is a beta feature, meaning it is very unstable right now. First of all, I would not recommend publishing Axe Fusion programs on sites targeted to end users because those programs may not work with future versions of Axe. Second of all, I'm not sure if it is working with Axioms right now, I didn't have time to check. So basically, I added this feature prematurely so that you can all test it out and tell me what you think. How much is it reducing your code sizes? 
50
« on: February 02, 2012, 11:10:38 pm »
Axe Parser
Omega 1.1.2
Happy 2 year anniversary to Axe!  Some very cool and game-changing features here to celebrate... New Features:- Shiny new commands list! Thanks to Etienne Gauvin!
- [Beta] New compile setting to reduce executable size: "Axe Fusion" (But requires Axe to run)
- Axioms can now define their own custom token replacements. Thanks to Runer112!
- Optimized sprite commands, Z-Test(), and more!
- The "equal" and "not equal" operations can be used in constant expressions.
- New command to give default values to undefined constants.
- Pt-Mask()r now works on any buffer.
- Circle() now works on any buffer.
- New optimized shorthand for screen buffer copying.
- New command to retrieve an indexed string from a list of strings.
Changed:- Removed default Axiom tokens, but you can add them back to your Axiom if you used them.
- Axioms can now be redefined multiple times with no effect on the program.
- Fixed documentation of EndIf command.
- Z-Test() will throw an error if used in a for loop instead of crashing.
- Fixed some syntax bugs with files.
51
« on: January 31, 2012, 10:18:10 pm »
Quigibo: I've had a few premature run-throughs with compilers before. Last time, I went through and changed some key rules which really affected parsing and verification rules for classes & interfaces. I do have a couple aspects already in place; However, the new design is free of MUCH of that red tape (since it lacks a type-hierarchy), so I might be able to put more up sooner (school etc. permitting) How are you creating the parser? Changing rules should be simply a matter of changing a line or so of code. When I wrote my python compiler, it was programmed as an LR parser using Bison as my Parser-Generator. You simply tell it the rules line by line and it generates an abstract syntax tree from any source or gives an error if it cannot match. Here is an example of what rules look like for a simple language: input:
expr TOKEN_SEMICOLON
expr:
expr TOKEN_PLUS expr
| expr TOKEN_MULTIPLY expr
| var TOKEN_ASSIGN expr
| var
var:
char
| char var
char:
TOKEN_A
| TOKEN_B
etc.Changing a rule should be very very easy in Bison, even extreme changes! Again, I'm not sure what method you're using, but if you're doing recursive decent or some other inefficient method, I would recommend switching because a compiler-compiler will produce code that is faster and more accurate than a human would write, and its way easier.
52
« on: January 31, 2012, 09:28:35 pm »
I think the "Done" covering the text is the normal behavior and that the emulator you are using is incorrect. Regardless, I would add a res 5,(iy+0) to the beginning of the program which tells the OS to not display "Done" at the end. Also, I recommend WabbitEmu instead as it has more features and emulates more accurately.
53
« on: January 30, 2012, 04:52:13 pm »
There are advantages and disadvantages of both design techniques. Certainly by spending more time engineering a well thought-out syntax you end up with a more consistent language. There are definitely several areas of Axe that I wish I had planned out more before it became too late to change such as Boolean operators, function call syntax, variable referencing, and even token choice. You do however get the advantage of instant feedback by releasing earlier, not from a feature standpoint, but from an efficiency/trade-off one. I think the best thing to at least build the parse tree part of the compiler (without releasing it) and add the features you have designed so far. If you're programming it correctly in a massively inheritable object oriented way, this should be extremely easy to add and remove features at around the same speed you can come up with them on paper. It also allows you to program in your language and get a feeling for how the actual flow will end up in the parse tree. Just a suggestion
54
« on: January 30, 2012, 04:26:16 pm »
What were the 2 models of calculator? I know in particular, Nspire calculators are not as precise in their emulation timing.
55
« on: January 30, 2012, 02:57:48 am »
I'm currently in the process of merging the token replacements. However, one problem I see is that subprograms would not be able to use the replacements because they would each be unaware of which program is the parent (and there could be more than one with different axioms).
To solve this, the #Axiom() command will now be ignored if it's been imported already. Currently, #Axiom(A):#Axiom(A) either throws an error or puts the axiom on the stack twice (which will quickly fill up the 5 Axiom limit). This way, you can redefine the relevant Axioms again in each sub-program to see the token replacements in the editor, and the code will compile as expected without error.
Runer, I'm also changing your new suggested syntax of the SDK. Its basically the same except it doesn't have $C0DE again nor the size. It knows the size of the Axiom ahead of time and can use that to determine how many token replacements to import. So it's still reverse compatible and simpler to write because you simply list them after the $0000.
56
« on: January 26, 2012, 01:09:47 am »
Weird in that it must be constant rather than variable. I see this as being confusing to beginners also due to the parser-interpreting which isn't intuitive without explanation.
57
« on: January 26, 2012, 12:21:04 am »
There is already an optional buffer argument, I can't use that spot for mode unless you're talking about an optional 6th argument but its a weird syntax since the 0 or 1 is part of the syntax rather than a variable.
58
« on: January 25, 2012, 10:23:05 pm »
Well... I could do what I did for the Rect() command in that there are only options for "Black" and "Invert". You would just have to draw both of them to get white. That's probably what I'd do. But even more important than that, what I really REALLY want is line clipping. I have yet to find an algorithm simple enough to implement efficiently in z80 but I challenge anyone to write a routine for it
59
« on: January 25, 2012, 10:14:01 pm »
Also I think he meant actually erasing the tile from the screen. Parser you can do that by drawing a Rect( and a RectI( at the coordinates of the tile.
...or a single Pt-Off() if the tile is 8x8. If its smaller than 8x8 you can use Pt-Mask()r to erase and redraw the new tile just like Pt-Off().
60
« on: January 25, 2012, 10:07:22 pm »
Request:
Option to turn off the progress bar and just show percentages like in old versions for faster compiling, or alternatively have it be off by default for zoomed compiles
Its essentially the same speed, it takes almost the same amount of time to display the percentage bar as it did just displaying the percent. However, this can be sped up by maybe 15% if I display nothing at all, but that's a bad experience for the end user since they feel like it freezes. It wouldn't be that much faster anyway, its not like its double the speed or anything. I am still considering adding a white line command but there is no token for it. Adding an extra argument is unoptimized and I don't want to invent some obscure syntax for it either. I would probably end up overwriting the Plot3() token instead. The routine is large though, just as large as the black line drawing, so only use it if you absolutely have to and need more speed than the DrawInv method. Of course, if you decide to use the experimental Axe Framework, this is never an issue  .
Pages: 1 2 3 [4] 5 6 ... 135
|
Show Posts