Flipping the LCD is pretty much like doing a fastcopy in old xLIB. So you will need to draw text twice if there is stuff moving in the background.

To further explain the getkey function:

if you just want to get the key in Ans then you can do:

real(2,0

And the key will be in Ans, the same was as its always worked.

The demo however takes advantage of the extra functionality of getkey. Namely that it can update USERVARIABLES depending on what keys are pressed:

real(2,4,4,1,-8,1,1,8,2,0,-8,3,0,8

Will add or 8 or -8 to user variables 0 or 1 depending on if up/down/left/right are pressed.

Here is a breakdown:

real(2,4,4,1,-8,1,1,8,2,0,-8,3,0,8

real( = xLIB token (for now)
2 = getkey function number
4 = number of keys to test

4 = keycode for UP
1 = USERVARIABLE 1, being used to hold playerY
-8 = value to add to USERVARIABLE 1 (playerY)

1 = keycode for DOWN
1 = userVARIABLE 1, being used to hold playerY
8 = value to add to USERVARIABLE 1 (playerY)

2 = keycode for LEFT
0 = USERVARIABLE 0, being used to hold playerX
-8 = value to add to USERVARIABLE 1 (playerX)

3 = keycode for RIGHT
0 = userVARIABLE 0, being used to hold playerX
8 = value to add to USERVARIABLE 1 (playerX)

This way you can do 4 key tests and update the variable appropriately in 1 real( statement. The reason for this is key handling was possibly the biggest reason for slowdown in BASIC games.

Currently it only supports addition, but that can be expanded. That said you would probably have your movement work like this and if you have menu keys you can process them seperately. That said the way it has always worked hasnt been taken away so the standard way to handle keys is still there.

I should mention that the lib will require very different coding techniques over previous xLIBs or other ASM libs. This is unavoidable due to the speed limitations of the platform. Here is the code for the sprite demo:

:real(1,1,0,0
:real(1,1,1,0
:real(1,1,2,0
:real(1,1,3,0
:real(1,1,4,127
:real(1,1,5,0
:real(1,1,6,0
:real(1,1,7,64
:real(0,1,0
:real(3,0,5,6,7,0,0,1
:real(3,0,5,6,7,0,0,0
:real(1,1,8,real(3,1,0,1,7
:Repeat real(2,0)=15
:real(4,0,1,8,8,0,4,239,1
:real(4,2,3,8,8,0,8,1,0
:real(1,1,8,real(3,1,0,1,7
:real(1,1,2,real(1,0,0
:real(1,1,3,real(1,0,1
:real(2,4,4,1,‾8,1,1,8,2,0,‾8,3,0,8
:End
:real(0,1,1

Oh, that key thing can come in handy!
And that is an interesting way on how to make two buffers.

Opps i was on my phone, must have hit lock topic when trying to change pages :S.

Also the reason people use Link's Awakening is because they are 16x16 tiles im pretty sure where most other Zelda games have a higher resolution (Aside from NES etc).

I think it's like the graph buffer on monochrome calcs but it's in GRAM to save actual RAM and also a lot of speed.

It's a good idea, because drawing in another RAM area then copying it over the GRAM when done would have really been slow on this calc. On older models it was fast only because the screen contained much less data.

As for LA sprites lol I remember when DarkAuron ranted on Maxcoderz about how overused they are, but I think it's fine because no Zelda using them ever got finished anyway.

Well I really meant finished Zelda games. So far the only two that ever got finished (ironically both within one month span) are Dark Link Quest and Hero of Hyrule. The first is ASCII and the 2nd uses custom graphics that looks very close to Link's Awakening, but scaled down, and it isn't as much of a Zelda game as DLQ. But yeah among unfinished ones, I never saw any using anything else than ASCII graphics or LA sprites/derivatives. I guess that maybe people just found the NES graphics too bland but found the SNES/GBA Zelda ones too complex to be converted to 4 shades of gray.

I personally would probably re-use LA graphics, but I'm not planning to do a Zelda game in xLIB (probably a 84C exclusive RPG or something). I am already making a Zelda in BASIC which is intended to be as small as possible and graphical while staying as TI-BASIC as possible, and I'll probably leave other Zelda projects to ASM/Axe coders, while I try to work on new original stuff.

I didn't hear much about that game but I think you were working on a calc remake back in the days, right? I need to check that stuff out at one point.