Reasonable Codea 1.4 suggestions

Hello TLL,
I don’t mean to drive you crazy with suggustions, but I just want tI cast in my vote for things coming in the next few updates.

  1. Sprite pack support - At least allow opening .spritepack files that we can make on our computer and eventually create a spritepack creator in Codea.
  2. Sockets - This has been a touchy subject, bet here is my opinion: I think it is allowed. Any other doing apps have it. And Apple is on iLuaBox’s case and wants then to remove many things like the GUI (I don’t know why), but they havent been asked to remove sockets. I noticed that there is just one little chunk of code that you need to include to enable sockets (the socket API is already included in the .ipa file). Apple has only warned you onced about something and about 3 times for iLuaBox. And you won the best app in 2 catagories and you reached staff favorites once, and etc.
  3. Project tagging support
  4. Project info support like name, description, author, icon…
  5. topOfKeyboard() function that returns the top of the keyboard pixel just I case their using a Bluetooth keyboard or split keyboard.
  6. Ability to search the help files.
  7. Ability to read the clipboard
  8. Possibly file IO?
    I really don’t mean to rush anything, nor drive you guys crazy, but I would really like to see these features rolled out sometime soon. Have idea of how to do something interface wise? I’m always happy to help. (Infact I’d love to help.)
    Thanks and no rush at all whatsoever!

Yes, I would like to second more complex file system io to be able to read and write a broader range of data structures.

About file IO, I discovered how to enable it. I’ll put it on my iExplorer hacks page as soon as an can.

Tagging files would be nice. I have 56 projects and th most important a at the end :frowning:

Good suggestions. But I believe that not all features will be done in 1.4 version.
By the way, Sprite pack support is the main feature that interests me.

This is probably too much but I would like to be able to draw dimensions x,y, and z. I feel this could allow us to make more complex games and really open up 3d world.

@Georgian - TLL already has socket support (they just have to insert a few lines of code) and file IO (in fact they purposely got rid of it. I’m fact, I also currently have file IO with a little jack of mine). This seems to be an easy update (If they only add ability to open .spritepack file, not spritepack creators).

@Ldsguy1 - Intresting idea… So basically if we draw farther back in z, it gets smaller? So basically a grid? So we could say something like line(startx,starty,startz,endx,endy,endz)? That sounds fun… I already want ability to open .spritepack files in 1.4

the issues are not just technical - they have to do things Apple will allow. If apple made them pull .codea sharing, do you think they’ll allow sockets at this point?

Having said that - I’d like to see zlib, and encode/decode for png, gif, jpg, and base64. Real spritepack support (which means either grabbing them from the net, or .codea export) would be a reasonable alternative.

@Bortels - Take iLuaBox for example - They had code sharing and such, but that was taken away from them. They’ve had sickets for a while now… And there have been no requests for it to be pulled. For spritepacks, I atleast want to be able to open and email spritepacks. My opinion that many disagree with.

I would like support for data files that have their own editor panes but are not Lua source. The program could use an API to open and read data files as needed, so that data doesn’t have to all be loaded into the Lua interpreter, as is the case with data stored in Lua tables.

Maybe there could be special editors for CSV data, images, sounds, …

I am hoping that Apple will be ok with the downloading of graphics - it shouldn’t be against their policy. if I can write a project where I can say "getSpritePack("")" and it grabs and saves the spritepack for that project - that’ll be a big step in the right direction. Graphics are big, and encoding them and cutting and pasting them isn’t going to scale.

The problem with sockets for Codea is that it opens the door to user written code sharing. Apple won’t care about sockets until they realize that (which be as soon as somein does it), and then they wiil care, so they’ll just pull it. And if they think that someone was trying to slip one by them, then they’ll go straight to the penalty phase.

So the only safe way to add sockets, would be to insure that it can NOT be used for code downloading. And I have no idea how that could be done…

I’d also like access to the stencil buffer for writing sophisticated masking effects

Theres “I want this” and “I want that”. Ill put up a poll for what we want next. That’s a good start @Bortels. The worst we can do is encode code in images (haha). I was hoping for the feature to be able top open a .spritepack file.

I do need a rounded rectangle stencil @Nat. You have a point.

Rounded rectangles are easy with meshes:

function RoundedRectangle(x,y,w,h,s,c)
    if not c then
        c = 0
    if w < 0 then
        x = x + w
        w = -w
    if h < 0 then
        y = y + h
        h = -h
    local rr = mesh()
    local v = {}
    local ce = vec2(x + w/2,y + h/2)
    local n = 4
    local o,dx,dy
    for j = 1,4 do
        dx = 1 - 2*(j%2)
        dy = 1 - 2*(math.floor(j/2)%2)
        o = ce + vec2(dx * (w/2 - s), dy * (h/2 - s))
        if math.floor(c/2^(j-1))%2 == 0 then
    for i = 1,n do
        table.insert(v,o + vec2(dx * s * math.cos((i-1) * math.pi/(2*n)), dy * s * math.sin((i-1) * math.pi/(2*n))))
        table.insert(v,o + vec2(dx * s * math.cos(i * math.pi/(2*n)), dy * s * math.sin(i * math.pi/(2*n))))
        table.insert(v,o + vec2(dx * s,0))
        table.insert(v,o + vec2(dx * s,dy * s))
        table.insert(v,o + vec2(0,dy * s))
        table.insert(v,o + vec2(dx * s,dy * s))
    rr.vertices = v
    rr:addRect(ce.x,ce.y + (h-s)/2,w-2*s,s)
    rr:addRect(ce.x,ce.y - (h-s)/2,w-2*s,s)

The c parameter controls which corners are rounded. To save time, one could render the result to an image and reuse that instead of redoing the mesh each time, however I’ve not noticed any performance hit in this as yet.

(I’d really like a code profiler where I could time bits of the code to see where the slowdowns are and thus where it’s worth thinking about optimisations.)

Ah, just realised that this isn’t what was requested: a stencil is something like a clip?

Okay, ignore the previous post … though maybe one could combine a mesh with an texture from an image to get a generalised clip … hmm …

@Nat, I would love data files separate to lua code. At the moment, encoding data is a pain due to having to wrap it in strings or tables.

I want to talk about Sprite pack.
@Zoyt said: “If they only add ability to open .spritepack file, not spritepack creators” - And if they will not?
I have a great ideea, if they will not add ability to open .spritepack file It is a tragedy.
We have another solution: Add ability to open/import images from Camera Roll.
So, here at Sprite Picker, add a button “Load from Camera Roll” or add a button “Create new SpritePack”.
If the button “Create new SpritePack” is pressed, it will open an SpritePack creator, here will be few forms:
Icon, Name and ability to add images from Camera Roll and then save it.
I have over 100 apps in my iPad and over 70% of apps, not the games, use this function: Load images from Camera Roll.
So, do not tell me, Codea can’t do that.