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 ... 70 71 [72] 73 74 ... 153
1066
« on: August 20, 2011, 12:14:21 am »
Here's a pretty nasty bug. The length() routine isn't being inserted properly; the code for checking if the ON key is pressed is being inserted in its place. And that code doesn't have a return, which can cause very bad stuff to happen... If there's some table you can easily look at that simply has an incorrect value for the length routine, perhaps you should check all the other routines while you're at it.
1067
« on: August 19, 2011, 10:47:14 pm »
I think relatively specific things like reading and setting clock data and getting the calculator's ID are best left to inline assembly. Getting the calculator's ID is especially simple, I can whip up some code for it right now:
.Returns a pointer to the first 5 bytes of the calculator ID
.Returns 0 if unsuccessful
Asm(EF7E802199842803210000)
Control for crystal timers in Axe, however, would be a bit more complicated and possibly Axiom-worthy. It could be tricky to implement all the possible options with crystal timers while still retaining ease of use so you don't have to be the person who wrote it to understand how on earth to use it.
1068
« on: August 19, 2011, 02:56:48 pm »
shmbis, you are correct that the pixel commands to arbitrary buffers are not working. The parser is correctly identifying the commands as arbitrary buffer commands, but it's calling the wrong entry point to the pixel routine. So Quigibo needs to fix this. Sprite commands still work for arbitrary buffers, though. Remember, sprite commands take 3 arguments just for a normal call.  I haven't checked all the other drawing commands, but I'm just going to assume they work correctly.
1069
« on: August 16, 2011, 04:31:02 pm »
2 or 3 bytes with End, 4 or 5 bytes with EndIf or End!If. But While 1 and Repeat 0 themselves result in 0 bytes of compiled code.
1070
« on: August 14, 2011, 11:51:02 am »
Both are the same size: 0 bytes.
1071
« on: August 13, 2011, 07:56:50 pm »
Those tiles look great shmibs, but do we want to copy the graphics of Link's Awakening and/or other games? Personally, I think if Omnimaga is making it's own RPG, it should make its own graphics too.
1072
« on: August 11, 2011, 04:29:36 pm »
All of Axe math simply truncates, so I think the current square root algorithm is pretty good. Anyways you have to remember that Axe uses 16-bit math and that's an 8-bit square root function. 
1073
« on: August 10, 2011, 12:41:34 pm »
thepenguin77, I have no such problem. And I have absolutely no idea what would change a 'd' into an 'r'. Perhaps by some strange chance the source got corrupted? Is it still a 'd' in the source?
1074
« on: August 07, 2011, 02:16:41 pm »
It's 7.22 because it can get an 8th, though you know that eighth has no usable purpose. With Axe, if the XXX.XXX must stay, make sure to warn people that the sixth X is crap and never ever to use it.
The 3rd decimal digit of Axe fixed point numbers has a purpose. Try representing 1/256, a very useful number for transformations, without it. Or try representing 1/3. Whereas 0.33 would equal 84/256, 0.333 would equal 85/256, the latter of which is 4x more precise. I, and I believe many others, would not want to forfeit this additional precision. Saying that the 3rd decimal digit doesn't matter is like telling someone to ignore the units digit of a 3-digit integer. If you limited numbers to 99.XX, people will think 99.99 is the maximum number possible, although it's really 255.997. If you thought they'd be confused when 0.138 equals 0.139 (I'm simply obliging your suggestion here; not once in my programming experience have I seen someone check for exact equality to a number with more than one decimal place), think about the confusion caused when they learn that, in a system that presents itself as a mod 100 system, 50+50 doesn't overflow. And I know you might suggest having BCD math routines for this purpose, but there are multiple problems with this. To list the ones that come to mind: - Bloated code in regard to both size and speed.
- Cannot optionally interpret the highest bit as a sign bit to easily use signed and unsigned numbers interchangeably.
- Most importantly, Axe doesn't have types (and it shouldn't, it's much more flexible and optimizable without them), so there's no way for Axe to know if you're operating on a BCD number. Every single operation Axe has would need to have a second token representation for the BCD operation. Weigh the following: which would be more confusing? 0.138 equaling 0.139? Or + not equaling +?
EDIT: As a note, I just want to mention that I'm not dragging this out for the sake of trying to prove anybody wrong. I just think it's simplest to leave fixed point numbers the way they are.
1075
« on: August 07, 2011, 11:10:14 am »
And when you type 7/10 in Java/C, it DOES equal 0.7f/d, not something like 0.66f/d. You know as well as I do that's not a good comparison; the two forms of floating point notations work entirely differently, using different techniques (and in most languages, the amount of numbers that can be stored is already specified in digits, not in 256 base-units).
In Java, C, C++, and most other modern languages, 0.7 DOES NOT equal 0.7. They use binary-encoded floats, not decimal-encoded floats, and 0.7 cannot be perfectly represented in binary. If you don't believe me, check out this IEEE 754 converter. The number of decimal digits that can be stored in a regular float is 7.22. That's right, it's not an integer. Just like the number of decimal digits that can be stored in an Axe fixed-point number is 2.41. Java, C, and C++ don't throw an error if you enter an 8-digit float, so why should Axe throw an error if you enter a 3-digit decimal? It's fairly common knowledge that you shouldn't use equal/not-equal comparison for floating-point numbers, and this applies to fixed-point as well.
This is very true. Just like you would never check if a float is exactly 112.453 after some calculation, you wouldn't check if a fixed point number is exactly 112.453.
1076
« on: August 06, 2011, 09:33:25 pm »
Axe can display strings, characters, tokens, numbers, and hexadecimal numbers, but not a list of numbers. To display a list of numbers, you'd have to loop through them and display them one by one. The reason you're seeing 34540 is because L₁ is a pointer to an area of free memory, and 34540 happens to be the decimal value of the pointer. Try calling the following modified version of PAS, it should display the values as it calculates them.
Lbl PAS
ClrHome
For(J,0,r1
r1-J->B
sub(EXC,r1
A->C
sub(EXC,J
C/A->C
sub(EXC,B
C/A->C
C->{L1+J}
Disp C>Dec,i
.Imaginary ^
End
Return
1077
« on: August 05, 2011, 09:49:26 pm »
There is no reason for ᴇFF.FF, since that is exactly the same as ᴇFFFF. And I prefer the .999 notation for fixed point numbers. The point of the XXX.XXX support was to make fixed-point numbers easier to add as decimals for programmers more used to TI-BASIC. If you want to specify an exact fractional part, you should probably be working in hexadecimal anyways since that's more like how the number is actually stored.
1078
« on: August 05, 2011, 08:50:16 pm »
Ashbad, I am not stating that I think the .999 representation is better. I am stating that it is what Axe uses, regardless of which representation any of us thinks is better or worse. Your constants will not be parsed correctly if you use the .255 representation.
1079
« on: August 05, 2011, 08:33:22 pm »
It's not the representation Axe uses though. So whether or not it can be correct in other situations, I don't want people using it in Axe and then being helplessly confused when their program acts just a little strange because of a slightly off constant.
1080
« on: August 05, 2011, 04:28:11 pm »
Just for clarification because people seem to be confused: fixed point numbers in Axe are represented in decimal just like you would represent them normally. 255.255 is not 255+(255/256) or 0xFFFF. It's a decimal representation, so 255.255 is 255+(255/1000) or 0xFF41. If you wanted to represent the maximum fixed point number, you would use 255.999 which is 0xFFFF.
Pages: 1 ... 70 71 [72] 73 74 ... 153
|
Show Posts