Pony Express (monochrome)
---------------------------------
So if you saw on google on Tuesday, there was a cool little game that you could play. I decided to try to recreate this on the calculator. This may or may not turn into another of my projects, so if someone else wants to take it up and make it faster and more playable (in Axe, ASM, whatever) you can.

Screenshot: (the game doesn't actually look buggy on my calc; that's just jsTIfied)

The lines represent cacti, and the boxes represent mail. Currently, there's no collision detection/mail detection, as I literally just started coding this like 20 mins ago...

EDIT: Things (hopefully) to be added
-More obstacles and paths
---obstacles: rocks, cacti(added), falling snow, cowboy, fences, water, trees, houses
---paths: bridges, horse stable
-mail counter (points)
-finish line (town)

-optimization and movement smoothing probably using DoorsCS basic libs

Anyways, the code is currently written in almost pure basic, with 1 hex code that shifts the screen left 4. I chose left 4 because the program was too slow to support smoother movement.

Code:

prgmZPONY:

Code:


Also, the way it generates the obstacles and mail is just random. On the google doodle, the map is the same every time, so the code could be improved to do that. I'm not super good when it comes to scrolling and maps, so maybe someone else could program that.

As always, I strongly recommend you use the relevant existing Doors CS libraries, in this case ShiftScreen. Good luck with this: tifreak8x and I were discussing a port, so it looks like if we do get to it, we should focus on the TI-84+CSE to avoid treading on your toes.

nahh, don't worry. as i said, if someone would like to take this up themselves, than please, go ahead. I'd be happy to help whoever takes this up. anyways, making one for CSE would be very cool! I can't wait to see it. Looking at the image size of the doodle, it looks like you would be able to make a very close replica (graphically) of the game because of how big the CSE screen is

As I said in the post, I am not very experienced in scrolling games, especially if I wanted to implement a map, just like the google doodle has (the google doodle isn't random, like mine), so I would be happy if anyone wants to be a co-author. Anyways, I will look into those libs.

Well, all you need to do to make the map the same is to seed rand.

In preliminary optimizing for speed, if you're looking to use hybrid BASIC, each call to rand takes 15 ms. The framerate seems to be about 150 ms/frame, and you have two calls to rand, one of which can be replaced by a 5-ms fPart(E7[rand from earlier] without losing much randomness.

You can save about 6 ms in overhead by unrolling :For(B,0,50,10:Pt-On(94,B:End, and another 5 ms or so by changing all of them to Pxl-On. Assembly would be a better choice, though, or changing the existing assembly code to not shift them at all, or something...

It doesn't seem like you can do much optimizing at all in pure BASIC.

aha! I had completely forgot about seeding rand, thanks for reminding me!

Kerm, thanks for the BasicLib help. Is there any other things I can do to speed this up?

[Note]
Things (hopefully) to be added
-More obstacles and paths
---obstacles: rocks, cacti(added), falling snow, cowboy, fences, water, trees, houses
---paths: bridges, horse stable
-mail counter (points)
-finish line (town)

of course, the color version will look way better, but unfortunately i don't have a color calculator :/ :/ still gonna try to do this though! any help is appreciated, as this area of coding is where i'm less experienced

[EDIT]

would you happen to know how to do that? would that speed it up or would the adjustment needed for that to happen slow it down? if it speeds it up, which i'm guessing it does, how big of a difference is it?

Sorry, I don't know any assembly, though it shouldn't be too hard. Of course, don't change it until you're done with the program.

You can use a smaller screen movement in your assembly program (assuming it's a Very Fast routine) by calling it multiple times per loop. For example, you can call it once after generating your random numbers and doing collision detection, and again after moving stuff, and move the screen by 2px each time.

When I get to the computer, I'll edit your code to what I believe is a more optimized version.

...and?

I don't know what willwac had, but I can't see any major optimizations. The small things I do see: first, it saves a multiplication (although I'm only about 90% sure this is faster) if you use these:
Code:


The correct idiom for speed is
Code:

That is only called when the player moves, so it will make only a small difference in speed.

The Text(,,"[plotsquare] can be a Pt-On(,,2, but that doesn't happen most of the time so it will make a tiny difference in speed.

Like I said before, what you have is pretty much all you can do for speed in BASIC.