New bugs report:

-SETGRAMOFFSET  does nothing at all. (syntax used= real(8,1,10). I also tried with both TI-OS and xLIB Rand functions)
-Text doesn't switch GRAM/update LCD
-Text also doesn't support variables nor things like randint or xLIB rand as arguments. Only constants can be used.
-When updating the LCD it seems that it isn't aligned properly.
-Rectangles takes 2 seconds to appear

This is my program as of the other day (which now uses real(0, 6, 7 and 10):

real(0,1,0)
real(7,9,0,0,160,120,0,0) //The part that takes 2 seconds
"HELLO/WORLD
For(Z,0,25
real(6,0,Z,25,3,"/",1) //If I used variables for the text location or color, no text appeared. Also even if changing the last 1 to 0 text only remains on one GRAM side. Also newline char doesn't work.
real(10) //WARNING: SEIZURE!
End
real(0,1,1)

Thats very strange since the assembling has never changed, and the file sends+installs to my calc?

it is in the same format.

I will see what i can do.

Are you sure it was .8ck, ive never used that extension (there is no official extension). The APP transfers and works fine on my calc.

There are no options for compiling APPs for the 84C - its the same as the 83+ with the signkey field updated.

Its possible that my web host has corrupted something?

Question, how do we detect if the screen is inverted or not? Currently, xLIB just toggles between both mode using the same command, but that can pose some issues if somebody exits the program from the wrong place and the calc ends up in inverted mode, since when the game will be ran again there's no way for xLIB to detect in which mode it is.

That could work.

Also bug reports for the new xLIB version you sent me:


-Text still isn't fixed (the same bugs are there, meaning it doesn't properly update GRAM location.)
-15 MHz mode doesn't work. I tried in both 6 and 15 MHz mode and both the demo and my little program still runs at half speed (with full screen rectangles taking 4 seconds to generate instead of 2.)

Also, something I noticed is that in the ADEMO.8xp program that came with the other xLIB version, when you exit the map it doesn't switch to the next map anymore. I wonder if that is due to a syntax change like the 160x120 mode setup?

By the way, will real(10) and text LCD updates be fixed in the next DCSE release? So far I still have the following issues:

Real(10): Does nothing at all
Real(6 text:
-In most cases, Only displays text on one LCD area without updating the other side in most cases.
-In one case where I got it to work (such as using a constant rather than variable for text location), some chars changed the background pixels color and pixelates down the background to 160x120. This seems to only happen on TI-OS backgrounds, though and the green in the battery indicator isn't affected as much. Is it due to the xLIB palette? I am concerned this might cause some conflicts with Celtic II and pure BASIC commands.
-Also, one extreme annoyance is that real(6 returns 0 to Ans. Basically, if we need to display the same text multiple times, such as an animation or shadow effect, then we have to store it to a string first, then store it to Ans over and over, which slows things down a lot. Would it be possible to make the command not return anything to Ans?


Inverting pixels seems to have the same problem with LCD update. Always remains on the same side.
xLIB ran in 6 MHz mode no matter if real(0,2,0 or real(0,2,1 was used.

Another thing I noticed is that when in 320x240 mode, sprites/tiles displays as garbage.

By the way, how would someone scroll through the screen? Normally it would have been While 1:For(Z,0,319:real(8,1,Z:End:End to loop through it, but since that doesn't automatically update the screen offset and that real(10) doesn't do anything at all, this makes pretty much any smooth scrolling or earthquake effects impossible.