GRAPH 3D v2.425 (20-FEB-2017)

[Han]

I have a version that includes touchscreen gestures, but done differently from how you did it. It's based on a generic key and touchscreen handler I wrote a long time ago (the skeleton is found in an article I wrote on programming the HP Prime). A few folks already emailed me about touchscreen gestures and I kept putting it off since it wasn't high on my priority list. However, if people are interested in using the touchscreen, I will put up another update once I test it more rigorously. You can then see how I implement it so that it also detects taps on the screen and keeps it separate from motion gestures.

[Tim Wessman]

Han, is there a reason you don't package the 3d app as a zip file with the source already in the .hpappprgm file? Then people just need to drag/drop the zip to install everything without any cut/paste action.

[Han]

(12-15-2014 09:58 PM)Tim Wessman Wrote:  Han, is there a reason you don't package the 3d app as a zip file with the source already in the .hpappprgm file? Then people just need to drag/drop the zip to install everything without any cut/paste action.

Mainly because having it as a .txt file means people can look at the source with just a text editor as opposed to having to open with the conn. kit. I am usually in a Mac environment so the ability to use .hpappprgm file is not readily available. I can start adding the .hpappprgm file as an addition if that will help (it's pretty small).

[Trickfisch]

(12-15-2014 08:05 PM)Han Wrote:  I have a version that includes touchscreen gestures, but done differently from how you did it. It's based on a generic key and touchscreen handler I wrote a long time ago (the skeleton is found in an article I wrote on programming the HP Prime). A few folks already emailed me about touchscreen gestures and I kept putting it off since it wasn't high on my priority list. However, if people are interested in using the touchscreen, I will put up another update once I test it more rigorously. You can then see how I implement it so that it also detects taps on the screen and keeps it separate from motion gestures.

Ok good.
I think it's better with touch support. Because I hate the frickling on the keys and the viewcontrolling in trace mode (I don't want to type the view angles in).
Maybe I can try to make a version with full touch and you can develop your app on this code and you don't need to spend time for this. It would be a nice addition.

[Han]

Here's a new beta for those who have to have touchscreen input. You will need at least firmware 6940.


  graph3dtouch.txt (Size: 110.93 KB / Downloads: 79)

[Han]

Here's a short clip on the touchscreen pinch-zoom and swipe gestures (works in both trace mode and regular plot view).

I will likely get rid of the colorful icons in place of text-generated buttons (for smaller size) when tapping on the screen.





Source code in previous post above.

[Trickfisch]

The problem in your code Han is the very slow reaction, when you touch the screen. Even the scroll renders in real time. This is not possible with the prime. You must take a screenshot, zoom the screenshot and at the end you can render it new.

So I've make more with my code. The single touch command is supported and the trace mode is even better with touch.
I know that it is slow with complex functions or the trace mode. But with little functions you can have your fun and in trace mode it is a good option, to change the view without go out of it.

I hope Han, that you can accept this code. I don't use the wait(-1) cmd. No if a finger is on screen I crap the coordinates directly with "MOUSE".
When nothing is moved, then a old variable (who is defined with the coordinates, before I analyse the touch data) must have the same value. I think it is acceptable for the HP Prime Touch Screen with his very rough touch grid.


Even I've changed the g3D_drawtrace and g3D_draw function. So every time, when I'm in trace mode, I wrote the picture from g3D_draw not to G0. I write it to G2 and then render the g3D_drawtrace raster over it.

So here's the updated code:

  HPPrime_touch_v2.412.txt (Size: 54.66 KB / Downloads: 43)

I have marked all changed lines with "// CHANGE BEGIN", "// CHANGE END" and for single line "// CHANGE"

I have used really these words. So you can do a simple search or replace it with "".

TO HAN:
Isn't it possible to have a faster rendering? Only because you add some lines with line_p in trace mode, the function runs semi slow. I think that can't be normal.

But you are the brain here and you have created the script, so I think you know more about the speed and how fast it runs then I.

I would be so happy, when this code will be used in your code.

[Han]

(12-16-2014 08:54 PM)Trickfisch Wrote:  The problem in your code Han is the very slow reaction, when you touch the screen. Even the scroll renders in real time. This is not possible with the prime. You must take a screenshot, zoom the screenshot and at the end you can render it new.

I'm not sure what you mean here. As for zooming, the zooming action uses real-time rendering because I didn't want the pixelation and the image appearing cropped (when zoom out).

Quote:So I've make more with my code. The single touch command is supported and the trace mode is even better with touch.
I know that it is slow with complex functions or the trace mode. But with little functions you can have your fun and in trace mode it is a good option, to change the view without go out of it.

I'll check it out. The code I posted, however, does have real-time trace mode rendering with rotations and zooming.

Quote:I hope Han, that you can accept this code. I don't use the wait(-1) cmd. No if a finger is on screen I crap the coordinates directly with "MOUSE".
When nothing is moved, then a old variable (who is defined with the coordinates, before I analyse the touch data) must have the same value. I think it is acceptable for the HP Prime Touch Screen with his very rough touch grid.

I'll test it out. The problem with MOUSE() is that it once you start waiting for MOUSE() events, there is now way to handle any other events.

Quote:Even I've changed the g3D_drawtrace and g3D_draw function. So every time, when I'm in trace mode, I wrote the picture from g3D_draw not to G0. I write it to G2 and then render the g3D_drawtrace raster over it.

Yes, this is old code that isn't optimized (in fact, I don't think G2 is needed anymore). I used G2 in older versions to to avoid having to call draw commands, but I think it's no longer needed. An IF THEN ELSE END is not necessary; you can simply just not draw if tmode is on.

