#### Howdy, Stranger!

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

# beta 1.3

• Posts: 2,161

Elsewhere, Simeon asked what features I would like with regard to using Codea in teaching. There are two that would be fantastically useful for me:

1. More flexible drawing capabilities. I haven't explored the physics stuff yet, though the sort of thing that I want to do will be a bit more general so using that would be like using a fish slice to make sandwiches - perfectly possible, but not quite what it was designed for. I'm teaching differential equations, so simulating what happens would be great, but not all differential equations come from considering moving bodies! Given my status as a beta tester, what I'd love is to have access to the glsl stuff, then I could happily write my own shaders, use them, and report back on what turned out to be useful. Then you could decide whether or not they looked useful enough to be turned into Proper Code.

2. The "Holy Grail": itex2MML. I haven't tested whether it works with lua yet (though via swig it works with ruby, perl, python, and php so I doubt it'll fail with lua) but this would be absolutely fantastic. It converts a subset of LaTeX's mathematical syntax to MathML. Of course, I'd have to write a MathML renderer to convert the resulting MathML to something Codea could put on the screen, but that's the easy part and is perfectly possible in Lua. Recoding itex2MML as pure lua would be ... tricky (I could do it, but I'd really rather not). I want to be able to type e^{i \pi} = -1 and have it display nicely on the screen.

Posts: 5,700

Sorry @Andrew. Next update will have the fix.

text("abcdefg") is a lot more efficient. Since it combines the render-to-texture for all characters into one step. It also means far less draw calls.

Posts: 5,700

More flexible drawing (way more flexible) should be in build 10. I.e. the next one. (Not GLSL though).

• Posts: 2,161

No worries about the "hello world" fix: I wasn't sure if it was in or not and if it was then thought you'd like to know that it wasn't working for me.

