Survey posted 2004-07-09 21:43 by Jon.

Contribute ideas to surveys by sending a mail to survey@ticalc.org.

Survey idea by Morgan, choices by me : )

POTY = "Program of the Year"

Publicity, sorry, but i didnt think many people would see it way down there.

try this code (83x BASIC):
Input "STYLE: ",A
Input "FREQU: ",B
Shade(-10-(10/96), 10+(10/96), -10-(10/63), 10+(10/63), A, B

Remove the spaces after each comma.
It's really amazing. For example: Clearscreen, run the program and enter 3 and 3 as your values. The wait and without clearing the screen, run it again and enter 3 and 4. Repeat, still not clearscreening, and enter 4 and 3. One last time with 4 and 4. It makes a really cool pattern. You can try a bunch of variations on this, just play around, it's stunning the kind of power this code has. Really, TRY IT OUT. I made an advanced version that takes list inputs instead, for those extremely confident in their use of this code:
Input L1
Input L2
For(A,1,dim(L1),1
Shade(-10-(10/96), 10+(10/96), -10-(10/63), 10+(10/63), L1(A), L2(A)
End

Remove spaces after each comma in the Shade statement.
Have fun, and I really insist you try out that first code and do my example.

Oh, and in the first code, the first two lines /might/ be switched, but it doesn't affect the example and I have no way of checking the code as I'm at the library. It's just in my head; I had a field day with it every math class every year and decided it was time to tell someone. You can get, to my count, about 50 self-repeating (is that the term for when you zoom in and see exactly what you saw from afar, like in fractals?) patterns. It's really a reward to find a really good one after awhile of trying. Plus it passes the time very well.

Just to clarify and avoid any questions. All featured programs from 2004 and some from December of 2003 witll be in the contest. Thus by "submit" we aren't saying there is a place to submit your files. If you need something featured to get it in the contest, talk to featprog@ticalc.org.

I hate to be one of those people that always says that you forgot an option, hpwever you let one slip by this time. I would fall into the category:

I am not a good enough programmer to have a program featured! :-)

same here, I only program in BASIC... But good BASIC though, none of that bad stuff... :)

I also have very little experience programming in anything other than TI-Basic...so I'm not going to even hope one of my programs is featured because the chances of that happening are so low.

"good BASIC" is an oxymoron.

Not necessarily. Guardian for the Ti-89 is an awesome game I played a while back, completely written in basic. However, that game did have a few bugs that never got corrected, and it was written in 2000 so I'm not sure if the authors would fix them anyway. It was (and still is) an awesome game.

I write good BASIC. What bad techniques do you assume I use?

I don't think he was talking about coding technique. I think he was talking about gameplay, graphics, and most importantly speed of games. I would rather have miscellaneous files in basic than asm because of stability, but for games speed is definitely an issue.

I can write it to be fast.

of course, but there just isn't enough power to do a /lot/ fast.

Of course, this is where the art of making a program look like it's doing a lot when it actually isn't (event-based architecture) comes in.

it's fun to see how deep you can make a program look without any features. For example make a botchat client that only responds to things might type right off the bat, like "hi" or "what's your name". Or try to predict what the player will do in a game and make that the only thing you develop. always fun.

I was thinking about, for example, getting pointing device coordinates and the confirmation key (I use a routine called zzmouse), opening a certain menu based on the confirmation key, then processing the menu choice at a certain label (based on what the user clicked on) by using the fact that Exact mode symbolic variables are recognized as valid label names.

To generate the menu, I would define strings at the beginning of the program to make menus and then pass them to FLib at certain labels. Perhaps I could also use a routine to generate the filename based on events and then open it, which generally is faster. OK, FLib isn't BASIC, but part of 'good programming technique' is not reinventing the wheel.

Off the top of my head (returnel is a routine I use to turn a list element into a string) is a word-processor routine: Click on a formatting button and go back to accepting text

This is a self-contained routine, not a program

:Local ms, fl, str_el, mode (C) Declares the routine return variables and the mode restoration variables local
:getMode("ALL")->mode (C) Saves settings
:setMode("Exact/Approx", "EXACT") (C) Allows expressions to be used as labels
:flib("clrscr", "fillrect:0,0,5,5,2") (C) Clears the screen and adds a control
:zzmouse() (C) Allows the user to click on the control
:returnel(ms,1) (C) Returns the column, and inferentially what control was clicked on
:Goto expr(a&ceiling(expr(str_el/10)))
:(C)Labels for each button
:setMode(mode) (C) Restores modes
:hsr() (C) Recalls the home screen

That's good BASIC. It may need some debugging, like any code (I just thought of it off the top of my head), but it's still conceptually good code. It's low-level, in BASIC, and surprisingly fast.

heueh? is that computer BASIC or TIBASIC?

TI-BASIC.

Don't the colons and ->'s give it away? :)

