Trig example

Examples
1

In order to test out my new BT keyboard (and given that Codea was designed to look like the Processing language) I decided to convert one of the Processing trigonemtry examples to Lua.
The orginal example can be found at http://processing.org/learning/trig/ and is a useful guide to anyone learning about sine, cosine etc, the lua code is given below.
:slight_smile:

--[[ Sine Console
* Processing: Creative Coding and
* Computational Art
* By Ira Greenberg */
* Ported to Lua by Jon Howard (techdojo@gmail.com)
* Original post http://processing.org/learning/trig/
--]]

local px, py, px2, py2
local angle = 0 
local angle2 = 0
local radius = 100
local frequency = 2
local frequency2 = 2
local x=0
local x2=0

function setup()
    displayMode(FULLSCREEN)
end

function draw()
    translate(-50,(HEIGHT/2)-radius/2)  -- move the drawing to the center of the screen
    background (127)
    noStroke()
    
    fill(255)
    ellipse(WIDTH/8, 75, radius, radius)
     
    --rotates rectangle around circle
    px = WIDTH/8 + math.cos(math.rad(angle))*(radius/2);
    py = 75 + math.sin(math.rad(angle))*(radius/2);
    rectMode(CENTER)
    fill(255, 0, 0, 255)
    rect (px, py, 10, 10)        -- draw the rect on the edge of the circle
    stroke(222, 0, 255, 255)
    strokeWidth(5)
    line(WIDTH/8, 75, px, py)
 
    angle2 = 0
    fill(0)
    -- draw static curve - y = sin(x)
    for i=1,WIDTH do
        px2 = WIDTH/8 + math.cos(math.rad(angle2))*(radius/2);
        py2 = 75 + math.sin(math.rad(angle2))*(radius/2);
        point(WIDTH/8+radius/2+i, py2)
        angle2 = angle2 - frequency2
    end

    -- send small ellipse along sine curve
    -- to illustrate relationship of circle to wave
    noStroke()
    fill(8, 0, 255, 255)
    ellipse(WIDTH/8+radius/2+x, py, 15, 15)
    angle = angle - frequency
    x = x + 1

    -- when little ellipse reaches end of window
    -- reinitialize some variables
    if (x>= WIDTH-60) then
        x = 0
        angle = 0
    end

    -- draw dynamic line connecting circular
    -- path with wave
    strokeWidth(3)
    stroke(0, 255, 66, 255)
    line(px, py, WIDTH/8+radius/2+x, py)

    -- output some calculations
    fill(0)
    textAlign(LEFT)
    text("y = sin x",   180, 225)
    text("px = " .. px, 180, 205)
    text("py = " .. py, 180, 185)
end
2

Very nice trigonometry example. Thanks for sharing it!

3

A good understanding of trig is essential for many sorts of real-world coding problems - excellent. I wish I had these sorts of things when I was in high school…

4

Simpoll but coooool :-bd

5

Yes, thanks–answers my rhetorical question elsewhere of what ‘point’ does. (Neither Lua nor Codea references contain it, so Processing is where I’d have had to look for a definition. And yet ‘line’, ‘ellipse’, ‘rect’ appear in the online reference.)

6

Yeah that confused me for a while as well, I just copied the code and it ran, it was only when I was dissecting it after that I discovered point was undocumented, although you’ll notice a MASSIVE speed up if you just comment the point call out.

7

I completely forgot that I implemented point and pointSize. I am now reminded to add the documentation.

(point was always on the verge of being removed — given that you can just use an ellipse, but maybe it’s convenient to have)

8

Just a thought, but I remember correctly isn’t the ellipse drawn using a shader?
Would it be faster to implement point either as a simple rectangle or use a fixed texture of a circle - would that make it faster?

9

@Simeon, thanks. (and I’ll utilize the bug list in future!)

I suppose, as my graphics textbook points out, you could always draw a point as a line between the same points. But that might have a performance hit too, or other unintended consequences, or limit capabilities that a point has over a line. Depends on the context–don’t know what it would do here, I haven’t tried it. Still just at the learning stage and playing with other things!

10

A line between two identical points may, at some point (HA!) be opimized-away.

I just use a tiny rect. Simple, quick, and you know it won’t get nuked.

11

@Bortels,@Simeon–I’m a little worried with the discussion of what might get dropped/unimplemented/optimized out of Codea. If I write code that relies on these features (whether optimized, intended or otherwise) and you nuke the supporting structures or methods, you nuke my code too–not just clean up Codea. Fixing bugs and optimizing code is one thing.

12

@kfin63 we definitely keep this in mind when making changes to the API. Generally if something is deprecated it is left in but removed from the documentation and autocomplete to discourage its use.

13

It is less an issue of TLL dropping something, and more an issue of “Future versions of OpenGL may behave differently”. Point being - if you want a dot, draw a dot; avoid depending on quirks of the current OpenGL implementation.

14

Ah gotcha, thanks, I will keep this in mind. Just never sure what’s Codea, OpenGL, Lua, Processing, C (math.h?)

(@Bortels, I see what you did there with ‘point being’ :wink:

15

Point… HA! I didn’t even notice that when I typed it. I SLAY ME.

16

Surely there is irony in whether line, rect, or ellipse is the best way to draw a point.

The one that takes the least time to execute or calculate is the best. To heck with standards and ‘simplifying’ things, I don’t really care who does it. Deprecating ‘point’ because an ellipse can draw one is not maybe the best reason to do so.

But removing or deprecating the ability to draw a ‘line’ to two identical points, and yet still let ‘rect’ (and ‘ellipse’?) do that very thing–well, that’s just crazy, unless there’s some good reason for it. How would I find out that suspected reason? Why should I reasonably expect that ‘rect’ will not get treated in that manner, but ‘line’ might?

It’s just far from obvious to a beginner why one should be encouraged to use one method that way, and yet another even seemingly closer in concept would be discouraged.

17

Then draw a line. If I’m wrong, you’re good to go.

I will continue to draw something most definitely non-zero in size, because I’m old. :slight_smile:

18

I do appreciate the help, I also want to future-proof anything I may come up with, but ensure if possible that I am using the ‘best’ or most efficient method to draw a point when I choose to do so. (I’m still futzing with my mistakes with scope.)

That the ‘point’ really wasn’t required because ‘ellipse’ can do it then raised the question (someone else’s) whether ellipse was suitable due to shading was raised by someone else, and then ‘rect’ came into the picture.

At the end of it–is ‘rect’ the approved, not-likely-to-be-deprecated, way to draw a point outside of a specific image context? (or just stick to images where Get and Set are available? I’m old too, I have much less time to spend on this than I’d like!)

19

There’s no real “approved”, really, other than avoids ellipses in codea because they can be quite slow. :slight_smile:

20

@kfin63 we will keep point. I like having the function. I think we might change the shader for it to something more efficient in the future, though (at the moment I believe it uses the ellipse shader).