@Simeon Just loaded the newest beta. I couldn’t get Codea to crash by inserting code at the last line. Also, my second Dropbox folder doesn’t show anymore. So it looks like those 2 bugs are fixed.
@Simeon Sorry for putting the Beta discussions under Bugs instead of the Beta category. I switched them to Beta so the normal users won’t see them.
That’s ok, I don’t really mind either way.
@Simeon I expirience an editor-scrolling issue when pasting big chunks of code.
This is especially annoing when bluetooth keybord is connected.
To replicate the bug:
- create a new tab
- select everything (CMD+A) and paste code from clipboard (CMD+V)
- try immediately to scroll - it’s not working.
When showing you tap the “eject” button on the bluetooth keyboard to display the software keyboard and tap it again to hide it – the scrolling works again.
When not using bluetooth keyboard, just hide the software keyboard and you can scroll again.
Hi y’all,
Very excited to see the new betas and am looking forward to new features!
With all of the current slew of betas I’m getting memory issues that I don’t get with the normal Codea.
On my iPad 4, the following code crashes at around 100 images. Commenting the line table.remove (as below) makes no difference as to an eventual crash. Taking out the sprite line means that it goes on essentially for ever (I’m running it to over 1000 images with no problem). So I think it’s to do with transferring the images to the GPU and the memory not getting cleared.
function setup()
images = {}
for i=1,66 do
table.insert(images,image(WIDTH,HEIGHT))
end
frame = 0
parameter.watch("#images")
parameter.watch("frame")
end
function draw()
frame = frame + 1
if frame%2 == 0 then
-- table.remove(images)
table.insert(images,image(WIDTH,HEIGHT))
end
sprite(images[#images])
end
Obviously, this is a test script. I noticed the crash in my Penrose Tiling program which does quite a lot with images and meshes, but that’s quite a big project to share to demonstrate the problem.
@se24vad I’ll give that a test
@LoopSpace thanks so much for the memory code, I’ll run it through the instrumentation and see what’s happening.
@LoopSpace I looked into your use case and think it might be necessary for you to manually call collectgarbage() during your draw loop, because Lua won’t call it soon enough and you may be holding onto unnecessary image references.
You are right that calling sprite increases the memory usage. From what I can see iOS is compressing memory when you create blank images with image(WIDTH, HEIGHT) — we allocate about 9 MB of 0s at this point (about the size of a bitmap for a retina iPad screen). But the instrumentation is showing almost no additional memory usage — it is likely that iOS is compressing these regions of memory until they are actually used.
When you call sprite on each image you are forcing a texture to be created from the bitmap data. That texture is then attached to the image in case it needs to be rendered again. iOS memory compression no longer applies and you have a large image in memory.
The reason we don’t ditch the texture attached to the image is that it is expensive to create if you want to render that image again. We don’t know if or when your code will render a particular image, and so it is kept around.
One way to ditch the texture data for a given image would be to copy it (image:copy()), release the reference to the original image, then collectgarbage. The copied image will not have been rendered yet and will not have a GPU texture created.