#### Howdy, Stranger!

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

# beta 1.3

Mod
edited January 2012 in Beta Posts: 1,557

Lol, I made the beta notes. Ah well - I was having server-side issues with the touchpad thing anyway. There's a reason I prefer Lua to Javascript... (don't get me wrong - node.js is awesome. I just wish it was a sane language...) (They took sockets out of the beta and I weep... meh. I've had some time to get used to the concept and say goodbye. Perhaps we'll meet again, dear sockets... Oh, hi - I'm jailbroken, perl does them. :-) )

I like the physics stuff at first glance - there's a few effects ("filter" and "raycasting") that I've never seen and I can see great utility for, and of course collision detection, w00t! Is #9 on the example just incomplete? (It must be - just noting #9, "bullets"... isn't?) Is it still the case that the intent is to use Box2D as a sample implementation as much as possible? I guess what I'm really asking is, for an online API and tutorial of the stuff, will Box2D be close enough to be useful?

No text example - but it seems simple enough to me that the inline docs suffice. I do see you added "How Codea Draws", that's good.

Semi-Off-Topic: Saw this today from Penny Arcade and it inspired me to make a project I'm calling "Trek" for now... and now the beta comes along with juicy new features, that's going to put me off of the new project. An embarrassment of riches.

Posts: 5,362

Sockets will be back if Apple allows me to include them. Strangely, iLuaBox has Sockets available as in-app purchase, so it seems as if Apple has reviewed that IAP and allowed it.

Filtering and raycasting (and AABB queries) are very important to a game physics API. Consider the example where you have a player character and monsters. You might want the player to be able to collide with monsters, but monsters should be able to move through each other. That's what filtering gives you.

Raycasting and sensors let you pick up information about the world from a particular point. Raycasting is especially handy.

Rather than have a specific text example I will probably add little bits of text throughout the existing example project such as frame-rate counters and titles.

• Mod
Posts: 1,557

Ok - I'm officially loving the physics, in that it's irritating me, in a good way - it's bothering me the way the cute girls back in high school did, kinda sorta. Well, not exactly the same, but you get the idea. My brain has these physics muscles from college (I have an AS degree in Laser Electro-Optic technology - mostly enginering work involving plumbing and optics and electronics that will ZAP your ass across the room), and that involved your normal college physics as a prereq - and that was a loooong time ago, and those brain muscles are saying "What? You want to remember things?". GRAND FUN!

The demos are surprisingly short - you get an awful lot of bang for the buck there. Programs that use the engine are going to be significant setup, and then just let things happen.

Gravity is unidirectional, yes? If I was to, say, want to do orbiting bodies stuff, I'd have to apply the gravity myself as individual forces, right?

LOL - I didn't even NOTICE the physics demo also uses text. How cool. :-)

So - it looks like the actual world, and it's simulation steps, are "understood", in that I am guessing/assuming that the world simulation is processed once each draw() call?

edited January 2012 Posts: 5,362

Yeah, we wanted to make it as simple as possible. You can pause and resume the simulation, but it is stepped automatically if you are using physics.

However the physics uses an accumulated time-step. So it is not linked to the frame rate of the scene. What this means is that physics will evaluate at the same rate on iPad 1 and iPad 2.

(The way it does this is to accumulate the frame delta each frame. If the accumulation exceeds the fixed time step value it steps the physics simulation forward. Conversely if the delta accumulates so fast as to cover multiple time steps it will step forward multiple times in one frame.)

• Mod
Posts: 1,557

For those following along at home - I'm going thru the examples and looking at the corresponding Box2D docs at the same time - and it looks like TLL did a really good job of tucking away a lot of "busywork" you'd normally have to do yourself in, say, a C++ program using Box2D. You don't need to explicitly set up a world or call it's simulation - it just happens. Bravo! Physics is always semi-painful to get into because of it's complexity - but this should make it less so.

In fact - a lot of the routines in Main in the physics demo are likely to make it, intact, into people's projects, as well as the PhysicsDebugDraw stuff.

I tend to tell people who want to code "go look at the examples, find something close, and start modifying it" - this goes double for the physics stuff. The engine takes care of the animation, so the part the programmer needs to worry about it setup - and you have some perfect templates to model off of here.

Posts: 5,362

Only a few people can see the beta section of the forums. @alvelda, @ruilov, @Andrew_Stacey and you.

I've set it up like this so beta discussion doesn't confuse users who don't have access.

Thanks for the comments on the physics, that's all John's hard work. I'm sure he'll appreciate your feedback. PhysicsDebugDraw is a file we want people to copy all over the place - I'm thinking to add the cross-project file import feature just for that file.

• Mod
Posts: 1,557

Heh - wasn't sure. That's good - I kinda felt guilty posting about goodies before they can get their hands on them - now I'm guilt-free!

Tell John he officially Wins. The physics stuff is such a neat toy I may be able to forget sockets for a while :-)