Quote:TO HAN:
Isn't it possible to have a faster rendering? Only because you add some lines with line_p in trace mode, the function runs semi slow. I think that can't be normal.

I am pretty sure this is due to the comments above about G2.

Quote:But you are the brain here and you have created the script, so I think you know more about the speed and how fast it runs then I.

I would be so happy, when this code will be used in your code.

If it's faster and does what I need it to do, I'll include it in my code branch. If not, I won't -- but anyone is of course free to modify the source for their own use.

[akmon]

I've tested trickfish and han versions. Trickfish 's strongest point is zooming, smooth and fast, but the code has minor bugs, han versión is more stable and complete , but I don't like zooming, slower and less responsive.
The mixture of both codes should be the right way.

[Han]

(12-17-2014 11:10 PM)akmon Wrote:  I've tested trickfish and han versions. Trickfish 's strongest point is zooming, smooth and fast, but the code has minor bugs, han versión is more stable and complete , but I don't like zooming, slower and less responsive.
The mixture of both codes should be the right way.

Yeah, with the current firmware, WAIT(-1) is buggy -- it seems to fail to detect pinch-zoom sometimes. I will likely not implement trickfish's zoom because it is too limited. For example, zoom in -- to the point where the bounding box is no longer visible. Now, zoom out and you lose a LOT of information during the zoom since it does not actually redraw until you lift your fingers.

I implemented my own mouse handler that will also allow 2-finger gestures for panning the window. However, I ran into a firmware bug that I need to work around. A few places were also optimized (in particular rotations during trace mode). I'll post new code shortly.

[marcusnicolas1]

SO which is the newest version of the 3D graphing? Is it the 2.42 or 2.412 as seen on this last page? Please advise. Thank you

[Han]

(12-19-2014 03:27 AM)marcusnicolas1 Wrote:  SO which is the newest version of the 3D graphing? Is it the 2.42 or 2.412 as seen on this last page? Please advise. Thank you

2.42 is the newest

My version scheme is: the newest version is the one with the larger version number; in this case 2.42 = 2.420 > 2.412

[marcusnicolas1]

ok thanks. I have to say ... Thank you to all of you. Everyone has been very helpful with answering my questions about the Prime. I want to master it because I am an engineering student and want to know how to use most of its functions.

[marcusnicolas1]

One last question. How do I get version 2.42?

[ww63]

you should find it in the first post or post #107.

[slawek39]

Each time you press the Plot and rotate 3D chart calculator has less free RAM. Maybe problem is in advanced form of Triangle and Line.

[Han]

(12-19-2014 05:38 PM)slawek39 Wrote:  Each time you press the Plot and rotate 3D chart calculator has less free RAM. Maybe problem is in advanced form of Triangle and Line.

Quite possibly. The question is whether the behavior is similar to that of the HP48 and later series in which the amount of RAM available is dependent on whether garbage collection has happened.

In this case, I'm leaning more toward a memory leak in the TRIANGLE and LINE commands.

[Han]

Here's a slight update to the current beta (v2.421)

I've tried to also implement panning with two-finger gestures, but there seems to be a bug with MOUSE() not properly updating coordinates sometimes. It usually happens when you do a pinch zoom gesture followed by holding your fingers a fixed distance and moving them in tandem.

Anyway, you can choose to disable panning with the setup screen.


  graph3dv2421.txt (Size: 83.06 KB / Downloads: 79)

Errata (20-DEC-2014): In the g3D_recolor function, insert the following two lines before the "else" statement toward the bottom of the code block.

Code:

    ptdef:=ptdefs(fsel); // <-- add this line
    Zvals:=zvals(fsel); // <-- and this line

  else
    zColor:=makemat(g3D_zcolor(I,J),grid3D+1,grid3D+1);
    ptdef:=makelist(g3D_makeptdef((X-1) mod (grid3D+1),IP((X+grid3D)/(grid3D+1))),X,1,(grid3D+1)^2);
    ptdef:=concat(ptdef,corners);
  end;

There are two known issues. While "spinning" the graph (via a quick single-finger swipe), tapping on the screen may make the rotation "jump." Normally, using the mouse code would fix this issue, but sometimes the MOUSE() command returns the wrong code (e.g. #0h or #7h during a single-finger dragging instead of #2h). The other issue is that sometimes panning/zooming may misbehave because again the MOUSE() command is misbehaving (sometimes it doesn't update both mouse coords when both fingers are held down). So both MOUSE() and WAIT(-1) have their issues (and I suspect they are related).

The way the mouse motion was implemented was to mimic grabbing onto the graph and actually rotating it. I like to tap on a "corner" of the bounding box and move it. The mouse auto adjusts for inversion unlike with the keyboard rotation.

[Gilles]

(12-19-2014 05:53 PM)Han Wrote:  Here's a slight update to the current beta (v2.421)

Really impressive !
Bravo

[Han]

If you downloaded v2.421 prior to 21-DEC-2014, there is a minor bug that appears when switching colors while trace mode is active. In the g3D_recolor function, insert the following two lines before the "else" statement toward the bottom of the code block.

Code:

    ptdef:=ptdefs(fsel); // <-- add this line
    Zvals:=zvals(fsel); // <-- and this line

  else
    zColor:=makemat(g3D_zcolor(I,J),grid3D+1,grid3D+1);
    ptdef:=makelist(g3D_makeptdef((X-1) mod (grid3D+1),IP((X+grid3D)/(grid3D+1))),X,1,(grid3D+1)^2);
    ptdef:=concat(ptdef,corners);
  end;

Basically the bug was that the recolor function altered the current zvals and point definitions of the selected function.