Re: stroke alpha. In my tests, stroke alpha is respected. When I set the stroke to 255,0,0,0 (transparent red) I see a tiny amount of red fringing around the shape. This is caused by the anti-aliasing, which is applied either side of the stroke line. As it fades from the fill color to the stroke color, some red becomes visible before the color becomes totally transparent. If the stroke width is very thin, it’s possible this fringing could resemble a stroke. You can adjust the thickness of the anti-aliasing in the shader. It’s supposed to be a pixel or less (ie only really in effect when the line is not axis-aligned). I think I’ve got it to the lowest it can be, and still be having an effect. When I worked on the wireframe shader I found out about a way to precisely control line thickness (using the GLES standard derivatives extensions), but I haven’t got round yet to trying to apply this o the rounded rect stroke/ aliasing.
Re your latest code: the program now makes much more sense when you’re using it (ie button positions are remembered between launches, functionality is retained). One thing I noticed: there’s some kind of artefact that stays on screen after the welcome button disappears (it looks like it’s that button’s blurred background image?)
Secondly, regarding performance, it looks as if you’re defining a closure for each button 60 times a second. I imagine that this is a bad idea, performance wise, based on stuff I’ve read, eg http://lua-users.org/wiki/OptimisationCodingTips
Memory allocation from the heap–e.g. repeatedly creating tables or closures–can slow things down.
It might be worth checking FPS and memory-usage.
Again, I don’t think ellipse
is the model to go for with buttons, as they need to have logic attached to them, which should happen in a setup phase. I think you need a 2 or 3 part structure: define the button once (callback is attached here), draw the button, test for button touches. I suppose the model I was thinking of when creating Soda was less ellipse
and more parameter
, tween
, http.request
etc, anything where a callback is attached at the initiation stage.
In terms of blur crashing the project when you were using the small images, was there a particular reason to be creating the blur every frame? ie, is it because the background under the button is moving? If not, just do it once, and cache it. Soda only redoes the blur when the orientation changes. Now that Soda has a draggable window option, I suppose I should also get it to redo the blur once the window is dropped (and think about live updating as it’s being dragged I suppose). Were you defining a new image
every frame as well? That would certainly crash the project, as it’s very memory intensive. Again, you need to have a once-only button setup where the image is defined, then just reuse that same image each frame. I’m not sure that setContext
is expensive, but creating new images definitely is.
If you do want to have live updating of blurriness (ie if the underlying scene is moving a lot), then the approach you have here is probably best, one blurred image for the entire backdrop, and then passing in texCoords for each panel.