Welp, you got the attack animations and battle background wrong (although it looks cool so far). This is actually the forest background from Reuben 2, unless you decided to use that one instead?




(Btw, the sword is a standalone sprite which is XOR'ed over Reuben's hand)

The background and stuff is very easily changable, the only thing i'm paying attention to currently are the animations, lol.

So, open sprite requests:
4lvl magic menu
4lvl reuben sword

Do i see it correctly that you have your own double-buffering implement and own pause routines?
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.......

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

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

Also, I do re-draw a lot in the moving engine, so maybe I shouldn't use this after all?
EDIT: Could it be that getKey^r causes it to crash? >.<

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

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

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.

You've got it working fine? That's awesome, I was actually expecting it to be a lot more of a hassle.   Let me know if you have any other questions about it.

Here's the sword. Just recolored the one from DJ's animated colored sprite. It *should* be ok. Feel free to modify it as need be. *edit* Forgot to mention that I made the middle sprite match the width of the other diagonal sprites.


*Edit* Added magic menus and normal menus.