Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

beta 1.3

12346

Comments

  • BortelsBortels Mod
    Posts: 1,557

    I can't seem to be able to use an image() as a texture for a mesh. Is this expected? It does seem to pick up the color from one of the pixels, maybe.

  • SimeonSimeon Admin Mod
    Posts: 5,700

    That's odd, I tried using setContext to render a sprite to an image earlier today and it worked. Maybe your texture coordinates are off?

  • BortelsBortels Mod
    Posts: 1,557

    Hmm - I didn't set any, the mesh example with sprite textures didn't.

    This is just with a triangle, not a rect. Note that the docs for mesh.setRectTxt are... not. Not the docs for that call, that is.

    I've uploaded the code I'm seeing this in - pardon the mess, this is my "mess around with images" project, it's got a lot of cruft (indeed, it's mostly cruft) - I used it to exercise all of the parts of my Pic() class. The last few lines in setup() are all of the mesh stuff - I'm just using this project because it has some pre-made images.

    The right triangle in the lower left of the screen is the mesh.

    http://bortels.posterous.com/imageutil

  • Posts: 2,161

    Not as good as a ray-tracer, but still ... http://www.math.ntnu.no/~stacey/documents/Codea/Torus.codea.

    I imagine that using my Vec3 class makes this slow, certainly slower than if the basic operations were natively implemented in the vec3 class.

    But I'm doing something more than just changing the coordinates since the order in which the triangles appear in the mesh depend on their z level, and that is only known after their positions have been recomputed. That does feel like quite a natural thing to do, though: transform the vertices and then reorder the triangles (not the vertices) according to an ordering (though the ordering couldn't be perfect).

  • Posts: 384

    @Simeon, the fix on the sound buffer is great - it has eliminated any of the jitters in draw() I found I got when playing more than one note at a time.

    I have noticed a few times while playing lots of sounds in quick succession that the triple tap doesn't bring up the buttons until the sounds are done.

    Great looking stuff there with that mesh doughnut, I mean torus, @Andrew_Stacey! :)

  • Posts: 384

    Here's another thought... I've been puzzling over why my piano program doesn't release the notes as quickly as it used to when you play chords. Then I figured it out: when you play a three-note chord, it takes longer to release the touches... But not when you do a two or four note chord... I think the triple tap to exit is hanging things up a bit. This is also evident in the Multi touch example.

  • BortelsBortels Mod
    Posts: 1,557

    Narrowed down the code - should this work?

    -- Use this function to perform your initial setup
    function setup()
        i = image(64, 64)
        setContext(i)
        background(0, 0, 255, 255)
        strokeWidth(5)
        ellipse(32,32,64,64)
        setContext()
        m=mesh()
        m:addRect(300,300,128,128,3.13159/4)
        m.texture=i
        m:setRectTex(1, i)
    end
    
    -- This function gets called once every frame
    function draw()
        -- This sets the background color to black
        background(0, 0, 0)
    
        -- This sets the line thickness
        strokeWidth(5)
        sprite(i, WIDTH/2, HEIGHT/2)
        m:draw()
    
    end
    

    My mesh is just a blue box. I think it should be a copy of my image?

  • Posts: 2,161

    I'm almost at the point where I'm thinking of signing up to twitter so that I can upload stills somewhere public direct from my iPad. The torus (glad to see that Fred uses the correct spelling of the edible variety) looks so much better now!

  • JohnJohn Admin Mod
    edited January 2012 Posts: 643

    @Bortels
    Your confusion is mostly my fault. When I writing the documentation for setRectTex, I was copying and pasting another method (copied from the image documentation) and didn't update it properly. basically you should do the following:

    -- setRectTex(index, s, t, w, h) 
    -- s,t,w,h = rectangle in texture space where s,t is the lower left coordinate
    -- and w,h with the width and height of the texture rectangle
    -- this means that 0,0,1,1 will give you a rectangle that uses the entire texture
    -- since texture coordinates are normalised to 0-1 rather than 0-WIDTH/HEIGHT
    
    m:setRectTex(1, 0, 0, 1, 1)
    

    Hope this clears up the confusion

    Edit: Also note that addRect automatically sets the rectangle's texture coordinates to (0,0,1,1) and the color to white

  • BortelsBortels Mod
    edited January 2012 Posts: 1,557

    Ok - but doing, that, it still doesn't work.

    I have

    m=mesh()
    m:addRect(300, 300, 128, 128, 3.14159/4)
    m.texture = i -- my image() texture
    m:setRectTex(1, 0, 0, 1, 1) -- should not be necessary, is default
    

    And I still get a blue square (but not solid blue? I see a hazy faint white line perpendicular to the side, it may just be an artifact of the LCD screen)

  • BortelsBortels Mod
    Posts: 1,557

    Hmm - if I get rid of the setRectTex call - the hazy line goes away.

  • JohnJohn Admin Mod
    edited January 2012 Posts: 643

    Thats odd. I'll try running the code myself. Have you tried rendering the image with sprite?

    Also, if you print out the value returned by addRect, what does it print?

  • BortelsBortels Mod
    edited January 2012 Posts: 1,557

    Yes - see the code 5or 6 replies above. I make the image, then sprite() it to the screen as a sanity test (blue square, white circle, filled with grey). I then use that as the mesh texture, and the whole Rect is the background blue, with a hazy, faint white line.

    If I change the stroke() to red, the hazy faint white line turns purplish - so it's definitely part of the image.

    addRect returns 1, which is as expected?

  • JohnJohn Admin Mod
    Posts: 643

    Try setting the texture before using addRect. Basically if you haven't set a texture yet it will assume you aren't using one, and not allocate or set texture coordinates. Not sure if thats the best behaviour but thats what it does at the moment.

  • BortelsBortels Mod
    Posts: 1,557

    same result. I get something clearly related to my texture (the colors are the same) - but not my texture. Try it - the code above (in my "Narrowed down the code" post) is complete.

  • JohnJohn Admin Mod
    Posts: 643

    I did. I removed the setRectTex and moved the m.texture=i to before the addRect call and it worked.

  • JohnJohn Admin Mod
    Posts: 643

    That being said, there may be some bugs in the current beta version of mesh, next version should work just fine.

  • BortelsBortels Mod
    edited January 2012 Posts: 1,557

    Ah - got rid eof the setRectTex() and it it works.

    So now I'm confused where that would work with respect to an atlas - if my original image was, say, 2x2 images (ie. each occupied 1/4 of the full), I'd want to do "setRectTex(1, 0, 0, 0.25, 0.25)" to grab the lower left quadrant (right?) - but that doesn't work, I'm back to blue box.

    Is ok for now - wasn't trying for an atlas, yet. :-)

  • JohnJohn Admin Mod
    Posts: 643

    Try using index 0 instead of index 1 for now

  • BortelsBortels Mod
    Posts: 1,557

    ...

    Ok, that's weird. "m:setRectTex(0, 0, 0, 0.25, 0.25)" works, in that I see the image - but it's the same as 0, 0, 0, 1, 1 - ie. it doesn't seem to be selecting a fraction of the texture.

    Or doing anything, really, I guess - rect 0 isn't rect 1, so it's not changing the rect I'm drawing is what I take from this.

  • JohnJohn Admin Mod
    Posts: 643

    Ok, I've look at the code. There's quite a few issues with it, so probably steer clear for now. I think i've fixed most of it now you'll have to wait for the next beta version. Sorry about that.

  • BortelsBortels Mod
    Posts: 1,557

    hee hee - good! Part of the job of beta testing is to poke code and find what's broken. Now I get a cookie. I'll look at it again next update. :-)

  • SimeonSimeon Admin Mod
    Posts: 5,700

    Don't install beta 14. It's completely broken for sprites. Not sure what happened.

  • Posts: 2,161

    Whoops. Too late. Good thing I don't use sprites!

    Actually, not too late. The install failed with "unable to download".

  • SimeonSimeon Admin Mod
    Posts: 5,700

    Okay B15 is out which should fix the major problem. There's still issues with mesh, though. @John will have a look at them.

  • SimeonSimeon Admin Mod
    Posts: 5,700

    B16 has an experimental new feature added by @Dylan. Codea now autocompletes variables under "self" in your classes. So stuff self.position will now autocomplete after you've typed it the first time. Tab names also autocomplete (and have for a while now).

  • Posts: 1,255

    I like the self.autocomplete feature, but I do see some problems with the current implementation. I'm getting an incomplete list of values on some classes, and on one class a couple of function names appeared in the list.

    On a related note: is it possible to change the error messages to include the tab name? I'm having real trouble pinning down the source based on what I see now, as sometimes it seems to give me what's at the top of the file, other times not so much. Thanks.

  • SimeonSimeon Admin Mod
    Posts: 5,700

    Thanks, @Mark. @Dylan fixed it so that autocomplete only happens with appropriate symbols (anything after "self."). We're unsure if this feature can make it into 1.3 - we don't know if it has the potential to cause crashes, so be sure to let us know if you run in to anything bad.

    I'll look at adding the buffer name to the error message - it might be simple enough to make it in to 1.3.

    I want it to highlight the tabs that have errors. I just haven't gotten to it yet. I know how you feel though, drives me crazy as well. It will probably be in a 1.3.x update.

  • Posts: 447

    is the y coordinate of meshes flipped in 1.3(16)?

    I mean the elems of the meshes are drawing in the right place, but they seem to be drawing upside down

  • Posts: 447

    Example that draws the sprite upside down

    function setup()
        mesh = mesh()
        mesh.texture = "Planet Cute:Character Boy"
        mesh:addRect(300,300,100,200)
    end
    
    function draw()
        mesh:draw()
    end
    
  • SimeonSimeon Admin Mod
    Posts: 5,700

    @ruilov yes, that seems incorrect to me. I will have to talk to @John about it. I think he's been trying to get image textures and sprite textures to work consistently with meshes, which has led to this flipping around.

    But in the final version of 1.3 that code should render the correct way up.

  • Posts: 447

    ok, thanks. In the mean time mesh:addRect(x,y,w,-h) works around it.

  • Posts: 384

    I tried mixing physics and sound... :) In the physics demo changing the sound() call in PhysicsDebugDraw class to:

    sound({Waveform = 3, StartFrequency = 0.5, Volume = contact.normalImpulse/200})
    

    will adjust the volume of the crash according to the strength of the collision... :)

  • BortelsBortels Mod
    edited January 2012 Posts: 1,557

    W00t - setRectTex() is working (ie. my "atlas" example is successfully applying a chunk of the mesh texture to a particular rect)

    not as expected - it's origin appears to be upper-left - but working.

    And now I'm back to "it would be nice if all of our coordinate systems pointed the same way". I think I may actually be ok with this as it is, because not only is the coordinate axis different, the range is 0-1 rather than pixels, so maybe it's just different enough I shouldn't worry about it.

  • SimeonSimeon Admin Mod
    Posts: 5,700

    @Bortels ah you are correct! That's annoying. Will have to fix that so it's the right way around.

  • BortelsBortels Mod
    Posts: 1,557

    The "upside down surprise" is always fun :-)

    I'm just excited about mesh() - the more I mess with it, the more powerful it is clear it is. Very subtle. And I like exposing GL this way - with most of the details hidden by default, but accessible.

  • Posts: 2,161

    I just tried putting startRecording in a program and it crashed Codea (I don't know if you'll get reports on that, I was offline at the time - offline and in an airplane.).

    I was trying to devise a "playlist" feature. Apart from the recording bit, it worked really well.

  • Posts: 2,161

    Which reminds me ... Mark, those graphs that you drew for Gravity and so forth are great! I've stuck them in one of my programs for teaching to draw a graph of something as you see it happening on the screen (tweaked it a bit, of course).

  • Posts: 2,161

    Just tried it again after upgrading to the latest beta (1.9). Crashed again.

  • Posts: 2,161

    It works if I call it in "bare code" but not if I call it from setup. On the other hand, stopRecording worked fine in ’draw.

  • SimeonSimeon Admin Mod
    Posts: 5,700

    Hmm thanks for the report @Andrew. Does startRecording() crash if you call it at some point during draw?

    Might have to remove the recording API if we can't get it working in setup()

  • Posts: 2,161

    I think it's a state thing. After getting it to work in another program, I went back to the original one and it worked. But the first frame was from the second program. So maybe something isn't properly getting reset with the recording stuff.

    So I can successfully call it from a program if I do something to "clear" things first. I'll try to narrow it down and post code later.

  • SimeonSimeon Admin Mod
    Posts: 5,700

    I'm looking at the recording bug and updating to Mark's latest Spritely. It will go out shortly. This will be the final beta unless there are any major bugs.

    Also we have a new beta tester, @asronline. Welcome :)

  • edited January 2012 Posts: 447

    Congrats on pushing out!

    And I really like the link to the forums inside codea. This is psychological but I really like going to the forum without ever leaving codea. In fact I'm using the news link and then pressing on "all discussions" rather than pressing the "forums" button on the lower left corner because that goes to safari, and I hate safari

    Now let me report a bug :) Afterall this is the beta forum

    Using the one you just pushed (1.3(21) I think). The first time you run this after closing and opening codea, it looks ok. But the second time, it looks strecthed out. And each time after. Unless you press the reload buttom in the side bar.. weird huh?

    function setup()
        displayMode(FULLSCREEN)
        text("test",0,0)
    end
    
    function draw()
        background(0,0,0)
        text("test",400,400)
    end
    
  • SimeonSimeon Admin Mod
    edited January 2012 Posts: 5,700

    Would you prefer if the little forum button on the lower left opened within Codea? I could change that behaviour and resubmit the update.

  • SimeonSimeon Admin Mod
    edited January 2012 Posts: 5,700

    That is a weird bug. Slightly disturbing too.

    It's related to drawing text in setup(). I think the texture cache is being re-used the next time but is incorrect. I don't think the fix will make it to 1.3.

  • Posts: 447

    Yes, I would prefer if it opened within codea, but honestly I don't think it's worth resubmitting the update. Maybe on the next one

    And yeah I'm sure we'll keep finding bugs, but let 1.3 go out. We're five people finding bugs in beta but I'm sure once lots of people are using they'll find much more. I'd go into bug fixing mode and make 1.3.1 (and possibly more) be bugfix updates.

  • SimeonSimeon Admin Mod
    Posts: 5,700

    It's submitted with the change. I had considered it initially but for some reason thought the minimal in-app browser might create a worse experience. That was wrong.

    Yeah there will be plenty of 1.3.x updates with fixes and features.

  • Posts: 2,161

    I've added meshes to my shape explorer:

    http://www.math.ntnu.no/~stacey/documents/Codea/Cube.codea

    Go to Shape->Load Shape and pick one of the last three shapes.

  • BortelsBortels Mod
    Posts: 1,557

    The user experience in portrait mode is wonky due to window placement. And I don't know how to abort when I accidentally choose "save" when I meant to hit "load". Still love it, I'm just still looking at everything in beta mode :-)

Sign In or Register to comment.