This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Runer112
Pages: 1 ... 134 135 [136] 137 138 ... 153
2026
« on: September 02, 2010, 03:12:08 pm »
I believe you meant to say one byte instead of two bytes? Each row of 8 pixels is only one byte, so you'd end up copying 8 rows of 1 byte each.
The screen is 96x64 pixels, so diving it up into 8x8 blocks would give you 12x8 blocks. The following routine, with inputs 0-11 (r1) and 0-7 (r2), would copy a block from the back buffer to the front buffer. r3 is used as a temporary variable.
Lbl B2F
For(r₃,0,7)
r₂*8+r₃*12+r₁→r₄+L₃→r₄+L₆
End
Return
EDIT: Oops, just realized I had L3 and L6 reversed.
2027
« on: September 02, 2010, 03:07:34 pm »
For the storing code to work better, you should change the line that stores the length to:
length(Str9Z)+1->V
The length() command returns the number of characters in the string, not including the null byte that actually terminates the string. Without that last byte, it doesn't actually store the end of the string signifier to the appvar, so calling length() or trying to display the string would result in garbage being added to the end until a zero byte is reached in RAM.
For the reading code, the easiest thing to do would be to simply display the string from the appvar, without copying it out, like this:
Disp D
2028
« on: September 01, 2010, 08:53:39 pm »
Oh wow, I completely forgot about NL... yeah, I guess they're all variable lengths then. Dang.
2029
« on: September 01, 2010, 06:00:16 pm »
Quick question: the SDK says programs, appvars, and groups are all 14-byte VAT entries, but lists are 13 bytes. Are lists actually 14 bytes, just with the last byte not representing anything? It seems that having fixed-length entries is probably more reasonable, just trying to confirm this.
2030
« on: September 01, 2010, 04:41:57 pm »
It would be very difficult to make a routine that can search based on many different possible distinctions. Although still not too easy, it would be a good amount less difficult to make a routine to search for a specific distinction, such as searching for appvars with a certain value as the first two bytes of data to designate it as a level for a certain game. Did you have a specific distinction in mind?
2031
« on: August 25, 2010, 12:45:01 pm »
Yeah, now that I think about it, it probably wouldn't be that easy to use on 84s anyways, because of the unaligned key layout.
2032
« on: August 25, 2010, 05:17:41 am »
It sounds like I might be a little late to be supporting 22.5, but what about extending the radius of keys detected around the "5" key to 2? So instead of having just the numbers 0-9, you'd have all the numbers, "x2", ",", "(", ")", etc. going all the way around.
2033
« on: August 23, 2010, 07:53:23 pm »
This thread shouldn't be floating down this far! And since I just answered a question in the main thread about how to retrieve data from OS matrices, I may as well post these two routines here:
.Returns an element of OS matrix (pointer to matrix, 0-based column, 0-based row)
Lbl M
float{r₃*{r₁-2}+r₂*9+r₁}
Return
.Returns an element of OS matrix (pointer to matrix, 1-based column, 1-based row)
Lbl M
float{r₃-1*{r₁-2}+(r₂-1)*9+r₁}
Return
.Returns an element of OS list (pointer to list, 0-based entry)
Lbl L
float{r₂*9+r₁}
Return
.Returns an element of OS list (pointer to list, 1-based entry)
Lbl L
float{r₂-1*9+r₁}
Return
2034
« on: August 23, 2010, 07:30:58 pm »
I don't know which you intended, but the commands list says float{ is mapped to iPart(, while the actual application maps it to fPart(.
2035
« on: August 23, 2010, 07:18:16 pm »
There is no built-in support for reading specific entries from OS matrices or lists. However, the most recent version of Axe (0.4.4) includes the new float{PTR} function, which is the fPart() function. This converts a 9-byte real number from the OS to a 2-byte integer Axe can understand. This would not accurately convert decimal data or numbers that exceed the 2-byte integer limitation (0-65,535), but it should work otherwise.
Anyways, how to apply this to a matrix. The first two bytes of an OS matrix (the 2 bytes before the pointer a GetCalc() would return) are the number of columns and rows. To access the entry in row A and column B, for example, you'd have to do something like the following:
"[A]"→GDB1
GetCalc(GDB1)→P
.Number of columns
{P-2}→C
Disp float{A-1*C+(B-1)*9+P}▸Dec
I haven't tried this code myself, so I can't guarantee it will work. But it should (unless I have where the OS stores the rows and columns reversed).
EDIT: I have tried this code, and it works.
2036
« on: August 22, 2010, 12:51:56 am »
Wow...75 pages.
I was wondering: is there a good way to easily get less flickery gray? it bugs me that I can't just type in Pt-On( and Pt-On()r and see some smooth gray! I wouldn't mind typing more, but I don't know what to type 
What do you mean? The grayscale methods currently supported by Axe are just about as good as gray gets. The screen on TI-83s and TI-84s weren't built for grayscale, have no automated processes for grayscale, and are relatively slow. As far as im concerned, based on the hardware we have to work with, Axe's grayscale routines do an amazing job. The only way to get less flickery gray is to update the screen more often. If you're doing things like drawing sprites, a good way to help maximize the update frequency is to make sure you're only drawing things on the screen that moved or weren't there before and actually need to be redrawn. Also, optimize your program for speed as much as you can. Use as little processing power as you can between screen updates, and try to make sure the time between updates is somewhat constant and doesn't have large spikes of processing time used up between two screen updates. If you wondering why there's no automated process to display grayscale without having to call DispGraph r/DispGraph rr, it's because that would require interrupts to update the screen automatically, but the display routines don't work with interrupts. You wouldn't want that anyways, because it would display the buffer contents a potentially inopportune moments, which could cause tearing (the screen updating while the buffers are being updated, resulting in displaying part of the new image and part of the old).
2037
« on: August 21, 2010, 08:35:42 pm »
No biggie, but the title of the new Commands.htm still says Axe 0.4.3. Make sure to keep that updated!
2038
« on: August 21, 2010, 02:35:15 am »
Well if you do start releasing uncompressed level data and challenging us to compress it as best as we can, I'll be waiting to take on (and win) that challenge. ;-)
2039
« on: August 20, 2010, 09:23:07 pm »
I have an idea: as you design levels, post the uncompressed tilemap data and pose a challenge to see who can compress them the best. I'd love to try that. And while I'm here, I was wondering: isn't 4 tiles (as you showed in your demonstration) a little too few? Don't you need things like doors and switches and emitters?
2040
« on: August 20, 2010, 02:40:28 pm »
I'd really like InsertMem and DelMem. I'm currently working on a project that stores data in an appvar that can get very large and change size, and there may not be enough RAM to make a whole other appvar of the new size to coy the data into.
Pages: 1 ... 134 135 [136] 137 138 ... 153
|
Show Posts