This is a real bug: det(5 displays something on the screen
- solarsoftware
- Advanced Member (Posts: 299)
- 20 Oct 2015 06:51:02 pm
- Last edited by solarsoftware on 22 Oct 2015 06:37:27 pm; edited 2 times in total
Here's a bug:
APD doesn't initialize when using Pause, Input, Prompt, or Menu( when running a BASIC program within Doors CSE 8.x.
APD doesn't initialize when using Pause, Input, Prompt, or Menu( when running a BASIC program within Doors CSE 8.x.
- CHill
- Power User (Posts: 339)
- 21 Oct 2015 04:45:57 am
- Last edited by CHill on 29 Dec 2015 09:10:28 pm; edited 1 time in total
solarsoftware wrote:
Here's a bug:
APD doesn't initialize when using Pause, Input, or Input when running a BASIC program within Doors CSE 8.x.
APD doesn't initialize when using Pause, Input, or Input when running a BASIC program within Doors CSE 8.x.
Input or Input?
**Note, fixed
Caleb_Hill wrote:
solarsoftware wrote:
Here's a bug:
APD doesn't initialize when using Pause, Input, or Input when running a BASIC program within Doors CSE 8.x.
APD doesn't initialize when using Pause, Input, or Input when running a BASIC program within Doors CSE 8.x.
Input or Input?
I'm assuming he meant the commands that pause the program, so I think he meant Input, Pause and Menu.
And I think it isn't supposed to APD in a program... ever...
Here are some other bugs:
[] When renaming a program, the program will being locked
[] When editing a hidden program, while loading, the first character of the name is messed up. After loading, it works properly.
[] If you rename a hidden program, the program will being unhidden.
[] When renaming a program, the program will being locked
[] When editing a hidden program, while loading, the first character of the name is messed up. After loading, it works properly.
[] If you rename a hidden program, the program will being unhidden.
This is not a bug in Doors (I guess) but in xLIBC. When you have the code
Code:
it seems that it worked accurate to A<=4, but not above. From A=5, it says they are colliding...
Code:
For(A,1,10
real(4,6,1,0,0,1,1,0,3,A,A
Output(A,1,|LXL
End
I found a bug. When running any ti basic program clrhome doesn;t reset the homescreen cursor to the top left. It starts where the last time the screen Disp -ed, Input -ed, or Pause -ed , provided there was not a manual clear performed before execution.
PT_ wrote:
This is a real bug: det(5 displays something on the screen
I can confirm I'm having this issue too. Also, I'm not sure what part of the code this was in, but I had code that unarchived a subprogram, ran it, archived the parent program, read from an Appvar, unarchived the parent program before exiting, and then archived the subprogram. This caused a Doors CSE Error (something to the effect of "not enough memory") yet continued to run despite this error.
solarsoftware and I figured out a new bug - it is a bug, but we can't figure out how it works.
This is our (his) code:
Code:
When you run in immediately after a reset, it works. The second time too. But after the third time the program crashes. How?
This is our (his) code:
Code:
"rowSwap(ONECORE->Str0
"ONECORE->Str8
det(8
If Str9="..P:NT:FN
Then
"rowSwap(WNSTART->Str9
det(4
1:det(1
End
If Str9!="rowSwap(WNSTART
det(5
0:det(0
Str8->Str9
theta+1:det(2
det(5
When you run in immediately after a reset, it works. The second time too. But after the third time the program crashes. How?
PT_ wrote:
solarsoftware and I figured out a new bug - it is a bug, but we can't figure out how it works.
This is our (his) code:
Code:
When you run in immediately after a reset, it works. The second time too. But after the third time the program crashes. How?
This is our (his) code:
Code:
"rowSwap(ONECORE->Str0
"ONECORE->Str8
det(8
If Str9="..P:NT:FN
Then
"rowSwap(WNSTART->Str9
det(4
1:det(1
End
If Str9!="rowSwap(WNSTART
det(5
0:det(0
Str8->Str9
theta+1:det(2
det(5
When you run in immediately after a reset, it works. The second time too. But after the third time the program crashes. How?
For me, the AppVar contents are correct, but then it resets instantly.
Here's a bug:
det(5 draws a white rectangle in the center of the screen while trying to undraw what's not there.
det(5 draws a white rectangle in the center of the screen while trying to undraw what's not there.
Bug report:
With the real(4,0 command (DrawSpriteA), the PICINDEXSTART argument doesn't do anything. The command will use sprites from the first tileset regardless of if PICINDEXSTART is set to 0 or 1. And if you try to specify a sprite from 128 to 255, it will act as if you specified a sprite from 0 to 127.
And there is a bug with real(4,8 as well (DrawSpriteSequentialListA): If PICINDEXSTART is set to 1, then PICINDEX0, 1, etc will draw the wrong tiles (it seems like PICINDEX0, 1 and stuff ignores real variables).
With the real(4,0 command (DrawSpriteA), the PICINDEXSTART argument doesn't do anything. The command will use sprites from the first tileset regardless of if PICINDEXSTART is set to 0 or 1. And if you try to specify a sprite from 128 to 255, it will act as if you specified a sprite from 0 to 127.
And there is a bug with real(4,8 as well (DrawSpriteSequentialListA): If PICINDEXSTART is set to 1, then PICINDEX0, 1, etc will draw the wrong tiles (it seems like PICINDEX0, 1 and stuff ignores real variables).
DJ_O wrote:
Bug report:
With the real(4,0 command (DrawSpriteA), the PICINDEXSTART argument doesn't do anything. The command will use sprites from the first tileset regardless of if PICINDEXSTART is set to 0 or 1. And if you try to specify a sprite from 128 to 255, it will act as if you specified a sprite from 0 to 127.
And there is a bug with real(4,8 as well (DrawSpriteSequentialListA): If PICINDEXSTART is set to 1, then PICINDEX0, 1, etc will draw the wrong tiles (it seems like PICINDEX0, 1 and stuff ignores real variables).
With the real(4,0 command (DrawSpriteA), the PICINDEXSTART argument doesn't do anything. The command will use sprites from the first tileset regardless of if PICINDEXSTART is set to 0 or 1. And if you try to specify a sprite from 128 to 255, it will act as if you specified a sprite from 0 to 127.
And there is a bug with real(4,8 as well (DrawSpriteSequentialListA): If PICINDEXSTART is set to 1, then PICINDEX0, 1, etc will draw the wrong tiles (it seems like PICINDEX0, 1 and stuff ignores real variables).
Not a bug
PICINDEXSTART is the number from which argument which sprite will be drawn. But let's say you have a moving character. The sprite for UP would be 1, the sprite for DOWN 2, and for LEFT and RIGHT 3 and 4.
Now you have variable A with 1 of the 4 directions, from 0 upto 3.
Your real(4 command now looks like this:
Code:
real(4,0,......,A,1,2,3,4)
This draw a sprite of the tilesheet, based on A.
Quote:
You can use the PICINDEXSTART argument to specify which sprite to draw out of a list of sprites. This can be useful for drawing a differen sprite depending on a direction variable. For example drawing an 8x8 sprite where pic index 10=up, 11=down, 12=left & 13=right, and you have a direction variable "A" which holds 0=up, 1=down, 2=left & 3=right you can do:
Code:
Code:
real(4,0,32,32,1,1,248,1,A,10,11,12,13
After all those years... I always thought that PICINDEXSTART specified which sprite sheet you wanted to start drawing from (0 or 1), or at least that's always how I understood the xLIBC wiki doc.
However I still can't use tile 128 to 255 it seems because it draws 0 to 127 instead. Unless I need to set PICINDEXSTART to 128 for that?
Anyway thanks.
However I still can't use tile 128 to 255 it seems because it draws 0 to 127 instead. Unless I need to set PICINDEXSTART to 128 for that?
Anyway thanks.
That is based on your ManagePic. There you can state which slot (128 tiles) will be loaded in the calc. Tiles 0-127 is slot 0, and 128-255 slot 1.
Aren't we supposed to be able to load two tilepics at once? Because that's what I was doing, yet 128-255 still drew tiles from slot 1.
DJ_O wrote:
Aren't we supposed to be able to load two tilepics at once? Because that's what I was doing, yet 128-255 still drew tiles from slot 1.
Nope, you have to switch them if you use both slots.
Did you real(5,0,0) followed by real(5,0,1)? Are they different tilesheets?
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
» Go to Registration page
» Go to Registration page
» Goto page Previous 1, 2, 3 ... , 12, 13, 14 Next
» View previous topic :: View next topic
» View previous topic :: View next topic
Page 13 of 14
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement