@John - Done.
My sprite pack in my documents folder seems to no longer be in the sprite pack chooser (and not found when I try to access a sprite from it). The files are still there.
(Incidentally, on some update - not this one - I seem to have lost a load of files from my test project.)
I have Codea in “Night mode”, but when the keyboard comes up then it starts in Day Mode very briefly.
Are all the maths functions updated to 64bit? I’ll need to do a bit of investigating, but some equality test that I was doing now fails.
There are several symbols that are now hard to reach that used to be in the +- list. I’ve noticed <, >, and ^ in particular.
Some functions/variables are not in the autocomplete. So far, I’ve noticed ElapsedTime and isRecording.
Re tapping vs dragging, and tapping on the pop-up displays: I think I’m faster with tap-to-display then tap-to-select than hold-to-display then release-to-select. It’s annoying having to wait for the whatsit to display.
Another missing character: #.
I agree that the hold-to-display is a bit annoying. If you would add the default-button do the hold-to-display-view making it focused and show it immediately, then drag to selected another button. And do it the same way with ±x%-button so that + is selected as default for example.
I would also suggest removing animation of opacity of keyboard, since it disturbs the focus.
Is my description understandable?
Bug: selecting a line doesn’t show the keyboard or copy/paste options (unless the keyboard is already visible)
@Andrew_Stacey does your sprite pack have a “.spritepack” extension, or “.assetpack”?
The white keyboard bug is an odd one, I’m still trying to figure out if it’s iOS 7 or my bug.
The math functions will need to be updated for 64 bit — I forgot about those, thank you for the reminder (i.e., functions in math.*). The way it works is as follows:
- Lua is internally 64 bit
- OpenGL remains 32 bit
So anything you fetch from the renderer (viewMatrix, et al) is converted from 32 to 64 bit when is comes into your Lua code. This is a little more expensive than what was happening before, but the tradeoff needed to happen some time. If there is anything fishy going on with maths then please let me know about it.
ElapsedTime and isRecording both autocomplete for me — there may be a case where Codea autocompletes local variables with similar names instead of built-ins. If you can discover such a case it would be good to hear about.
Regarding the extra symbols: I can add them back in, but cluttering the popup could lead to it being less used. So I’m trying to give a lot of thought to what’s included.
@Andrew_Stacey on the tapping vs. holding: the previous version of Codea only had the expression popup appear instantly — which is the same as the new version. None of the other keys had “extra options,” those are additional in this version. So there should be a net gain here (excepting the symbols you are missing).
I’m hesitant to change the behaviour, but I will try reducing the hold delay for the next build so you don’t have to wait as long. Typing speed isn’t the only factor I’m trying to optimise here: consistency with iOS and discoverability are quite important for me as well.
@tnlogy good suggestion and I will give it some thought as well. I’ll have to see how it feels.
On the whole is the editor feeling better for everyone than the previous version? Is autocomplete more helpful? Do the new features such as multi-line comments, inline errors, colour preview make much difference?
Edit: I’m not sure if anyone has noticed this feature but when the circle appears around the text insertion caret it means you can grab the circle and drag to immediately start selecting text. Did anyone discover this?
Okay, I’m beginning to find my way around the new keys. I see what you mean about the +- one being an honest pop-up, so that one is okay (once I get used to the hold-release rather than tap-tap). What’s causing my complaints is that the [], {}, and "" are no longer on that pop-up so take longer to get to. Also, I think that < and > at the least are high-use symbols so should be there. I’m less bothered about # and ^, though they’d be nice. Maybe > and < can go on the = pop-up since they are comparisons.
I also liked that the selection button could start a selection: if I have the cursor at the right point then I don’t want to risk tapping the screen again. And that both ends of the selection could move - though I think I’ll like the current behaviour once I get used to it as I can see distinct advantages.
I’ve just noticed that the comment button -- always inserts the comment at the start of the line, not at the current cursor position. Is that deliberate?
Some positive comments: Yes, I like the new commenting facilities. And I hadn’t noticed that about the circle, but now that you point it out then I like it a lot. Not so bothered about the colour preview (most of my colours are virtual anyway), but quite happy to have it there.
@Andrew_Stacey yes the comment button has two behaviours: at the start or anywhere in a line it toggles the comment on OR off for the whole line. If you are already at the end of a line (one space past the end so the cursor is not at a character boundary) then it adds a comment marker after the end so you are ready to type a comment for that line.
I felt that these were the two behaviours I used the most. The unaccounted for behaviour, commenting a part of an existing line, is something I do much less frequently so that is left to doing manually.
Thanks for all the feedback on symbol keys, I will keep thinking on it.
Thanks for:
- The updated math library works with the code that had previously broken.
- Renaming my sprite pack to an assetpack worked also.
Next on the list:
This isn’t really to do with this update, rather has been around for a while. I find that the video recorded by Codea is a bit “choppy” - not nearly as smooth as when the app is running. That is to say, all looks fine in the app, even when it is recording, but the video itself is a bit jerky.
Works fine. My camera for Infinite 3D heightmap in a thread below, is more shaky, might my rotated vectors getting unaligned faster due to the better precision maybe, or have I had to much coffee?
If you are working with the shader code could you please add a print when the compiler fails, would be appreciated 
Sorry for this one, I don’t know what’s wrong with this chunk: https://www.dropbox.com/s/73fbmn81hyzsdg7/services.lua, but it crash Codea (2.0(5) IPad 2) when:
- I tap on the tab name to display it
- I paste it into a new tab
[edit] a start, varargs crash the app
function fn(...)
end
Sometimes when I tap to select a line, then move the end of the selection, it selects everything from the beginning.
Some issues with setContext: it seems to reset the matrices (or some of them), I don’t think it used to.
Please, please, please can we have z-buffering in setContext.
With regard to the pop-ups, how about they pop-up if I drag upwards on them?
Sorry about the crash @toffer — I will have it fixed next build. It’s great that you’re finding these.
@tnlogy I’ll look at adding a print on compiler fails, or something similar.
@Andrew_Stacey I have looked at z-buffering setContext, our initial attempts did not work. I’ll have to have another go at it.
Regarding the matrix reset, we haven’t touched anything explicitly in setContext, but it might be due to other code changes. I’ll look.
Popups appearing instantly on drag sounds like I good idea, I’ll try it out.
I’d like to get some feedback on a feature I’m considering adding.
Inline shaders
When you make a shader call in Codea, such as shader("Documents:MyShader") your code becomes less shareable.
I was thinking (in particular for the “Copy” option on projects) to automatically in-line any shaders that are not built in. So your code gets re-written with:
shader([[pasted vertex shader]], [[pasted fragment shader]])
Would this be helpful?
@Simeon - I was thinking about writing a quick Lua script that would do that for me yesterday. Yes, that would be super useful since I tend to forget to include the shader in the code.
I’m also wondering: are there any plans for project based assets (not global) and project folders in v2.0, or will that have to wait?
Thanks!
@Zoyt yes there are plans for them, as to whether they will be in version 2.0: that depends on whether you want version 2.0 to come out later or sooner. Either way you’ll have to wait
@Simeon - re inline shaders. I can think of two problems with inlining any shader references. One is that this will create a big mess right in the middle of the code, and secondly, they are often used multiple times, making an even bigger mess.
Better might be to add them at the end, checking first of course that they weren’t already in the code elsewhere.
But I don’t think this is necessary. Even better (and probably much easier for you) would be to provide an option within the Shader Lab to copy the code to the current project, in table form. I prefer this because then the developer sees what goes into his code, and it doesn’t happen “behind his back” when he copies it to export it.