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 ... 115 116 [117] 118 119 ... 135
1741
« on: April 08, 2010, 12:13:01 am »
Linking is very easy. I could add that feature literally in about 10 minutes. I already made the routines when I made puyo puyo. Actually coding it well with Axe Basic to get the link synchronized is going to be tricky on the programming side though. I have spring break coming up next week. I'll definitely finish the beta sometime around then and I'll have most of these commands working.
1742
« on: April 07, 2010, 08:46:33 pm »
That's the most common error. It usually means that you either used an unsupported command/symbol or you used the wrong type of data like using a number when a variable is expected or having a closed parenthesis without an open one.
1743
« on: April 07, 2010, 08:34:04 pm »
Definitely will add that doc when finished. Currently, I have VERY non-descriptive errors like TI-Basic. There are only about 15 possible errors right now, but I plan to have about 50-100 when finished to be really specific about the exact part of the code that has the problem.
1744
« on: April 07, 2010, 08:30:21 pm »
By the way, some commands currently don't like to be the very last command of the program. I know that >Dec has a problem if its the last character in the code. You can just add an extra [Enter] to fix it though. If anyone finds another one of these please alert me, I am trying to fix them all.
1745
« on: April 07, 2010, 02:18:32 pm »
Nope. Just nothing happens.
Oh wait a minute! I forgot to document that! The Archive/Unarchive command returns 1 if it actually performed an unarchive/archive and 0 otherwise.
1746
« on: April 07, 2010, 02:11:55 pm »
After you select the name of the appvar, immediately unarchive it. Then, when you try to do getCalc() you're sure that if it existed, its definitely in RAM and so it only returns 0 if it doesn't exist.
To write data, you have to store the pointer that is returned by getCalc() either into a variable or in RAM. Then you read and write to that location as if it were any other RAM location. The same way you would do 100->{L1+6} You can do 100->{A+6} if you stored the appvar pointer to A.
1747
« on: April 07, 2010, 02:02:40 pm »
Bit shifts are not the best way to go for division since it takes 4 bytes each shift. That's why I didn't optimize higher divisions of 2. But now that I think about it, multiplication as a method of dividing is small enough to optimize. I'll add that next time.
1748
« on: April 07, 2010, 01:56:13 pm »
It only updates the % done every 255th character it reads. When it starts counting is a random value, so yes, definitely it would change from compile to compile. It will jump to the error in the future so you never need to rely on the percent anyway.
1749
« on: April 07, 2010, 02:56:08 am »
Just updated the list fyi.
1750
« on: April 07, 2010, 01:39:27 am »
Come to think of it, I haven't seen any virtual pet programs for the TI's comparable to the real virtual pets. Let me know if you need any extra help with the coding, this is a cool idea.
1751
« on: April 07, 2010, 01:08:46 am »
That's is basically a Pt-Off() routine, but it only works when the sprite is aligned to the 8x8 grid. BUT, if you only need the sprite aligned anyway and are always using Pt-Off(), it sure does work. Keep in mind though that the axe sprite commands are usually smaller and faster. I haven't compared this one though.
1752
« on: April 07, 2010, 01:03:02 am »
Wow this is getting more impressive every day! On the subject of optimizations, also consider that I haven't been working on the hardcore optimizations on the parser either. Things like evaluating constant expressions during compile time (for instance L1+8 should really only be a 3 byte command, but its currently 7), moving automated subroutines to the end of the program (saves 2 bytes per subroutine), new common commands that are more optimized themselves than native axe code, and also just general improvement of algorithms. All these things combined can probably cut the product 15% smaller than now. Then, optimizations in the Axe Syntax itself can usually make a difference of another 15% (Like always multiplying constants on the right side).
1753
« on: April 07, 2010, 12:39:30 am »
For sprites larger than 8x8, you can just use a subroutine:
:[your 16x16 sprite here]->Pic1
:0->X->Y
:Pic1sub(DS)
:DispGraph
:Return
:Lbl DS
:->A
:Pt-On(X,Y,A)
:Pt-On(X+8,Y,A+8)
:Pt-On(X,Y+8,A+16)
:Pt-On(X+8,Y+8,A+24)
:Return
This will draw sprites with any size from 9 to 16 pixels.
1754
« on: April 06, 2010, 04:28:35 am »
Nope  The only one I did so far was multiplication. I still have to write about 15 new routines from scratch for signed math, but I'll see if I can do them all (or most) by next version.
1755
« on: April 06, 2010, 04:25:24 am »
Yes, but just like the calc's instr(), it doesn't just return 1, it returns the location of the found byte if it is found (a pointer) because this is much more useful.
Pages: 1 ... 115 116 [117] 118 119 ... 135
|
Show Posts