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 ... 12 13 [14] 15 16 ... 153
196
« on: March 08, 2015, 08:56:22 pm »
The approach looks correct. But some specifics are off.
Firstly, B_CALL(_Load_LFontV) should be assembled as ED6F80. It's a little surprising that what you had didn't just crash your calculator, as it calls a somewhat random point of RAM.
Secondly, although documentation and people may refer to the data copied to RAM as a font "bitmap," it's not in a format to be displayed by Axe's Bitmap() command. The first byte is the width of the character, which is variable for the small font (but often 4) and fixed as 6 for the large font. The next 7 bytes are the character "bitmap," where each byte represents a row, and in each byte, the image data is in the lowest bits. So to display this with Axe, you'd at the very least want to add a zero as an 8th byte of data so you can display it with a normal sprite command, and then due to the data being in the lowest bits, you'd have to adjust the x coordinate by a formula like X-8+width.
At least, I hope that information's correct. I haven't tried any of this, but this would be my best guess as to doing it correctly.
197
« on: March 08, 2015, 01:23:02 pm »
I believe that's the way to build the encoding. But once you've built the tree and saved it in some format to embed in the output, you can scrap it for a much more efficient table/map format, as I described earlier, for the encoding process.
198
« on: March 08, 2015, 01:09:20 pm »
Those are the RAM locations to which the OS copies large and small font character bitmaps, respectively, in preparation for them to be drawn.
199
« on: March 08, 2015, 12:57:23 pm »
Disclaimer: I've never actually implemented Huffman compression, but I've read enough about it that I think I would be able to do so.
I was under the impression that, when compressing, the simplest way to store the huffman encoding information is in a table or map. This structure would have an entry for each source symbol, mapping the symbol to a bit length and pattern. To make storing the pattern easier, you usually enforce that patterns can't be longer than a certain length so your pattern entries can be contained in bitfields of the same size, but that's not strictly necessary.
Decompressing, though, probably does need a tree that you can navigate binary search style.
In either case, I'm unaware of any efficient encoding/decoding method that only references the canonical representation. So you definitely need some amount of RAM to allocate for an expanded structure, but it shouldn't be a colossal amount; it should be constant with respect to the number of source symbols.
200
« on: March 07, 2015, 09:41:03 pm »
Did you know that one of the features of my GrayLib library is the ability to print text with any combination of 3- or 4-level grayscale foreground and background colors? If you're making a grayscale program, you might be interested in the library for other reasons as well. But if that doesn't float your boat, you probably want to look into the _LoadPattern, _Load_SFont, and _Load_LFontV system calls. The first two are documented in TI's 83psysroutines.pdf and the third is documented on WikiTI.
201
« on: March 07, 2015, 09:21:31 pm »
It's possible with the MemKit Axiom included in the Tools folder of the Axe download. The commands you're looking for are the somewhat poorly-named New and Delete commands. If the included readme doesn't explain them well enough and you have questions about them after looking at it, just ask.
202
« on: March 06, 2015, 08:13:42 pm »
That's been on my todo list for a while, but it's a bit tricky to do optimally. And I generally don't like adding a new feature unless it's already well-optimized, which is why it's unfortuantely never made it into Axe.  For now, I'd recommend writing your own clipping code and feeding the clipped coordinates into the line routine.
203
« on: January 27, 2015, 02:20:18 pm »
5 binary degrees seems like it could work to me. If not, you can just decrease it easily enough.
204
« on: January 27, 2015, 02:10:57 pm »
You simply loop through angle values between the left edge of the field of view and the right edge. If you're raycasting for rendering purposes, the step size should usually be set such that one ray is cast for each column of pixels in the output. If you're raycasting for other purposes, it should usually be the largest value that is still small enough not to "miss" seeing objects between two rays.
205
« on: January 02, 2015, 02:45:46 pm »
This looks like it's coming along really nicely. But one thing has always bothered me slightly... the appearance of character sprites when scaled down. Loss of detail is of course unavoidable, but when lots of pixels are lost at smaller sizes, it can be hard just to recognize the character. Have you considered a mipmap-like system for which each sprite has a few scaled down versions as well? This would of course mean that every sprite needs more artwork done and will take up more space, but the graphical improvement may be worth it.
206
« on: December 19, 2014, 04:29:26 pm »
Hmm, I probably should've been able to guess you'd need to know how to turn it off too.  It's pretty straightforward, just one B_CALL which translates into this: Asm(EF7E4F)
207
« on: December 19, 2014, 04:07:14 pm »
In response to the last five posts, I don't think those pertain to what CKH4 is trying to do here...
Anyway, I managed to whip up a small "Axe" program to swap the functionality of the 2ND and ENTER keys. I put "Axe" in quotes because, as you probably know, a fair bit of assembly is needed to make hooks. But the logic of what the hook actually does is written in Axe.
As a preface, this will only work if your code is compiled as an application. With that out of the way, here's how to enable the hook:
ʟHook:Asm(DB06EF7B4F)
And here's the hook itself:
Lbl Hook
Asm(83FE1BC0260068)
(-9?+9-54??9-54)+54
Asm(F6017D)
Return
The assembly skeleton of this hook doesn't look exactly like those in MGOS' tutorial, and for an important reason. That's because his hook captures the kind of keypresses that you get from getKeyr, while this hook captures the kind of keypresses that you get from getKey. The important difference is that, as you may know, 2ND isn't actually captured by the former; it's a modifier key that changes the eventual result, but doesn't itself register as a key. So we need to intercept what are known as scan codes (the things returned by getKey) instead of key codes (the things returned by getKeyr).
This hook is called whenever the OS scans the keypad. The assembly skeleton handles things in a way such that the Axe code gets in the getKey-style scan code that was read, and should put out a scan code of the same format. In this case, my weird line of code with lots of 9's and 54's swaps scan codes 9 (ENTER) and 54 (2ND), leaving any other scan codes unchanged. If you wanted, you could replace these numbers with any pair of scan codes to swap them.
208
« on: December 02, 2014, 08:40:27 pm »
I never fully learned to touch type properly, so I use my index fingers for a lot more keys than I should. Apparently it couldn't have hurt my typing ability that much, though. 
209
« on: December 01, 2014, 02:12:20 pm »
Hmm, I guess I'm out of easy solution ideas then. Do you think you'd be capable of debugging the issue at the assembly level in an emulator? If not, are you able to post either the source or compiled code and tell me how to reproduce the issue so I could try it?
210
« on: December 01, 2014, 01:59:18 pm »
I can't think of any reason why Axe's interrupts would mess with the letter variables, at least in their default location. I just double-checked to make sure I didn't do anything really stupid, and I think I can confirm that no Axe routine or RAM location overlaps with the default location of the letter variables, at least since they were moved out of L1 (saveSScreen) in 1.2.0. Do you use any parts of static RAM not "sanctioned" by Axe, e.g. not L1-L6?
For reference, the letter variables were moved to $9D2F for 1.2.0 and 1.2.1, and were moved again to smallEditRam ($90D3) for 1.2.2. Also, the changes to interrupt code in 1.2.1 made it use $8624-$86A4 and $9200-$9301.
Pages: 1 ... 12 13 [14] 15 16 ... 153
|
Show Posts