Can you make it zoom without resetting rotation also?

Sadly, I might not be able to do the re-coloring without re-rotation either, although that is at least feasible. For zooming without modifying rotation, I would have to calculate the current amount of rotation and re-apply that rotation, which has been the problem all along.

gbl08ma: I unfortunately don't think I can use GetKey, as I need more fine-grained control over the modifier keys. I see that PowerOff() is indeed defined in the PrizmSDK's headers, and I have implemented that in the text input routine and all the major screens. If only we could find the syscall for capturing. Although, because I'm using the GetKeyWait_OS() call, we can take Screen Receiver screenshots over USB inside Graph3DP, as demonstrated by the screenshots at the beginning of this thread.

Ahh, I see, but I don't think I understand. Every time the user rotates, the graph is redrawn, right?

Now, to redraw the graph, we have to know the rotation angle. Which means that we can save this angle and redraw the graph from the same angle... correct?

I think I may be wrong, so please help me understand


Also, If I draw two graphs and then press [f5] (next) and rotate the graph, and the press [f5] again and rotate that graph, and then press [f5] (all), the rotation is wrong for both graphs. If I rotate both graphs at the same time both will be displayed incorrectly. Maybe you should make it so that you can either not rotate the graphs seperately, or make it so when it goes back to display all, the graphs are displayed at the default angle of rotation.

It's not that simple. When you rotate in one plane, the rotation is easy to calculate. When you then begin to rotate in another plane, though, it gets more complicated, because you're modifying the rotation angle in all three planes, even though you're only rotating in one plane. I haven't found a good enough reference for the math to work backwards and calculate the overall rotation, or else I just can't wrap my head around it, as I spent months trying and failing to track the overall rotation rather than explicitly performing the rotation on each rotation tick.

Good catch. Fixed.

But that's only for the text input routines, right?

I think we should do more investigation on the text input syscalls used by the OS and use them instead. That'd allow for setting the right flags on the status bar, and the cursor would be consistent with the rest of the OS.
If we find out there's really no more simplified text-editing syscall than the current mess, then the solution may be to write a routine around the syscalls that's as simple as yours - after all, a SDK is meant to ease development...

Ahh, gotcha




Just curious, how did you fix it? I hope you did not have to get rid of the feature to view graphs separately...

Indeed. I agree that the current text input solution is not perfect, but I don't hate it, to be honest. Also, I notice that PowerOff(0) doesn't debounce and tends to turn the calculator right back on again, so I am using PowerOff(1) for now.

Flyingfisch: I removed the case in the rotation routine that skipped over non-visible equations, which was a glitch.

At any rate, I just need to make the Z axis start out pointing the right way up, and I'll be able to release RC 2.

Awesome!

I am very much looking forward to this as I am actually going to take a class that uses 3D graphs this year

True... forgot to mention that part (it didn't come to my mind at the time). I don't think there's a solution to it, other than having the user wait after the key is pressed and before PowerOff(0) is called (which, in the end, is what Casio does by displaying the logo).



I guess this also means that now rotating a single graph will be as slow as rotating them all, something that didn't happen before... oh well, nothing is perfect, right?

Correct. Sadly, nothing is indeed perfect. Ah well. I'm still getting this silly initial rotation issue fixed up, then packaging RC2. Do you guys think it's worth creating another news article for RC2, or just editing the current article? I'm tending towards the latter, since I'll likely have news about 1.0 soon anyway.

The latter is better IMO. I don't recall your other Prizm projects taking more than two articles (this one will take at least three, accounting for the 1.0 release), and since RC 1 was released not too long ago...

Can I graph a 3D heart with this? 8D

Theoretically, yes, but it would be easier if it had parametric equation support (which it doesn't). That might be a 2.0 feature, if I get around to it. Thanks, gbl08ma, I agree with you on that.

I can't find the abs() or pi functions in the "commands" window, so no, not yet. However, I got a heart in 2D graphing.

Graph1: sqrt(1-(abs(x)-1)^2)
Graph2: acos(1-abs(x))-pi


@Kerm: Could you add abs() and pi to Graph3DP?

EDIT: nvr, you have pi, sorry. All we need is abs()

Nope, abs() is there too. Just not in the version that you have. Does my pi constant actually work?

No, just realized that it doesn't.


EDIT:

Seeing how slow this is already, I don't suppose this would be feasible, but it would be cool to have a mesh feature in 2.0 like this: http://www.cemetech.net/forum/viewtopic.php?t=8078&start=0

For me it still feels much faster than native 2D graphs, and I almost forgot to congratulate Kerm for that

Do you have plans for developing an alternative 2D graphing software for the Prizm?

Oh, it is faster than the 2d graphs, it just is not as fast as the 3rd party 3d graphing addin for 9860, or hugh's example addin that I linked to.

I don't think hugh's add-in is drawing based on the solution of math equations, while this one is. hugh's example draws from static 3D models.

Ouch, flyingfisch, that's quite harsh. Part of the slowdown is the lack of an FPU, part of the slowdown is the custom CAS (which, to be fair, is pretty streamlined), and part of it is the non-negligible overhead of the Bdisp_PutDisp_DD() call. I find Graph3DP to be quite fast, even when whizzing more than one graphed equation around the screen.

Anyway, added the "pi" constant, fixed the initial axes, and that heart looks particularly good under Graph3DP's default zoom settings with these equations:

Z1= 3*sqrt(1-(abs(.33*X)-1)^2)
Z2= 3*acos(1-abs(.33*X))-3*pi

I'm now packing up RC2; I'll bump this thread with the announcement.