Please can we have more graphical stuff!

This is intended as a counterpoint to all those clamouring for sockets and similar advanced stuff. Whilst those things would be nice to have - and in particular I don’t see this as an “either-or” - they aren’t the things that I’d really like to see in Codea. In short, I’d like:

  • Better graphic support: specifically, being able to specify a path as a sequence of lines and beziers and then do something with it, like draw it, fill it, and so forth.
  • More iPad specifics: the great thing about the iPad is the interaction; touching and moving it. With more bits of the iPad-stuff available in Codea (such as the compass), it would make it easier to make things that use the full range of what makes an iPad a different experience to other computers.

My point there is that Codea is an iPad application and I think it should make more use of what an iPad is special for: the screen and the interaction.

I know I’ve said all these things before, but no-one’s said them recently so I’m saying them again.

The computer is the network - the key feature of the iPad isn’t touch, it’s portability. So, sockets, which are not advanced, they’re communication. It’s what people do - communicate. a computer is only as useful as its ability to communicate.

But for the sake of the mental exercise:

GLSL has been suggested, and would be super-cool.

Camera and/or microphone input - again, it’s about communicating with the real world.

Real sound output (mp3/AAC support, sampling) - mostly for games/music, but I have a wild hair to combine mike/sound and make a 300 baud modem :slight_smile:

Access to iTunes library and photo library.

I’d say fonts, but they’re mostly covered - just build in a bitmap font.

HTML/svg for rendering stuff we already have :slight_smile:

Ooh -real library support. If I want to use Andrews fonts (or mine!), I shouldn’t have to save them to global storage (although that’s better than nothing) or copy/paste. Just co-opt “require” so we can “require(“projectname/tabname”)” - and we can manage our libraries.

Real file I/O - not necessarily to the file system. I’d love to be able to use the standard file io to open, read, and write tabs in my projects.

Related, Export tab as text to other apps (thinking mail or Dropbox). Import would be awesome too, but apple , sigh.

. . .

I really love Codea, but I feel like I’m “stuck in a box” - I can’t communicate with the “real world”, and I can’t even communicate locally much (I can feel movement, get poked, but cant see or hear, and can only make grunty noises). I can’t even access memory (my music and photo libraries). And apple doesn’t even want me to email my pen pals about what we do in our boxes.

I want to see, to hear, to share and communicate and play.

I agree that these things would be nice, though having watched my kids with the iPad then I’d still say that the nature of the interaction is higher than the portability. But I think that the graphical stuff is more important. It’s all very well being able to communicate, but if you have nothing to say …

Graphics is what is going to make people want to do stuff in Codea. The iPad is one big screen!

Would love to see more audio related support like mentioned above including .wav support. Would love to see a sweet drum/sample sequencer made in Codea.

I agree more drawing tools would be a great addition and we are exploring various possibilities. One API I was thinking of including would be a mesh class that lets you render arbitrary polygons. For example:

myMesh = mesh()
myMesh.vertices = {vec2(-10, -10), ... }
myMesh.triangles = {index1, index2, index3, ...} 
myMesh.texCoords = {vec2(0,0), ... }
myMesh.colors = {color(...), ... }
myMesh.texture = myImage / spritePackname


Basically the idea is just to have a low level api for drawing meshes but more efficient than using an immediate mode style api

I agree with Andrew. iPad is more about interaction with its users, first. The touch, the screen, the sensors, etc. are the main attraction of iPad. Then about interaction with other users/devices (through any media i.e. internet, bluetooth, etc). Of course it’s important but as complement, not main attraction. If it’s more about network, iPad wouldn’t become such a big hit. Simply because every other device before iPad had been very well connected to each other.

More and better graphic support was requested since the beginning. Such as more drawing shapes (triangle, polygon, etc), more drawing features (flood fill, put pixel, font, etc), more packed sprites (UI, cards?), custom sprites, etc. More and better interaction support was also requested not too long after that. Such as gesture API, GPS info, camera access, etc. The third most requested is better sharing features, not just with the outside world, but also with other internal Codea projects or other iPad apps. Such as cross project library, import class from other library, music library access, photo library access, global/project data, etc.

I believe we all very understand that it takes time to provide those requested features. Some of them had been fulfilled on the recent version. I also believe TwoLivesLeft would do their best to satisty its customers. As all those had been requested and documented on the bug tracker, I don’t think we need to ask about it over and over. Though remind it once in a while is necessary. :slight_smile:

