I have noticed that several recent beta versions have been causing some projects to become extremely slow, whereas they used to run at a normal speed. I am not sure what has changed. Are there any friends who have encountered a similar situation?
For instance, the project named ‘shooter’ is available for download on WebRepo, or you can choose to download it directly from the link provided here (if you haven’t installed WebRepo, although I highly recommend that you do). However, the issue with the slow running speed of the ‘shooter’ project did not start with the latest version; it appeared in a previous version.
I am not certain which version it was; I had originally planned to pinpoint the exact issue but was delayed by other matters. Today, after updating the version, I found that it is still running slow. Shooter.zip (3.7 MB)
@binaryblues - loaded latest version Codea and Shooter, made the mods you suggested and ran Shooter. Did seem a little jerky. Pulled across the parameter window and it fired up loads of error advice, notably that addressing assets with “Documents:Mysprite” isn’t viable now. This error was accumulated to the max then it stops displaying but probably still sees the errors. I think that could be the problem. After looking at the code I saw several sprite(Project:etc…) lines in the code.
@Bri_G Thank you for the reminder. I also have some doubts that the issue lies with the asset processing prompts. However, these prompts have not affected the project’s running speed in the past, which is why I did not modify them. It seems it is time to start making changes.
In another project, the speed has become intolerably slow. That project also has a large amount of old code for asset processing that needs to be updated.
i had a similar issue in a recent thread. Accessing assets is now considerably slower than before. If you have a loop in which you access the same asset you should access it once outside the loop and save to a variable and then access that variable in the loop. Similarly in the draw you should preload the asset to a variable and refer to that variable in the draw.
@piinthesky@binaryblues - I raised a question recently in the forum asking what was the best way of addressing assets for Codea, whether to use an asset path in a sprite() function call or whether to use readImage() or even a tabled array of addresses. It obviously depends on the number of assets you wish to call on, where they are stored and the frequency that you call them on.
I tend to use a couple of methods namely
Defining a variable like. Pic = asset.documents.canines.alsatian
Or in an array like
dogs = {
asset.documents.canines.alsatian,
asset.documents.canines.pug,
…. Etc
}
That condenses the code, keeps them in a single page so they are easy to edit and reduces code clutter.
What I was trying to find out is is it better to use
Defining a variable like - Pic = readImage( asset.documents.canines.alsatian)
Or in an array like -
dogs = {
Alsatian = readImage(asset. documents.canines.alsatian),
pug = readImage(asset. documents.canines.alsatian),
…. Etc
}
The latter I would expect to be faster as each image is loaded when defined, but could conceivably gobble up memory.
P.s. I’ve been all the way through Shooter and changed the addressing to update it but ran into a problem with concatenation see below
@piinthesky Thank you for the reminder. It seems that everyone has to face this issue. The problem I am facing now is that there is a lot of old code that needs to be modified. For the newly added parts that use assets, I will refer to the experience you have provided to write them. @Bri_G Thank you for providing the issue localization. I have also seen this piece of code, and the alternative solution I have in mind is as follows:
@sim Thank you very much, you have saved at least half of my projects!!!
I am currently trying to identify the cause of the extreme slowness in the other half of my projects, and I hope that I can find it.
@sim the slowdown is no joke though, it’s bad. Like, bad. The following code used to run 200 times instantly:
function createSphere(x,z,size,type,r,g,b,xv,zv)
sphere1=scene:entity()
sphere1.model = craft.model.icosphere(size,1)
sphere1.position=vec3(x,1,z)
sphere1.material = craft.material(asset.builtin.Materials.Specular)
sphere1.material.diffuse=color(r,g,b)
table.insert(tab,{ent=sphere1,xv=xv,zv=zv,size=size,type=type})
end
…and in fact it still runs instantly if you comment out the part with the icosphere.
But with that part left in, doing this 200 times takes around 38 seconds. That may not sound like a lot of time, but if you’re looking at a blank screen it’s a lot.
If possible, you could pass the material into the createSphere function so that you can load it once, outside the loop.
That said, I wonder if optimising from reading asset keys from the builtin libraries might be worthwhile (these are the only ones where we can guarantee no one else is touching the asset file)