1.
The language is
1. + pending
I am not afraid of BBC Basic. Please do not insult your members.
Besides that, let me try to be clear on what I mean by "pre-rendering" and
"let the game do the drawing". First let me divide our engine into two parts, the "pre-rendering" part, and the "rendering" part. The "pre-rendering" part is given the dimensions of a 3D prism, and calculates the coordinates to draw it on the screen. The "rendering" part takes the said coordinates and uses them to draw the 3D prism on the screen. Thus, the "rendering" part does no calculations at all, it merely takes pre-calculates coordinates and literally connects the dots.
Originally, the thought was that our engine would contain both parts together, so that when the game needed a 3D figure drawn, it would simply stick the dimensions in a list, and run our engine.
When I originally conceived "Pre-Rendering", what I meant was that our engine wouldn't have the "rendering" part in it; it would leave the actual drawing up to the game to do when it pleased. This would allow it to get all the coordinates ahead of time to make the game faster, but such a choice would be optional. This is what all of my previous posts have been referring to/trying to explain when I said "Pre-rendering"
A slight variation of this idea is for our engine to include both the "Pre-rendering" and the "rendering" parts, but in separate programs. Such a method would allow the flexibility of not having the "rendering" portion, while allowing the "rendering" part to be handled by the faster BBC basic. Although if it were up to me, we wouldn't even be discussing Ti-Basic vs BBC Basic until we knew for sure what we were trying to do!!!
I think that we should decide on one of the three aforementioned configurations (or a new contribution), without bringing Ti-Basic vs BBC Basic into the picture. Personally, I think that the last method is the best, affording both flexibility and speed.
2.
Whoops, my bad. Do you have both CUBES and PRISMS? I tried to download what I had uploaded, but it only gave me PRISMS. PRISMS is just the engine, it is completely useless on its own. CUBES is in the page's files, just go to PRISMS' page and select "files" at the bottom of the page. You should then see a list containing PRISMS, CUBES, and a PNG file (the screenshot). Click on CUBES to download it.
Once it is on your calculator, run CUBES. It will prompt you for a bunch of variables; here is what they mean
H: height of the prism (10-30 is a good number)
W: width of the prism (10-30 is a good number)
D: depth of the prism (10-20 is a good number, bowing becomes more prevalent at higher values.
S: whether or not the prism is solid. enter 1 for a "solid" prism, 0 for a "transparent" prism.
Once you have entered all the values, it will display your prism on the screen. Use the arrow keys to move it around.
Just a side note, for a game like cube field, this engine does all that we need. Yes, I know that it is too slow, but my knowledge of Ti-Basic has increased greatly since then, and I could more or less rewrite both of them only in optimizations, not actually changing anything. And if some of it were rewritten in BBC basic, who knows, maybe that's all it will take to make cube field a reality?
3.
I am not suggesting Ti-Basic. I am not suggesting BBC Basic. I am saying that BBC Basic won't work. I am not saying that I don't like BBC Basic. I am not saying I am afraid of BBC Basic. I am merely suggesting that we let this discussion wait until we know what we are trying to do!
Let me point out a few things:
1. x and y translation has absolutely nothing to do with 3D calculations. If you already have the coordinates to draw a prism, to change its location on the screen only involves adding or subtracting a number from all of the x or y coordinates. This is a quick and simple process in any programming language process; I simply suggested that the game handle it because I was trying to reduce the size, speed, and complexity of the engine.
2. The simple fact that the game will incorporate Ti-Basic will limit the final products speed to a max of maybe 10 fps, if our engine is entirely asm. I think that we need to be realistic about our expectations: the fastest Ti-basic game I've ever seen is War, and it runs at a blazing 7 fps. It would nearly unbelievable if we made a 3D engine that Ti-Basic games could incorporate and still run at 4 or 5 fps. That is what I hope to achieve, although in all reality 2 or 3 would still be groundbreaking. If you're aiming for 10+ fps, sorry but that's really aiming a little too high; Ti-Basic and BBC Basic have their limits. Unless of course, the game that utilizes this engine was written in BBC Basic or Asm.
Now, as for translation, I take back what I said. I think that it would be simpler if the game sent the coordinates of where it wanted the prism to our engine, which would then generate the coordinates of the prism relative to that point.
4.
I will post my revised method (and accompanying preliminary code) once I know what exactly it needs to do.
I need to let you know something. With all this mentioning of "our engine" and "the game", I have done something terrible. Many times. That's right…
I LOST THE GAME!