It looks like you're new here. If you want to get involved, click one of these buttons!
Following code draws no sprite at 500,500 but does draw her at 600,600.
-- imagecopy
function setup()
img = readImage(asset.builtin.Planet_Cute.Character_Princess_Girl)
end
-- This function gets called once every frame
function draw()
-- This sets a dark background color
background(40, 40, 50)
spriteMode(CENTER)
sprite(img, 500,500)
sprite(asset.builtin.Planet_Cute.Character_Princess_Girl,600,600)
stroke(255)
strokeWidth(3)
noFill()
rectMode(CENTER)
rect(600,600,100,100)
end
Comments
OK this is weird. I changed the above program to print(img.width,img.height) and it started to work. Removing the print, it still works. Closing the program, still works.
exiting codea, and it still works. I confess total confusion. Change the sprite referred to, still works. Absolute confusion now.
Worked OK for me the first time. Haven’t noticed any problems with readImage in the past.
OK. This code prints false, false. I believe this means that the result of readImage is all zero. And, of course, so is the copy.
Something is borked with `readImage, but it isn't consistent. My prior example at first did not draw the sprite, then later it did.
Yes, it's weird, Dave. It failed, then worked. And there's no doubt that the shields in Invaders are blank. They are read with readImage and copied with image.copy to get unique copies for each, for individual damage.
An extended version of the same program. Display shown at https://ronjeffries.com/articles/020-dung/01ff/d-17/spritebug.png
I've seen it work, and I've seen it not work. Sometimes with the same darn program. I am confusée.
readImage seems to work, but :copy messes things up. Run the below code as is. It displays the large asteroid. Tap the screen and the cloudy nebula shows. Uncomment the kmg line and run again. Tap the screen and the nebula shows but the asteroid disappears. Uncomment the lmg line and run. When you tap the screen, everything disappears. The print statements show that the kmg and lmg have values when they’re uncommented.
@Simeon looks like there’s a problem.
PS. This appears to work OK with version 3.2.6 (242).
@dave1707 @RonJeffies - I can confirm your observations. Tried to see if viewer.mode and blanking out background() had any effect. Also triedsprites from my documents and Dropbox with no change. But measured spriteSize() and that was consistent, copy seemed to work in those terms but no display of the sprites.
Code below, but - I did notice a flash on the screen just after running the project. Think the sprite routine may be at fault or the download of the sprite data.
@Simeon - 328 (244) wow, that’s what I call rapid service. Now seems to be working well but needs further testing. Thank you.
if it's just copy, why does the checkbits in my example say there are no bits in img?
@RonJeffries - is the result with the code you just posted after updating to 328(244) ?
No, that's 3.2.7 is 3.2.8 on the app store?
@RonJeffries - yes and I've checked out some of your code and mine on it and it works - but we need to check further and make sure poistioning etc is OK.
i'm only seeing 3.2.7 in app store. are you running a beta?
@RonJeffries 3.2.8 is a beta version only available to beta testers.
thot so. i wonder what the bug really is. it'd be nice to know.
@RonJeffries Here’s what was on the comment for the new release.
Fixes image:copy / get / set APIs
does my final example above run on .8? it doesn't seem to be a copy problem. i guess it could be a get problem ...
@RonJeffries Three asteroids were displayed and 2 true printed.
super, thanks! i hope something got added to the automated test suite that's run before all releases.
@RonJeffries sorry about the bug, there were changes (optimisations) made the
image
class for Shade that got merged into Codea's codebase. We've now fixed them in 3.2.8 while maintaining the optimisations from Shade (just preventing unnecessary copies into/out of GPU memory where possible, allowing better use of RAM)Super. I look forward to seeing an updates soon. Optimizations are tricky: my experience is that they break things rather often. The only thing I've found really useful, since I don't really get smarter over time, is automated tests, which are often possible.
Typically our approach is don't optimise unless there's an actual problem.
Unfortunately, that happened with Shade. Very large graphs were not able to load on older devices due to limited RAM, and would just crash. We were able to cut down memory use by 30-40% or so by optimising the image class backing store to reduce copying. Apple should approve 3.2.8 with the fix shortly
Yes, i had no doubt that it was needed. Just lecturing, as is my wont. Thanks!
@Simeon I'm guessing this issue is related to the image copy problem - but saveImage is not working correctly - It just seems to save a completely transparent image. Hopefully solved in 3.2.8
Edit: 3.2.8 just arrived and problem solved. Thanks
Maybe a related issue. I have a simple image as a PNG file. If I use image:copy() the new image is distorted (colour, transparency etc.. not shape). Whereas if I set up a loop to copy every pixel - the result is as it should be. The attached picture shows the original image at the top, a pixel by pixel copy on the left and the image:copy() on the right.
@timber that looks like the copy has a premultiplied alpha channel. I'll look into it
@timber for now, try setting this blendMode prior to rendering your copied version of the image:
@timber oh, actually it looks like the issue is that img:copy fails to copy the
premultiplied
flag of the original image.So on your image copy do the following:
Then Codea will know to render your image with a premultiplied blend mode already set up
I've fixed this for the next version of Codea so that the premultiplied flag is correctly copied on using
image:copy
@Simeon thanks for helping, your suggestion
works for the copied image, but not if you save and subsequently reload the image. See code below:
Tapping the screen saves and reloads the image, the result gets worse and worse - the attached screen prints show initial screen and then 5 iterations later. Maybe the changes you are making solve this too, but thought I should share.
@timber looks like we have an internal, undocumented flag on the
saveImage
function which fixes this behaviourFor now, please use:
saveImage(asset.documents.."test", img, 0)
The
0
at the end tells Codea to save the image assuming it is a premultiplied type. We should be checking thepremultiplied
flag in this case, but it's not and it's a change I will make. (Using1
saves as non-premultiplied, the default.)@timber this will be fixed in 3.2.9 to respect the image premultiply flag on saveImage
@Simeon. Fixed - thanks for your quick response to solving this. Cheers
@dave1707 @Simeon - couple of things in 3.2.8 both may have been there a while.
First tried to record video on a number of projects, including mesh example, when the dialogue for allow don’t allow access to photos/videos popped up, selected don’t allow and Codea crashed.
Secondly the cursor positioning and scrolling when a a selection is being made, while the keyboard is present is problematic - slow dodgy near the keyboard and sometimes scrolls in the wrong direction.