I saw a remark about a clip() function and there’s no detail in the “Roadmap” thread (which is closed) so I’m curious as to what extra we’ll be able to do with drawing stuff in 1.2.
Ah I forgot to include clip() in 1.2, it’s currently in the physics branch as John added it for making a split-screen version of his game. That will have to come in 1.3. (Unless there’s a resubmission before then).
Sorry, I knew I missed a feature. The roadmap lists all the changes in 1.2, the biggest ones drawing-wise are the image class and retained backing.
I personally dissappointed because native text rendering support isn’t there yet. I thought it was asked by many users since the launch of Codify. I like Bortel’s font class but I’d love to have native and richer text drawing support. Also more primitive 2D shapes i.e. triangle, arc, star, etc. aren’t mentioned anywhere either. I think such basic features are quite important for beginners to create simple games. I do really hope they will be available on 1.3. finger crossed 
I would rather they spent time on things we can’t do, not things we can. Triangle, arc, star, etc are all things that you can do with existing line drawing commands and some math. There are at least 3 different font libraries out there, mine and two others (although an API to access native fonts would be awesome).
re. the image stuff in 1.2 - can you publish the docs now? Or did you, and I just missed it?
After the stuff mentioned in 1.2, I’d really like to see socket support, moreso than anything else. Persistent non-project global storage would be keen as well, but is a distant second.
For people like us who are pretty familiar with logic and mathematics, yes such features are very easy to be done by ourselves. We don’t create “simple” games either because it’s too easy to us. We’re not beginners, it’s not our problem.
But, imagine if a 10 y.o kid wants to make a simple game. A true simple game. Moving around some shapes to build another shape, for example. Or to create a moving text around the screen, for another example. It’d be too hard for him if it requires computation just to draw a triangle, or to import a class just to draw some texts. If it’s too hard for him, he’ll lose his motivation to learn more about programming in fun and easy way. And he’ll soon leave Codea to play Angry Birds, again. 
I have more faith in kids than that.
Besides - you misunderstand my point. A “shapes” library would be great - and anyone who wants to is welcome and encouraged to write one and make it available to everyone. Maybe I’ll do it - maybe you will. (In fact - I could swear I saw someone working on a Turtle-graphics library, like logo) Point is - your 10 year old can use that library. What I can’t write, and what you can’t write, are things like native font support, or sockets - we can’t change Codea itself. That’s what I’d most like to see the Codea developers add, because that’s something we simply can’t have without them doing it. A library to make regular polygons is easy to do - to do arcs and curves is not much harder, I bet it’s already out there somewhere, someone just needs to find it and port it.
I mean - they didn’t (and still don’t) include fonts - and now, you have a few different options if you want fonts. They didn’t include any 3D stuff, but Andrew’s balls-and-sticks stuff does 3D. And there’s no support for shapes, and arcs, and so on - but there are programs out there, published on this forum, that do them - people who want to can go look and see how they did it. That’s the excitement of a system where the programs are all open-source by definition.
I’ll upload the 1.2 docs shortly.
1.3 will contain physics, most likely, and the clip() function. Don’t worry, we’ll get to all these features eventually, and hopefully update review times will speed up so there’s no big delays like last time.
I don’t want to include too many new features in each update because the chance for bugs will go up.
On the top of the list are: text(), custom sprites, sockets (or similar), and increased sound parameters.
Custom sprites and physics are in progress at the moment.
@Bortels: You misunderstand my point as well.
The lack of native font and more shapes is not MY problem, nor yours either. I know it’s easy for us to roll our own. It’s beginner’s problem. I’m just trying to stand on their shoes. Beginners who never heard of Lua before, never know what a class is, they just found out an app that said can be used to make simple games using simple commands. They might don’t even know this forum exists. Or, worst, they don’t speak English but can read simple English with the help of a dictionary. The built-in documentation is all they got, with a little help from internet here and there. Yet, they’re capable enough to write simple programs using Codea. The availability of basic features would motivates them to learn more and more. And the lack of them would become barriers and make them no longer interested in Codea (and programming in general as well).
The lack of advance features i.e 3D stuff, socket, etc. though bother us, they won’t bother beginners. They don’t need it anyway (hence they’re called beginners). But the lack of basic features will indeed bother them (and us but in different scale). It will reduce the fun and ease factor of Codea, in pretty significant amount. Besides, if those features are so easy to provide, why Codea doesn’t have them built-in? If Codea devs are able to provide advance 2D physics engine, for example, how difficult is it to provide basic features along with it? Why bother the users?
Well, that’s just my suggestion to Codea devs. I believe they know what are best things to do for better Codea. I said all this because, AFAIK, Codea also wants to target beginners. CMIIW.
Bee: text and custom sprites are my two most important features. John is working on Physics and Dylan wrote the image library.
@Simeon: Thank you. How about more primitive shapes? Also text or keyboard input?
Bortels, how are you envisioning doing filled shapes and curved shapes with the current technology? Your fonts do curves by doing lots of short straight lines, isn’t that right? That’s going to get really difficult with filling. I’d really like the basic drawing ability of Processing or SVG.
I'd really like the basic drawing ability of Processing
My 2 euro cents: I’m very happy with the current update, the coming one and with the road map as has been laid out. But, FWIW, I’d love to see the Processing-like filling of complex shapes created by points using functions like beginShape()/endShape(). Is this already planned or am I missing something?
P.S. I’ve just checked out the new online docs and note that Safari (latest-5.1.2) on my Mac (running latest Lion update) truncates the page to the window size which means that I can’t see more on a page than my maximum window size i.e. longer pages such as ‘Graphics’ or ‘Lua’ are only partially readable.
@simeon: BTW, if you (I mean Codea devs) could provide color selector, why can’t you provide font selector (to choose font’s face, size, style, and color) for text drawing function? I think it would be awesome!
@Blanchot click and drag to scroll, don’t use the mouse wheel / two finger drag. I know it’s weird but that’s because it’s designed for touch.
@bee we probably can, but then we need to support that many fonts (which means having texture atlases for the appropriate character sets for each font). At first I’d like to get a simple text() API in using one font.
click and drag to scroll, don't use the mouse wheel / two finger drag. I know it's weird but that's because it's designed for touch.
@Simeon, wow yes that is weird… but it works! Many thanks!
(Perhaps an idea to insert a short sentence mentioning this at the top of the web page?)
@simeon: Then don’t support all fonts. Just like Codea didn’t support custom images on the image selector when it first released. I think ‘times new roman’, ‘arial’, and ‘courier new’ would be sufficient as they represent 3 major kind of fonts (serif, sans serif, and fixed). What do you think?
@bee: I was thinking to only support one font initially, probably Myriad, as that is used throughout most of the app.
Bitmap fonts can be done in two ways:
-
A pre-rendered character atlas, which is fast to draw dynamic on-screen text. But inflexible, it can’t change the rasterised font resolution, can’t change the font, and can’t change the character set.
-
A dynamically generated bitmap string using the TTF directly. This is slower because each new string needs to rasterise a bitmap into memory, and then upload it to the GPU as a texture. It’s flexible because it has a variable size, font and character set.
I would prefer to implement the first method, however it wouldn’t be very international, since it would only support the ASCII character set. Perhaps both methods could be supported and toggled between using a textMode() style function, we’ll see.
Any method is fine with me.
About the second method, using TTF directly, how slow is the slow? Can it drop the framerate significantly? I thought OpenGL already has had internal TTF drawing engine, no?