So when doing complicated things with text, it seems as though I should work with tables up to the point where stuff is rendered onto the screen. At that point, I should combine it back into strings (all in one chunk, not by incrementally augmenting a string!) where each string is the maximum that I can render with a single text command. So if I want to write "something in italics" then I end up writing text("something in ",x,y) text("italics",x,y) (where between the two commands I've changed font and adjusted x and y appropriately). That doesn't seem too annoying.

Great to hear about the drawing, I look forward to playing with it. The GLSL is, and always will be, for me a stepping stone. I don't really want to be programming my own shaders, but it seemed like it might be easier for you to put that in as a temporary way of shutting me up!

• Posts: 447

keyboard:

• backspace always deletes from the end of the keyboardBuffer? If so I think it's ok to pass the backspace event in keyboard(key). I'd define a global variable like BACKSPACE

• seems like at the time keyboard(key) is pressed the key still hasn't been added to keyboard buffer. Is that right? Easy enough to concatenate but would make more sense to me if it was already part of the buffer

• is there a notification that the user pressed the little keyboard button that hides the keyboard? If not, how would you detect that the user finished writing stuff? Maybe you could pass that as keyboard(key) event. Alternatively have a isKeyboardOn() function

• I think I wouldn't have keyboardBuffer() in the API. It's easy enough to accumulate the keys pressed. And if the user implements the ability for the player to touch the middle of the string on the screen and start typing from that position, then the string displaying on the screen is now different from keyboardBuffer

edited January 2012 Posts: 5,700

@ruilov interesting points

• The way it works is that there is a hidden text view on the screen that gets focused when you call "showKeyboard()". Because you can't touch the text view, you can't set the caret position, so you can't backspace from anywhere other than the end.

• If you use a bluetooth keyboard, you can actually control the caret and selection amount with the arrow keys and shift key. I can disable this, do you think I should?

• I was thinking to do the notifications as global functions, but I like your solution of passing them into the keyboard( key ) function as consts like WILL_SHOW_KEYBOARD / DID_SHOW_KEYBOARD. It's more elegant.

• keyboardBuffer() is a bit confusing, I agree. But it is really nice when you're feeling too lazy to do it properly. But that's one vote for its removal - does anyone else think keyboardBuffer() should be removed?

• Mod
Posts: 1,557

It would be nice to preserve the functionality of the keyboard arrows on a bluetooth keyboard. Could you simply make a cursor move be an event reported back?

I think the keyboard() event call is simple and elegant - haven't used keyboardBuffer, can't see need for it. Having non-keypress (but keyboard related) events passed to keyboard() seems reasonable.

I still wish there was a lower level access - I could see losing the left-arrow, for example, if the text cursor was already to the left.

Posts: 5,700

Here's what iOS gives me with regards to text callbacks. Keep in mind that I'm trying to translate this into a keyboard API that wouldn't seem out of place on an iOS device or a desktop device. So here's the three methods I have to use to develop the keyboard API:

• shouldChangeTextInRange:(Range) replacementText:(String) - Called when a character is about to be entered. You can return false from this function to prevent the character being entered.

• didChangeText - Called when the text has been changed in any way

• didChangeSelection - Called when the selection area or caret have moved (not called if they are already at an edge and can't move further)

At the moment I use shouldChangeTextInRange to trigger the keyboard(key) callback. However this causes the problem @ruilov has discovered: keyboardBuffer() is not actually updated until didChangeText is called.

• Mod
Posts: 1,557

Well poot. Petition apple. Yeah, that'll work. :-)

Posts: 5,700

It's not too big a problem - I could update an internal buffer in shouldChangeTextInRange rather than relying on the text buffer kept by the iOS text view control. I just posted those callbacks in case you or anyone else had any ideas about the best way to turn the iOS API into a more conventional one.

• Mod
Posts: 1,557

Ack.

A project named "iCade" (note lowercase i) sorts to the end of the project list. And I weep, because I have about 80 projects. I know it's not slated for 1.3, but project management is begging for attention...

• Mod
Posts: 1,557

Hi!

Unexpected side-effect of writing iCade "driver" for Codea - when 3 year old stops by to see what you're doing, and frobs with the joystick - your keyboard disappears, and you take an enforced coding break. Yes, I could turn off bluetooth - but then I'd have to turn it on again. Sigh. (There is no way to shut off the iCade other than to wait...)

edited January 2012 Posts: 5,700

Haha, I'm not sure there's anything we can do about that one. So iCade must take over the editor keyboard too? That could be annoying.

80 projects? That is a long list.

• Mod
Posts: 1,557

Yes. Never Delete Anything. :-) (and to be fair - half of them are protoypes of various sorts, things I wanted to look at...)

Indeed - the iCade shows up as a regular old bluetooth keyboard (and takes over in the editor as well). Which for our purposes is good, because keyboard(key) and a big table of actions is all we need to use it. I'm just trying to wrap it up in something pretty, so someone can do i=iCade() and then it's transparent.

At least when the iCade goes to sleep, the soft keyboard pops back up.

Posts: 5,700

I'll be pushing out build 10 shortly (pretty big update). Just have a few things to implement. It's nearly ready for submission.

• Mod
edited January 2012 Posts: 1,557

Given the track record, I'm expecting build 10 to include lead-to-gold transmutation and teleportation. Just sayin.

but not sockets. :-)

• edited January 2012 Posts: 1,255

This is how I'm handling backspace at the moment:

function keyboard(key)
if key ~= nil then
if string.byte(key) == nil then
--backspace
else
--something other than backspace
end
end
end


Noticed that I leave the app with the keyboard "up," the next time I run the keyboard is there whether I call for it or not, and the list of full screen buttons are kind of hit or miss (if I rotate the screen, I can get them to appear, but they're usually absent on startup if the keyboard is present.)

• Mod
Posts: 1,557

Woot - I have a working iCade demo. I'll post a project and demo soon - I just need to figure out how to film it (can't use the in-app record, because the hardware joystick is kinda part of the fun).

Posts: 5,700

@Mark you could probably do:

if key == "" then
-- backspace
end


I was thinking to just expose a BACKSPACE const as a Lua global and it would really just be the empty string, "".

Thanks for pointing out the keyboard state bug! It's not fixed in build 10 but will be in 11.

Posts: 5,700

@Mark how do you leave an app with the keyboard up? I am unable to recreate this, perhaps I am missing something:

• Show keyboard
• Press back
• Launch an app that doesn't show keyboard

Maybe I inadvertently fixed this in build 10. Let me know if it still happens.

Posts: 5,700

@Bortels I reckon a great iCade demo would be to port @ruilov's Pacman to portrait orientation and have it support iCade controls.

• Mod
Posts: 1,557

Random observations on (10):

1) Love the "new" banner on the new examples

