For real(10) I had this happen with every xLIB command or alone. It just failed to switch GRAM areas.

As for text failing to update GRAM too, I discovered why: It's because real(6 stores 0 to Ans, overwriting my string. The problem would be solved by making real(6 no longer return anything to Ans. It would solve many other problems too.

As for text changing some background colors if drawn over TI-OS material, it's most likely because xLIB uses 160x120 scaled up 2x and 256 colors instead of 320x240 with 65536 colors. I don't think much can be done about that. I never had the problem happen when drawing text over xLIB sprites/backgrounds/other text. It could definitively get in the way for certain programs utilizing TI-OS and Celtic drawing, but it could actually possibly become handy for special effects in the future.

Regarding InvertPixel failing to update GRAM area regardless of if using 0 or 1, here's the code I used:

real(0,1,1,0)
While 1
real(7,4,0,0,1)
For(Z,0,100:End
End
The 6 MHz issue is pretty much self-explanatory. The xLIB commands runs at 6 MHz by default no matter the real(0,2,mode syntax used.

For the garbage sprites/text issue, just remove the 160x120 res command at the top of ADEMO.8xp and see what happens.


For LCD Offset failing to change, this is my code:

real(0,1,1,0)
While 1
For(Z,0,319
real(8,1,Z)
End

Wow that's cool to hear. By the way was the DRAWSTRING string lenght issue why I sometimes saw an extra ?Dec or something at the end of my strings? I noticed it once I think but I thought I just did some mistake since I didn't have it happen with very small ones like HELLO/WORLD. Also what does inherents DRAWSPRITE entry mode fix mean?

Glad the text command no longer stores to Ans btw. Will DRAWSTRING now accept TI-OS vars for X, Y and Color?


Also glad to see this SETGRAMOFFSET fix . I am curious about what kind of stuff could be achieved by using it and by switching active GRAMs in ways that are not meant to be (I'm not getting my hopes up due to the nature of TI-BASIC and my lack of knowledge in xLIB sprite functionality, but we never know lol)


Are rectangles now faster btw or will they still draw in 2 seconds? Also will 15 MHz mode be set properly?


Also suggestion: Make xLIBC doc more visible on the DCS wiki (although I guess that would go more for Kerm). The only way I could ever find it when I went there was by typing xLIBC in the search box.

Ooh ok, I didn't know what "inherents" meant. Thanks for the clarification.

Also this is an awesome fix. I always wanted to be able to use variables to draw text in case I do animations or need to generate a menu or something. As for 160 mode not being supported, will this be fixed in the next release or will text only be useable in 320x120 mode from now on?

Glad to hear about the rest!

Oh I see now lol. By the way we can really decide on which section of the GRAM we want to draw, right? This would be handy if someone wanted to make a game using 320x120 resolution for higher details or if screen shifting is used.

I am surprised this happened, considering I got no connection error . Must have been the forum spazing out.

Also tr1p1ea I tried DCSE RC2 and WOAH xLIB rectangle speed is ridiculously fast now!! (also variables usage in text argument works now)

Thanks, so Mario would be possible?

Also real(8,2,offset works now .

EDIT: Bug report: Real(10) still doesn't work. Nothing happens at all:

real(0,1,1,0
While 1
real(10
End


Also I was wondering if there would be a way to add a real(8,2,x command that is completely independent from active GRAM buffers?

Weird.

Also another bug report: There seems to be some Getpixel lag occuring. If, for example, I fill the entire screen with a low value color (such as black), then draw light stuff afterward, Getpixel will still return the original black value. I am unsure why this happens, but basically I had a splash screen with a black background, then overwrote the entire screen (both GRAM buffers) with the road, yet it still returned the title screen bg color as getpixel value. I was using GetpixelB (xLIB palette).

Yeah the issue is that with xLIB, due to the weird real commands, you always need to carry a copy of the instructions with you when coding because it's impossible to remember commands by heart.