I guess it's better that way, though, especially if someone uses the function over 500 times in a game. It doesn't sound like much, but 500 bytes can make a big difference. Sometimes, someone may only have 800 bytes of RAM left to run his game.

Actually, why not have a way to map all your programs to some value or something.  Like have PrgmA map to 0, PrgmB map to 1, etc, then you could do:

Code: [Select]

int("0
int("1
for A and B respectively. Saves bytes, at least, and int remains as int and won't get confused.

That actually doesn't save much space, right? (Unless prgm is a 2 byte token and you use program names that are longer than 1 character?)

Quote from: Hot_Dog on January 06, 2011, 11:34:09 am

Quote from: DJ Omnimaga on January 06, 2011, 03:19:46 am

That actually doesn't save much space, right? (Unless prgm is a 2 byte token and you use program names that are longer than 1 character?)

Program names for fonts have to be 8 characters long, no less.  However, the big issue is how does the calculator know what program is mapped to 0 and what program is mapped to 1 unless you tell it?  And if you tell it, that takes a lot of space.

Not necessarily. I was thinking of having it be in the font files itself, but that might have conflicting fonts.  So then I thought of a font name that was just for that program.  You could even have primary and secondary names in the file, and still save bytes.  So, file prgmA, and prgmB have a primary name of "SADTest2", and a secondary name of "Hellowrd".  If SADTest2 has, say, two files that both claim to be the 1 file, then it tries the secondary name.

Does this make sense at all?