2) The mesh demo is hypnotic. And powerful - I'm only vaguely understanding what it can do and can think of uses for it. Plus - triangles!

3) More physics, yay! Love the gravity selector

4) The recording API is a (delightful) surprise, but it occurs to me that this adds a powerful new functionality that maybe wasn't there before - I can see using this, plus fonts, as a way to generate regular old mov animations, not code, for all sorts of external stuff. I have a buddy at JPL I'm going to show this to not as a programming environment, but as a visualization creator (real 3D meshes and model loading, along with texture mapping, would seal the deal). There's a part of me that's starting to envision an animation framework (as a project - not something I'm looking to TLL to provide) to do things like pan, zoom, wipes, and so on.

nits:

All of my project say "No description available". Let us fix that. Yes, it's unglamorous. I suggest simply looking at the first line(s) of Main, and if they're a comment - there's the description. Likewise, you have image and video capture now - let us capture an icon for the project, maybe under program control so the cut-and-paste crowd can have a nice icon as well.

In the help viewer, if I choose a specific item, then go back - I'm at the top of the list. I should go back to where I left, I think.

And I already whined about sorting the projects (should not be case sensitive) and the need for project management. Like I said - picking nits.

I need to go stare at the mesh demo more. It speaks to me.

• Mod
Posts: 1,557

ooh - good point on the pacman demo. it should be pretty straightforward.

edited January 2012 Posts: 5,700

Thanks for the feedback, @Bortels!

Custom project descriptions will come as soon as tagging support comes. It's been put off for a while, but I imagine it should come fairly soon after 1.3.

You want case-insensitive project sorting? Can at least do that one fairly easily. Edit: actually that's just the file system sort order, which I'm inclined to keep

Posts: 5,700

I'm also planning to let you change project icons.

The image capture button currently gives you two options: tweet and save. In an update there will be a third option, "Use as Icon." Which will use the screenshot as the project icon. When we include that, we'll include metadata editing, and so on.

• Mod
Posts: 1,557

Andrew, my daughters got up to 35 on the anagrams until I booted them off :-) You're a hit.

edited January 2012 Posts: 5,700

Forgot to mention this in the release notes, but in build 11 I rearranged the top row of the keyboard. I was writing a lot of code and found I like it better this way, the more common keys are easier to access with your thumbs, if you are thumb-typing. I also found them easier to access when typing in landscape mode with all fingers.

Edit: This version is pretty final, and just waiting on one more piece - @Mark has allowed us to include his fantastic Spritely project and has been adjusting it to take advantage of the new 1.3 features.

Edit2: It also exposes a BACKSPACE const that can be used to check if key==BACKSPACE.

• Mod
Posts: 1,557

I am having issues wrapping my brain around mesh(). It's triangles - but it has .addRect(). The demo is hypnotic, but has few comments.

FWIW, the mesh.addRect docs have the "y" parameter twice in the Parameters section. There are also some word-wrap issues in the main "mesh" section.

Posts: 5,700

Thanks for pointing those out. I'll ask @John if he can comment it a bit more. Mesh is basically low-level access to an OpenGL vertex buffer object.

addRect is a convenience method for adding four vertices, indexed to generate two triangles, to the mesh. Basically a mesh is an array of vertices and indices telling OpenGL the connectivity of those vertices. There is also vertex data such as colour and texture coordinates associated with each vertex.

• Mod
edited January 2012 Posts: 1,557

Ok - I had guessed it was adding two triangles. But - I don't see addTriangle. And I don't understand it enough to tell if I should care or not :-)

It's 2am - I'm off to bed. As per usual, my spine will think about this all night, and it'll either make more sense in the morning, or I'll be asking questions (or writing exploratory code).

There is a part of me that is thinking that this mesh() thing can be nutty powerful if I figure out exactly what it's for...

edited January 2012 Posts: 643

@bortels
The addRect() method is just for convenience. It adds 6 vertices to the buffer and sets their position, texture coordinates and color based on the supplied parameters. I should probably add an addTriangle method, but just as i said, it's mainly for convenience.

You can make any arbitrary list of triangles by doing the following:

-- create an empty mesh object
myMesh = mesh()

