BigDecimal can do whatever precision you specify, so it's speed would be proportional to that. The question is, do you actually need floating points (If you want speed that is.) Maybe you can use an array of longs, for example, as fixed point.
Oh whoops didn't see there was another page But yeah, you can have named constants but not named variables, unless you use a constant as a pointer to a variable o.O
:If something :Data(.......)→Pic1 :End :If somethingelse :Data(.......)→Pic1 :End Gives me a duplicate error. (and I know that it should happen) Is there a way to get around with it?
Also, if something is a constant, you can do this in Axe 1.1.0:
4*^B returns the same thing it did before, the high word. The ➔(r₁,r₂) does almost the same thing as ➔r₁, except that in addition, the low word of the last *^ is stored to r₂. However, feel free to make other suggestions. I'm still open to other ideas.
:r₁∗r₃+(r₂∗^r₃)➔(r₁,r₂) .Basically store high word (plus r₁∗r₃) to r₁, and the low word (not affected by the add) to r₂. This has the added advantage that ➔( doesn't seem to mean anything in the current version (also, it causes an invalid token error). To compare with what Quigibo suggested, ➔(A,B) would be equivalent to ➔A(or B):<undecided token>➔B(or A), with the advantage of not using another token, and being more intuitive.
:r₁∗r₃+(r₂∗^r₃)➔r₁ .This would also work, storing just the high word (plus r₁∗r₃) to r₁, just like before. :r₁∗r₃+(r₂∗^r₃)➔(r₁,) .maybe same as the last last line, but returns low the low word of the multiplication, rather than the value of r₁?
Spoiler For Implementation:
Use memory: Axe.inc: axv_Extra =;MD5Temp, axv_SpriteBuff+6, axv_Y3t, OP1+0..64, whatever ; If you are wondering about the axv_SpriteBuff+6, I was thinking that it would be ; cool if there were an alternate ▸Dec that put the 5+1 byte string in axv_SpriteBuff. ; The leading zeros could even be removed this way (by the routine or in Axe). ; The routine/Axe code would just increment the pointer past the leading zeros... ; Anyway, my point is that even this wouldn't interfere with axv_SpriteBuff+6, ; only the sprite routines would affect it. Compiling: exp1∗^exp2 compiles to: ; load hl and de call sub_MulFull ld (axv_Extra),hl ; or better yet, put these in MulFull ld h,c ; especially if you take Runer's suggestion to break ld l,a ; Mul88's reliance on MulFull. ➔(var1,var2) compiles to: ld (°var1),hl ; only if var1 present? ld hl,(axv_Extra) ; always? ld (°var2),hl ; only if var2 present? A cool thing I just noticed, is that both left to right parsing and the old functionality of sub_MulFull are preserved, and as far as I can tell, compatibility is 100% preserved (even with the few Asm( hacks I can think of!)
Or a more optimized idea – use registers: Compiling: exp1∗^exp2 compiles to: call sub_MulFull ex de,hl ; or better yet, put these in MulFull ld h,c ; especially if you take Runer's suggestion to break ld l,a ; Mul88's reliance on MulFull. ➔(var1,var2) compiles to: ld (°var1),hl ld (°var2),de But of course this is probably way too volatile to be user friendly. (although with peephole... ) Oh, especially since my Axe code example above wouldn't work!
In the future, this syntax could definitely be useful for new commands that return more than one value.
Lol, I used Axe syntax in assembly
On an unrelated note, I just 2nd+Off on the Axe error screen, and now free mem = 0. Shouldn't B_CALL(_GetKeyRetOff) be used here? Unless zStart had something to do with it...
Jacobly, are you sure this works because I've been going through the code and it seems to me like the second 'rl c' should instead be 'add carry flag to c'. 2 times 'rl c' per loop seems wrong to me. Could you explain please? Because I've tried it as well in wabbitemu, taking the different input in account, and it is still not doing the right thing.
That's strange. My test program must not have been working right, because when I went back and changed it a bit, it suddenly started telling me that the second routine doesn't work. Anyway, my new test program seems to agree with this change.
Umm... so I *just* figured out the problem. (There are actually two bugs, but one hides the other)
First of all, you cannot call GetPixel with a negative column, and expect meaningful results. The first step in fixing this, is to change negative columns to zero, with the code such as the following, before call GetPixel.
bit 7,a jr z,TGetPixel xor a TGetPixel: The second step is to change horizontal clipping. When the col is negative, (pointer) and (mask) should not change, so that when col becomes zero, they are already set up correctly.
ld a, (temp) bit 7, a jr nz, TNoCarry ;instead of TEndPlot
If you just change the above code, there are still problems because there is an even more subtle and tricky bug. When you order the start and end of the scanline, so the start is before the end, you do an unsigned compare, which causes the wrong result if start and end have opposite signs (which is the case when there is clipping).
// Multiply a times b temp = 0 repeat for each bit in a temp <<= 1 if (high bit of a set) temp += b a <<= 1 return temp if a and b are 2 bytes, temp is 4 bytes, and you loop 16 times.
Spoiler For for code:
stolen from Axe p_MulFull: ; Input in hl and de, result in cahl ld c,h ld a,l ld hl,0 ;11 ld b,16 ;7 __MulFullNext: add hl,hl ;11 rla ;4 rl c ;8 jr nc,__MulFullSkip ;12/7 add hl,de ;11 adc a,0 ;7 jr nc,__MulFullSkip inc c __MulFullSkip: djnz __MulFullNext ret __MulFullEnd:
// Sqrt a temp = high byte of a a <<= 8 b = 0 repeat for every 2 bits in a test = b << 8 + 0x40 b <<= 1 if (temp >= test) temp -= test set low bit of b temp += high 2 bits of a a <<= 2 return b If a is 4 bytes, then b and temp are 2 bytes, and you loop 16 times.
Spoiler For code:
stole my own routine from axe (and modified it) p_Sqrt88: ; input in hlde, result in de ld b,16 ld a,h ld c,l push de ; ld ixh,d pop ix ; ld ixl,e ld de,0 ld h,d ld l,e __Sqrt88Loop: sub $40 sbc hl,de jr nc,__Sqrt88Skip add a,$40 adc hl,de __Sqrt88Skip: ccf rl e rl d add ix,ix rl c rla adc hl,hl add ix,ix rl c rla adc hl,hl djnz __Sqrt88Loop ret __Sqrt88End:
Kool. Thanks. But, shouldn't the first one have two inputs?
Show Posts
But yeah, you can have named constants but not named variables, unless you use a constant as a pointer to a variable o.O
Good eye.