I have noticed certain objects like ellipses and circles do not appear to be displayed in retina resolution. I don’t know if it’s just me, but is anyone else experiencing this?
By the way, I can only see the difference when looking at the edges of circles on the background.
@dave1707 No. On the smooth() sprite, I can still tell where the edges are on the pixels. On the O, I can’t. Tomorrow, I’ll make a picture comparing the two.
@dave1707 Open this image in a new tab in Safari, and zoom in. If you compare the top of the noSmooth sprite’s head to the ) in the text above him, you can see a big difference.
@SkyTheCoder When I look at the noSmooth sprite, what I see are the individual pixels that make up the sprite. Apparently the text isn’t affected by the smooth/noSmooth commands. I’ll have to verify that when I have more time. From what I see, the sprite images are shown correctly. The noSmooth shows each pixel the way they are, and shows a sharp image. The smooth shows the pixels averaged out with the pixels around it which makes for a softer image. The only way you really see the difference is if you magnify the image. I posted a magnify program a while ago. I’ll look for it tomorrow and see what it shows.
@dave1707 A magnifying program won’t do any good, because it’s Codea that’s not sizing it properly. Look at the O on your virtual keyboard, and notice how hi-res it is. Then look at a noSmooth sprite, and notice how you can see each pixel (which you couldn’t on the keyboard).
@SkyTheCoder The O on the virtual keyboard isn’t more hi-res than the sprite. The pixels are the same resolution for both of them. The O looks hi-res because it’s Smooth. If you magnify it, you’ll see that there are pixels between the black and white that are an averaged between the two of them. A noSmooth sprite doesn’t average those pixels, so a black pixel next to a white pixel will be just that, a black pixel next to a white one. On a Smooth sprite, there won’t be a black pixel next to a white one. There will be an averaged pixel between them. So that’s why you can see the pixel difference on a noSmooth sprite but you don’t see the pixel difference on a Smooth sprite, unless you use a 10x lupe and magnify the screen.
@SkyTheCoder Here are two displays, one smooth and the other not. If I look at these two images with a 10x lupe, I can clearly see the difference between them. But without the 10x lupe, the smooth image is just a little fuzzy compared to the noSmooth one. This is on a retina display. I’m not sure what you’re seeing that it’s not pixel per pixel. If I try this on my iPad 1, I can’t see a difference between the two using the 10x lupe.
function draw()
background(255)
smooth()
stroke(255,0,0)
strokeWidth(2)
line(0,600,WIDTH,600)
sprite("Planet Cute:Character Boy",WIDTH/2,600)
text("(smooth setting) line smooth, sprite smooth",WIDTH/2,650)
noSmooth()
stroke(255,0,0)
strokeWidth(2)
line(0,400,WIDTH,400)
sprite("Planet Cute:Character Boy",WIDTH/2,400)
text("(noSmooth setting) line sharp, sprite sharp",WIDTH/2,450)
end
@SkyTheCoder The screen resolution for a retina display is 2048x1536. Something drawn as “smooth” and “noSmooth” are drawn with the same resolution. Something drawn with “noSmooth” will have a sharp edge, or a jagged edge if drawn at an angle. Something drawn with “smooth” will have an averaged edge so it won’t look jagged. If I look at the O on the keyboard with a 10x lupe, I can see the lighter pixels next to the black pixels, so to the eye, you won’t see the jagged edge. Run the code below. The small O and the large O are the same. On the larger O, you can see where lighter pixels were placed to make it look smooth.
supportedOrientations(LANDSCAPE_ANY)
function setup()
img=image(WIDTH,HEIGHT)
setContext(img)
background(255)
fill(0)
text("O",WIDTH/2,HEIGHT/2)
setContext()
end
function draw()
sprite(img,WIDTH/2,HEIGHT/2,20000)
text("O",WIDTH/2,HEIGHT/2)
end
@YoloSwag The edges of objects aren’t sharp. They tend to blend as they go from the background color to the image color. It’s done in about 2-3 pixels. Is that what you’re referring to. I drew a white circle and checked each pixel across the diameter of the circle including the 1/2 positions (retina display) and each one had a value of 255,255,255,255 (white) except for the few pixels at the edges.
It does antialiasing with the standard drawing functions like lines and circles etc. This makes the edges fuzzy as described by @dave1707 it’s also somewhat expensive CPU wise. From memory I think there’s a thing you can set like noSmooth() or something which will blat them down pixel wise with no anti aliasing.
I’ve used noSmooth for lines in the past, but I would assume it affects the drawing of all primitives, but I could well be wrong.
I’ve noticed some odd things with retina devices. For example, if you turn off smoothing (noSmooth()), and sprite() an image (“Planet Cute:Character Boy”) with no size parameters, it SHOULD display pixel-for-pixel, right? No. You can very clearly see the pixels, obviously not normally sized. I’m not sure how it looks on non-retina, but it looks terrible on retina.
@spacemonkey I believe noSmooth apples to all primitives, but it can be enabled/disabled in between drawing, i.e.
noSmooth()
rect(200, 200, 100, 100) -- Crisp square
smooth()
ellipse(400, 400, 200, 200) -- Anti-aliased circle
@SkyTheCoder I believe apples should be smooth as a primitive standard :-" also I do experience smoothing on my retina iPad with noSmooth set.
@dave1708 You’re proving my point. What I said is that sprite pixels aren’t the same as a screen pixel.
I know what vector graphics are. But the fact that the vector graphic’s pixels are high resolution than the PNG’s shows there are more pixels on the screen than the sprite is using (2-4 real pixels for 1 pixel on a sprite)
@SkyTheCoder I haven’t looked at the details of the sprite files yet, but I think the sprites marked as Retina do a 1 to 1 pixel move. I’ll check on that the next time I’m on a PC.
One other thing I think is happening. When a sprite is drawn, 1 pixel of the sprite is drawing 4 pixels (2x2) on the screen. If I create an img=image(size,size) and do an img:set(100,100,0,0,0), I end up with 4 pixels (2x2) on the screen. The text command might be using the 1/2 values and only drawing 1 pixel which would make it a lot sharper. Of course without seeing the actual code for the sprite and text commands, I’m only guessing.
@SkyTheCoder This might explain what’s happening. Look at the picture on the right.
http://en.wikipedia.org/wiki/Vector_graphics
@dave1707 Codea prints 1024, 768 (you said 2048, 1536) as the resolution, so it’s obviously not pixel-for-pixel.
If you still don’t believe me, run this:
function draw()
background(255)
noSmooth()
fill(0)
font("HelveticaNeue")
fontSize(72)
text("o", WIDTH / 2 - 24, HEIGHT / 2)
sprite("Planet Cute:Character Boy", WIDTH / 2 + 24, HEIGHT / 2)
end
Compare how pixelated the O is to the sprite.
I think(May be wrong) that fonts are vectors but the sprite you are using is a bitmap which is one reason for the difference.
@SkyTheCoder I agree with @Coder because the “text” command isn’t affected by “smooth” or “noSmooth”. Since you have “noSmooth” set, the sprite will be jagged whereas the text is still very sharp. The WIDTH and HEIGHT values show as 1024 and 768 depending on the rotation of the screen, which is what you said. But on a retina display, there are pixels at the 1/2 values of the screen which doubles the resolution to 2048x1536. If you do a rect command with a size of 1,1 you’ll get a square with 4 pixels, 2 on a side. If you do a “rect” command with a size of .5,.5 you get a square with a size of 1 pixel. If you run the code below, there will be 2 pixels shown at a 45 degree angle to each other. You might need a magnifying glass to see them.
displayMode(FULLSCREEN)
function draw()
background(255)
noSmooth()
fill(0)
rect(100,100,.5,.5)
rect(100.5,100.5,.5,.5)
end