-- add some vertices (each 3 count as a new triangle)
--           v2=(50, 100)
--           /\
--          /  \
--         /    \
--        /      \
--       /        \
--      /          \
--     /            \
--    /              \
--   /                \
--  /                  \
-- /____________________\
-- v1 = (0,0)       v2 = (100,0)
myMesh.vertices = {vec2(0,0), vec2(100,0), vec2(50,100)}

-- each color corresponds to a vertex (i.e. colors[1] maps to vertices[1])
-- if colors is nil, then the fill color is used for all vertices
myMesh.colors = {color(255,0,0,255), color(0,255,0,255), color(0,0,255,255)}

-- draw the mesh in its current state
drawMesh(myMesh)


You can set each of these properties as many times as you like when adding more triangles or changing the positions of vertices, colors, texture coordinates etc. As long as you have a multiple of 3 vertices with an equal number of colors and texture coordinates you have a valid mesh, which you can render using drawMesh(). If you set colors to nil it uses the current fill color. If you don't set a texture or texCoords it doesn't render with a texture. This should let you create anything from sprites, to lines / bezier curves, gradients, arbitrary polygons, etc...

Hope this helps. I'll work on making the documentation better before release.

• Posts: 447

I havent played with the last two builds (holy cow, you release fast), still on keyboard: hum caret movement and ability to select part of the buffer in an invisible way is another reason to drop the keyboardBuffer functionality.

key events is a common way to implement keyboard support and that's what keyboard(key) offers. Left/right keys could be reported as events through that too. I dont think anyone will find that unexpected or surprising.

• Posts: 447

Was going through the sound example and saw that roundRect function. "hum, Simon never mentioned a roundRec..." until i realized they're just really thick lines. Good trick

• Posts: 447

Physics, i suggest making a really simple example too. I like the one that's there because it shows a lot of what you can do, but a say 20 line example would be helpful to beginners

Posts: 5,700

Good points @ruilov. A really simple box-on-a-plane physics example would be good. Left / right keys are unfortunately not possible to do without getting pretty hacky since iOS only reports "selection" changes, not key codes.

• Posts: 447

I'm trying to use mesh to draw sprites. I think there's something missing in the API, probably mesh.size(). I'm adding an elem to a mesh and later on I want to change the position of this elem (say I have a obj:translate(dx,dy) method). How do I do that? I don't know the index of the elem into the mesh so I can't use setRect. I mean I can keep track of the index myself, but that's dirty

So I'd have either mesh.size, or make mesh.addRect return the index, or make mesh.addRect take the index. One of those would do it.

• Posts: 447

@Simon, so you'd have to keep track of selection and if it extended to the left, that's a left key, etc. And make sure that you add stuff at the start/end of the buffer so that the user never reaches the end and keys stop being reported to you.

Yes sounds hard..but if you do report left/right keys at some point I'd expect it to be through keyboard(LEFT_ARROW/RIGHT_ARROW)

Posts: 5,700

@ruilov yeah that's the hack that I meant, I might leave it for an update.

I've been finding bugs with the mesh API all night as I've been writing this test: – I'll have to get @John to look at it tomorrow. I fixed quite a few bugs so I'll put out a new build now with those fixes and email you this example project.

• edited January 2012 Posts: 447

Thinking about meshes, couldn't you make meshes transparent to us? Ie whenever I do sprite(name) I draws the sprite on a mesh under the curtain.

OR is that not possible because all objects in a mesh are at the same z-level?

Edit: hm, no forget that. Meshes are probably fast because they use something like retained mode

Posts: 5,700

All the data in a mesh needs to use the same texture, the mesh can have arbitrary vertices - though you can't transform the current matrix in the middle of drawing a mesh. You have to instead transform the vertices.

What you describe is sprite batching. That is, detecting all sprites drawn with the same state and batching their vertices into a single draw call. It's pretty tricky to do automatically in Codea.

We've done it for previous game engines by using a binning system, but when the user can write arbitrary code that can do anything to the style and transform state at any time, it becomes a much harder problem.

I'm still planning to optimise plain sprite() drawing, because it's too slow. And we may implement a higher level batching system than mesh (though probably not transparent). Mesh has its place for when you need huge amounts of data at the cost of flexibility.

• Posts: 447

makes sense

• Posts: 2,161

Now that we have quite a customisable display (orientations, fullscreen, and so forth) I'd find it useful if there were callbacks for when the screen changed. I'm thinking mainly of orientations, I guess, since fullscreen isn't directly user-activated. The thing is that I often set things up using WIDTH and HEIGHT, but when the screen changes these become out-dated. It's be useful to have a function that I could then add a load of reinitialisation stuff into.

