I've been working on a program for the Ti-83+ which displays a Mode-7 style Pseudo-3D floor, similar to old games for the SNES like Super Mario Kart or F-Zero.


Download: https://drive.google.com/file/d/1eMi_uTRjV7W9wwHqIvkm4SloyUb3yUZ_/view?usp=sharing

Right now it runs at about 4 fps on a 15-MHz Calculator. I want to make this into a racing game for the 83+, but I don't know if it runs fast enough to be an actually fun game. What do you think?

I think a maximum for a monochrome calculator game should be about 15 FPS, and I mean maximum.

If you go to this website, and set it to a stationary background and no motion blur, you can see for yourself what a good FPS goal might be. For a game I was making, I decided on:

- 10 FPS = bare minimum to be playable
- 15 FPS = a good minimum goal to strive for when possible
- 20 FPS = pretty good for a calculator game
- 30 FPS = anything more than this is unnecessary and is just wasting battery

However this was for the CE, which has a much faster display. If you try to go above 8 FPS on a monochrome, the image will start getting blurry. Be aware these are just guesses, so do with this what you will.

Sorry about the messy thought pattern here by the way.

I say 4 fps is probably adequate given how fast you are going. Of course, that doesn't mean I don't want to see the framerate improved, but I think as long as the game doesn't go much faster that this could be a great racing game someday.

Very cool! I particularly like how you have object positioning included already.

I'm sure there are some optimisations you could make to gain some more FPS, but it's a good start .

tr1p1ea, I just noticed this thread of yours: https://www.cemetech.net/forum/viewtopic.php?t=9757&postdays=0&postorder=asc&start=0

Is it alright with you that we're working on very similar projects?

Of course - the more the better!

Looking forward to seeing some more progress .

I've managed to get the frame-rate up to about 7 fps by optimizing the multiplication routine.

looks neat
But I got to say 7fps is bear playable.

How are you going to speed up the fps?

The only thing I can think of right now would be to lower the resolution some more, but I'm not sure if that would be worth the speed increase.

you don't want to your project to eat up mem. so try running "functions" when needed and add and manage parameters.

I've been working on the exact same thing but I think I have a much faster method method using lookup tables (I'm hoping for full-res 20fps but I'll likely have to do half horizontal resolution on the non-SE model), can we team up or something if you're still here? I have ideas but not much experience with assembly

My idea involves a lot of of lookup tables, about 80k of them, but I think it can be optimised down to something like 15k which would fit in a single application page

This is my progress on the calculator so far, except I had to make it ridiculously tiny because I haven't figured out how to create applications so I have to fit it in 8k of data
https://cdn.discordapp.com/attachments/270991870576820224/822530865380720730/unknown.png
This is the logic implemented in Python (this is entirely lookup tables, no maths needed)
https://cdn.discordapp.com/attachments/270991870576820224/820352928615104542/output.gif

Oh, looking at the code, you do use a lookup table of some sort, hmm...
Well my idea shouldn't need a multiplication routine
What exactly is your lookup table for? (I'm very new to assembly so I can't really understand it)

My C code (I'm using sdcc for now and I'll port it to assembly later) for the lookup table looks something like this:

Code:


So that should be a lot faster than anything involving multiplication, I hope?

The lookup-table in my program is basically there to skip half of the calculation needed for the 3d effect. The first few calculations for each pixel didn't take into account the camera's position or rotation, and thus always result in the same value, so I made a lookup table to replace those first few calculations.

Your approach involving many more lookup tables is interesting. My one concern with your method would be how much memory it would take up. About how big do you think each lookup table would need to be? If I remember correctly the 83+ only has 20 pages (320k bytes) of application data, and less than 2 pages (32k) of ram.

The way I'm doing it is similar to a 360° panorama, except instead of storing pixels I store positions on the plane that can be offset, 2 bytes for X and 2 bytes for Y. 32 pixels vertically as it fills half the screen and with an 80° FOV it works out to 432 horizontally.
32 × 432 × 4 bytes = 55296 bytes
But we can improve that number. In theory we should be able to only store a 90° section and use negation to calculate the rest, so
55296 bytes ÷ 4 = 13824 bytes
Also, the bottom 30% or so of the image only needs 8 bytes to point to the position, so that cuts it down to around 11759 bytes (this isn't exact).
But scrolling along a panorama creates a fisheye effect and doesn't look very convincing, so to get what was in that GIF we need distortion correction. This can be done with another lookup table, just storing a new Y position to sample for each original position. That's 1 byte per pixel.
32 × 96 × 1 byte = 3072 bytes
But the lookup table is symmetrical (I think), so we can halve that to 1536.
11759 bytes + 1536 bytes = 13295 bytes
I think that's reasonable for much better performance
P.S. Do you have Discord? I can talk here but I prefer Discord if you wouldn't mind talking there, I'm circuit10#0158