*bump* I've gotten a lot down in the last three weeks or so, despite other engagements; the following is the list of what I have completed from my Graph3DC to-do list since May 25th:
Code: ; [X] Add ZoomFact to Window menu
; [-] Remove step_x / step_y? -> Still need for fixed-point X and Y computation
; [X] Try to optimize computation as much as possible: Pre-compute X and Y and X/Yinc, eg? -> Saved ~14% time for 289 points
; [X] Don't use ScaleFactor to scale ZoomFact in Window menu (x2)
; [X] Fix looping menu <> graph after using the Zoom menu
; [X] Consider averaging point colors for line colors -> Thanks to Runer112 for working through this with me and writing an optimized version
; [-] Experiment with the regraph hook for v--- this
; [X] Fix rendering when you leave via a menu and then return
; [X] Add some kind of graphDirty flag for switching between trace and graph.
; [X] +/- zooming from graph mode
; [-] Fix 2D graphing freezing after entering a 3D equation (Cannot replicate...?)
; [X] Implement Format menu
; [X] Implement Tracing
; [X] Apply graphhook key fixes to formathook and vice versa so all keys work right
; [X] Fix redrawing Format menu after other menu -> change cxCurApp? Yep, that did it.
; [X] Display proper number of equations based on mode
; [X] Add high-resolution, 2-equation mode -> set starting res properly based on mode
; [X] Set default res to 17/27 when switching modes
; [X] Erase progress bars using a fill
; [X] Reset colors before possible error message in graph computation
; [X] Fix resetting window when entering the Format menu
; [X] Fix erasing behind Format menu
; [X] Fix flashing trace cursor when no equations are enabled
; [X] Fix memory leak on context change out of Graph or Format mode
; [-] Fix bug in Y= menu when entering a menu or using Rcl. -> Unable to replicate
; [X] Explain what's happening while computation is underway
; [/] Add tip for equation entry in Y= menu
Most recently, I implemented proper labeling for the axes, by computing three extra points in 3D space for the center of each axis label. Here's a demo of rotating a graph with LabelOn.
Looking great! I'll be getting a CSE soon, and this'll be one of the first programs on it!
Ivoah wrote:
Looking great! I'll be getting a CSE soon, and this'll be one of the first programs on it!
Thanks, and I'm glad! I'm going to want to do extensive beta-testing to make sure that it plays well with the OS and with other Apps and programs, so beta testers will be wanted and needed.
*bump* Here's what's new:
Code: ; [X] Add ability to label X, Y, and Z axes; add LabelOn/Off flag
; [X] Add tip for equation entry in Y= menu
; [X] Fix top line of Y=/Z= menu in splitscreen mode
; [X] Implement cleaner way to avoid going into style icons
; [X] Fix freeze when scrolling up after multiline Z= equation entry (changeset 38)
; [X] Resolve inconsistencies with how enabled Z= equations are displayed (changeset 39: hl was destroyed in YEquHook_Full)
; [X] Fix bug when Z= equation entry expands to second line -> related to blocking style editing? -> ended up being very complex.
; Final solution is to perform equation-swapping between Y= and Z= equations and to just use the Y= menu in its normal function mode.
; [X] Try to fix Window menu title in scrolling splitscreen mode
; [X] Fix ellipses with long equations in graph status area -> simple logic error
; [-] Fix EOL erasing not occuring properly in Y= menu when screen scrolls -> Cannot replicate
; [-] Fix status area app title in graph menu [not replicable?]
; [X] Fix explanation display when Z= scrolls -> Moved to top of window
; [X] Test interactions with programs -> Allows programs to use Y= mode even when Z= mode is enabled for the user
And here's what's still left on my todo list: Code: ; [ ] Fix context-switching out of Format menu (context-change hook getting wrong value) -> stack level...?
; [ ] Make 2:Goto in syntax error go to proper equation somehow
; [ ] Deal with split-screen flag.
; [ ] Adjust MapFactorY and/or MapFactorX for splitscreen modes?
; [ ] Test in splitscreen mode, including -F-o-r-m-a-t-, -W-i-n-d-o-w-, -Z-o-o-m-, -Y-=-, Graph
; [ ] Test interaction between Transform and G3DC in all menus
; [ ] Lots of beta-testing!
To add some eye candy to this post and make it less a wall of text, here's a demonstration of the horizontal split-screen mode enabled and disabled in my custom Y= (Z=) menu:
Two major items of progress from the last few days and today, respectively:
1) Over the last few days, I figured out how to force the TI-OS to give my App control when re-drawing the top half of the screen in horizontal splitscreen mode. This was a really tricky one: my eventual solution is to (a) set grfSChanged,(iy+sgrFlags) every time the TI-OS is changing contexts or leaving a menu, which (b) forces my reGraphHook to fire, allowing me to draw a 3D graph on the top half of the screen. I introduced a new checksum over the graph's coordinate and color data, stored in RAM Page 6, that allows me to avoid recomputing the graph every time the user changes apps (that would be a real drag!).
2) I realized from working on splitscreen mode that something was wrong with the mapping to screen Y coordinates from 3D space. I determined the following useful formula for variable-height Y viewing areas, optimized to work well with my fixed-point math routines:
Code: Let desired = px_height*[0.5+(dy-ey)*(ez/dz)]
Let output format = 256*MapFactorY+256*[(dy-ey)*((5/4)*ez/dz)]
256*MapFactorY + 256*[(dy-ey)*((5/4)*ez/dz)] = px_height*[0.5+(dy-ey)*(ez/dz)]
256*MapFactorY + 256*(dy-ey)*[(5/4)*(ez/dz)] = px_height*0.5 + px_height*(dy-ey)*(ez/dz)
Equating terms, 256*(5/4) = 320 != px_height
Rename MapFactorY to MapFactorY2, add new MapFactorY1
256*MapFactorY2 + 256*MapFactorY1*(dy-ey)*[(5/4)*(ez/dz)] = px_height*0.5 + px_height*(dy-ey)*(ez/dz)
Thus 256*MapFactorY2 = px_height*0.5 and 256*MapFactorY1*(dy-ey)*[(5/4)*(ez/dz)] = px_height*(dy-ey)*(ez/dz)
MapFactorY2 = 0.5*px_height / 256; 256*(5/4)*MapFactorY1 = px_height
MapFactorY1 = px_height / 320
Screenshots coming once I fix a few more things.
Great work! I can't wait until this is released, and I hope TI notices how important the app signing key is to us and how it would help them.
Thanks, I appreciate the continued support, and I can't wait for your help in beta-testing the application.
I've made further strides with splitscreen support; here are my latest screenshots showing proper clipping:
Continuing superb work, sir. What's left with this particular support? What's next on the list?
tifreak8x wrote:
Continuing superb work, sir. What's left with this particular support? What's next on the list?
Thanks, and thanks for asking. There are still a few missing items for splitscreen support, notably in exiting menus and properly redrawing the graph, and displaying the contents of the homescreen correctly when a 3D graph is also drawn. Here's what my todo list looks like: Code: ; [ ] Deal with split-screen flag.
; [X] Fix invalidating graph on zoom menu items (move the _resets) and Y= editing
; [X] Adjust MapFactorY and/or MapFactorX for splitscreen modes?
; [X] Test in splitscreen mode, including -F-o-r-m-a-t-, -W-i-n-d-o-w-, -Z-o-o-m-, -Y-=-, -G-r-a-p-h-
; [X] Adjust culling code to take max and min Y into account
; [X] Fix redisplay of homescreen in 3D splitscreen mode
; [X] set grfSChanged when switching 2D<>3D modes in splitscreen mode
; [X] Replicate and fix freeze after switching split mode without enabling 3D mode
; [ ] Test and correct glitchiness of graph after Catalog
; [ ] Implement self-adjusting scaling!
; [ ] Fix context-switching out of Format menu (context-change hook getting wrong value) -> stack level...?
; [ ] Make 2:Goto in syntax error go to proper equation somehow
; [ ] Test graph-table mode and adjust accordingly. Implement table mode?
; [ ] Test interaction between Transform and G3DC in all menus
; [ ] Lots of beta-testing!
Edit: Corrected the list above to reflect what I got done since 8:55pm. Here's a demonstration of all that working properly:
Great work, it's coming along wonderfully! Just two little questions:
1. will there be the calc menu? To find like min, max, intersection points, etc.?
2. Why the change from black to white background? Is it just to ressemble the OS's graph screen?
mr womp womp wrote:
Great work, it's coming along wonderfully! Just two little questions:
1. will there be the calc menu? To find like min, max, intersection points, etc.?
My current plans don't include such a menu, unfortunately. You can trace over any graphed function, though.
Quote:
2. Why the change from black to white background? Is it just to ressemble the OS's graph screen?
I changed the default background color to white, to resemble the OS's graphscreen, but as you can see from the Format menu, users are more than welcome to change it to black:
Edit: I believe I've just about solved the last issues, bugs, and missing features for splitscreen graphing, including re-rendering the graph properly when leaving a menu. It turned out that because the regraph hook is not called when the TI-OS is returning from a menu to the homescreen, I instead needed to detect leaving a menu from my existing menuHook and install a temporary cxRedispHook. The cxRedispHook displays the current 3D graph over the top half of the screen, then disables itself (restoring any existing cxRedispHook, and chaining with it as well). On to these items! Code: ; [ ] Implement self-adjusting scaling!
; [ ] Fix context-switching out of Format menu (context-change hook getting wrong value) -> stack level...?
; [ ] Make 2:Goto in syntax error go to proper equation somehow
; [ ] Test graph-table mode and adjust accordingly. Implement table mode?
; [ ] Test what happens when you select Draw, Calc, and Table menu items when 3D mode is enabled.
; [ ] Test interaction between Transform and G3DC in all menus
; [ ] Lots of beta-testing!
*bump* New progress so far from last night and this afternoon:
Code: ; [X] Fix bounds when no equations enabled -> create fake min/max Z
; [X] Fix display of graphs not centered on (0,0,0) (rotation already works properly) -> current work manipulates cx/y/z
; [X] Don't force rotation around z=0 -> store computed Z bounds in appvar for use, including for cz?
; [X] Re-fix label erase
; [X] Test graph-table mode and adjust accordingly. Implement table mode? -> No. But catch it?
And of course, to keep people interested, some screenshots:
Edit: Here's a question for you guys: what do you think the defaults should be for:
1) Axis labels (x, y, and z)? On or off?
2) Bounds (the gray box around the graph area): On or off?
KermMartian wrote:
Edit: Here's a question for you guys: what do you think the defaults should be for:
1) Axis labels (x, y, and z)? On or off?
2) Bounds (the gray box around the graph area): On or off?
1) Axis labels on
2) Bounds off
PT_ wrote:
KermMartian wrote:
Edit: Here's a question for you guys: what do you think the defaults should be for:
1) Axis labels (x, y, and z)? On or off?
2) Bounds (the gray box around the graph area): On or off?
1) Axis labels on
2) Bounds off Thanks for your opinion; I happen to agree, and I have adjusted the included defaults accordingly. I hope other people will weigh in with opinions as well! More progress this evening, with a chunk of code that very concerningly works well on the first try: Code: ; [X] Implement self-adjusting scaling!
; [X] Move code to convert OS min/max X/Y to FP a function called separately, call from Window menu
; [X] Actually make this the self-adjusting scaling routine
Edit: More code that concerningly works correctly on the first try: Code: ; [X] Catch/fix divby0 when trying to set small window bounds
; [X] Make zoom in/out manipulate the OS values instead of FP values, then call function from previous bullet
; [X] Fix zoom in/out to work with non-zero centers, then call the self-adjusting scaling function
This looks awesome and kind of like 3D graphing on the TI-89 Titanium. It would be an app, right? It seems a lot like the app for inequality graphing because it looks like it becomes part of graphing, with a different option for 3D stuff. What would happen if you ran either Inequalz or Graph3DC and then the other without quitting either one?
Suggestion: Support for Table (2nd + Graph)
2d grid of cells
X values across the X axis, Y values across the Y axis, Z values in the cells.
Erasing feels much slower in normal resolution than high resolution, suggest using block erase.
If it's feasible to support editing Xsteps and Ysteps directly instead of only having the choice
between "Normal" and "High" resolution, I think that would be good. It would allow things
like having a very high resolution for one axis while having a low resolution for the other axis.
Useful, for example, if I had a high frequency wave on the X axis and a low frequency wave on
the Y axis. You could perhaps, if you wanted, add an upper limit to how high the Xsteps and Ysteps
values are set based on their product (like if NewXsteps * NewYsteps > SomeValue, revert their
values to what they were previously).
This is a bit of a stretch goal, but:
Toggling orthographic vs perspective graphing.
An example of this is in the 3d modelling program Blender, pressing (I believe) 5 on the numpad will
switch between those two modes. It can be useful in certain situations, though off the top of my
head I can't think of any.
Seems like something that would be cool to add if it wouldn't take too much work. Basically all you do
is disable the perspective calculations, so the X and Y values of points on screen are affected by
things like rotation, but aren't divded by the Z values of the points (or however you calculate perspective).
Unknownloner wrote:
Suggestion: Support for Table (2nd + Graph)
2d grid of cells
X values across the X axis, Y values across the Y axis, Z values in the cells.
This is possible, but it would be a fair amount of programming work. How much do people want a Table mode?
Quote:
Erasing feels much slower in normal resolution than high resolution, suggest using block erase.
I'll time it. Currently, there's a threshold of number of lines to erase above which block erase is used. It's very possible I need to adjust that threshold.
Quote:
If it's feasible to support editing Xsteps and Ysteps directly instead of only having the choice
between "Normal" and "High" resolution, I think that would be good. It would allow things
like having a very high resolution for one axis while having a low resolution for the other axis.
Useful, for example, if I had a high frequency wave on the X axis and a low frequency wave on
the Y axis. You could perhaps, if you wanted, add an upper limit to how high the Xsteps and Ysteps
values are set based on their product (like if NewXsteps * NewYsteps > SomeValue, revert their
values to what they were previously).
This is pretty much already implemented (see Xsteps and Ysteps in the WINDOW menu). The only missing piece is allowing resolutions above the nominal maximum (say, Xsteps = 50) when the other step is low (say, Ysteps = 5).
Quote:
This is a bit of a stretch goal, but:
Toggling orthographic vs perspective graphing.[...]
Since this would indeed save just a single division operation per point, I'm not sure that it would be worthwhile (or clearer?) for me to offer that. I'll file it under "possible future features".
KermMartian wrote:
Since this would indeed save just a single division operation per point, I'm not sure that it would be worthwhile (or clearer?) for me to offer that. I'll file it under "possible future features".
The point of it is not to speed graphing up, so much as it is to get a different view of the graph. Orthographic rendering can be particularly useful, especially when looking at something at a standard isometric angle, because it doesn't distort the size of things based on distance from the camera.
Can I Test This App? I am an amateur programmer, but i want to learn more, and i would like to test this app.
Great job, and it is quite a wonderful app for the creative mathematical mind. This program would be impeccable were it not for a few minor bugs. When you try to 2nd-mode in the graphscreen the screen goes haywire until you reset, and using Mathprint or alpha menus in horizontal graph mode results in the screen reverting to 2d functions. Also, using Mathprint in 2d y= menu then pressing 3D mode results in there being lines of color between the lines. Keep up the good work!