Anyone who has used Kerm's Graph 3DC 3D graphing application for the TI-84 Plus CSE has probably noticed that its equivalent has yet to be published for the TI-84 Plus CE. During the past two weeks I have been working on my own 3D grapher for the CE, utilizing the CE's superior processing speed and written using PT_'s ICE Compiler. I am already underway into coding this, though I have hit a few roadblocks simply to ICE's constraints. This program, once complete, will be packed with features, even more so than Graph 3DC. A few major differences (some of them negative, due to this program being written in ICE) between my program and Kerm's will be:

▪It will use the entire screen, and will not show the OS status bar.

▪It will not be able to interact with OS Trace features, though my own will eventually be created.

▪All menu interaction (Z= menu, window customization, settings) will be tailored specifically for this program and will not resemble OS menus.

▪Not all OS Catalog functions will be available, only the essentials. I will create my own that ICE lacks, especially trig functions.

Ok, maybe those things were all bad. But here's the list of features!

▪Editable window/zoom variables

▪Isometric mode and Perspective mode

▪Multiple drawing modes: Each of the following modes can be independently turned on an off.

~Wire frame: Applies a frame of squares to the graph, each point being a point on the graph.

~Contour levels: Applies high quality contour levels to the graph, showing height differences.

~Solid: Simulates placing non-transparent shapes inside the wire frame squares, and hides lines behind it. Essentially a solid surface rather than a transparent surface.

~Colorization: Applies color based on the Z state of each point. This will affect the wire frame, contour levels, and solid surface, but will only affect one at once.


▪Full rotation

▪Polar and Parametric graphing modes (Kerm said this was a little ambitious, and he's probably right. If it's too hard I won't do it.

▪Color layering: When colorization is enabled, it will be crucial to include smart layering that will depend upon rotation and graphing modes. This will prevent the graph from placing a father away line above a closer one.

Screenshots will be added as soon as I can (translation: as soon as I feel like it). A small poke at PT_ to make tirg command in ICE, but I can make my own if I truly need them. Suggestions, hatemail, and marriage requests below!

So... Trig commands are kinda... ambitious for an ICE project, seeing as ICE uses 24 bit (PT_ can correct me if I'm wrong) integers. And to create trig functions, you can either do BCD or F.P. Since it would be slightly annoying (translation: very annoying) to rewrite ICE to fit this, you probably will want to try to work it out yourself if you want it. And how are you working with negative integers? A bias on the numbers? This could be interesting, though.
How far along are you with this?

The program currently simulates negative integers by adding some large power of two (I forgot exactly what it was) to each expression and then having all number below that be negative. The program also simulates decimals (to the hundredth) by adding an extra two zeros to each integer. It's complicated.

I'm not quite 1/4 complete, but I've gotten what I think are the complicated items out of the way. I still don't have a pretty way to handle Z= user input.

Why don't you just use two's complement for signed integers? It's not hard at all.

Well i could but that would mean rewriting my program at this point but it's doable.

For the trig expressions, you can use the Taylor series. http://people.math.sc.edu/girardi/m142/handouts/10sTaylorPolySeries.pdf

Just approximate the series to a certain arbitrarily large amount, and you're done. Almost.

Thanks a lot! Kerm pointed me in this direction at one point, but I lost the link...

What you could do given the fact that ICE does not support all the tokens that are generally available, would be to create your own asm sub program and insert it into ICE using exechex(). The simplest way I can think of doing this would be to just create a basic program with the user's input in it and have it loop through the points you want to calculate one at a time, storing them to a list to be recalled later. This would also account for errors within what the user has inputted, if there is a mistake, the OS will catch it.

I have a system similar to this already in place, but it's not pretty. In the end I'd like the program to be as seamless as Graph 3DC.

You should consider changing it; it might save your program from being too slow.

Marry me?

(btw, this is awesome, and i am looking forward to it!)

Really awesome! I only think this is not feasible in ICE, unless you can write native Assembly as well. Anyway, if you have questions about anything or ICE, feel free to ask it!

I fear that this program may be out of ICE's reach without the code being ridden with execHex(. I'm going to try writing this in C.

C would probably be best for this. Plus, it's a lot easier to write stuff in C. (especially math stuff)

The C iteration of this program is now up to date with its ICE counterpart, though when I tried implementing contour levels, a bug appeared which proceeded to slowly transform my calculator screen to some multicolored hellscape.

One thing I've been working on is a sort of predictive program architecture which, when you are viewing a graph without rotating, continues to calculate graph video data for rotations around the current rotation, allowing for near instant graph rotation when turning short distances. Of course, the current one being calculated will be terminated if a key is pressed, to simulate just a pause in the program.

This is exciting! Screenshot, maybe?