This is a real bug: det(5 displays something on the screen

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.

Input or Input?


**Note, fixed

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.

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...

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.

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?

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.

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).

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:

This draw a sprite of the tilesheet, based on A.

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.

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.

Nope, you have to switch them if you use both slots.

I can't find any command to do that, though, in the wiki.

Did you real(5,0,0) followed by real(5,0,1)? Are they different tilesheets?

I did the following:

"SPRITES1
real(5,0,0
"SPRITES2
real(5,0,1

They are two separate tilesheet appvars.