I'd love to see how fast this runs displaying the graph. Looks awesome so far!
tifreak8x wrote:
I'd love to see how fast this runs displaying the graph. Looks awesome so far!
An excellent question! I still have plenty of math adjustments to make (for example, it's using a hard-coded equation right now), but here's how it looks so far:

*bump* I've actually been working really hard over this over the past week or so; my goal is to have something reasonably functional to show off by the end of the weekend (which is even more of a challenge given how much thesis work I need to do). I've focused on:
  • Sunday, Tuesday, and Wednesday: Jumping through the ridiculous hoops necessary to sanely hook the Y= menu to create my Z= menu. Our documentation is a bit sparse, so there has been plenty of trial-and-error.
  • Thursday and Friday: Further refinement of input in the Z= menu. Changeover from a single hard-coded equation to actual use of equations entered in the Z= menu via _ParseInp, plus plumbing and debugging to make multiple simultaneous equations work as designed. Implementation of a new "high-res" mode that allows 2 equations with 27x27-point meshes instead of the normal 5 equations with 17x17-point meshes.


*bump* New progress from today: progress bars that show how far along the program is in calculating the initial graph (this only has to be done once when you press [GRAPH], not every time you rotate). Fixed bugs with swapping the scrap RAM page used to store coordinates and colors in and out. Fixed bug with very small fixed-point numbers causing graphical glitches. Noted down other very minor bugs to be fixed. The following screenshots include a section of z=2sin(x*cos(y)) on x=[-2,2], y=[-2,2] with a grid of dimension 27 along the x and y axes.

I've been working hard on my thesis work, but chipping away at relatively easy-to-fix bugs and features in Graph3DC in my breaks. Here's what I've done between yesterday and today:

Code:
; [X] Fix color leak with 2+ simultaneous equations
; [X] Go somewhere handy after selecting a zoom option -> fixed via JForceGraphNoKey
; [X] Handle errors in ParseInp
For that last one, I wrap an error handler around _ParseInp via AppOnErr/AppOffErr, which allows me to silently handle nonreal answers and divisions by zero. For example, the following is the graph of z1=1/(xy):



Code:
; [X] Fix rendering in 3D even in 2D mode. -> Was related to RAM page swapping.
; [X] Display proper Zn value next to progress bars
; [X] Fix wrong RAM page swapped in when GraphRender ends
; [X] Fix Window menu not triggering starting from Graph screen -> Now fix no lines appearing -> Done
; [-] Fix spectrum colors coming out too dark -> Marked WONTFIX for now (was intentional)
; [-] Is graph getting drawn X-flipped? Y-flipped? -> Looks good.
; [X] Try to improve precision when doing mapping to screen coords.
For that last one, I managed to re-arrange my fixed-point math to get another 4 bits of precision out. Left is before the fix, right is after the fix. This is looking straight down onto the graph of z1=max(x,y):
Kerm; this looks amazing! Smile Keep up the great work, and I hope that if and when an app key comes for the CE, rendering speed will also increase.
Thanks! I'd like to briefly step back and review the goals and status of this project. Graph3DC is a 3D graphing App for the TI-84 Plus C Silver Edition and (hopefully) the TI-84 Plus CE. Like Transformation Graphing and Inequality Graphing, it uses hooks to enhance the TI-OS's own graphing features, so users still use the familiar Y=, Window, Zoom, and Graph screens. Graph3DC can graph up to 5 simultaneous 3D equations in a normal-resolution mode, or 2 simultaneous equations in a high-resolution mode. Like the 2D graphing features in the TI-OS, it will provide zooming, tracing, and manipulation of graphs.

The screenshots below show the current status of Graph3DC. From top left: (1) One version of the splash screen that lets you install, reinstall, or uninstall Graph3DC; (2) the normal Y= menu, with an option to enable 3D graphing in the Plot line; (3) the 3D Z= menu, with an equation entered and the option to disable 3D graphing in the Plot line; (4) the Window menu when 3D graphing is enabled; (5) the Zoom menu when 3D graphing is enabled; (6-8) sample graphs, showing different formatting options.

*bump* I've been working hard on all kinds of things, but here's an update from about a week ago, when Runer112 helped me to implement an optimized version of an algorithm for averaging two RGB565 colors together. This was necessary because the color for each line segment was previously derived just from the color assigned to one of its endpoints. For lines with steep changes in Z, this led to asymmetrical coloring on the wireframe, as on the left below. With averaging, a line's color is the average of its endpoints' colors, providing symmetric coloring, as on the right below.



Edit: I put together some rudimentary tracing today while waiting for an academic cluster to come back online; here's how it looks so far. Funnily enough, working on this finally pushed me to just write a custom context instead of trying to continue to work with cxGraph and the GraphHook, because the cxGraph context will redraw the borders around the graph area on the graphscreen when the user presses [TRACE] before giving the [TRACE] key to the GraphHook (which means the hook doesn't have a chance to cancel the OS's trace action before the redraw, and I didn't want to toss on more keyhooks).

