JWinslow23 is currently making This is the Only Level for the 84+ calcs in assembly. He challenged me to make a playable one-stage demo in pure TI-BASIC for monochrome 84+. Although that was mostly a joke, I think it's actually marginally possible given enough speed optimization. This thread is mostly so I can keep track of my own ideas/progress.

I've looked at a few other attempts at platformers, like Contra 83 (the very first one) and Absolute Madness. Contra is very slow, averaging about 2 FPS (but that's at 6 MHz). It uses, I think, text sprites, and has enemies, which slow the game down more. Absolute Madness also uses text sprites as far as I can tell, but has several further features like being able to push around a ball during movement. Both are tile-based, and both are barely playable before one adjusts to the input lag.

My goal is 6 FPS at 15 MHz, giving me a budget of 167 ms per frame in the average case. I hope that techniques discovered since 2011 can make this possible.

Here are some ideas I have to speed a program up:

* Finance variables throughout. The objective is speed; size isn't too important.
* Checking for solid ground using one or two pxl-Test( instead of looking up position in a matrix.
* Very simple sprites, just a single letter. Displaying the letter with Text( takes just 5 ms, and erasing a position with spaces takes only 10 ms.
* Perhaps a tile system like that of Absolute Madness, if the required speed is infeasible without tiling. Perhaps the character can move in half-tile increments?
* Lots of short-circuiting. Possibly Lbl:End subroutines.

Some problems:

* getKey takes 8 ms per call. If I take input more than once per frame, this will quickly eat into the time budget. If not, input will be restricted to once per frame, which may make gameplay difficult. Additionally, getKey can only detect one keypress at a time.

What I think is feasible to implement in 167 ms/frame:

* Left-right movement on a platform
* Movement while jumping
* Gravity with acceleration
* Maybe a way to control jump height?

Some things that are probably impossible:

* Scrolling (it's possible to have two sides of the screen, though, stored in two different pictures)
* Impressive graphics that aren't static.

Other helpful timings:

* Skipping each line of code in a false If:Then statement takes about 1 ms.
* 2>abs(|N-25 takes about 3 ms.
* RecallPic takes 27 ms. I guess I could recall a picture every five frames or so, fixing any mistakes with correcting player position. However, it's a bit expensive to call every frame, and probably too expensive to call more than once. I'll need to carefully plan my sprite drawing to minimize the number of calls.
* StoPic takes 4 ms. I don't know how often I'll be using it without text sprites though.
* ClrDraw takes 100 ms. I won't be using many of those, if any.

Oh wow, now a thread. You're really serious.

...heh. Touche.

Is this going to be compatible with all 84+ series calculators, being Pure TI-BASIC?

Dudeman313: Yes. I can't think of a reason I'd need MP commands like remainder(, so this should work on pre-MP OSs as well. I'm currently writing for monochrome calculators, because that's what I own.

Oh, okay. I just have a CE that I'm thinking of modifying Portal CE for the same project, and I'd love to test this when it gets going.

This looks like a pretty neat idea! I love platformers One thing that certainly makes it faster is if you limit the amount of things you are drawing onscreen. I made a simple one for the monochromes in basic quite a while back; not too sure how the source is looking, but it is fairly fast considering all of the things that are happening: DigMan (For inspiration or something)

Anywho, good luck, and I can't wait to see how fast you can make it

I've written my first code on the project. Right now it's just basic l/r movement, jumping, gravity with acceleration, and hardcoded flat ground, and takes 55 ms per frame (18 FPS). Which is about what I thought it would be. I tested it with a rand delay in each frame to bring the frame rate down to 6 FPS, and even though only one key can be processed in each frame, it's quite playable. So I won't be taking input twice per frame.

It's a pretty standard, but it proves two things: that what I thought could be implemented in 50 ms/frame really can be, and that 6 FPS is acceptable.

As for whether to restrict movement of the player to tiles, I don't see any cons to restricting that horizontally; however, vertically it will make jumps much less smooth. I don't like the idea of having the player only move one tile at a time vertically.

However, if we don't restrict vertical movement to tiles, we run into another problem: how to check for the ground. It can no longer be done with one or two pxl-test(): say the player is 2 units above the floor and would descend 3 units based on the gravity. There would need to be some way to determine where the floor is.

Solutions for this are "floating" gravity where the player descends a constant amount per frame while falling, in effect making the tiles smaller than the player.

It seems like it'll get even more complicated with midair platforms.

Bump.

How's progress on this? Any sort of demo you willing to release?

Yes, Lirtosiast, I confirm that sometimes miracles happen in TI-Basic

A few weeks ago , I started to write a lateral scrolling in pure TI-Basic and succeeded in writing a kind of mini-demo :
in this last version , the game is during a few minutes and we have infinite lives.
I found a way to have a sensitive keyboard : you let the key [del] pressed , meanwhile you press on another key to move up "a la flappy bird".

It also runs on 6mhz calculators but 15mhz ones are recommended.

Here's a screenshot:



(more details here : https://tiplanet.org/forum/viewtopic.php?f=11&t=17866&start=20#p197949 )

Unfortunately, I have limited time due to homework (for both this and serious projects). I can't promise anything soon.

grosgred, that's some impressive speed. I'll look over your source to see how you manage to get the entire screen to shift so fast.

He actually doesn't shift the entire screen. He uses Line() commands and the checkerboard pattern of the ground to give the illusion of screen shifting by two pixels at a time. It's still impressive, though!