Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: AngelFish on November 29, 2010, 08:31:12 pm
-
Where is the screen data located in Axe? Is it in L6?
I'm trying to move a sprite on a 4 lvl greyscale image and drawing the sprite erases the underlying image. I'm not sure how I would undo that without either a complicated array or just replacing the data from the underlying image.
-
Redrawing it (or backing up the entire buffer-pair (you'll need a 768*2-byte appvar)) is probably the easiest option :D
But yes, screen data is at L6. The backbuffer is at L3, and is also used for displaying greyscale images.
-
Are there a couple of memory blocks easily available in Axe that can store the front and back screens? How would you transfer the contents of the screen to this memory and recall it?
-
Are there a couple of memory blocks easily available in Axe that can store the front and back screens? How would you transfer the contents of the screen to this memory and recall it?
Well, the buffer (L6) is pretty much just a chunk of memory that the OS uses to keep a temporary copy of what's on the screen. What's actually on the screen is controlled by the RAM of the display, which is separate from the calculator's RAM. When you use DispGraph, you're basically sending the data in the buffer to the display's RAM, so that it can display it.
The back-buffer (L3) was originally meant by TI to be another chunk of memory for backing up the buffer (so you can display a menu "over" what's already on the screen. Axe uses this for grayscale instead, so if you're using monochrome, you can still use this as a backup for the buffer.
Then there's L1, which is a chunk of SaveSScreen. SaveSScreen was originally meant by TI to save a copy of the screen when the calculator APD's (auto-power down). You could also use it for buffer storage, but Axe uses the first 56 bytes of it for the A-Z and theta vars, so you only have 712 bytes left, which isn't enough for the whole screen (768 bytes).
There are a few commands to save copies to other locations. StoreGDB saves what's actually on the screen (what's in the display's RAM, which could be different from what's in the buffer) to the buffer L6. StorePic saves the buffer to the back-buffer L3, so you can use that as a backup if you only have monochrome. If you're using grayscale, though, you'll have to make your own 1536-byte chunk of memory to save stuff in. You could do that with a chunk of your program set apart for this (with Zeros(1536)) or with an appvar. Just Copy( the buffers there.
-
I'm currently using StorePic, but the program needs greyscale and I have plenty of speed to spare. But what I'm asking is if there's a way that I can do something like
:StoreGDB->"appvTEST"
:StoreGDB^r->"appvTEST2"
:[Move sprite]
:Recall "appvTEST"
:Recall "appvTEST2"
If there were some way to access specific bytes in the screen, I wouldn't even need to recall the whole thing.
-
I'm currently using StorePic, but the program needs greyscale and I have plenty of speed to spare. But what I'm asking is if there's a way that I can do something like
:StoreGDB->"appvTEST"
:StoreGDB^r->"appvTEST2"
:[Move sprite]
:Recall "appvTEST"
:Recall "appvTEST2"
If there were some way to access specific bytes in the screen, I wouldn't even need to recall the whole thing.
Nope, you'll have to use Copy( :-\
You can store specific bytes, since it's basically just an array of 12 bytes per row, 64 rows total. You'd have to find the byte(s) to copy for that, though. And eight pixels are stored in a single byte, so it's pretty hard to find the right bytes when the sprite overlaps an edge.
The easiest way to do it would probably be to use Pt-Change( (so you can just use it again to take the sprite off) or redraw the entire screen every frame. Or store the entire screen, as you said.
-
If the screen is stored just once at loadtime, then I can probably get away with not reloading it every frame. If loading just the row is faster, then it would work.
-
L1 can be used completely if you plan to use no variables and use other storage areas for data. You can also use it and still use variables if for example your game screen is 12x7 tiles large, for example if there's an HUD at the bottom/top of the screen
-
L1 can be used completely if you plan to use no variables and use other storage areas for data.
The full 768 bytes would start at L1-56, though (unless Quigibo changed that in the new version?). You won't be able to use the A-Z, theta, or rand, though, which means no For( loops either.
-
L1 can be used completely if you plan to use no variables and use other storage areas for data. You can also use it and still use variables if for example your game screen is 12x7 tiles large, for example if there's an HUD at the bottom/top of the screen
I've already broken the variables rule by using pointers. Plus, this is for a GUI, meaning that the whole screen is fair game. It's pretty efficient so far (>700 bytes).
-
L1 can be used completely if you plan to use no variables and use other storage areas for data.
The full 768 bytes would start at L1-56, though (unless Quigibo changed that in the new version?). You won't be able to use the A-Z, theta, or rand, though, which means no For( loops either.
Oh, I forgot about that. That's a bit less convenient, then...L1 can be used completely if you plan to use no variables and use other storage areas for data. You can also use it and still use variables if for example your game screen is 12x7 tiles large, for example if there's an HUD at the bottom/top of the screen
I've already broken the variables rule by using pointers. Plus, this is for a GUI, meaning that the whole screen is fair game. It's pretty efficient so far (>700 bytes).
Yeah that works. The only problem is that when you use something like {Str1+15}r instead of A, for example, several times in a piece of code, the code looks very hard to read after a while. X.x