I honestly think the physics stuff is one of those things where it'll take a bit to get momentum (ha!) then take off. There are some insanely fun things we can do with it. I'm actually marveling at some of the add-on stuff that might be useful for physics, but is also useful for other things - you mentioned the raycasting and AABB stuff, holy cow! I did raycasting in OpenGL back when it was "picking", and the AABB stuff solves some things I was thinking of the best way to write, so w00t! The best way for me to write code is find someone else already wrote it. (indeed - the region query alone I know I'm going to use for the Trek thing I was looking at - being able to say, quickly and easily, 'ok - where are the enemies close enough I should actually look at interacting with them' is really handy) - and you know I wanted collisions for ages - I was delighted to see it in the demos. A lot of the stuff I want to do won't use "normal" physics (like the orbital stuff, and the game I'm just starting), but the adjuncts to it make the engine so valuable anyway. Can't say enough good things.

And yes - when I saw the debug tab, I thought "what we really need is to just 'require' it and go on". But it's nice to be able to see how it's implemented as well, so it's good it isn't just built-in and hidden. Some of the stuff in main like createCircle and such will also be used all the time. (mmm - I actually want to mess around making the draw for some of this be sprites from the spritepacks... I wonder if the asteroids in the space pack are properly centered...)

• Mod
edited January 2012 Posts: 1,557

Oh boo - sockets are gone, and took mime with them - specifically the base64 encode/decode, which I liked to use for binary persistent data.

Any chance we can get mime back?

And zlib too, while your at it :-)

I can roll my own - did for b64 - but they'll be slow. And ugly.

Posts: 5,362

If we allowed general file IO, would that be preferable to mime?

Or just the ability to write and read PNG from the project bundle?

• Mod
Posts: 1,557

That's orthogonal - what I really want is base64 encoding as a way to save binary as copy/pastable ASCII blobs. General binary file io would elimate a class of places I'd use it (marshaling data to/from persistent storage), but until we can io to the real world (either sockets or file import/export), there will still be utility in that.

Png is an interesting problem - we want, in the end, to be able to easily share, including custom graphics. That means either spritepacks, and the ability to manually import/export them, or perhaps the ability to fetch png from a URL and save it. What goes unsaid in both is that someone (not me, not in public) can use png as a means of code sharing. I don't see a way around it other than moderation, which strikes me as unworkable and unacceptable. Maybe the remove from actual code will be acceptable enough for apple to allow this sort of sharing. Baby steps I guess.

Physics: is there a way to see/set the world gravity vector? I want to slave it to the accelerometer, but i don't see access to the world object? Maybe I missed something.

• Posts: 447

just had a chance to play with the physics, it looks awesome!

Something like this would be easy to make right?

http://megaswf.com/serve/102223

• Posts: 447

on file I/O one advantage of having it would be the ability to read/write code and data so 1) we can do a user version of library mgmt, 2) we can write a project loader in case .codea does stay out.

• Mod
Posts: 1,557

If we had file i/o to projects/tabs (including the ability to make new ones), then yes - we'd at least be able to re-create projects, including persistent data (??? I think - we'd need to be able to write to a plist file), from a single cut-and-paste loader. Hmm - could a project nuke itself to clean up afterward?

Not to argue against something I suggested, it's a kludgey workaround for the whole can't-import issue; there's real utility to a filesystem aside from that, but I'm still not 100% satisfied with it as a solution to importing - I guess nobody is. Plus - do we want to allow write-access to another project's files? I had envisioned write access to the local project, and read only access to other projects (and data). Idea being that a project gone berserk could only corrupt it's own files.

• Mod
Posts: 1,557

Physics again: Is this Box2D under the covers, and if so what version, or is it based on or adapted from Box2D, or something else? It strikes me it's real Box2D, version 2.something, with some adjustments to fit the Codea run loop. I ask because I'm trying to pin down docs and features in versions, so that I'm not confused when I try something and it doesn't work as expected.