hmmzah, definately not 83 basic...

w00t! for the TI-89 family. Its TI-BASIC is so much different...

and the (C) instead of REM

I'm not sure about 68k BASIC, but in 83+ BASIC, you can use the Input command with no arguments as a pointing device. it gives you the big plus used on the graphscreen, and you can use the arrows to move around and hit enter when you are done. The coordinates are in X and Y, but they are Cartesian: they depend on the WINDOW settings.

yupyupyup. There's an 'ok' 83+ BASIC tic-tac-toe that uses that technique. I made a "interactive picture" of windows XP (what with the start menus, and other hierarchial menus branching off of that) with that command too. It's in the manual I think.

zzmouse is faster. Plus, with Input the cursor is a plus sign and it only works on the graph screen.

I never use that because it is too slow. It doesn't support 2nd + Right or Left

It really isn't. I am working on a BASIC RPG right now with one of my friends. It has a frame rate of around 10 fps, which is about as fast as you can get in BASIC, I think. The graphics are very good, too. It should be finished in a few months.

10fps? That's hard to believe... i dont even think a for-looped clrscrn can run 10 times in a second.

For...EndFor is slow.

:Local getky
:Loop
:flib("clrscr")
:blackscr()
:getkey()->getky
:If getky!=0 Then
:Exit
:EndIf
:EndLoop

That-^ is much faster. In fact, it's so fast that occasionally the gray is indistinguishable from the contrast.

For Z80, substitute Lbl...Goto for Loop...EndLoop.

I know != is a C operator, but there's no not-equals symbol on my keyboard.

If you really want For...EndFor, you can code it yourself and it will be much faster, especially if you integrate it with the loop and it will distribute the slowness over the routine instead of having one very slow function.

While 1 ... End is faster than Lbl ... Goto.

Why not just use CyclePic? (Yes, I realize that flib uses the entire screen, but is it really worth the stability problems?)

FLib is unstable? I used it becasue it uses the whole screen and it's faster.

I started programming a large game with it, and every time I turned off my calculator it crashed.

Your Calculator?

HW:

TI-:

AMS:

Free Memory:

Program Size:

Execution in Archive:

Any other notes about the program? Were you trying to turn off the calculator? What FLib calls were you using before the crash?

HW2
AMS 2.09
Free Memory
RAM: about 70000
Archive: about 500000
Program size: the main program was about 3000, but all the other files that were necesary took up almost 100000 bytes

I could do whatever i wanted while the calculator was on, but as soon as I turned it off, a black bar appeared at the top. I used many different flib calls in the program, and many flib2 calls as well, since I was using a text file to hold most of the data. I used getline to retrieve long strings of characters from the teext file. I then used flib("map") to create a picture using about 70 sprites called:
#("sp"&char (seq(x,x,1,n,1))) [ommitting characters not allowed in variable names]

What is an example of a name that would be produced by that statement?

Did it ever Garbage Collect?

Wait...I still don't get whether you were using the program to turn off the device or it was manual or it turned off as the result of a crash. If it was manual, this would be the first ever case of a BASIC TSR, so that's probably unlikely.

Some example names are "spa", "sp4", and "spö".

It never garbage collected.

I turned it off manually using 2nd + Off

The only other ASM program on my calc besides flib and flib2 was fastkbd.

Are you sure it stopped running before you turned it off?

Did it come back to the screen you left it on or did it display the APPS Desktop with the Line1111 bar at the top?

This is unlikely to make a difference, but did you use local variables? If you did, try globalizing them and run it again (if you still have the program).

Specifically, what command did the program stop on?

