Cross-posted from Omnimaga

Hey guys,

Seeing the challenge TheMachine02 shamelessly sent me (), I wanted to try and do some 3D, but this time without defining any vertex by advance. So this came out.

What it features :

• 3D graphing of any function that only involves integer maths (8.8 maths are coming, maybe) on the [-6,6] range (13*9 = 117 dots)
  
• Dynamic movement around the graphed function : translation, rotation around the Y axis and zooming in/out
  
• Dots and grid view
  
• Clipped line routine !
  
• Support for animated functions. More on that below
  
• All of that in less than 2400 bytes of pure Axe !

So yeah, it's not really useful, but I found that it would be cool to try and do such program.

Small precision : the graphed function doesn't give exact results. I mean, there's no such thing as units. The only point of that is making good-looking results on-screen, it's not a mathematics tool.

How to use it : by default, prgmDOTSURF (Noshell executable) will graph the 2x² function. You can move around the graphed function with the arrows, zoom in with + and out with -, rotate left with [Y=] and rotate right with [graph], switch between dots and grid view with [mode] and exit with [clear].

You can also define your own function for the program to graph. To do that, just edit prgmFUNC3D. While I'm speaking about a "function", this is actually Axe code that you'll have to compile. I want to make this into a more user-friendly way, but I still have to figure how. Here're instructions on how you can define your function :

• The graphed function is f(x,z) = y. X and Z of the current point are passed respectively in r2 and r3, from -6 to 6 and -4 to 4 respectively. You are free to use these, but they must remain the same value at the beginning and the end of your function. They are used for the drawing code. Also, store the resulting Y coordinate into r6. Do not use Return.
  
• You cannot edit any of the following variables, meaning that they must have the same value before and after your function : r2, r3, r4, A, B, C, D, E, F, H, V, Y, Z, Θ. Also, you can't use any of the bytes from L1 to L1+702, nor the 256 first bytes of L3.
  
• If you want to use trig, do not use Axe's sin/cos functions, but type Sin() and Cos() instead. Those are way faster, LUT-based routines that I made. Remember that this will destroy r1, unless you call it with sub(Sin) or sub(Cos) and write the value right before it. Those functions still returns the same output as Axe's ones. Also, Y holds the current Y rotation angle.
  
• You can write animated functions : the O variable is a timer that gets incremented by 16 every frame. You are free to use it.

Remember that grid mode will lag a lot at 6MHz, since the program has to draw a line between each of the 117 dots.

So, I think that's all. For those who don't know Axe but want to try anyway, I give you some functions that you can copy in prgmFUNC3D (that will also be an example for those who want to write their own ) :

The default 2x² :
r2*r2*2→r6

One of my favourite functions (also, one that demonstrates well the clipped line routine), the good old x^3 :
r2*r2*r2→r6

Some animated sinusoidal function :
Sin(r2*16+O)//4→r6

More animated sinusoidal function to demonstrate the use of both X and Z coordinates to generate Y :
Sin(r2*16+O)+Cos(r3*16+O)//4→r6

Here's a little screenshot that describes the process of drawing 2x² and navigating around the graphed function (at 6MHz of course) :



Don't be horrified by the how-so non-user-friendly interface, I'm working on it

prgmFUNC3D is the program you have to edit to write your own function, prgmSINE3D is the source to compile, and prgmDOTSURF is the executable (here, it contains the 2x² default function).

Feel free to make functions, share them with others if you want, and don't hesitate to ask if you have questions

That's a very nice use of your routines, Matref! It looks like it's only about two or three times slower than Graph3, which is pretty cool given how optimized Graph3's trig routines are. I'm glad to hear that you're working on making the interface a bit more friendly, and I hope that this turns into a decent 3D grapher for the 83+/84+ series. As you know, I'm partial to my Graph 3D v4.0, which is equally accurate but of course much, much slower. Keep us updated on progress on this, especially considering how much we care about promoting educational programs in addition to games.

Well, as I said this is not educational. It's not giving any result in form of numbers, and I'm not willing to make it a grapher. It's just to have nice things on your calculator screen.

Oh, you don't anticipate adding a trace function or anything? Fair enough, I understand making it an eye candy sort of program too. So what do you plan to add in the more user-friendly interface you mentioned?

I plan to add 8.8 fixed-point maths support, to emulate a support for decimal numbers, but the main thing I'm willing to do is to have the ability to input the function in TI-Basic style. I guess I'll have to write my own parser for that.

Why not just call into _ParseInp? Writing your own parser is a massive pain in the neck, as AHelper and I discovered for Graph3DP. I'm planning to port that to the TI-84+CSE (in ASM), and although the 3D math is going to be less fun in ASM, the fact that I can use TI's equation parser is going to make my life a lot easier.

But _ParseInp does run Basic programs, right ? I can't use that, because the functions would be waaaay too slow when ran through all the 117 points of the environment.

_ParseInp computes the result of any kind of expression, of which TI-BASIC programs happen to be one type. Y= equations are another, as are expr()'d expressions. I'm not sure how fast or slow it will be, but it's certainly what I'm going to use, regardless of speed.

Well, I told you it was not that hard to write an equation parser

This is 6 MHz :



This is 15 MHz :



I don't release anything for now because I want to get number parsing working first.

X*((X*X)+X) gogogo correct operator ordering. It's far from easy to write an equation parser, especially in ASM. But anyway, keep up the good work; it looks particularly nice in 15MHz!

Of course it's not easy, I was joking. However, implementing parenthesis is even easier in ASM than in Axe : it's just push/pop.

Also, I just noticed some possible optimisations.

True, but if you have (X+1)+(X+2)*(X+3), you have to process the three parentheses, then the multiplication, then the addition. One possible approach is to simplify the contents of parentheses until you can remove them completely, then process the remaining operators in order of precedence. And glad you noticed some optimizations!

Seeing the non-mathematical purpose of the program, I can take some liberties on the equation parser. For example, no operations priority.