Being able to draw anything is useless unless you have something interesting to draw. Most of the interesting things come from the net. Those that don’t… You’ll probably, hopefully, want to share.

Yes, kids don’t want the net, because they don’t know about it. But - not a lot of kids posting here, and those that are are by definition net users.

I’ve said it before, I’ll say it again - id much rather TLL spent their time on adding features we can’t add ourselves, rather than ones we can. Things like more graphic primitives, or convenience features, or advanced shapes (breezier curves) - we can do that. And if we do and they’re just too slow - then it becomes useful for them to add. (things like glsl or image compositing or such, sure)

Case in point - fonts. Codea has no built-in font support, as you all know, but if you look at the newer nicer projects, you wouldn’t know that. Indeed - I wanted TLL to add a simple bitmap font, but no longer; Andrew’s X11 ports are awesome, and all I want now is for them to be included by default. I doubt very much TLL can come up with something much better, unless they expose full html and svg support. I think many of the graphics primitives are in the same boat - I can make a crappy proof of concept, and that may goad those smarter than I to improve on the concept. :slight_smile:

What we need is them to expose hardware and APIs - sockets, but also cameras, images (png and friends), compression, microphone and sound, iTunes/iPhoto content, and so on.

Perhaps I should say that I just tried adding a bit of anti-aliasing to Bortels Pic stuff and the result was Extremely Slow. There are no doubt a few optimisations, but I doubt that there are many. That’s what prompted me to raise this again.

As for:

Most of the interesting things come from the net.

Have to disagree there. Most of the interesting things come from the imagination. The net is a great way to share those things, but if you’ve got ideas - and this place shows just how common that is - the net is secondary.

The way those interesting things get from other people’s imagination to yours is, today, the net.

And, if you have great ideas… And you can’t share them…

Indeed, Andrew, your career (teaching) is based on sharing, and I know the net is important for that because I’ve been to your web page! The sciences in general depend vitally and fundamentally on sharing - and the net is the biggest advance in that since the printed word, I’d say.

I got Codea from the net. This conversation is on the net. The net is, in effect, a force multiplier.

I just hate to see Codea crippled in that regard.

And yes - per-pixel image stuff is dang slow. This is a classic example of things it’s worth the time for TLL to work on. I’ll go further - a low level code flood fill would be awesome too. I’m not saying these things are useless - I’m saying they’re probably less useful than TLL working on stuff we can’t do at all. (example - give us good GLSL access, and with some admittedly advanced work, we can do image compositing and antialias an such ourselves, at hardware-accelerated speeds)

Out of curiosity - what exactly did you want to antialias? There’s an antialiased line drawing routine I was thinking of trying, but I bailed when setContext then line() became reality. (indeed, the pic class was largely a placeholder until setContext came along - I think the only thing it does now that’s not better accomplished in another way is flood fill, and yes, it’s dog slow)

I was driving home this evening, thinking about this thread, and about “advanced” users and “beginners” (it’s a continuum, of course), and I thought back to airline safety instructions, of all things. They say, very specifically, if you’re traveling with children, and the cabin depressurizes, to put the oxygen mask on yourself first, then help the children. They say this, of course, because the children can’t help themselves, or you - by taking care of people who can help others first, everyone gets helped.

There is an analog to that here - TLL can work in features that allow their advanced users to write code that benefits the whole userbase (and perhaps pinpoint code we can’t do with high performance) - or they can write code to do simple things we can already do, but maybe faster. That’s lovely - but only helps the fraction of the userbase doing that specific type of coding - the features are more specific in application, less general. Writing a fast filled n-gon routine is great for anyone who needs fast n-gons - and useless for anyone else. But exposing HTML/svg/glsl/camera/gps/whatever is of general utility.

To put it another way -TLL should put the oxygen masks on those who can help others first. (this is NOT intended as a slight on beginners - we all began once, and some of them will go on to teach and help in turn. We stand on the shoulders of giants…)

Besides - I think I can do fast (faster anyway) filled n-gons (or ploys in general) with image() and rect() and rotate() and clip() (to get arbitrary triangles) and setContext() (to composite). The general use routines solve many problems specific-use code would not.

You’re a mathematician, Andrew - I’m just suggesting that solving for the general case (if possible) is usually more useful than solving for the specific.

TL;DR: help me help you. :slight_smile:

