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 ... 46 47 [48] 49 50 ... 135
706
« on: November 20, 2010, 04:00:13 am »
If you're trying to make a triangle solver, it would be much easier to write in BASIC. Axe is designed for games and so the math functions are optimized for speed and size instead of precision. Trig functions are uncommon in calculator games (unless its an attempt at 3D) which is why there is only minimal support for them.
707
« on: November 16, 2010, 05:40:25 pm »
Actually, storing to a variable might be valid syntax in the next version, that is "Hello"->P will be parsed the same as ("Hello")->P
708
« on: November 16, 2010, 05:30:38 pm »
That's possible, but it would complicate things a bit becasue there would need to be an "installation" process when adding new axioms. There could also be conflicts between multiple axioms and the vat would still need to be searched for the information file every token which would still slow it down considerably.
709
« on: November 16, 2010, 05:26:08 pm »
Unfortunately, due to the way the token hook works, it would be virtually impossible to add custom token replacements. In order for that to work, every token you type in the editor would have to scan the entire program for the Axiom() keyword, look in that file, compare against all the replaceable tokens, and then copy the new value. This would be way too much of a delay and scrolling would be really sluggish.
My compromise is to provide a bunch of generically sounding token names that are unused by the axe language itself in hopes that they will fit into the axioms. I will have a poll/thread for suggestions next week when I prepare for the next update, but to give you some examples I have now: Draw1() Draw2() Draw3() Setup() Move() Load() Save() New() Del() and of course in addition to these you have all the unused OS tokens.
710
« on: November 15, 2010, 05:56:25 am »
Axe actually does have some support for larger numbers. You will want to look into the *^ (high order multiplication) routine as it captures the overflow when the numbers don't fit into a single variable. Addition overflows can also be detected by checking if the result after the addition was smaller than the original number. I'm sure calc84maniac could help you out with the routines, but basically its just like how you would do "long" multiplication by hand but instead of digits, you have 16-bit numbers. The algorithm is the same as the one you were taught in elementary school, you just never really think about it like that.
711
« on: November 14, 2010, 05:04:37 am »
Don't forget that inData() only works with 8bit numbers (1-255) it won't work with 16-bit numbers. I could add an inData()r to take care of that but it would be slower.
EDIT: @DJ, he means that if your possibilities were 0,1,2,3 then instead of doing inData(A,Data(0,1,2,3,0)) which wouldn't work, you could do inData(A+1,Data(1,2,3,4,0)) which would work because now you are comparing values that are in the right range.
712
« on: November 14, 2010, 04:37:27 am »
DJ is right, the rectangles should have height 1 and the width of the road, that's what I said in my PM. I got about a 3x speed increase when I tried it though.
713
« on: November 14, 2010, 12:19:36 am »
Arguments are stored in the stack except the last argument which is in hl.
Qwerty, I'm not sure what you mean. If you're asking if you can make your own block statements with axioms, that will not be possible with the current axe syntax (using "End"), but I'm sure you could invent your own syntax for it with some hackish code by making a separate ending block routine. Although debugging would be a little difficult since they would not be detected as block errors if there were one.
714
« on: November 12, 2010, 05:34:05 pm »
Yes, there are going to be some special formats. I am still working on them right now, but I can give you a little preview.
First of all, each axiom you add will need a header to indicate the size of the axiom, the type of routine (inline or subroutine), the shells its compatible for, any variation to the structure (like ending in r or having the "stored to" format), the number of arguments the routine takes, etc.
After the header, its just regular assembly. However, there are some convenient differences. If you use any form of absolute jump or call with an address less than $4000, it will treat the jump as a relative jump instead of an absolute one by replacing the value. That way, you can preceded any axiom with .org $0 and then all the absolute jumps and calls will work. Also, numbers between $3FFF and $3F00 are special keywords for "AxeCalls" which will be replaced by the built in routines. These aren't numbers you have to memorize, the axiom include file will come with all of these predefined for you.
In addition to defining the AxeCalls, the include file will also define the location of all the variables, free-ram locations, files, and other values of interest.
715
« on: November 10, 2010, 08:09:32 pm »
To move data around when its not just a byte or 16-bit entry, you have to use Copy(). I used this a lot in the starship example program for the lists of enemies and bullets. Basically the way I deleted an element in the array was to copy the last element over the current one and then shrink the size variable by 1.
I should probably write an array library for this to make it easier.
716
« on: November 10, 2010, 07:55:16 pm »
Yeah, I'm still reading all of this, even though I'm less active, I still visit just about every day  I've even been able to do a little more progress with Axe even with my busy schedule. Runer112, are you sure that comparison is correct? It seems like all it does is just change the high order bit before doing the subtraction. It needs to check if the parity changed in that bit before and after the subtraction. I actually already have plans to optimize this since I will be able to use the parity/overflow flag once I get relative jump replacement working with the axioms (so I can carry that feature over to the built-in commands).
717
« on: November 08, 2010, 01:28:00 am »
Great job on the optimizations! By the way, you can use this for convenience:
Zeros(1024)->GDB1
And it will work the way you expect it to, no need to use the [] before it.
718
« on: November 03, 2010, 11:26:20 pm »
You can use the L6 or L3 buffer directly if you want to get every pixel in order for a screen transformation or something, but otherwise the 2 coordinate pixel plotting is more optimized. There has never been a pixel command with one argument, you must be thinking of Output() and Text().
719
« on: November 03, 2010, 08:12:15 pm »
Actually, volume can be controlled (to a point) by altering the duty cycle. The duty cycle is how long the pulse lasts relative to the period of the pulses. If anyone remembers the old Freq() command when it first came out in Axe, it was much softer because it had a much smaller duty cycle. I do not have a control for the volume in the Freq() command because it would make the routine much larger. Some sound players even have a separate routine for every possible volume in the duty cycle to speed it up for some decent quality audio.
720
« on: November 02, 2010, 08:30:16 pm »
I'm not sure what the actual tones correspond to, but I have been using the wavelength column of this table which seems to give pretty good results.
Pages: 1 ... 46 47 [48] 49 50 ... 135
|
Show Posts