Interesting point @Jmv38. I guess if you have certain accessibility features enabled — such as triple-tap-to-zoom, they will override any apps that use them.
Maybe a four-finger tap then, though that seems a bit much.
.@Simeon - might be easier to just leave it out and take it out of the documentation. You can always implement your own close button if required.
Hello @Simeon. I think the following is a bug in beta 1.5(20):
The in-app reference for ‘buffer’ implies that user-defined buffers can hold data of type ‘float’. However, when I try to set a ‘float’ attribute per vertex using the buffer mechanism, all that seems to be stored/returned is an array of ‘zeroed’ vec3 data.
On the other hand, the in-app reference for ‘buffer.set’ implies that user-defined buffers can not be of type ‘float’.
(Update) The work-around is to use vec2(x, 0) and myAttribute.x when only x is required.
For what it’s worth, I have a couple of apps that use triple-tap to access security settings, so it is being used by other apps.
Not to say it should be.
I am working on a window tool and i get many crashes. I do many edit/run/stop cycles and have the feeling the memory is not correctly cleaned up inbetween, because there is no error but after 5 to 10 cycles i start getting a black screen, and eventually a crash. I have the feeling it is a new behavior, because i always work hat way. Anyone having the same problem?
[edit] i have added collectgarbage() at the beginning of my setup() => not a single crash since.
I saw later that there was a missing popStyle() in my code. I remember another time (months ago) when i had the same kind of problem and i linked that to a missing popStyle() too.
Hello @Simeon. I am experiencing something similar to what @Jmv38 describes above. If I work through my projects, opening them, running them, closing them, I get to a couple where the Viewer is black when run and then Codea crashes. Rerunning Codea, the projects in question then run fine. I will try to experiment to see if I can be more precise about the circumstances.
(Update) I am reasonably confident that it is not project-specific behaviour. I have to open/run/close a large number of projects for the odd behaviour to manifest itself. Most recently, the manifestation was that the Codea home screen stopped rendering any icons for user-created projects (and then Codea crashed).
(Further update) I also tried a large number of run/stop/run cycles with a single project, with no problems - so perhaps it is something to do with open/close/open cycles.
.@mpilgrem @Jmv38 thank you for finding this. I’ll look into it.
.@Jmv38 it’s very strange that collectgarbage() helps with the issue. I’ll check it out.
BUG using saveProjectTab: after modifying part of a tab with string edition, the editor does not work correctly in the edited zone: when i select some characters, it is a different region (some 10 characters before) that is really edited. I have to kill and restart codea to get it right. Closing the project isnt enough.
Btw, how should i implement line breaks? ’
’ works, but should i do ’
\r’ instead? Could it be the cause of the problem?
Hmm I’ve been trying to recreate this crash behaviour on my iPad 3. I spent about 30 minutes opening, running and closing example and user projects over and over again (i.e. going all the way back to the project browser screen each time). I have been unable to get it to happen. I’ll have to try more.
With that code i get the black screen about 1 out of 2, but no crash: https://gist.github.com/JMV38/4752973
There s a way to accelerate or remove the crashes: play with the win.w or.h parameter: the bigger, the more problems. These param are there in the code, win.w=800,win.h=600! With win.w=400 i am ok but win.w=1000 never works. It is clearly a memory problem.
Windows = class()
function Windows:init()
self.window = {}
--<windows>
local name = 'details'
local win = Window({})
self.window[name] = win
win.top = 200
win.left = 800
win.w = 200
win.h = 200
win.name = "details"
win.HEIGHT = 1024
win.WIDTH = 768
win:refresh()
local name = 'console'
local win = Window({})
self.window[name] = win
win.top = 50
win.left = 0
win.w = 800
win.h = 680
win.name = "console"
win.HEIGHT = 1024
win.WIDTH = 768
win:refresh()
--</windows>
end
Ipad1, ios5.1, Lanscape
Oh, i forgot again to join my FPS() class. You heve 2 lines to comment in the main: fps=FPS() in setup and fps:draw() in draw(). Dependencies are good, but not for copy command…
Hello @Simeon. Any news on the ‘black screen bug’? It is really annoying, because since it seems due to multiple images, sprites, setContext, i hesitate in investing time into graphics tools that will not be really usable if they generate mutiple crashes. And i am sure others will have the problem too, it happens too often, when i start using the memory a little bit more than for very simple things.
.@Jmv38 thank you for the sample project — it’s been very helpful. It looks like an OpenGL state bug.
If you tap the sidebar button it will bring your graphics back immediately (or if you rotate the device). So far it doesn’t seem to crash for me, only a black screen, but I’m still experimenting.
It seems to be an issue with setContext(). @John modified its behaviour recently (to allow for outside-of-viewport drawing). So I’ve asked him to look into it.
We’ll still release 1.5, but this looks like it could be a quick bug fix submitted immediately afterwards.
Great!
Hello @Simeon. The following has me scratching my head: on my iPad2, the ‘clock’ seems to increment about a third slower than I would have expected it to, as I understood it to return seconds.
--
-- Relativity
--
function setup()
x, y = WIDTH / 2, HEIGHT / 2
fontSize(128)
fill(222, 182, 32)
end
function draw()
background(0)
local t = string.format("%.1f", os.clock())
text(t, x, y)
end
That’s very strange, especially noticeable if you add ElapsedTime for comparison:
--
-- Relativity
--
function setup()
x, y = WIDTH / 2, HEIGHT / 2
fontSize(128)
fill(222, 182, 32)
end
function draw()
background(0)
local t = string.format("%.1f", os.clock())
local e = string.format("%.1f", ElapsedTime)
text(t, x, y)
text(e, x, y - 150)
end
```
The C code for os.clock() is:
static int os_clock (lua_State *L)
{
lua_pushnumber(L, ((lua_Number)clock())/(lua_Number)CLOCKS_PER_SEC);
return 1;
}
Where CLOCKS_PER_SEC is 1000000. I wonder if iOS C library clock() is a bit different.
Edit: It looks like it is a clock() / iOS issue. I’m guessing CLOCKS_PER_SEC is incorrectly defined for iOS. It also seems like a bad way to get the time, I’m unsure why Lua relies on this method.
The thought that I had, having read around a little, was that the ‘processor time consumed by the programme’ (clock()) might have a complex relationship with elapsed time.
Anyhow, best to put os.clock() to one side and rely on:
-(void) updateElapsedTimeAndDelta
{
NSTimeInterval curTick = [NSDate timeIntervalSinceReferenceDate];
NSTimeInterval delta = curTick - prevTick;
elapsedTime += delta;
[[LuaState sharedInstance] setGlobalNumber:elapsedTime withName:@"ElapsedTime"];
...
prevTick = curTick;
}