Hello all,

This is my attempt at building a 3D grapher for the CE using the C toolchain. The math is based on some 3D grapher I found on desmos (https://www.desmos.com/calculator/nqom2ih05g). It's actually really slow and very poorly written for now, since this has just been an on-and-off project I've worked on for the last few months or so. Features for now are:

►Typing in custom equations in Reverse Polish (or postfix) notation
►Rotating the view of the 3D graph

sadly that's it actually (for now). In the future, when I have some time to spare:

►More efficient, faster graphing
►Shunting yard algorithm for infix notation parsing
►More options for graphing (perspective vs orthographic, colors, etc)
►Cylindrical and spherical plots (in the VERY distant future)

Here it is graphing a hyperbolic paraboloid (be patient haha):


If you want to look at my (awful) code:
https://github.com/garrettluu/r-cubed
I haven't had time to really sit down and polish this code, but I tried to be good about commenting.
You will see how some stuff is crudely commented out and left to rot in "I might need this later" hell.

Anyways, thank you for taking time to read this post! Any help you can give on this project is appreciated, since I don't usually have much time to work on this.

16.5 KB. Not bad for a first design. I suppose the one way to get experience on programming is just doing it.

That said, you should take advantage of the self-documenting paradigm of C and strive to keep your code as clean as possible. For instance, instead of doing this:

Code:


do this:


Code:


Note that the float and double primitives both have a width of 32 bits in the eZ80, but you could probably get a speed improvement if you switched to another float type (can't find anything about this online, probably due to the absence of processors with 24-bit registers without built-in FP instructions). See Xeda112358's FP routines for the Z80, whose thread URL is not liked by phpBB due to parentheses. It's quite interesting, and you should be able to inline it or link it despite being in assembly.

Second, are you recalculating the points on every new perspective? You'd get a significantly better framerate if you did transformations on the points themselves and then drew lines between them.

https://www.omnimaga.org/asm-language/(z80)-floating-point-routines/

Looks nice!

2 things though: it might be a good idea to add a timer/progress bar when displaying a graph. Otherwise you are just waiting until the graph suddenly appears. Other thing is that if you use Git to push commits, please add a .gitignore with "bin" and "obj" in it, otherwise bin/DEMO.8xp, bin/DEMO.map etc will be changed with literally every commit you make. If you don't use Git, I recommend you to do so

Very nice work I got bored tonight so I just really quickly cleaned up your code and repository. You can approve the pull request here to merge it into your code base. Keep up the good work; and always remember there is an easier way

Confirm PR here: https://github.com/garrettluu/r-cubed/pull/2

Here's the speed at 9.6KB I got just with some optimizations and whatnot; still always more to find



Enjoy!

Sweet!
I'm having some trouble compiling the project right now though. It's complaining about my obj files, any help?

Make sure you have installed the latest toolchain and run this command:


Code:

Fixed the issue! I edited the makefile in the past to work with my setup, and those changes didn't survive the merge. Thanks for the help anyways

I want to point you to my ICE Compiler RPN parser, which parses RPN notated equations as well. From looking at your code, you call parseRPN twice per vertex, so it's very important to optimize that for speed. So here are some suggestions from someone who has a bit experience with RPN notation:

• Each time you call the routine, it does the same handlings, except the variables of course. To increase your speed a lot, you can 'save' these handlings the first time you run the parser, to call later. Then you don't need to check if "sin" = "sin" etc, which saves a lot of time.
  
• Like that, I recommend to parse the equation once, before calculating stuff, and instead of using the characters from the equation, parse them as types, i.e. numbers, variables, functions, etc. if (tok == TYPE_FUNCTION) is a lot faster than something like if (strcmp(tokens,"sin") == 0).
  
• Once you evaluate an operator/function, you push the result to a stack. Fine, but I think it can be shorter somehow. ICE stores the result in 'Ans', and if the result is used in one of the next 2 operands, it recalls Ans instead of popping it from the stack. If the net 2 operands (numbers, variables, operators, function...) isn't an operator or function, then you can push it to recall later. This requires a lot more parsing, but after all it'll be faster, I think.

Goodluck with this project!

Wow a 3D grapher in C. Works good!!! Great job!