I like how that graph shown in the animated screenshot a few posts ago actually renders faster than 2D graphs from the TI-OS. Razz

Good job, by the way. I like the integration in the TI-OS Smile
This work you've been doing is simply amazing. That cannot be stressed enough. I really, really wish I knew how to use this project to its full potential.
DJ_O wrote:
I like how that graph shown in the animated screenshot a few posts ago actually renders faster than 2D graphs from the TI-OS. Razz
By the time you're rotating a graph, the colors and Z coordinates of all of the points in the grid have been computed; in that screenshot, it is erasing the graph, performing 3D rotation on the model, then re-rendering it. The slow part, which I haven't shown here, is the initial computation of the Z coordinates of each point. It's slow because I need to pass the Z equations through the OS's parser (Xsteps * Ysteps) times, unfortunately.

Quote:
Good job, by the way. I like the integration in the TI-OS Smile
Thanks! I appreciate you all suggesting this; I think it's a much cleaner solution than having a standalone program, now that I see it in action. The hooks are not fun to reverse-engineer, but I like the result.

tifreak8x wrote:
This work you've been doing is simply amazing. That cannot be stressed enough. I really, really wish I knew how to use this project to its full potential.
That's very kind of you to say. Your encouragement certainly helps drive my progress on this project.

Edit: Lots of debugging and feature-writing. I fixed the X and Y coordinates being flipped left-to-right and top-to-bottom, and I've begun the laborious process of displaying the trace coordinates. I'm going to try to save and restore the LCD under the coordinates, and switch them to the bottom of the screen if the trace cursor is in danger of overlapping the coordinates. I'm planning to display the equation for the currently-traced graph up in the status area.

