One thing to be wary of, which it looks like might have tripped you up in your code, is that Pt-Off() is a little bit deceptively named. It does not actually erase a sprite, but in fact draws a sprite (with overwrite logic instead of the OR logic used by Pt-On()). If you actually want to "erase" a sprite, you have to redraw what was behind it on top of it. In this case, I'd say that the easiest thing to do is to re-display the entire board at the start of rendering each frame, overwriting all tiles wherever they may have been last frame.

Also, I think you need a /8 after the multiplications by frame and frame+1.


As an optimization note, you can make division by small powers of two faster, at the cost of size, by chaining together divisions by two, like /2/2/2 for /8. If you divide by the same power of two more than once, you can often mitigate the size cost while keeping most of the speed gains by putting the division into a subroutine and calling that whenever you need to divide by it. You divide by both 8 and 4 in your code snippet, which could be pulled into subroutines that even share the same code:

Lbl Div8
/2
Lbl Div4
Return /2/2


The swap sector should always exist, so that shouldn't be a problem.

Hey there.
I have 2 answers, actually:

• TI will only ever put the swap sector starting at page $08 or $0C, but technically third-party code could put it somewhere else and the OS should theoretically still function fine. If you need to locate it, I'd recommend using B_CALL(_FindSwapSector). Despite what that documentation says, I wouldn't worry about the swap sector not existing, and the call is not pointless.
  
• Sounds like you got a little mixed up about the variable data flag: "The flag byte will be 0FCh (valid) or 0F0h (deleted, ignore it)." To clarify, $FC marks the start of an archived variable and $F0 marks the start of a deleted archived variable to be removed at the next garbage collection. These flags exist at the start of every archived user variable, not just at the start of user archive sectors, but of course if a user archive sector is non-empty, it will start with a user variable, and that will start with $FC or $F0. So if a sector starts with either of those two flags, it's a user variable storage sector.

This topic has been moved to WabbitStudio Software Suite.

http://www.omnimaga.org/index.php?topic=21012.0

Labels can be one or two (uppercase) alphanumeric (including theta) characters. Variables are just single uppercase letters (and theta).

One of many reasons why TI-BASIC leaves much to be desired.

Do i see it correctly that you have your own double-buffering implement and own pause routines?

Yup, GrayLib uses two pairs of buffers. One set is the drawing pair, and the other set is the displaying pair. And setting the constant °GIW (GrayLib Include Wait) to a nonzero value results in the inclusion of the pause routines GWait(), GWaitG(), and GWaitN() routines, which wait until the frame currently being displayed has been updated with each dither mask rotation, has been updated the given number of times, or has been updated r₁ times, respectively.

Because with my double-buffering I sometimes do nasty things like drawing to the real screen so that I can erase that easy by copying the backup-buffers over. Using GrayLib would mean I'd have to re-write a lot of code then.......

I'm not quite sure I understand what you mean, but I'm going to assume that you mean you don't have a second pair of buffers dedicated to storing the background/tilemap and simply draw sprites, display, and then erase the sprites by redrawing the background/tilemap that was under them. You can still employ this tactic with GrayLib, but when you "send" a buffer pair for display, you'll need to burn a little extra time and copy them back to the drawing buffers, and then you can erase them on the drawing buffers. So something like the following:

.Draw sprites on drawing buffer pair GB1/GB2
GDisp()
Copy(GB3,GB1)
Copy(GB4,GB2)
.Erase sprites on drawing buffer pair GB1/GB2


Also, can you make it use L1 and L2 instead of 1.5k more ram?

The comments I left tell me that, by default, GrayLib uses L6, L₃, L₂+103, and L₄-512 as buffers (one important thing to note about the last one is that it will be destroyed by Archive, Unarchive, or Copy() from flash). If you want, you can suppress these default values and provide your own by setting the constant °GII (GrayLib Include Initializations) to 0 and storing your own values to GB1-GB4. Keep in mind that suppressing the default initializations means it can't initially clear the buffers for you, so you'll have to do that yourself.

With the default buffer setup, if you use your own extra pair of buffers to store the background/tilemap, you could still manage to fit one of them into L₁, but the other would probably have to be allocated in a temporary variable.

EDIT: I can't get it to not crash my calc Plus it is so large

You say "so large," I say "fully featured."

Also, I do re-draw a lot in the moving engine, so maybe I shouldn't use this after all?

I thought the character was the only thing that needed to be redrawn, since the tilemaps are static and don't smoothscroll. Is that not the case?

EDIT: Could it be that getKey^r causes it to crash? >.<

It's probably best to stay away from getKey^r with GrayLib, since it can probably mess up a number of things (reinstating the OS interrupt, drawing modifiers in the top-right corner of the screen, etc.). If you don't need the 2nd and alpha modifier logic and really just wanted the waiting key check, you could set the constant °GSGK (GrayLib Support getKey) to 1 and use a routine like the following:

Lbl KeyWait
 While 1
  Stop
 EndIf getKey
Return


Also, something on exiting, also in the example progs, causes my calc to crash

Hmm... the example programs certainly don't crash my calculators. Can you reproduce that on an emulator? If so, I could debug it more easily.

Also, am i supposed to draw my sprites etc to L6 and L3? (the normal buffers)

I was sort of lazy in the GrayLib post and readme and basically told people to look at examples to learn how to use it, so the confusion is understandable. You want to do all your drawing to the buffer pair GB1 and GB2. GB3 and GB4 are the buffers currently being displayed by the interrupt, and GDisp() "sends" a frame by swapping the buffer pointers held by GB1 and GB2 with GB3 and GB4, respectively.

And now that I look at this, I should probably make GDisp included by default, since it's basically the most important command... You currently have to request its inclusion by setting the constant °GID (GrayLib Include Display) to 1.

Yeah, I mentioned it earlier.

Could there be an menu option to choose to have small font on or off?

I believe the latest version was exclusively made as a quick hack to test the small font editor, which is why there are no options related to it. If you don't want it for now, just drop back to the last version, and nothing else should be different.