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 ... 10 11 [12] 13 14 ... 135
166
« on: November 23, 2011, 04:44:03 am »
Its Pt-Mask()r that draws to a single buffer, not Pt-Mask(). I know that's a little confusing because usually the r involves the back buffer but it was only because I added that feature later and I wanted to make it reverse compatible.
167
« on: November 23, 2011, 04:39:00 am »
If you're using a shell like DCS or Mirage, those will write back changes you made to the program after quitting. If you still want to use those shells, another alternative is to copy your static data to free ram using the Copy() command and then modify the data there instead of in the program itself.
168
« on: November 22, 2011, 06:06:45 pm »
Axe does not use any SMC in the program itself because this is a required invariant of the language in order to ensure things optimize correctly. The only SMC it uses is to modify some free RAM that is executed over when an interrupt occurs (which has nothing to do with writeback).
Judging by the size of the mentioned programs, they are both well over the 8kb limit meaning they are using Crabcake or Fullerene, both of which I think use SMC, but you'd have to double check that.
169
« on: November 18, 2011, 05:43:23 am »
Fun fact: The link routine Axe uses was just copied over from that game and optimized slightly.
Like I always say, linking is easy, but syncing is hard. Puyo Puyo runs fast because it only needs to send data when a particular "event" occurs (combos). Event driven programming style is a little different than what you're used to but basically you put the Get() in your main loop so its always ready to receive an event. Don't forget, Get() doesn't delay or wait unless the other calc is sending something.
You send data by first sending an enumerated event type (1 bytes) followed by the event data (which may be different length depending on the event). For instance you might need to send a character's position. This can be done by sending a "X change" event followed by the x coordinate whenever that coordinate changes and a "Y change" event followed by a y coordinate. The actual transfer speed is about 500 bytes per second maybe. If your main loop is running at 30fps and don't mind reducing to 20fps that's about 8 bytes per frame of data you can send which is probably enough for a decent subsets of multiplayer games.
170
« on: November 18, 2011, 12:23:54 am »
I think even when they're not nested they still add to the block count because the end of each elseif block needs to link to the cumulative end of the entire statement. But generally, if you're using 17 elseif statements, you're doing something wrong and you should probobly be using some kind of lookup table. If you really do need them though, you should use a subroutine instead because it will save you tons of bytes:
:If <S1>
: <B1>
:ElseIf <S2>
: <B2>
:ElseIf <S3>
: <B3>
:...
Convert this to:
:MySub()
:Lbl MySub
:If <S1>
: <B1>
: Return
:End
:If <S2>
: <B2>
: Return
:End
:If <S3>
: <B3>
: Return
:End
:...
171
« on: November 16, 2011, 08:54:40 pm »
But TI doesn't have a text flag for that  It has to be something that already exists.
172
« on: November 16, 2011, 08:51:52 pm »
That's because the 2 passes get out of sync since it did the replacement in the first pass but didn't in the 2nd. That can result in all kinds of crazy stuff. 
173
« on: November 16, 2011, 08:45:25 pm »
Look closely at your first for loop. A and B are in the ranges from 0 to 7 and 0 to 11 respectively. You are trying to do the same with Y and X in the ranges 0 to 63 and 0 to 95. So basically to remedy this, just divide each coordinate by 8 and that should give you the correct block. In fact, you should turn this into a subroutine because you will likely reuse it a lot:
:.Syntax TILE(X,Y)
:Lbl TILE
:Return nib{r2/2/2/2*12+(r1/2/2/2)+(GDB1*2)}
Now in your for loop, you can call TILE(B*8,A*8 ) and elsewhere call TILE(X+2,Y+16).
EDIT: Added a speed optimization since it saves you from needing the division subroutine.
174
« on: November 16, 2011, 06:04:05 pm »
I know exactly what is causing that error. It is as runner said, the peephole optimizer. There is currently a bug where Axe confuses offsets with constants and is turning your code into exactly this:
Data(0,0,0,0,0,0,0,0,0,......)->A
GetCalc("appvMTEMP",)->B
Copy(A,B,48
The current offset in the code is 48 and you were using 48 at the same time to specify the size. It also happens to be in a pattern that normally peephole optimizes. So now its attempting to create an appvar with a size equal to the pointer which is a number around $9E00 which is over 40,000 bytes! You can fix this temporarily as Runer said by using zoom compile or adding one more zero to your data. Adding more code to the end wouldn't fix anything because there aren't any known bugs with ending code changing behavior to my knowledge.
175
« on: November 16, 2011, 05:52:32 pm »
Thanks! 
176
« on: November 15, 2011, 06:17:58 am »
A surprisingly accurate approximation for arctangent is:
atan(x) ≈ (π/2)*x/(abs(x)+1)
Which, when converted from radians, can be implemented in fixed point notation as x*64//(abs(x)+256) however this has overflow problems in the numerator. Fortunately you can perform long division to reduce it to 64-(16384//(abs(x)+256)) which accounts for everything except the sign. This can be done with a simple if statement:
:Lbl atan
:64-(16384//(abs(r1)+256))→r2
:If r1<<0
: Return -r2
:End
:Return r2
177
« on: November 14, 2011, 12:48:50 pm »
Many Axe programs never need interrupts at all but don't remove them because they either don't know about them or think that there is some reason to keep them. You should only KEEP the interrupts on if you are using: You should especially REMOVE the interrupts on if you are using:
178
« on: November 13, 2011, 07:14:02 pm »
I thought I already added this... oh well, I'll add it soon then. One use of this is computer generated data (For instance music, large pictures, levels, and more). Those can export to an appvar format and then you don't need to have tons of extra space taken up in your source code in hex form.
179
« on: November 10, 2011, 10:52:11 pm »
Ah yes, I did forget about this case. Fixed.
180
« on: November 10, 2011, 06:21:55 pm »
I found the bug with peephole opts a while ago which happens in extremely rare cases when you use a data offset in your code followed or preceded by an actual constant that has the same value as the offset and they happen to be in a pattern that can peephole optimize. An example of where I saw this was during a GetCalc(Str1,6) where the start of Str1 was the 6th byte of data and Axe erroneously optimized it to GetCalc(Str1,). Adding junk data to the beginning such as Buff(1) or some other small number which pushes the offset is a temporarily workaround, or simply zooming.
What you're reporting though doesn't sound like that. Are you sure that's what's causing it?
Pages: 1 ... 10 11 [12] 13 14 ... 135
|
Show Posts