I'll be honest, it's been a while since I've programmed on my calculator. But here a couple other tidbits (and others, please correct me if I am not remembering correctly). When you are using strings for collision detection you have to be a little careful for when your maps get larger. It can be a great way of doing it, but the further you have to search in the string for collision the slower your program is going to run.

You could, however, most likely use a list I believe. I can think of a few ways of accomplishing this, but with the list I don't think you will ever get slowness. The other side of that is that I believe lists are limited to a certain number of indexes, and you have a potential size issue again (but not as much as matrices if I remember correctly).

Anywho, just wanted to chime in real fast since I was mentioned.

Veterans, by all means tear this post to threads if I am incorrect

Well...it has been quite a while since I posted here. Hey everyone.

Anyways, point of this. A few years ago I wrote a snake game. That snake game was probably one of the smallest snake games (if not the smallest), at least at the time. 361 bytes (or whatever the unit is...I don't remember).

I was planning on not only releasing the game to you guys, but was also going to write a complete tutorial on basic game writing because I had kept each stage of the game. It would have just been about one way of going about a game. Places to start, how to think about it, maybe some optimization. I don't remember all the details.

Unfortunately, I have not come bearing this tutorial. I do come though with the game...in text form. I've been planning on just posting it for a while now so you guys could play with it, but haven't had the time/motivation. So I figured why not today.

ClrHome
{8.4,7.4→L1
DelVar DDelVarS2→C
DelVar Y1→X //DelVar Y then 1→X
Repeat min(L1≠F
randInt(1,16)+.1randInt(1,8→F
End
Output(10fPart(F),iPart(F),"+
Repeat L>1
getKey→K
Output(10fPart(L1(1)),iPart(L1(1)),"*
If Y
Then
(K=26)-(K=24→X
If Ans
DelVar Y
Else
.1((K=34)-(K=25→Y
If Ans
DelVar X
End
Output(10fPart(L1(C)),iPart(L1(C)),"_ //_ = Space
X+L1(1
Ans-16((Ans>=17)-(Ans<1
Y+Ans
Ans-.8((fPart(Ans)=.9-not(fPart(Ans
augment({Ans},L1→L1
If F=L1(1
Then
S+1→S
Repeat min(L1≠F
randInt(1,16)+.1randInt(1,8→F
End
Output(10fPart(Ans),iPart(Ans),"+
C+1→C
End
C→dim(L1
sum(L1=L1(1→L
End
ClrHome
Output(1,1,"SCORE:_
Output(1,8,S

I'll be honest, I don't remember how exactly everything works. But I do know that it basically just refreshes the start of the snake, deletes the last, and ya. Hopefully some of you guys can answer the questions about what things are doing what

I remember I had Kerm look this over after I wrote it and I don't think he saw any other spots to make it smaller or faster. I'm curious if you guys see anything.
I also apologize for if there is a typo somewhere in there. I don't think there is one, but could be.
Enjoy.

SIDE NOTE:
If I ever am able to get the actual file off my calculator I'll try to attach that.

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".

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.

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...).

So...this is awkward as it has been so long since I've posted anything, let alone started a topic. But, does anyone happen to have Weregoose's binary conversion algorithm? The really small one that outputs into a list. I could probably go track it down, but I feel like it is somewhere in the nether-regions of this website by now...

Thanks

Incredibly late post...again. But I am actually writing a tutorial/helper that involves a snake program I wrote. I was supposed to make this like a year ago but then life, school, and work took over...so I'm still working on it but it should be coming out hopefully in the next few weeks.