Looks awesome! Any chance that there will be different 3D graphing styles other than wireframe, like the 68k series and Nspire series have?
pimathbrainiac wrote:
Looks awesome! Any chance that there will be different 3D graphing styles other than wireframe, like the 68k series and Nspire series have?
I'd love to create a filled-polygon style, but I don't know what the correct way to do that is (ie, the sorting and filling of the polygons. I suspect scanlines are part of it. Does anyone have experience or documentation on this that I could read? I suppose I can also inspect the Graph3 source.

Edit: I added displaying the current equation in the status area, as well as tapping [TRACE] to switch between currently-enabled graphs.

Looking really awesome Kerm! I like the trace feature, I assume you can swith between two active graphs using that?
Unicorn wrote:
Looking really awesome Kerm! I like the trace feature, I assume you can swith between two active graphs using that?

KermMartian wrote:
...as well as tapping [TRACE] to switch between currently-enabled graphs.


That would be the implication, yes Razz

This is looking absolutely amazing, Kerm! I'm a bit confused about the initial calculation, though-- is it calculating all possible rotations/transformations of the graph right off the bat? If not, what does it set up?
M. I. Wright wrote:
This is looking absolutely amazing, Kerm! I'm a bit confused about the initial calculation, though-- is it calculating all possible rotations/transformations of the graph right off the bat? If not, what does it set up?
First, it needs to plug each (X,Y) pair in the grid into the Z1 through Z6 equations, and compute the coordinates of each (X,Y,Z) point in 3D space. That's the slow part, because the TI-OS equation parser has to be invoked for each (X,Y) point, once per enabled equation (ie, numEnabledEQs*dimX*dimY). The default "low-res" grid is 17x17, and the default "high-res" grid is 27x27, so that's 289 to 729 invocations of the parser per equation. That's the slow part. Once I have all of that information in 8.8-bit fixed-point format, I can perform much, much faster transformations to draw and rotate the graph, which is why there's a single slow process to show the graph, and then much faster rotation (and tracing).

I did a lot of work to figure out how to force the [2nd] and [ALPHA] symbols to show up in the status area (for future reference, it's 2,(iy+$3e), which I'm calling saIndicForce,(iy+extraIndicFlags)), and also decided to use RAM page 7 to store the 85x36-pixel area under the coordinate text, which you can see restored each time the trace cursor moves in the following screenshot. Also keep an eye on the status area; you'll see the equation change when I tap [TRACE] between Z1=3sin(X)+3sin(Y) and Z2=4sin(X)+4sin(Y). My next task, other than gradual fixes to interactions with the TI-OS, is to create the format menu, which should be fun and exciting.

Wow, this looks amazing!

How do you cycle through all the (x,y) pairs? I mean, not that I really want to know in that language, but in BASIC, I'm thinking you would have to use a For() command to loop through all the x's with y=0, all the y's with x=0, and then from there, you could do all the ones where x=y (0,0), (1,1), (2,2) etc. So then how would you do all the ones in-between? There's so many combinations... how would you do it in BASIC?
Michael2_3B wrote:
Wow, this looks amazing!

How do you cycle through all the (x,y) pairs? I mean, not that I really want to know in that language, but in BASIC, I'm thinking you would have to use a For() command to loop through all the x's with y=0, all the y's with x=0, and then from there, you could do all the ones where x=y (0,0), (1,1), (2,2) etc. So then how would you do all the ones in-between? There's so many combinations... how would you do it in BASIC?
Thanks! In TI-BASIC, it would look exactly like this:
Code:
For(Y,-8,8
For(X,-8,8
Z1(X,Y)->(whatever)
End
End
That would repeat the loop over all Ys for each X value.
KermMartian wrote:
Michael2_3B wrote:
Wow, this looks amazing!

How do you cycle through all the (x,y) pairs? I mean, not that I really want to know in that language, but in BASIC, I'm thinking you would have to use a For() command to loop through all the x's with y=0, all the y's with x=0, and then from there, you could do all the ones where x=y (0,0), (1,1), (2,2) etc. So then how would you do all the ones in-between? There's so many combinations... how would you do it in BASIC?
Thanks! In TI-BASIC, it would look exactly like this:
Code:
For(Y,-8,8
For(X,-8,8
Z1(X,Y)->(whatever)
End
End
That would repeat the loop over all Ys for each X value.

Oh, that makes perfect sense. I guess I wasn't thinking for a second there Razz For some odd reason I was thinking that two for() loops wouldn't work, but now I see.
I've started work on a Format menu. Because the user-accessible Dialog routines don't seem to work correctly on the TI-84+CSE and higher (presumably because TI didn't maintain those routines past the TI-84+/SE), I'm writing my own menu code for this sort of menu. Here's the current table format:

Code:
FormatTable:
   .db 2
   .db MT_OPTION,SETTINGS_AVOFF_AXISMODE,1,"AxesOn",0
   .db MT_OPTION,SETTINGS_AVOFF_AXISMODE,0,"AxesOff",0
   .db 2
   .db MT_OPTION,SETTINGS_AVOFF_BOUNDSMODE,1,"BoundsOn",0
   .db MT_OPTION,SETTINGS_AVOFF_BOUNDSMODE,0,"BoundsOff",0
   .db 4
   .db MT_TEXT,"Color:",0
   .db MT_OPTION,SETTINGS_AVOFF_COLOR,0,"Full",0
   .db MT_OPTION,SETTINGS_AVOFF_COLOR,1,"Blues",0
   .db MT_OPTION,SETTINGS_AVOFF_COLOR,2,"Flame",0
   .db 3
   .db MT_TEXT,"Background:",0
   .db MT_OPTIONW,SETTINGS_AVOFF_BGCOLOR,$ff,$ff,"White",0
   .db MT_OPTIONW,SETTINGS_AVOFF_BGCOLOR,$00,$00,"Black",0
   .db 2
   .db MT_OPTION,SETTINGS_AVOFF_LABEL,0,"LabelOff",0
   .db MT_OPTION,SETTINGS_AVOFF_LABEL,1,"LabelOn",0

And here's the result of my routine that displays the table. I haven't yet created the functions to deal with (1) keys and (2) the cursor flashing.

Edit: Now I have, and it works pretty nicely. It can handle one-byte and two-byte constants being set into offsets into a table of settings. If I were to work further on it for general use, I'd probably make it able to set/reset bits and handle title-only lines, like the real dialog system. Anyway, it works for my purposes; the only thing I still want to add is a callback that will let me draw a little thumbnail of the graph line color when you select an item in the Color: row.

  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 3 of 5
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement