zacharyfruhling

Yes! I love seeing these old resurrected TI BASIC programs! Keep 'em coming!

Go for it! Don't let these little threads of computer history be lost to time! Dig them up and share them!

I want to take a moment to thank you, @pixelpedant, for all the time you've spent making these videos and responding to questions, even extremely low-level questions like all of mine recently! I have a real love for the TI-99/4A, but I haven't spent much time with it since I was a kid, and I'm starting to stretch my wings and take flight one program at a time. I figure spending some time with the constraints of TI BASIC and TI Extended BASIC for their own sake will make it just that much easier for me to upshift to more advanced techniques. "Fundamentals are the building blocks of fun," as they say.

The new TI Extended BASIC game I've been working on and that I've alluded to in other posts is coming along nicely; it's playable and the sprite collision detection is working acceptably—albeit with some room for further improvement. While I do plan to explore creating a complied version of the game with the Game Developer's Package, eventually, I want to (stubbornly?) be a purist and stick to regular TI Extended BASIC for this version. I'm getting to the point where I can start optimizing the code to further improve performance, and I'm hoping that folks here can post their best tips & tricks for optimizing TI Extended BASIC code. From combining statements on the same line numbers to (fill in the blank!), where can I get the biggest performance boost in TI Extended BASIC and with what techniques to use or avoid? Thanks, everyone! 🙂 Zachary

Thanks to the help of my benefactor known to me only as "CAS," I was able to recover another TI BASIC program from old cassette tapes. According to my dad, he remembers writing this program to train new electrical technicians on the use of various electrical formulas (e.g., Ohm's Law, the power formula, power factor, three-phase power, decibel increases/decreases, etc.) when he was an electrical technician at a Ball Metal can plant in Fairfield, California in the early 1980s. What I love about this program is that it's not merely a game program on the TI but an example of how forward-looking people were envisioning that personal computers could be used in novel ways in an actual industry context. And, from an education standpoint, it anticipates the ubiquity of online trainings and online coursework that we're all too familiar with nowadays in corporate and educational contexts. In any case, here's the recovered program "Formulas." Enjoy! Zachary Digital Archaeology: Recovered TI BASIC Program: "Formulas"

I know this is well-trodden territory for some folks here, but for me it's practically brand new, as I've never compiled a program for the TI-99/4A before. What are the options for compiling a program in TI Extended Basic? I'm working on an upcoming TI Extended BASIC game and would like to explore compiling it for improved performance and perhaps also for ease of sharing. If someone could provide an overview of the various options for compiling and any related walkthroughs/instructions, that would be very helpful—to me and hopefully to others as well. Thanks! 🙂 Zachary

Oh, I've been using GOSUB, not named subroutines. I've never used ON GOSUB before, as I'm still getting reacquainted with the TI again after more than a few years. I'll have to spend a little time with the TI Extended BASIC manual and wrap my head around how ON GOSUB works and how I could use it in the program I'm working on.

This is very helpful; thank you! While I don't think I can get away with having only one type of collision overall, with the game containing three different types of sprites, I'll try reworking the sprite collision detection subroutine in the manner you suggest (checking for any collision and then conditionally checking whether the two sprites in questions have collided) and see how much of a performance boost that gives me. While we're on the subject of optimization, are subroutines expensive from a performance standpoint? I've been making liberal use of subroutines, trying to make the program as modular as possible. But it occurs to me that perhaps the subroutine calls themselves are slowing things down.

As I mentioned in another thread, I've decided to use TI Extended BASIC instead of regular TI BASIC for the game I'm working on: a re-created version of a game my dad made for me in TI BASIC in the early 1980s. While I'm sure this is well-trodden territory here, please pardon the newbie questions! I would appreciate suggestions related to any or all of the following questions about sprite collision detection in TI Extended BASIC. While I have a MOSTLY working version of the game already, there is definitely room for improvement in sprite collision detection: Which method of sprite collision detection between two single-character-sized sprites is generally more reliable, CALL COINC or CALL DISTANCE? How would you go about reliably detecting when a sprite has left the screen? I've brute-forced this in my game, and it's MOSTLY working, although not all collisions between sprites and screen-edge hits are being detected, even when I add what I consider to be a rather generous tolerance level on the distance between the sprite and any of the screen edges. Clearly part of the problem I'm having involves the fact that the CALL COINC and/or CALL DISTANCE commands (I've used both back-to-back to maximize the chances of successfully detecting a collision) are not being called in the game loop when the sprite collision actually happens (80% of the time, perhaps). One idea I've had to is create a separate subroutine strictly for sprite collision detection and to call that subroutine at the very beginning of every other subroutine to check for sprite collisions much more frequently as the program runs. This strikes me as a heavy-handed approach (if, perhaps, the best solution), but am I overlooking other possible approaches to detecting sprite collisions more reliably as the program churns away? Thank you in advance to anyone who spends time offering up helpful suggestions; it is much appreciated! 🙂

I appreciate all of the suggestions, although I'm not sure how or why exactly this thread got so far off the rails after what I thought was a fairly straightforward question. Nostalgia is apparently a hell of a drug, and no matter how efficient I make my plain-old TI BASIC code, I just can't get the game I'm working on running at a speed even close to what I remember in the version of the game my dad made in the early 1980s (which was definitely in regular TI BASIC at our house at that time). So, to make a long story short, I decided to upgrade to TI Extended BASIC, which is the perfect balance for me between the very bare-bones look/feel that I want for this minimalist game with just enough of a performance improvement to make it genuinely playable. I know I haven't shared any details of the game I'm working on, but I really want to crank out as much of the project solo as I can, to make it true to my vision of what I remember the game being, before posting the finished or near-finished version to share. Thank you, again, to everyone who offered genuinely helpful suggestions! Although I dearly love programming on the TI, I haven't really kept up on all of the innovations over the years; my apologies for wanting to keep things simple in light of the amazing creativity and passion that the TI-99/4A innovators continue to bring to fruition. Perhaps I'll stick with it and do increasingly deeper dives into the full range of possibilities before too long. 🙂

Nostalgia is the only reason. My dad was able to make a working version of the program in regular TI BASIC that I'm attempting to recreate, and I thought I'd give myself the same constraints, just for proverbial kicks.

I was thinking that I would need variables to store the previous X,Y coordinates as well. Yes, I'm trying to avoid as much blinking as possible. One more question: Short of using sprites in Extended BASIC, is there a way to detect key press / key hold (say, to adjust a firing angle from a spaceship.) without massively slowing down the velocity of other items on the screen (e.g., a moving target character). I am able to create a Call Key loop to detect a key press/hold to rotate a firing angle (after some trial and error), but then the action on the screen just grinds to a halt while doing so. Any guidance on key hold detection without getting stuck in a loop that freezes up the game action would be very, very helpful!

Oh, I didn't realize that HCHAR was faster for placing single characters than VCHAR. I'll take every speed-boost tip I can get for this program!

It's a long story, but I'm trying to recreate an old game program my dad wrote for me when I was a little kid in regular TI BASIC. Using sprites in Extended BASIC would certainly simplify things, but I'm hoping to create as faithful a rendition of this old game as possible using only regular TI BASIC. (More details are forthcoming as I get further along in recreating the program!) Ah, yes, it sounds obvious now that you've said it, but one could just clear the old character using HCHAR or VCHAR and then use another HCHAR or VCHAR command to place the new character in an adjacent screen position. Thanks!

What are the best way(s) to move a game character on the screen in TI BASIC without clearing the entire screen with CALL CLEAR every time a character is repositioned?