Ah, I didn't rememebr it started such a long time ago
(Also yes, a color version would be quite cool lol (but slower ?)

I think he should first finish the normal version, but yeah, a color version would be kinda cool (or a sound version?)

Necro-post for my favorite thread 
About the sprite drawing, iirc you kinda gave up and made the pokemon sprites drawn by asm because basic was too slow...
Why can't you use that text-sprite trick(the one with the for loop displaying characters).  Wouldn't that display the pixels fast enough to make drawing the pokemon fast enough to be viable in basic?

The size may or may not be an issue. While hex data represents four pixels in every one "number" (he is using hex right?), text sprites would be five pixels (I believe) to every one character stored, but vertically instead of horizontally. So there is promise there. However, there is one, or two or something, combinations that are not possible with text sprites. (If I remember everything correctly...) But also, when you get to size, you may end up having a whole extra row of data because you have...16x16 (?)...sprites, which isn't divisible by 5 evenly...So that could be where you're wasting space.

(By the way, I am extremely tired...so if the above statement does not make sense, let me know and I'll try to rewrite it. I also didn't bother doing the math because I'm far too lazy for that as of right now.)

EDIT:
Okay, I did some math now. Since I'm fairly sure all his Pokemon are 16x16 the size wouldn't actually change at all. This is because with hex you are storing 4 characters for the columns (4 is the number of pixels per number, so 16 / 4 = 4) by 16 characters for rows (since you need a new character for each new row) while if you use text sprites you will have 16 column characters by 4 row characters (5 * 4 = 20; 20 > 16). If you used 3 row characters you'd be missing an entire row.

However, this changes if he were to use 32x32 sprites (which I think he is for the NPCs?). In which case you'd have 8x32 characters for hex (8 = 32 / 4), while you'd have 32x7 for text sprites (7 * 5 = 35; 35 > 32). So, you'd have 256 characters per every hex sprite, and 224 for every text sprite. Which turns out to be a 32 character difference.

I believe my math is correct, somebody correct me if I'm wrong.

Anywho, what I basically mean by this is that size isn't really an issue. The only issue, assuming what I said is correct, is that text sprites don't represent every combination of pixels. So if you had a Pokemon sprite that used specific combination of pixels you'd either have to go without those pixels, change the entire sprite so it doesn't use that combination, or write in a specific case in the display routine that will turn that pixel on (which...isn't a bad idea really...).

Nah, I'm pretty sure even with the extended characters you can't. I remember making a text sprite maker a long time ago and making sure there wasn't any hidden character that fills them in. (I'm pretty sure you have to use some for the combinations...)

Oh, and he most certainly knows how to use them. I mean it's tifreak He just has his reasons, such as the none-usable combinations or speed or something.

But they don't save any size unless he converts the 32x32 sprites to them. And they don't necessarily save speed. It all depends on the algorithm you write. (Which, knowing him he'd optimize that crap out of it until it was as small/fast as possible.) I mean I'd be willing to bet the assembly version is much faster because, well, it's assembly. It's inherently much, much faster than TI-BASIC. Assembly will also give a very smooth animation as everything will display evenly, if not instantaneously, from the speed. Text sprites need to be drawn either straight left to right, with a five pixel skip interval vertically, slowing down slightly the further into the string you read.

But again, I'm assuming he has his reasons for using assembly instead of text sprites.

Yes, but the other point is that it's his game and he has his reasons. Which, he has them. Honestly, he's probably considered all of this before (or maybe not, I can't read his mind). For all we know, the assembly is smaller and better. Ultimately though, it's not our choice. It's his.

Ya, that's what I was saying. He's well aware of the method, but there is some reason he isn't. Whether it's speed, size, or something else.

Also, no if I remember correctly. There are most combinations but not all. I can't remember how many though, I think it's like 2...but not entirely sure. Z, or somebody, would know And ya, that's what I was saying in my longer post. That he'd either have to go without that set and substitute something else in OR he'd have to write in a specific statement that says "if this is a combination that doesn't exist, use the closest combination and turn on the correct pixels manually".