.@mpilgrem thank you for all the documentation bugs. I’ve fixed backingMode, pushStyle and zLevel.
point and pointSize — I’ve never liked these functions and always intended to deprecate them.
On the Lua chapter — debug should probably be documented. io.* won’t be documented as it’s unsandboxed by request and a temporary solution, until I can implement a different file access API that is more in line with Codea (i.e. visual pickers and in-editor editing/preview).
I’m wondering wether RETURN should be deprecated. Testing against "
" is probably more sensible. What are your thoughts on this?
.@Xavier setContext doesn’t allocate a z-buffer. I’ll try allocating a z-buffer for setContext in the next build and see how much it affects performance.
.@Simeon Could you consider solving the ‘displayed position is lost when switching from one tab to the other’ problem? This is really annoying when working with various classes, and making step by step improvements, like in my ‘ant’ program. I am surprised to be the only one complaining about that? I loose up to 5% of my time just sliding back again and again to the correct position…
I have been thinking about the new Codea version. Myself, I would prefer if the shaders used in my program were in a tab, just as any other code. Sure, you can reuse shaders, but it is fewer steps to edit the shaders. On the other hand I can load te shaders as strings if I want to.
Also it would be nice if the image data used would be contained in the project so it is easy to share, just copy the project folder and put it on github. No you have to copy shaders, code and sprite data. Well just my thought about the layout.
On deprecation, is that a two stage process: (1) deprecation and (2) eventually, complete removal from the API?
http.get() was deprecated very quickly after its first introduction. Perhaps it is now a candidate for removal in version 1.5?
If pointSize() and point() were never really ‘in’ Codea, perhaps you could go straight to removal? (Their uncertain status has been flagged in past comments on the Forum for some time.)
If RETURN has effectively been deprecated for some time (by not being documented), perhaps it too could just be removed from version 1.5. I do not think it adds anything of use to the API. As long as its removal is clearly announced, anybody who has actually used it (if anybody has) can easily add RETURN = "\ " to their code.