Posts: 5,362

I think it's the latest Box2D version. @John will be able to confirm that.

There should be a physics.setGravity( vec2 ) and physics.setGravity( x, y ). It looks like it hasn't made it into the docs yet.

Posts: 616

The version of box2d is from svn about a month ago, I'll have to check the exact version. You can set gravity with physics.setGravity(vec2) which is missing from the docs (oops). In terms of API completeness we are missing a few joint types and one shape type as well as low level access to fixtures. There's no support for composite bodies (more than one fixture attached to a single body), which will likely be in an update.

Another thing I'm working on which might make it in to 1.3 is a class called mesh2d. Basically its allows you to render an arbitrary list of triangles by specifying vertices, colors and texture coordinates. You can use images or sprites as the texture. The intent is to allow simple but powerful access to the hardware but without the tedious setup required.

• Mod
Posts: 1,557

So - love the font picker. Love it! But - now on using it, my brain wants the picker and font() call to specify both font and size, and I want to see that in the picker - indeed, I want to drag my selected font bigger and smaller (maybe with left and right drag). Perhaps font size can simply be an optional 2nd parameter in the font() call? Just a suggestion.

I'm confused about mesh2d - in 3d I understand you'd draw a triangle mesh and let the GPU do the perspective and shading and whatnot; but what would a 2d mesh get you over a plain old sprite or composited image (which I hope are textures on GL billboards or some such). Or - why not just go 3d? I'd love to be able to render a textured mesh.

Posts: 616

There's a few advantages. You can construct Tilemaps and render them much more efficiently. You can also construct a grid and use it to render a distorted image. You can render arbitrary shapes, gradients, etc. You can also set texture coordinates independently so you can have scrolling textures, and other similar effects.

The intent is to also support 3d meshes but for that we also need perspective projection support, depth testing and 3d transforms. All of that is going to require a significant overhaul of the current render pipeline.

Posts: 5,362

Depth testing is in there, as are 3D transformations.

All we actually need is a matrix class (wrap glm::matrix in a Lua userdata). And an applyMatrix(m) function.

• Mod
Posts: 1,557

I guess I don't understand how you'd distort the image without the triangles in 3d space...

Oh. By the texture mapping. I get it. So you could get, say, a lens warping by mapping a texture then changing the vertex coordinates, making the triangles smaller on the edges... Different.

Is the idea behind tile maps simply that you could pre build them, as opposed to nested for loops like we have to do now? (I've just been planning on larger tiles for performance, and compositing to an image that's cached until I scroll... But I have yet to implement that to know if it's performant. Interesting. In my case it's a starmap, so large tiles are necessary anyway, but I can see the utility there..)

• Mod
Posts: 1,557

In some other threads, they're talking about the keyboard coming in 1.3 - did I miss something, or should we manage expectations? (I'd like a keyboard too, but you know that)

• Mod
Posts: 1,557

Physics:

The gravity as expressed by Gravity.x and Gravity.y versus setGravity are orders of magnitude different - I am multiplying by 300 before they're high enough. Not a complaint - an observation. I suspect wanting gravity to match real-world gravity will be common - it might be nice to have some sort of convenience function where physics could just eat the Gravity vec3 and "do the right thing" (which would be ignore the z, and multiply x and y by some adjustable constant - 500 as a default?)

It would be nice if the docs for properties of bodies had default values shown. Side note: nothing in this world has a restitution of 0 except maybe a lump of clay. I'd default it higher, it feels more "alive" to me. Or maybe another demo...

Posts: 616

Here's the thing. There is a conversion between screen coordinates and physics coordinates is because box2d is tuned to use units on the scale of kilograms / meters / seconds, which means if you map things 1:1 on the screen you get low stability from the solver. There are about 32 pixels per meter in the current setup (this will be settable).

When the ipad is standing up i noticed Gravity.y is around -1. The units used for physics.setGravity are in p/s^2 (pixels per second per second). This means that if you want the equivalent of -9.8m/s^2 you need to set it to Gravity.y * 316.8 (pretty close to your estimate). The only thing i can really do is take out the conversion for gravity, or perhaps have a convenience function like: physics.setUseAccelerometerForGravity(true/false).

Posts: 5,362

I don't think it's worth having a convenience function when you can just multiply by a constant. It adds API complexity that solves something the user can easily solve themselves.

Posts: 5,362

I never mentioned that a keyboard would be in 1.3. Though that's not to say it won't make it in there. It's just not definite.

