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 ... 90 91 [92] 93 94 ... 153
1366
« on: April 04, 2011, 12:41:14 am »
This bug must have been present for a long time, because I can't even find a version of Axe in which this bug doesn't exist. Storing a 2-byte value backwards to an expression pointer like →{}rr throws a compile error. The error doesn't happen if the pointer is a constant, only if it's an expression.
1367
« on: April 03, 2011, 10:58:57 pm »
Found the problem. You're using what appears to be almost 900 bytes of memory starting at L2, although only 531 bytes are free at that location. Overwriting about 350 bytes of values used by the OS is definitely a no no. I haven't thoroughly examined your program enough to suggest an appropriate solution, but I would try to find a way to use less RAM. If you can't, you can always create an appvar large enough to hold your data and store your data there.
1368
« on: April 03, 2011, 10:40:12 pm »
Perhaps it's not frozen at all. An odd thing that occurs sometimes is that, when a program exits, the OS doesn't return to the home screen. Have you just tried pressing 2nd + MODE to quit to the home screen?
EDIT: Nope, it's definitely crashing. Looking into it now.
1369
« on: April 02, 2011, 05:51:57 pm »
Here are two smaller HUDs I threw together in case you wanted them. They're both (for the most part) only 16 pixels high. You'll see why I say "for the most part" when you see the second HUD. Although redrawing that small portion of it will take up a bit of space and CPU time, I think it looks pretty neat.
EDIT: How to draw and then later erase the portion of the second HUD extending into the game. I also attached a tokenized version of it, because this is a pain to convert.
{16*12+0+L₆}ʳ→{0+ᴇBE6A}ʳ·ᴇ0080﹢ᴇ0360→{16*12+0+L₆}ʳ
{16*12+0+L₃}ʳ→{2+ᴇBE6A}ʳ﹢ᴇFF7F→{16*12+0+L₃}ʳ
{17*12+0+L₆}ʳ→{4+ᴇBE6A}ʳ·ᴇ01C0﹢ᴇ0E38→{17*12+0+L₆}ʳ
{17*12+0+L₃}ʳ→{6+ᴇBE6A}ʳ﹢ᴇFE3F→{17*12+0+L₃}ʳ
{18*12+0+L₆}ʳ→{8+ᴇBE6A}ʳ﹢ᴇFC1F→{18*12+0+L₆}ʳ
{18*12+0+L₃}ʳ→{10+ᴇBE6A}ʳ﹢ᴇFC1F→{18*12+0+L₃}ʳ
{19*12+0+L₆}ʳ→{12+ᴇBE6A}ʳ﹢ᴇE003→{19*12+0+L₆}ʳ
{19*12+0+L₃}ʳ→{14+ᴇBE6A}ʳ﹢ᴇE003→{19*12+0+L₃}ʳ
DispGraphʳʳ
{0+ᴇBE6A}ʳ→{16*12+0+L₆}ʳ
{2+ᴇBE6A}ʳ→{16*12+0+L₃}ʳ
{4+ᴇBE6A}ʳ→{17*12+0+L₆}ʳ
{6+ᴇBE6A}ʳ→{17*12+0+L₃}ʳ
{8+ᴇBE6A}ʳ→{18*12+0+L₆}ʳ
{10+ᴇBE6A}ʳ→{18*12+0+L₃}ʳ
{12+ᴇBE6A}ʳ→{19*12+0+L₆}ʳ
{14+ᴇBE6A}ʳ→{19*12+0+L₃}ʳ
1370
« on: April 01, 2011, 12:54:38 am »
It fails instantly. I wouldn't worry about any bugs regarding this, Quigibo seems to have covered all the bases well.
1371
« on: April 01, 2011, 12:23:23 am »
Same error. I'm guessing Quigibo thought about this before implementing the inclusion of external source programs.
1372
« on: April 01, 2011, 12:18:31 am »
You get ERR: NESTED LIBS.
1373
« on: March 31, 2011, 05:32:47 pm »
Indefinite derivation/integration. 
1374
« on: March 31, 2011, 12:18:44 am »
In the next version of Axe, Quigibo will releasing a fix that puts the calculator in 6MHz mode before running the DispGraph routine and then returns it to the CPU speed it was previously running at when it finishes.
1375
« on: March 30, 2011, 12:56:56 pm »
The new DispGraph routine no longer works properly at 15MHz, so you can't really compare the speed of it running at 6MHz or 15MHz. However, you can compare the speed of the new DispGraph routine at 6MHz against the speed of the old routine at 15MHz. Depending upon the LCD's delay, it it will either be a bit slower or a bit faster than the old routine at 15MHz was. My calculator has a relatively small LCD delay, so the new routine at 6MHz is just a few percents slower than the old routine at 15MHz. On calculators with a larger LCD delay, the new routine at 6MHz should run just as fast or faster than the old routine at 15MHz.
1376
« on: March 30, 2011, 12:49:59 pm »
Do you run your program at 15MHz? Because the new DispGraph command currently only works at 6MHz.
1377
« on: March 29, 2011, 09:24:10 pm »
The weirdest Axe bug I have ever encountered! After a bit of testing I found the problem, and I bet you'll never guess in what code I found it...
COMMENTS! You thought they didn't affect your program, but you were wrong! Apparently there's a very peculiar bug regarding multi-line comments for which I will make a post in the Bug Reports thread as soon as I'm done with this post. If the ending "..." for a multi-line comment has an odd number of blank lines immediately preceding it, the comment doesn't actually end! So although you thought the parser was doing this:
... [[START COMMENT]]
SOLID WALL
BREAK WALL
WALK FLOOR
INCREASE RADIUS
... [[END COMMENT]]
[7EFFFFFFFFFFFF7E→Pic1
[7EC39FBFFFFFFF7E
[7EC5A3A995C5A37E
[7EFFFFFFFFFFFF7E
[00242400423C0000
[FFDBDBFFBDC3FFFF
[003C525E7A4A3C00
[003C7E7E7E7E3C00]
... [[START COMMENT]]
P1
P2
P3
P4
BOMB SMALL
BOMB MED
BOMB LARGE
BOMB EXPLODE
TOMBSTONE
... [[END COMMENT]]
It was actually doing this:
... [[START COMMENT]]
SOLID WALL
BREAK WALL
WALK FLOOR
INCREASE RADIUS
... [[1 BLANK LINE ABOVE, DO NOTHING]]
[7EFFFFFFFFFFFF7E→Pic1
[7EC39FBFFFFFFF7E
[7EC5A3A995C5A37E
[7EFFFFFFFFFFFF7E
[00242400423C0000
[FFDBDBFFBDC3FFFF
[003C525E7A4A3C00
[003C7E7E7E7E3C00]
... [[3 BLANK LINES ABOVE, DO NOTHING]]
P1
P2
P3
P4
BOMB SMALL
BOMB MED
BOMB LARGE
BOMB EXPLODE
TOMBSTONE
... [[0 BLANK LINES ABOVE, END COMMENT]]
Very peculiar, indeed. You have to wonder how seemingly random bugs like this even come to be. 
1378
« on: March 29, 2011, 09:22:23 pm »
After a bit of testing I found the problem, and I bet you'll never guess in what code I found it... COMMENTS! You thought they didn't affect your program, but you were wrong! Apparently there's a very peculiar bug regarding multi-line comments for which I will make a post in the Bug Reports thread as soon as I'm done with this post. If the ending "..." for a multi-line comment has an odd number of blank lines immediately preceding it, the comment doesn't actually end! So although you thought the parser was doing this: ... [[START COMMENT]]
SOLID WALL
BREAK WALL
WALK FLOOR
INCREASE RADIUS
... [[END COMMENT]]
[7EFFFFFFFFFFFF7E→Pic1
[7EC39FBFFFFFFF7E
[7EC5A3A995C5A37E
[7EFFFFFFFFFFFF7E
[00242400423C0000
[FFDBDBFFBDC3FFFF
[003C525E7A4A3C00
[003C7E7E7E7E3C00]
... [[START COMMENT]]
P1
P2
P3
P4
BOMB SMALL
BOMB MED
BOMB LARGE
BOMB EXPLODE
TOMBSTONE
... [[END COMMENT]]
It was actually doing this: ... [[START COMMENT]]
SOLID WALL
BREAK WALL
WALK FLOOR
INCREASE RADIUS
... [[1 BLANK LINE ABOVE, DO NOTHING]]
[7EFFFFFFFFFFFF7E→Pic1
[7EC39FBFFFFFFF7E
[7EC5A3A995C5A37E
[7EFFFFFFFFFFFF7E
[00242400423C0000
[FFDBDBFFBDC3FFFF
[003C525E7A4A3C00
[003C7E7E7E7E3C00]
... [[3 BLANK LINES ABOVE, DO NOTHING]]
P1
P2
P3
P4
BOMB SMALL
BOMB MED
BOMB LARGE
BOMB EXPLODE
TOMBSTONE
... [[0 BLANK LINES ABOVE, END COMMENT]]
Very peculiar, indeed. You have to wonder how seemingly random bugs like this even come to be.
1379
« on: March 29, 2011, 07:38:23 pm »
The Axiom system is great. Things like automatic jump and call replacements and manual 16-bit load replacements are great, which even the hard-coded Axe commands cannot do. But there's one thing that internal Axe commands can do whereas Axioms can't that I would love to be able to do. Would it be possible to add a new internal Axiom compiler feature that allows calls to be made with offsets? Perhaps a new macro like ld b,b \ .db BYTE \ .org $-2? Because this would be incredibly useful for calling a command in slightly different ways, like you often use with an optional buffer argument for drawing commands.
1380
« on: March 29, 2011, 07:07:50 pm »
The sine and cosine functions in Axe use binary degrees because they're much more optimized. That means 256 degrees in a circle instead of 360. cos(32) would return a value much closer to what you're expecting.
Pages: 1 ... 90 91 [92] 93 94 ... 153
|
Show Posts