Reasonable Codea 1.4 suggestions

2»

Comments

  • Posts: 9

    I dont know if you guys have seen this.
    Bret Victor - Inventing on Principle.

    A very interesting talk about how design makes us more creative. I noticed his first example has similar ideas to how Codea works, but i would love Codea to have the direct changes like he demos with the tree example.
    A split screen option where you could tweak certain areas of you project on the fly and
    see instant updates.

  • SimeonSimeon Admin Mod
    Posts: 5,054

    I watched it this morning. It's a really fantastic video, and some parts do seem similar to Codea — except he takes the ideas so much further.

    A split screen is interesting, but there are some coding environments that let you code on top of your rendered output (particularly GLSL shader tools). That seems like it might save some screen space on the cramped iPad. If your output was actually rendered in real-time underneath your code (and dimmed slightly to make sure the text is readable).

    The animation editor he shows off later in the video is just incredible.

  • Posts: 9

    Sure an on top option would definitely work, what do you think simeon doable?

  • Posts: 1,255

    How about a slider at the bottom, just right of the standard codea buttons, that lets you change the relative alpha? Slide left, code is perfectly visible / output invisible, slide right output visible / code invisible. And in between you can see both at some relative level.

    Want to make it exceptionally beautiful? Let me execute step-by-step in this mode.

  • Posts: 447

    On top of output would work well for a debugger!

  • Posts: 273

    Oh oh oh I would love a step by step debugger!

  • Posts: 2,820

    Wow... Looks really cool... But I want MANY other things first. By the way, this is why Codea invented parameters. But this show changes and repeat process and other things wouldn't be a bad idea fairy soon...

  • SimeonSimeon Admin Mod
    Posts: 5,054

    @Zoyt that's true- there are plenty of other things to do first, and I have my own UI ideas I'd like to experiment with.

  • Posts: 2,820

    @Simeon - Cool. About UI changes, I'm curious of some images of this you mentioned in the update tracker: • Visual makeover for project area. Thanks! And another thing, I'm not exactly sure what your plan is. I wouldn't mind if you posted a closed discussion with your plans in order from 1 to 10 and how many hours you estimate it to take. Thanks! And I might just decide to use my little file io trick to make something like the split screen option... Hmm.... I have a lot of big projects going on right now though.

  • edited February 2012 Posts: 273

    @nozzy just watched the video. Thank you very much for posting the link here.

    @Simeon I can't wait to see where Codea will be a year from now!

  • Posts: 2,820

    @Blanchot - That's when time traveling comes in handy...

  • BortelsBortels Mod
    Posts: 1,557

    I LOVE @Mark's idea about being able to vary the alpha blend between the editor and the output - and presumably being able to change code on-the-fly and see the render changing as you did it. I suspect it'd be a bear to implement, but woof - it'd be neat.

  • SimeonSimeon Admin Mod
    Posts: 5,054

    @Bortels there are some GLSL live coding demos on YouTube - it's really cool. The code editor sits atop the rendered output. There's some pretty good live coding software out there as well, stuff that highlights the execution of each line as you type.

  • BortelsBortels Mod
    Posts: 1,557

    I have, somewhere, a half-finished pre-text() thing where I made a console (using the atari 800 font), and when you did console() (a print() replacement) it would overlay on the screen, scroll up as you did more, and (never implemented) fade away after a while. So - it would be easy to print debug information for a full-screen app. It frankly became less interesting when text() was added and sockets went away (I was going to make an IRC client as a demo because it's a dirt-simple protocol...)

  • SimeonSimeon Admin Mod
    Posts: 5,054

    I was thinking, it would actually be quite easy to prototype the instant-coding thing in Codea.

    Bret Victor's javascript "book" is actually doing a lot more than just running the code from scratch after every edit. It appears to isolate the particular edit and insert the code back into the running script dynamically. A much harder task. But something that could be explored with loadstring, the keyboard and text rendering.

  • Posts: 273
     I was thinking, it would actually be quite easy to prototype the instant-coding thing in Codea.
    

    I would really love to see something like this... Codea's parameter sliders, as Mr. Zoyt pointed out, allow us to explore our code in a similar 'immediate' fashion. But we can only have so many parameters... and I imagine that much more is possible.

  • Posts: 196

    Heya,

    I couldn't find this mentionned anywhere. I think it could help productivity to add a code snippet interface.
    Typing on the iPad keyboard is somewhat tricky, and any speed gains would be welcome.

    Not sure if this clear, but say you select some part of your code, you can then add it to your "snippets", allowing you to easily reproduce them in any project.
    You press the "snippet" button, select one from the list, and it pops where your cursor is.

  • SimeonSimeon Admin Mod
    Posts: 5,054

    That's a really good suggestion, @Xavier. In my initial design of Codea I had a "code snippet" button on the keyboard that was intended to bring up a popup box of common code chunks. I eventually cut back on it due to time constraints and it became the "+=" button.

    Your suggestion makes me want to revisit it down the line and replace the "+=" button with a more generic one. I already have the icon and design for it.

    One other thought I had for code snippets is to use parameterizable tokens in the inserted code. They might look like <!#LoopCounter#> but Codea renders a nice, touchable highlight over the top of them. Tapping the token lets you instantly replace the text with your parameter.

  • Posts: 2,820

    @Simeon - the += sign really helps me. Can you see if you can change a different one? Thanks. But all this stuff sounds cool.

  • edited March 2012 Posts: 2,820

    @Simeon - I would like to get my final vote in before you choose:

    1. Custom sprite packs.
    2. Project tagging and meta data editing.
    3. More settings for things like the keyboard bar arrangement, show the status bar, or some other stuff.
    4. Search help files.
    5. Select a word and click define to look it up.
    6. Add topOfKeyboard().
    7. Try including sockets and see what Apple does...

    Thanks! No rush!

  • Posts: 146

    I can't find the thread about wait(), but I would like to state that I am all in favor of sich a function. Especially for simulations it is very handy not to have to program a whole infrastructure to re-render an unchanged state of the simluation but rather delay the redraw in order to reduce the frame rate. So, in the spirit of making easy things easy, I would actually like a wait(sec) function, with fractional seconds as an argument.

  • Posts: 159

    @gunnar_z You could do something along these lines to delay your drawing - inside your draw() method:

        counter = counter + DeltaTime
        if counter > Delay then    -- delay is time between updates in seconds
            for i = 1,StepsPerDraw do      -- you can set StepsPerDraw if you want multiple updates per draw
                step()    -- update your simulation
            end
            counter = 0
        end
    
  • Posts: 146

    @frosty yes, that is true, but you would still have to redraw your scene. See my last coroutine example for a case where this would not really work (i.e. requires workarounds)

  • BortelsBortels Mod
    Posts: 1,557

    search.

    I'd kill (or pay) for being able to easily search within a given project for a string (or regexp), among all of my projects for same, or in the help (which would then be expanded to include the standard lua docs).

  • JohnJohn Admin Mod
    Posts: 587

    There are a few things we are looking at in regards to search/replace. The idea was to have some kind of regular expression search with the option to put a lua expression in the replace field which can use captures as variables, as well as context (such as line number, instance counter etc), so you can do simple replacement and also more complex stuff.

  • Posts: 384

    Regex search would be great!

  • BortelsBortels Mod
    Posts: 1,557

    I don't even care about replace - it would be nice, but refactoring is a very large thing. Baby steps.

    I just want to be able to type "myclass." and have it hilight em all. Or search for "table insert" and find the right syntax in the help docs.

  • Posts: 2,820

    Here's my new list:

    1. Search (replace unnecessary).
    2. Project tagging.
    3. Proper project meta editing.
    4. Proper spritepack support.
    5. Custom syntax highlight IAP.
    6. Open source + export to Xcode.
    7. While...Wend loops. It's better than wait(). I took the idea from BASIC.
  • BortelsBortels Mod
    Posts: 1,557

    7 makes absolutely no sense - they are two entirely different things.

    A while loop loops until a condition is met. Lua has them. They're dandy.

    wait() is a delay (and yes, useless in Codea unless TLL monkeyed with it behind the scenes). Codea's model isn't a typical procedural waterfall - it's evented. So a statement that says "sit and do nothing" doesn't make much sense - you want to at least draw the screen.

    What am I missing?

  • Posts: 146

    "redraw the screen again in 0.1 secs instead of 0.017 secs"

    apart from that, I agree, @Zoyt's point 7 seems a bit weird ;)

  • BortelsBortels Mod
    Posts: 1,557

    That would be 10 fps - no, thanks. The draw loop executes as quickly and as often as possible, and that's as it should be. You want 0.1 seconds, look at delta time, and if 0.1 seconds hasn't passed - draw the same thing.

  • Posts: 2,820

    I meant that if we're going to add a wait, I suggest we do a while..wend loop instead. Therefore, you can do something while waiting.

  • BortelsBortels Mod
    Posts: 1,557

    function draw() if (ElapsedTime < 5) then drawTitleScreen() else drawMyApp() end end

    Let draw() be your main loop, young Jedi.

  • Posts: 146

    ok, think of this: you're doing a simulation, like the thing with he grass, the sheep and the wolves. If you're running his at 60 fps, you see basically a blur and your simulation is over. If you are running it at 10 or even 2 fps, you can see what's going on. Now I realize you can do what is basically a busy waiting loop, drawing the same scene over and over again in order to reduce your framerate to the desired limit, thus using resources like battery power basically in vain. Or you could call an OS supplied wait() function(*), that gives he unused time back to the OS, which can then do other things with it, or, if there is nothing to do, just shut down the CPU until it is needed again. Keep in mind, not everyone is using codea to do action games at maximum FPS, and extending the battery life while seeing what is going on is a valid use case.

    However, as TLL have not commented on this, I am quite confident that we will not see something like it, so no need to get all opposed like ;)

    Gunnar

    (*) an alternate solution might be to return an optional number from he draw function which would then be used as a delay until draw() is called next. (read again: optional!)

  • BortelsBortels Mod
    Posts: 1,557

    If things go too fast - delay your timeline.

    You're thinking of the screen as an easel with a pen - you draw, and what you draw is persistent. There is a mode for that sort of thing, but it's not how the codea loop was designed or intended to be used. Think of the screen like a tv screen - every 30th (or thereabouts) of a second, the phosphor beam refreshes the display - to keep a still image, you draw the same thing over and over.

    This seems inefficient - until you realize that by forcing the code to draw everything, you get animation "for free".

    Point is - you need to decouple your animation frame-rate (how fast things move) from the screen refresh, and the problem you describe will disappear. And you want a fast screen refresh rate - at 10 fps, your stuff will be jerky. Film only looks good at 24 fps because there is motion blur and we are used to it - you want to aim at 30 fps or better for smooth updates.

Sign In or Register to comment.