We are all just hosts to memes. Isolation allows a space for unique memes to develop. The net allows the memes to spread and crosspollenate. Standalone and Interconnection are memes in and of themselves.

Isolation also allows starvation.

If you are connected, you can choose to isolate yourself if you wish. If you are not connected - you have no such choice. All else being equal - strive for choice.

Besides - I think part of the reason Codea stirs such interest in people is we’ve been isolated for too long. We want to create, and to share. Those who don’t want to share - don’t have to. Again, choice.

This forum is awesome, it’s more than just codea, it’s a community.

My 2c is that who cares what the ipad is about…what i care about is what can i do with codea that i can’t do elsewhere. And Bortels while i really, really want connectivity (and I/O) i would rather have those things that my laptop (or desktop) doesn’t offer before i have sockets. Interaction with the user is more important for me in codea because frankly that’s why i bought it. Touches, gravity, compass, camera, etc.

Now Connectivity will be essential if i ever want to make a real app but I’m not sure TLL intends codea to be something you make real apps with, as opposed to prototypes (Mark, with spritely, and Andrew with his libraries surprised me in that sense though).

Happy new year all!

You’re a mathematician, Andrew - I’m just suggesting that solving for the general case (if possible) is usually more useful than solving for the specific.

Absolutely. I’d be happy with low-level stuff. After all, we only needed the image stuff and we got fonts as a by product. But I feel that I need something that is going to be better than working pixel by pixel.

As for using Codea, it is (for me) very definitely the “end product”. I’m not a programmer, but I often want to show something little visually - take the Borromean rings example from my cube project. That’s what I want to use Codea for.

re. Pixel-by-pixel - yes, agree 100%. SetContext replaces pixel-by-pixel 90% ( again, a fast flood fill would be a happy thing). The bit lib in 5.2 will help there a bit (HA!), and I honestly think GLSL will let us do insanely fast graphic manipulations (my os x screensaver is Conway’s Life in GLSL). I note those are both very general solutions that will apply to a range of things (I’m still learning about GLSL and it continues to astound me - it’s one of those tools where new, totally unintendeduses just pop out)

As for “… I’m not sure TLL intends Codea to be something you make real apps with” - heh, too late for that! All “we need this feature” chat aside, it’s already there - you can (and people do) make real, useful software in Codea, real “apps”. They’re being posted here - and many of the apps posted here are as good as (read “better than” the app store in terms of quality. We’re just limited in scope, thats all - we have a really neat tool here we want to use for other stuff. Was TLL Intending for us to want to write “real apps” - I think so, they’ve already talked about open-sourcing the back-end and libraries sowe can wrap em up and put them in the app store ourselves. And if the ability to make “real apps” isnt their intent - time to convince them otherwise!

But I don’t think that’s the case - I think they’d love to give us all of the functionality they can - it’s just that all takes time and work, so we talk about what comes first. I’d rather see building blocks than castles - low level stuff we can build from. Others (I think those feeling less constrained by current API availability) reasonably want higher level stuff, as labor savers or performance enhances.

One other note, just to be clear: I keep talking sockets, but they’re done - they’re in the beta. I didn’t do the work, but I suspect it was straightforward, and they work dandy - the problem is, Apple may not want us to have them to protect their business model, sigh. I want to write awesome stuff with sockets (check) and share it (nogo, because the release doesn’t support them now and may not anytime soon). And that’s crazy frustrating - I don’t want to sink a ton of time into an irc client (for example) that I can’t share. (would want good keyboard for that too). Point being - when I want connectivity, the work involved there is not technical, it’s political, and unfortunately largely out of TLLs hands, or we’d have it already. And more to the point, is unlikely to bump other Codea enhancements.

I’ve posted separately about file io - that’s another bit I expect would be straightforward to implement but be really useful in a variety of ways.

At the top of my list would be standard text that could be cut/paste out of an app. This would aid end user translation. It would be great if we could use our custom fonts but have a method where we could populate the string of text so that it could be cut and pasted as well.

Indeed - being able to select and copy output would be a good thing. It’s not all graphics! :slight_smile:

I thought that you could cut and paste the output of print statements.

True, I was thinking fullscreen/using some of the community created fonts.

You can??? Ok - that’s good then. something is better than what I thought we had. I habitually don’t use print() because I’v managed to hang myself too many times by putting it into a deeply nested loop.