Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 316 Plugins
- 70 User experience
- 75 Marketplace
- 291 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
In this Discussion
Adding setPixel method to Shape
Armand
Member
Hi,
I'm new to Gideros. After having worked with Marmalade and MoSync, I abandoned them both and now I'm trying my luck with Gideros. I also tried Titanium SDK, by the way, but this is much more complex to use and didn't run as smoothly as Gideros (although it offers many more interfaces to the native APIs and it uses Eclipse, which I like). So far, so good, and after a little less than 2 weeks I'm starting to get up to speed with my next app. By the way, my next app is not a game app, but I still like to try to use Gideros as an SDK. It seems to do pretty well so far :-)
My question is this:
Since I want good-looking and scalable graphics, I synthesize my own buttons and other GUI elements rather than using bitmaps for them. Synthesizing means that you're free to change colors, texts, sizes and whatsoever without having to re-create your bitmaps over and over again, and your app will always fit to whatever resolution your device will have,
For this to look good, I need sub-pixel graphics. Rendering the buttons to huge (4x4) sizes using the standard shape drawing methods and scaling down would probably work fairly well, but for performance and memory reasons I'd prefer direct sub-pixel rendering. Also, this allows for shaded areas, which is much harder otherwise.
Since the Gideros shape drawing methods are only full-pel-based, there is a lot of aliasing at the edges. I noticed anti-aliasing to be a roadmap item, so maybe I can be of some help creating them.
I now have a properly working Lua class that nicely renders the buttons as I want. (With anti-aliased rounded edges and the like.) The basis function for rendering is a draw-horizontal-line method that uses one or more smoothed pixels (using alpha values) at the end of the line. The number of shaded pixels is a parameter. However, to draw individual pixels with a different color or alpha value, one needs to 'close' the current shape and start drawing a new. Since there is no 'drawPixel' method in the Shape class, I made my own:
function HiResShape:setPixel(x, y, color, alpha)
self:setLineStyle(1, color, alpha)
self:beginPath(Shape.EVEN_ODD)
self:moveTo(x, y)
self:lineTo(x, y)
self:endPath()
end
of course, this is really slow - though acceptable at the moment. Furthermore, it seems to have quite a large impact on memory usage, even if I clear() and nil-out the shape after use. However, I can't point-out the exact cause of the memory drain yet, so I'm not really sure about that...
So, the first feature request I have is a relatively simple one: a Shape:drawPixel(x, y, color, alpha) method that is able to set individual pixels, like the Lua function above. This would significantly speed-up my code, while it is a simple and useful addition.
The second feature request would be a drawHLine method that is capable of drawing shaded edges, but this is of a little lower importance.
Once supplied, the next step would to augment it with other shaded (anti-aliased) drawing primitives like polygon, rect, roundedRect, circle or the like. I now have the Lua source code for a number of those, so they can be ported to C for further speed-up.
What would be the possibilities here? For instance, would it be possible to add my own extensions in C/C++-code?
Regards,
Armand.
I'm new to Gideros. After having worked with Marmalade and MoSync, I abandoned them both and now I'm trying my luck with Gideros. I also tried Titanium SDK, by the way, but this is much more complex to use and didn't run as smoothly as Gideros (although it offers many more interfaces to the native APIs and it uses Eclipse, which I like). So far, so good, and after a little less than 2 weeks I'm starting to get up to speed with my next app. By the way, my next app is not a game app, but I still like to try to use Gideros as an SDK. It seems to do pretty well so far :-)
My question is this:
Since I want good-looking and scalable graphics, I synthesize my own buttons and other GUI elements rather than using bitmaps for them. Synthesizing means that you're free to change colors, texts, sizes and whatsoever without having to re-create your bitmaps over and over again, and your app will always fit to whatever resolution your device will have,
For this to look good, I need sub-pixel graphics. Rendering the buttons to huge (4x4) sizes using the standard shape drawing methods and scaling down would probably work fairly well, but for performance and memory reasons I'd prefer direct sub-pixel rendering. Also, this allows for shaded areas, which is much harder otherwise.
Since the Gideros shape drawing methods are only full-pel-based, there is a lot of aliasing at the edges. I noticed anti-aliasing to be a roadmap item, so maybe I can be of some help creating them.
I now have a properly working Lua class that nicely renders the buttons as I want. (With anti-aliased rounded edges and the like.) The basis function for rendering is a draw-horizontal-line method that uses one or more smoothed pixels (using alpha values) at the end of the line. The number of shaded pixels is a parameter. However, to draw individual pixels with a different color or alpha value, one needs to 'close' the current shape and start drawing a new. Since there is no 'drawPixel' method in the Shape class, I made my own:
function HiResShape:setPixel(x, y, color, alpha)
self:setLineStyle(1, color, alpha)
self:beginPath(Shape.EVEN_ODD)
self:moveTo(x, y)
self:lineTo(x, y)
self:endPath()
end
of course, this is really slow - though acceptable at the moment. Furthermore, it seems to have quite a large impact on memory usage, even if I clear() and nil-out the shape after use. However, I can't point-out the exact cause of the memory drain yet, so I'm not really sure about that...
So, the first feature request I have is a relatively simple one: a Shape:drawPixel(x, y, color, alpha) method that is able to set individual pixels, like the Lua function above. This would significantly speed-up my code, while it is a simple and useful addition.
The second feature request would be a drawHLine method that is capable of drawing shaded edges, but this is of a little lower importance.
Once supplied, the next step would to augment it with other shaded (anti-aliased) drawing primitives like polygon, rect, roundedRect, circle or the like. I now have the Lua source code for a number of those, so they can be ported to C for further speed-up.
What would be the possibilities here? For instance, would it be possible to add my own extensions in C/C++-code?
Regards,
Armand.
Comments
one thing you should definitely check out is Mesh class, which allows you to create gradients and in some cases wrap Shape objects for anti alising
Example:
http://giderosmobile.com/forum/discussion/comment/27130#Comment_27130
Additionally there is a Media class plugin in the Labs (http://giderosmobile.com/labs/media) for upgraded members, which allows you to draw images (providing set/get pixels functions and some other drawing functions) and use them as Bitmap images afterwards
Likes: seppsepp
Fragmenter - animated loop machine and IKONOMIKON - the memory game
Thanks for the quick answer! :-)
This class indeed comes very close to what I need. I did encounter it in the documentation but never realized that it was capable of doing roughly what I needed. And since there was no example that highlights its capabilities (or I didn't notice it), I never noticed it running in practice. I now quickly tried the short example from the documentation and it works fine indeed.
The one thing that surprises me, though, is that it won't draw a single horizontal line if all points are on that same line. This is not the same behavior as the Shape class, so it seems, since Shape will draw all pixels included with the LineTo() function. Should not be a big problem, but I thought it was somewhat strange - because inconsistent.
@keszegh
I'll check out widgetCandy after having tried using the Mesh class. Thanks for pointing out.
I'll look into it further and perhaps I'll post an update if I have something remarkable to mention.
Thanks again,
Armand