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 ... 47 48 [49] 50 51 ... 153
721
« on: December 18, 2012, 07:25:39 pm »
I would just like to remind people that making all of $C000-$FFFF executable is entirely possible. For example, see Fullrene.
722
« on: December 17, 2012, 08:50:04 pm »
Freyaday, this behavior is not the result of an Axe bug. This is a result of your use of the parametric variables, which changed with Axe 1.2.0. I think I recommended not using them as general-purpose variables a while before 1.2.0 was released, by the way. 
723
« on: December 17, 2012, 12:18:49 am »
So I just released a new version of Axe about 4 hours ago... and I managed to screw up the flagship feature. So I have quickly fixed it and replaced the bad 1.2.1 with 1.2.1a!
If you were one of the five who downloaded Axe 1.2.1 already: go get the fixed version.
For everybody else: what crippling bug? I would never make such a silly mistake, what are you talking about? I don't see it anywhere.
724
« on: December 16, 2012, 08:01:22 pm »
Axe Parser
Omega 1.2.1
As expected, I introduced some issues with 1.2.0. So here's a few bug fixes and improvements, with some new features to boot! New Features:- BIG NEWS: Every geometry drawing command (lines, circles, and rectangles) can be drawn as black, white, or inverted! For black, use them as normal; for white or inverted, put a W or an I right before the command.
- New HLine() and VLine() commands (also in black, white and inverted). That's the letters H or V followed by the Line( token. They can be used to draw all the way across the screen, like HLine(Y), or line segments, like HLine(Y,X1,X2).
- New 8*8 sprite routine: Pt-And(X,Y,SPRITE) (this is the Plot3( token).
- Added For(EXPR)r, which treats EXPR as an 8-bit value; good for really fast, compact loops with a variable number of iterations.
- Added LnRegr, which repairs what custom interrupts destroy (table data). Please use this instead of the normal LnReg when disabling custom Axe interrupts!
- Constant expressions can now be included in blocks of inline assembly. For example: Asm(11(°Data+8)) to include a 2-byte value, or Asm(3E(°MapW)r) to include a 1-byte value.
- To help fix future bugs, you can now press STAT upon errors during compilation to dump a bunch of data. Copy it down and send it to me, and it should hopefully make isolating strange bugs easy!
Changed:- Adjusted the 4-level grayscale routine masking code to look *nearly* as good as pre-1.2.0 with the speed of 1.2.0.
- Moved custom interrupt data out of L2 (statVars) so it can be used with a custom interrupt enabled.
- Slightly optimized all the sprite, rectangle, and line drawing commands.
- Your lowercase setting will be remembered and restored if you run Axe after a RAM clear.
- Improved the progress bar when compiling in terms of both aesthetics (at least I think so) and speed.
- Optimized to use less power when doing nothing!
- Added even more delay to the direct key input routine. Hopefully there will be no more freak issues with it on any calculators.
- Fixed a long-standing bug that has been resulting in some routines (like the modulus routine) being added twice.
- Fixed a bug with rectangle clipping.
- Fixed special tokens not being properly converted to characters (like 'appv').
- Fixed compiling as an application possibly leaving random data at the end of the application name.
- Fixed token replacements not working for archived Axioms.
Known Bugs:- 3-argument HLine() and VLine() cause crashes.
- Inverted circles are missing a few pixels.
725
« on: December 11, 2012, 11:49:04 am »
iIs there any particular reason this would really be needed? The main reason I can think of is if you want an application to have routines that can be called from an external program, but in that case you should really be using a jump table anyways, and I think it's simple enough to figure out where that would start in an application.
726
« on: December 10, 2012, 03:28:39 pm »
I think there are three possible solutions to this problem using only the given classes/interfaces. They have the same basic hierarchy: X is a parent of B, X and G are parents of U, and U is a parent of Z. The three solutions come from the fact that either one or both of G and X can be an interface. Here are the three solutions (I think): - class G
- interface X
- class B implements X
- class U extends G implements X
- class Z extends U
- interface G
- class X
- class B extends X
- class U extends X implements G
- class Z extends U
- interface G
- interface X
- class B implements X
- class U implements G, X
- class Z extends U
EDIT: Fixed, maybe? Why does this hurt my brain so much...
727
« on: December 10, 2012, 12:58:32 pm »
I use 1.1.2 because of the bug in the rectangles.
Fixed in 1.2.1, which should be out shortly!  I currently use 1.2.0 because of all the optimization stuffs and 13 characters-long label names, but I think I'll go back to 1.1.2 because of the many bugs 
What many bugs? I would certainly try to fix them if they were mentioned in the Bug Reports thread. I do see that you previously mentioned one bug with custom Axiom tokens not working, but I was unable to replicate it. As I mentioned in the bug reports thread, if you could send me the Axiom and a program that includes it where the token replacements don't work, I can look into the bug and try to fix it. Also, are you having an issue with DS<()? If so, please post about that in the bug report thread, too! I haven't encoutered any bug in Axe 1.2.0 but I still think I'll downgrade back to 1.1.2 because the grey was better 
I did cut a corner on the 4-level grayscale masking with 1.2.0 to make it faster, but I couldn't really come to any conclusions of whether or not it would adversely affect real games. Could you direct me to the source for that program, perhaps sent in a private message if it's not publicly available? Or if you would rather send compiled code, the same program compiled under both 1.1.2 and 1.2.0? If I can see that it does definitely look worse with 1.2.0, I'll either revert the grayscale routine or try to make it look better without losing the gained speed. I wanted to use 1.2.0, but it's completely broken in wabbitemu, so im stuck using 1.1.2 so i can keep coding on my computer =(
Hmm, I'm not really sure how to fix that... if it doesn't send at all, Buckeye is probably the person to talk to. If it does send but acts strangely, then perhaps Axe is having issues with some strange property of your dumped ROM? In that case, would it be possible for me to get my hands on it to test?
Again, just a reminder to everybody: if you experience a bug with Axe, report it in the Bug Reports thread so I can look into and fix it!
728
« on: December 08, 2012, 11:05:03 am »
That would be very hard to do, I would imagine. Axe is pretty much entirely built to work with 16-bit values. But just wondering, what kind of things would you want to do with 32-bit values?
729
« on: December 07, 2012, 10:40:00 am »
Matrefeytontias, what would be the purpose of that? Adding a syntax for including label address as inline data seems like an extremely specific thing (one that I'm not even sure I can think of a use for).
Eventually I would like to allow for including any constant expression in the middle of an Asm() block, so you could do something like Asm((LLabel)). But until such a feature is added, is there perhaps a way that you can do what you're trying to do without it?
730
« on: December 06, 2012, 01:24:26 am »
Figured out that I couldn't do this: 0→{L1}→{L1+1}→{L1+2}, derp
Yeah, in fact, 0→{L1} returns L1, not 0 so you are actually doing L1→{L1+1} at the second arrow.
What you can do is Fill(L1,3,0), which would put zeros in the firts three bytes of L1, which is what you want
VALUE→{PTR} returns EXPR when PTR is a constant, so that code should work as far as I can see. You only get back the value of the pointer you're storing to when it's not a constant. Also, if you're not storing anything else in L1 at the point of setting these values, the best way I would see to initialize it is actually to clear the whole thing with ClrDraw(L1), which is only 6 bytes. If you have less then 600 (and some more , i think 667?) to store, then yes use L1+100
The "true" L1 is 768 bytes, but you have the 27 variables at the end of it (A,B,...Z and theta), each of them are 2 bytes, so the available size in L1 is 768-(27*2)
(As the Commands.html says, it can be expanded to 768 using Realloc, which would move the variables elsewhere than in L1+714)
* Runer112 points to Axe 1.2.0 changelog
731
« on: December 04, 2012, 05:10:05 pm »
Does that mean you can't see any better spots? I couldn't either, I just wanted a more expert opinion like yours. 
732
« on: December 04, 2012, 03:31:54 pm »
So Builderboy has requested that the vector table for im 2 interrupts in Axe be moved, because right now it occupies an area of safe RAM that Axe users often want to use to store data (statVars). And I agree that this is probably a good idea. The question is, where's a good, safe spot to put it in static RAM that Axe doesn't expose to users? Axe exposes the following RAM areas, so they are off limits: - saveSScreen
- statVars
- appBackUpScreen
- plotSScreen (duh)
Also off limits are any areas of RAM that are needed by B_CALLs in any Axe command; for example, all of $8000-$8400 is off limits because of possible archive operations. So far the best idea seems to be $9200, which is in the middle of where table data is stored. Destroying table data seems like it could be an acceptable side effect, but are there any better options?
733
« on: December 03, 2012, 05:49:54 pm »
Oh, perhaps I should explain a bit more. Firstly, °Pic and °PicN are user-defined constants, so they're not tokens, just some letters put together. You could call them whatever you wanted, but those names seemed logical to me. The square brackets contain hexadecimal data that is added to the program; [0760] followed by [0000] is really the same data as "Pic1" as you might use in a GetCalc() statement, so °Pic is our pointer to the picture name. The reason I broke the more readable "Pic1" into two parts, however, is because the 3rd byte in the name of a picture variable determines which picture number it is. So °PicN is a pointer to this byte in the picture name, and simply storing to the PicN variable will change it, like 1->PicN. One thing I forgot to mention, though, is that picture variables in the OS are ordered a little strangely. Internally, pictures 1-9 are really represented as 0-8, and picture 0 is really represented as 9. Thankfully this conversion is fairly easy. Depending upon which direction you're going, it's the value plus or minus 1, mod 10.
734
« on: December 03, 2012, 05:25:28 pm »
If you're not compiling your code as an application, I would do it like this:
:.Put this near the top of the program, and then just use PicN as the variable to hold the picture number in your program
:[0760]->°Pic
:[0000]->°PicN
:
:.The actual code
:If GetCalc(°Pic,768)->P
:Copy(L6,P,768)
:Else
:.Random stuff
:End
If you are compiling your code as an application, it's slightly trickier because you cannot modify internal data, which is what the PicN variable was. So we have to move the name of the picture outside of our code and into static RAM somewhere. We can do this by changing how our name buffer is defined, like this:
:.Put this near the top of the program, and then just use PicN as the variable to hold the picture number in your program
:.You can replace L2 with any free static RAM location for 4 bytes of storage
:L2->°Pic+2->°PicN
:ᴇ6007->Pic
735
« on: December 01, 2012, 02:44:29 am »
I would like to improve line drawing, but I need your help! I want to add horizontal and vertical line commands, and then also allow modifiers to all line and other drawing commands to allow white or inverted drawing. The question is, what syntax for these features looks best and/or is easiest to use?
I have added a poll to get your input on this question. Really this is two polls in one:
[1] What should the command for horizontal and vertical lines be?
[2] What should the syntax for white and xor drawing be?
So please look over all the options, and then pick ONE in the [1] category and ONE in the [2] category. Please consider the pros and cons of each; for instance, Horizontal seems like a great choice, but it might cause confusion with the existing Horizontal+ comamnd; and tokens like LinReg(a+bx) can be turned into much better names with the token hook, but without the token hook, they may look confusing.
I would like to note that, for specifying white and xor drawing modes, something like WhiteLine(X1,X2,Y1,Y2) is very much a possibility as well. But then the question is, what tokens should be replaced to be White and Xor? I don't see any obvious choices, but if you have an idea about it, pick the "other" option for [2] and post what your idea is.
Pages: 1 ... 47 48 [49] 50 51 ... 153
|
Show Posts
