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
16
« on: March 10, 2012, 03:26:36 pm »
Pic automatically do that, you just have to change the size of the pic. Pictures are not limited to heights of 95 and 96, but can actually have any height. If you send a picture with a smaller or larger height, Axe will import it correctly. For appvars, I don't think that is really very useful. If you have an appvar, you probably made it yourself/on a computer. Why would it be formatted such that you only need part of it? You could just have 2 appvars, one with the part you want to import, the other without it.
17
« on: March 10, 2012, 03:16:08 pm »
Btw, you can seed the RNG with 0->{orand}r. But it doesn't mean anything because it also uses the R register (which is like a mini clock) AND it makes random reads from memory. So you would literally have to have identical calculators, the same programs, both running exactly the same time, which is impossible if you do linking.
The problem is that rand provides and actual random number, you want a seed-able pseudo-random number. Here is a good algorithm for generating such a number:
S*7+4*3-1->S
18
« on: March 05, 2012, 03:45:19 am »
Yes, I believe that should work, that's a cool application for pixel buffering  Keep in mind that numbers are stored little endian though and so the "pixel coordinates" for X in 0-7 are actually the low byte and 8-15 is the high byte.
19
« on: March 03, 2012, 08:53:24 pm »
Yes, that is intentional... for now. Currently you can only store static expressions or static data to pointers. This is because if you were to use something like Str2 in a preprocessor conditional or other expression that requires a constant, it would fail because the actual pointer value of Str1 isn't known until the 1st pass has finished. However! Now that you bring it up, I think I can add that functionality, I'll test to see if it works.
20
« on: March 01, 2012, 01:20:55 am »
It should work sending the app to the computer, but not the other way around (until its signed). Is this something that happens every time with every program, or did it just happen once? The calculator doesn't check the signature when sending apps, only when receiving them.
21
« on: February 29, 2012, 03:41:02 pm »
How about this clipping code? Insert it right after the movement and acceleration code:
X<<0?0→X
Y<<0?0→Y
Y>56?56→Y
X>88?88→X
This is assuming a square 8x8 sprite, otherwise you can change the bounds.
EDIT: This is also assuming a regular coordinate system. If you're using fixed point "inflation", then the 56 and 88 should be 56.0 and 88.0 respectively.
22
« on: February 28, 2012, 02:55:57 am »
Yeah sorry about that, I've fixed this problem but haven't released the update yet.
23
« on: February 28, 2012, 02:48:20 am »
@MGOS
Well first of all, if I assume n is positive, (3/4)^n is going to be less than 1. So I believe it is a fair assumption that you want a fixed point output. Given this, we can start be rewriting it as (0.75^n). Raising a number to a power is just multiplying it over and over so you can simply perform the nieve method of starting with 1.0->A and for n times do A**0.75->A. You can also take the more optimized approach of successive squaring which only takes log(n) multiplications. If n is negative, its the same algorithm, but you use (4/3) or (1.333) as the base.
24
« on: February 26, 2012, 04:45:49 pm »
That's not currently possible but its an interesting idea. The image format is a bitmap minus the size bytes, so to draw it, you would have to copy the icon to another buffer that begins with Data(16,16) for DCS or Data(16,15) for MOS and then draw that new buffer using Bitmap(). However, this process could end up using more memory than just keeping another copy of the sprite in data.
25
« on: February 25, 2012, 07:13:20 pm »
It may be a small request but wouldn't it be much easier to be able to directly access matrices using the actual [A] matrix token. and if theres any way to directly access them please someone tell me because i feel like ive tried everything
I could do that, sort of like how I use "Ans" in Axe to represent the BASIC Ans. But its a bad idea because then programmers get confused from BASIC and try to use it the same way even though it has a totally different meaning. I kind of wish I hadn't done that with Ans for the same reason. Also, I'm considering using the matrix tokens to represent tables eventually.
26
« on: February 25, 2012, 06:59:38 pm »
The problem with Torio's code is that its not checking if send was successful. Also, the wait time is dangerously low as the Get could easily miss it, probably resulting in the byte 255 being received during the next iteration of the loop. Your pause time should be at least 1000. I recommend over 5000 to be absolutely safe. I notice in your code, you receive a byte in between sending. I'm guessing this is because you want to make sure the first byte sent, but this is definitely the WRONG way to do it. Here is some example code to send 2 bytes:
:Lbl SEND
:Repeat Send({or1},5000)
: If getkey(15)
: Return 0
: End
:End
:Return Send({or1+1},20000)
This has the same IO as the 1 byte Send command as well as the feature that it will continue to try until it is successful or the clear key is pressed. The Receive command would be:
:Lbl GET
:!If Get→r1+1
: Return -1
:End
:Pause 2
:!If Get→r2+1
: Return -1
:End
:Return r2*256+r1
Again, same IO as regular Get.
27
« on: February 25, 2012, 06:35:51 pm »
Nope, I double checked the routine. It definitely returns -1 if it fails. I'm guessing that either the link cable is faulty or the result is being stored to an 8-bit variable instead of a 16-bit variable.
Also, I forgot, but the Send() and Get routines disable interrupts automatically for you.
28
« on: February 22, 2012, 03:33:06 am »
I have used Git and SVN. Git is definitely more complicated but that's because it comes with more advanced features, especially useful for large, active projects. But SVN is comparatively simple and probably a better fit for you. I recommend using Tortoise since you're on windows, its all gui and graphical so you don't have to memorize all the command line stuff. You can even host your repo on DropBox! (As long as you aren't worried about possible security issues).
29
« on: February 22, 2012, 03:20:54 am »
Ah, cool  And I am glad that uses safe mode. Also, why would it take more time if it is updating a lot? I'll look at the code to figure it out...
I assume the reason it would take longer is because the overhead of the buffer checking is actually longer than the required delay to the LCD port when a difference is detected. By the looks of it though, I bet you can optimize this and replace the LCD waiting code with a sufficiently long pause to speed it up to be just as fast as a regular LCD update.
30
« on: February 21, 2012, 02:49:42 am »
Why didn't you divide by 16 in the first place? 8.8 format seems a lot more useful than the current range of the trig functions.
I wish I had. I added the sin/cos routines before I introduced 8.8 operations and so at the time, I chose the range because it would be convenient to be able to store the result into a single byte in memory. Its too late to make a change like that now unfortunately, but when it comes down to it, it only costs 1 byte to convert it in Axe and the resolution you lose is small since the routine is an approximation anyway. Also, the pseudo code is not literal to how Axe does the operation. Its far more optimized without multiplication or division, but rather a single routine that does everything together bit by bit.
|
Show Posts