• Mod
Posts: 1,557

I'd just have setGravity recognize that if you pass it a vec3 (ie. Gravity from the accelerometer), it should discard z, and set x and y to 318.6 times what's passed - that would make the idiom to set physics gravity to the real world be "setGravity(Gravity)" which seems pretty clean. You leave the vec2 and x,y behaviors as they are. Does that make sense?

• Mod
Posts: 1,557

I'm just suggesting it's going to be a FAQ; if we're willing to discuss things like convenience functions for n-gons when they can do simple lines, then an easy way to say "please use real gravity" seems fair, since "oh, multiply x and y by 316.8 and discard z" is fairly non-obvious.

edited January 2012 Posts: 5,362

It makes sense, but the user could also just do physics.setGravity( Gravity * 318.6 ). Or we can add a constant ACCELEROMETER_GRAVITY_TO_PHYSICS you can multiply.

I don't think it's necessary because most times 318.6 won't be the right value. It will depend on what feels right for your project. 200 might be better, or 500, or some arbitrary scale factor that makes things run correctly for your project.

• Mod
Posts: 1,557

But - setGravity takes vec2 and x,y - will it take Gravity, which is vec3? I haven't actually tried. If so, that's great - but it's still going to be a FAQ. :-)

edited January 2012 Posts: 5,362

Hmm you're right. I think it's better if we make setGravity do an implicit conversion (discard Z) and add multiply operator support to vec3.

Edit: as well as other operators. We'll need them anyway for when 3D is added.

Posts: 616

I might just make mesh2d, into mesh and change it to use 3d coordinates by default and just use z=0 for vec2 input. That way when additional 3D api stuff is put in, it'll just work.

• Mod
Posts: 1,557

• Posts: 447

Reqding through some of the physics code now.

Body:testPoint could have a better name. Maybe body:inbounds?

Posts: 5,362

Or Body:containsPoint

• Mod
edited January 2012 Posts: 1,557

Mmm... Assuming this is the same testpoint functionality as box2d, I'd avoid changing it - the better the mapping between the two, especially in function names, the more the docs and examples will apply to codea. Principle of least surprise.

• Posts: 447

Cooments and questions on the physics api.

• rigibody could be just "body". If you're thinking about adding non rigid bodies later, then make that one be the one to have a longer name

• getlinearveloc...how about just velocity? And if it's easy to convert from world to linear point and vice-versa, i'd just keep one of the two versions

• applyTorque: what's the units?

• applyForce: what happens if i dont pass a point, does it apply to every point? So i'm guessing if i dont pass a point, it doesnt change the torque, but if i pass a point it does (just tested this, seems to be the case)

• body:draw() and body:fill() would be cool

That's it for now. It all seems very cool.

• Posts: 447

Bortels, ok but least surprise for me would be a more descriptive name because i dont know box2d.

• Posts: 447

Also tried the font picker today and it's sexy. One idea would be to put common fonts up on top.

• Posts: 447

Also on the physics, on joints, do you just create one and starts doing its thing? Is there a way to get a list of joints? Could be useful (at least for debugging if nothing else)

• Mod
Posts: 1,557

I don't know box2d much either - but right now, if I'm looking for examples or questions answered, it's box2d that has info available, and it's box2d that the code is derived from. My point is - change the name if there's a reason to change it other than aesthetics. For example, if the name was misleading. testpoint isn't terribly descriptive, but it has the giant advantage of coming up with hits when I google for "box2d testpoint", whereas the others do not, or worse, will come up with something different entirely. There is tremendous value in being able to share the existing body of examples and documentation out there, just as there is for the Lua language itself.

Posts: 616

Hi guys, I realise some of the the method and property names are a bit long, and sometimes unintuitive. I've been wrestling with the idea of changing the names to make them nicer for Codea and keeping them the same, to make them easier to compare to box2d's API. At the moment I'm still not sure which approach is better since both arguments have merit.

@ruilov Joints just work after you make them (assuming you supplied valid parameters). It's not possible to have a joint without a reference to it somewhere because it gets destroyed as soon as it gets garbage collected (i should make this more explicit). So what you would normally do is add it to a global table, if you want access to all joints. The PhysicsDebugDraw class in the physics example does this to keep track of all bodies and joints.

The reason i used the name rigidbody initially was because i wasn't using the physics namespace and i thought the name was too common to be a class name, so i'll change it to body soon.