• Posts: 2,161

Just turned on my iPad, thinking I'd play with meshes for a bit, and found another update!

• Posts: 447

Also would be good to have the ability to remove a rect from the mesh. For roboarm I want the ability to drag and drop a command into the program slots. I'll draw the commands with meshes but when the user drags a new command I need to remove the old one from the mesh. Or is there a better way?

I think whenever you have a container type of class you need at least: add(), remove() and list(). size() and clear() are nice to haves for speed but could be implemented in terms of the others.

• Posts: 2,161

Really like the new icons, and the screenshot facility. Might just have to get a twitter account after all ...

The anagrams program has a little junk in it. The following are the necessary files:

Anagram
Colour
ColourNames
Fireworks
Font
Main
Touch
Words
utf8
utf8Case


The others are "legacy" from the pre-inbuilt font days. This does mean that some of the other stuff in the library files would not work if it were used, but it isn't used in the anagram program so is probably more confusing than if it were taken out. (Note that the Fireworks.lua file contains the old Particles.lua and Smoke.lua as I wanted to be able to easily transfer this from project to project.)

Also, I'd feel much happier if you'd take the word this out of the word list! This feels like you're in the last throws before releasing it, and given my schedule this week I probably won't get round to implementing a "no bad words" routine, so best if it were just taken out.

• Mod
Posts: 1,557

Heh - went to bed, you updated twice while I was out. Slackers!

Last night my spine said to me "don't be a dork - its just a table of vertices. Add triangle is just appending to the table". Then I see @john and his explanation, thanks!

So - going back to simple mode - the idea is I can manipulate the vertexes and colors (or texture) directly, then plop the mesh down, rather than drawing the many items in the mesh each frame, no? And a complex shape - a poly line or font glyph - would draw in a single fast call. Is a mesh() going to be faster than a single sprite() call (ie. for a static image, is there a win here)?

All triangles must have the same texture (its per mesh), but each triangle has its own color, and that color acts as a tint() on the texture - correct?

Posts: 5,700

@Andrew thanks. Will remove the unnecessary files and "this". Good point about an orientation callback. I've wanted the exact same thing.

@Bortels I wrote this mesh test example that splits a single sprite into thousands of quads and moves them: http://twolivesleft.com/Codea/Projects/Meshtest.codea

@Ruilov I think the optimal way to "remove" a rect from a mesh is to set its vertices to 0,0,0,0. You don't actually want to reallocate the size of the data because that will resend it to the GPU. We can put a remove in, I think, but it will be best to avoid using it. In your case you want to use the mesh as a "pool" of objects. You can set them to degenerate rectangles (0,0,0,0) and mark their indices in a table, then when you go to create a new object, fetch a degenerate one from the pool and set it appropriately.

Posts: 643

@bortels
The overhead for calling drawMesh is probably similar to that of sprite, although I'm not entirely sure. Yeah all triangles are drawn with the same mesh. The main idea is to either draw some massive number of rects (like a particle system or something), or some custom mesh shape, like a height field landscape, model or something else. Simeon wrote a test that draws 50,000 triangles that runs at 60fps on ipad2.

@rullov
The idea is that you can just use myMesh:setRect(0,0,0,0) to clear a rectangle. The reason there isn't a way to remove the actual vertices that the rect uses is that I would need to shift all the vertices down, which would invalidate all the id's returned by addRect. What you can do is keep track of 'cleared' rects and reuse the id later. It's fairly low level I know, but thats part of the idea.

• Mod
Posts: 1,557

Ah - it just clicked, when you pointed out deleting a rect by setting it to zeros, and talked about a particle system.

I've been thinking of a mesh as a contiguous set of triangles, because that's a common use - but it doesn't actually have to be a "mesh".

A mesh is just a list of triangles, along with their vertex colors and maybe a texture, that lives in the GPU and so can be drawn really fast, in a single operation from our point of view. It need not be a sheet - each triangle is independent, like in most particle systems.

Woot! I understand the "for" now :-) and yes - nutty powerful.

• Posts: 447

hm, re mesh that's a much better idea. I had implemented it keeping track of the objs and recreating the mesh without the elem