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.
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.
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.
I do like the idea of going with “body” instead of “rigidbody.”
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.
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).
-
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 liney = 100or is it (as it should be) that the baseline is aty = 100? -
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?
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.
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”)
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”.
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
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.
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
- leading
- slant angle
- underline position
- underline thickness
- x height
I’ll make ascent, descent, leading, cap height, x height, and underline properties available. Bounding box and slant angle look too obscure to be useful.
I completely forgot. This build also seriously enhances the sound() API thanks to Dylan’s work. Have a look at the Sounds Plus example if you’re interested. No docs yet.
On the other hand, bounding box and slant angle are very useful for a character.
However, those look plenty to be going on with.
I’ll update to the beta after tomorrow - I’m going to use Codea in a lecture in the morning and don’t want to risk my code suddenly failing just beforehand!
I’d love to test out the sound stuff, but for some reason I’ve never been able to get any sound in Codea. I tried turning-off-and-on-again. Should I just reinstall Codea? Will installing the beta be enough?
Some people (two that I know of so far) have had to reinstall or restart their iPads to get sound working.
Regarding bounding box: I believe it’s the bounding box for all characters, the docs refer to it as the ‘design bounding box for a font’. Slant angle is only available for a font, it’s a metric for italic fonts.
Yes, I discovered how useless the font bounding box was with my bitmap class. I thought it would be a “generic” character size so that I could use it for variable-width fonts if I wanted to make a box that was roughly 80 characters wide. Turned out it was more like the largest character size, including double-width characters. So instead I worked with the widths of x and m.
Hmm, slant angle might have something to do with italic correction. If I ever need it, I’ll bug you again!
Regarding sound, I was hoping not to have to reinstall to get it. I guess I’ll do a complete backup before installing the beta anyway so I may as well uninstall to try to get sound working.
Incidentally, there was a suggestion (by Bortels, I think) of including my cube project as an example. If so (and it’s fine if not), I should probably update it to use the new stuff, such as fonts.
I think it was me who asked about it. Would still love to include it. If you’re planning a big update for it then I’ll hold off until you’re ready.
First and foremost, you can include any of my code as and when you like. As I think has been said on the competition thread, having ones code in the “examples” is the “Holy Grail” for Codea users!
Regarding updates, I’m not planning any particular feature changes. It’s just to ensure that it first works with 1.3 and second that it makes use of the new features that are coming in which replace some of the hacks that I developed. After all, if fonts are built in then it seems a little silly shipping a 5000 line 3Mb file containing all the font information! (Not that I’ll throw away my font stuff - might still come in handy as I’ve said elsewhere for the mathematics.)
Okay fontMetrics() has been added to version 1.3 (4). It returns a table of advanced font parameters (everything except the design bbox). Here’s some code that draws the table of font parameters in the font itself, and lets you adjust the size.
function setup()
font("AmericanTypewriter")
print( font(), fontSize() )
parameter("FontSize", 13, 35, 20)
end
function draw()
background(37, 37, 45, 255)
fontSize(FontSize)
-- Need textWrapWidth to do multi-line text
textWrapWidth(1000)
textAlign(LEFT)
fill(255)
metrics = fontMetrics()
local str = ""
for k, v in pairs(metrics) do
str = str..k.." = "..v.."\
"
end
text(str, WIDTH/2, HEIGHT/2)
end
Let me know if this gives you the data you need, @Andrew_Stacey.