Posts: 616

Also:

The units for applyTorque should be in newton meters (i.e. force applied to an object in newtons * meters from the center of mass at a tangent) but this isn't mentioned in the box2d docs as far as i can tell.

If you don't pass a point to applyForce, it applies force at the center of mass of the body and doesn't apply any torque.

Posts: 5,362

I do like the idea of going with "body" instead of "rigidbody."

• Mod
Posts: 1,557

re. names: here's a thought - aliases.

In other words - keep the old names there - but in cases where they are undescriptive or you see a compelling reason to change them (perhaps to make a whole class of names the same), add aliases to those functions so either will work. You get the goodness of backward-compatability, and you can document things that make more sense - maybe a blurb somewhere that says something to the effect that this is the box2d library, and the old command names will also work - click here for those docs.

You could also just say "body.containsPoint - description - this is an alias for the Box2d body.testpoint function". And make sure the docs are indexed online; that way, eventually a google search for "Codea testpoint" or "Codea containsPoint" will show up the doc with the crossreference.

That's why the docs really do need to be online in an indexable manner, BTW - search engines. I used to like a language named "Io". I think one of the names it didn't take off is because it was effectively invisible in google. Food for thought.

• Posts: 2,161

This all looks very interesting and I look forward to trying it when it is released (and Apple approves it ...). In the meantime, a couple of thoughts (based purely on the discussion above so they might not be all that relevant).

1. With regard to the text, can I do useful things like measuring text? When putting instructions on the screen, one wants to automatically wrap the text and for that one has to measure it (preferably before rendering it). Composite characters also need careful handling - in the BDF specification, a character can say "The next character should start at these (relative) coordinates" meaning that if it is an accent or something then the positioning is easy to work out. Will this information be available? Similarly, if one wants to label a point then it isn't always the case that the label should go "above right". Positioning it "below left" will require measuring the height and width of the text. Lastly, when placing text at, say (100,100), is the text fully above the line y = 100 or is it (as it should be) that the baseline is at y = 100?

2. With regard to the physics, I'm curious as to whether or not this will be useful to me in doing simulations of physical systems, or is it just for defining a sort of "physics" for a game?

• Mod
Posts: 1,557

Andrew, from a mathematicians point of view, the physics will lack rigor; there are hundreds of little cheats that give them almost no predictive quality, and edge cases can be grossly wrong, not just inaccurate (things may pass thru other objects and so on). They're great for getting realistic-looking motion in games and such, but there's a million edge cases and caveats and approximations. I mean - it's 2D, that in itself is a giant limit on how real anything will get (notably, density acts weird, because it's not density, really).

Having said that, they may well be useful as models if you're interested in gross motion - I could see some fairly good first-year physics demos being done with them, and parts of the toolkit (the collision detection and so on) could be used in other types of simulation.

Getting text metrics would be handy, for sure.

Posts: 616

Text metrics should be fairly easy because simeon is using cocoa to do the font rendering.

I imagine it would be something like this:
vec2 textDim = textDimensions("string")

• Posts: 2,161

Done right, it should return three numbers: width, height, and depth. The reason being that if you put "Why" next to "me" then you want the bottoms of the "h" and "me" to line up, not the bottoms of the "y" and "m".

edited January 2012 Posts: 5,362

@Andrew_Stacey

The function for measuring text is called textSize( "string" ). It returns two values, width and height, which are the measurement of "string" under the current font style.

In order to wrap text there is a function called textWrapWidth( width ), setting this to a value greater than 0 will cause the text to automatically wrap when it hits that many pixels wide.

You can use this in conjunction with textAlign( ALIGNMENT ) to align the text.

There are two ways you can render text using the textMode( MODE ) function, which can accept either CORNER or CENTER. It works similar to rectMode.

(Your "Why" "me" example will probably work in the current system as text height is fixed for a particular font size and style. It's just the way iOS text layout works.)

Edit: do you want to join the current beta to test this text stuff out for us? If so sign up here http://bit.ly/oe7Utk

• Posts: 2,161

Hmmm, those look good but I just know I'm going to need depth at some point. Superscripts and subscripts spring to mind - I want to typeset e^{i \theta} and for that sort of thing I really need those metrics.

Posts: 5,362

Hmm okay I've looked into it. It should be possible to get the following parameters for a font or for a line:

• ascent
• bounding box (this is the "design" bounding box of a font)
• descent
• cap height