Yes I am sure it stopped running.

It came back to the home screen (where I left it) and froze up, with a black bar at the top.

I used global variables.

When you say "stop" do you mean stop normally at EndPrgm or Stop, or do you mean freeze up?

Freeze up. I was looking for a breakpoint.

You could type /= for "not equal". It's converted to the correct symbol on the calculator. Neat, eh?

Most languages use != , not just C.

prgmWAVES
:Lbl 1
:RecallPic 1
:ClrDraw
:Goto 1

Where Pic 1 is a all black picture.

When run on a 83+ is makes a weird wavy pattern <see link> (the screen shot makes it look really crappy, it is alot cooler on a real calc.)

try this code (83x BASIC):
Input "STYLE: ",A
Input "FREQU: ",B
Shade(-10-(10/96), 10+(10/96), -10-(10/63), 10+(10/63), A, B

Remove the spaces after each comma.
It's really amazing. For example: Clearscreen, run the program and enter 3 and 3 as your values. The wait and without clearing the screen, run it again and enter 3 and 4. Repeat, still not clearscreening, and enter 4 and 3. One last time with 4 and 4. It makes a really cool pattern. You can try a bunch of variations on this, just play around, it's stunning the kind of power this code has. Really, TRY IT OUT. I made an advanced version that takes list inputs instead, for those extremely confident in their use of this code:
Input L1
Input L2
For(A,1,dim(L1),1
Shade(-10-(10/96), 10+(10/96), -10-(10/63), 10+(10/63), L1(A), L2(A)
End

Remove spaces after each comma in the Shade statement.
Have fun, and I really insist you try out that first code and do my example.

I didn't use clrscrn, I used RplcPic

Why do you think I posted it the way I did?? I figured someone out there might get a good laugh out of that statement.

Actually, TI-Basic is great for any nontrivial symbolic manipulation.

Noooo...there are plenty of good BASIC programs. The reason that most people think all BASIC progs suck is because they only see the bad ones, which there *are* a lot of because BASIC is easier to use (in general) than assembly. The compiler is right on the calc-you don't need to download an assembler, learn opcode memnonics, etc.

Actually, I'm pretty sure basic is interpreted, not compiled.

BASIC is tokenized-parts of code mean parts of ASM code, which is then run. Specifically, precisely, it's more like the Exec arguments with a sophisticated program converting the arguments, functions, OS components, and programs to ASM versions. It's kind of compiled.

BASIC is tokenized into one- or two-byte symbols which are more easily interpreted than multi-byte commands. There still needs to be an interpreter to run the program.

On the TI-86 and the 68k calcs, commands can be typed in by hand or selected from a list. These have to be translated to tokens before the program can run. This is why recently-editted programs take awhile to start running. Editting a recently-tokenized program causes the tokens to be expanded to their human-friendly command names.

On the TI-83, 82, 83+, etc., I think commands are kept as tokens, but they are displayed as strings of letters and symbols (such as parentheses) when a program is editted (or on the homescreen). This is why programs (even recently-editted programs) all start running immediately or at least quickly on these calcs.

It is-the assembler I referred to was for writing assembly progs.

You obviously have not looked at the BASIC archives in any detail.

LOL, same here, though if I find the time, I will try to create an entry.

Some basic programmers are geniuses! O_o
I'd use a stable basic program over asm any day.
..seeing how a lot of asm programs are programmed poorly and when this happens your calc is liable to f**k up.

yeah, sicode was amazing. some code i've written is completely unintelligible too. coughcough line statements

That's why you archive everything. Simple.

Or you just back up everything before trying the program for the first time if you don't have flash. I've only found a couple of unstable assembly progs out of the hundreds I've tried.

Same here... if a program is really that unstable, I doubt they'd upload it. Most programmers try to work their bugs out before releasing their stuff.

I wanted it to be an optimistic survey!! : )

In other words, yes, I did seem to forget that option.

Tsk Tsk...its ok we are all rookies at one point in time :-)

aww, i was going to submit by ultra-sooper-dooper-mega BASIC quadratic solver... :(

that was a joke, people.

*phew* I figured as much.

[insert that kindly condescendingly looking phpbb ;) emoticon here]

GOOD!!!!!! :-)