Saturday, December 20, 2014

C++11 for Math Vector Types

Something about code has been ringing true since I heard of the idea at school: each line of code has a maintenance cost.  Code is rarely never changing.

Come in C++11 and the common issue of dealing with the vector types.  These include position (we have the CGPoint in iOS, skVector3 in SpriteKit, and so forth), size (CGSize), colour (4 either floats or bytes), etc.

What changes between these?  The number of elements, the type of the elements.

What remains constant?  The operations.  Dot product can be used for luminance as it can be used for getting the angle between two vectors.  Even it can be treated as an innate part of matrix multiplication which we use for general transforms in space, such as from RGB to YUV.

In C++11 we can define something very nice, a template with two parameters, a type and a size.  A colour will typically be 3 or 4 components with either a uint8_t or a float as a type.  A position can be 2-4 components and is typically a float but can also be a double.

For the constructor, we can use variadic templates to ensure that 0-N components can be initialized at once.  For example, in a RGBA colour we could initialize just the first 3 components.

Pushing this idea further, we can make a lot of code much simpler.  Consider parsing a range of memory containing an image.  We usually have a stride for the x and y which determines how many bytes until the next x pixel and next y pixel.  X is typically 4 for 32-bit colour and Y is the width of the image times 4.

Imagine we were to store the strides in a vector, then we could dot the stride with the desired pixel position to get the byte offset.  We then have replaced what may appear to be a bunch of semi-random operations all over the code with dot products.

Yes, the example is contrived, and would need some tweaking to be just as efficient - however the point is that all the varied structures described above can be represented using a single structure with a common set of operations.

Consider, my vector for a colour is now defined as: typedef Vector<uint8_t, 4> Colour;

For small hobbyist projects, this is an essential trick to have a rich set of types with relatively little effort.

Update March 1st, 2015 -- Sample code:
#pragma once//


#include <assert.h>
#include <cmath>
#include <initializer_list>
#include <stdlib.h>

template<class T, int N>
class LVector
{
private:
typedef LVector<T, N> _type;
T _d[N];
// Utility so constructor can take N elements
LVector(T*, int) {}
template<typename ... Args>
LVector(T *idx, T v, Args... args)
: LVector(idx+1, args...)
{
assert(idx <= _d);
idx[0] = v;
}
// Utility so swizzle can take N elements
template<int M>
void _swizzle(LVector<T, M> &ref, const int i)
{ assert(i == M); /* Ensure that we have given all params. */ }
template<int M, typename ... Args>
void _swizzle(LVector<T, M> &ref, const int i, const int idx, Args... args)
{
ref._d[i] = (*this)[idx];
_swizzle(ref, i+1, args...);
}
public:
LVector() = default;
LVector(const LVector<T, N>&) = default;
template<typename ... Args>
LVector(T v, Args... args)
: LVector(_d+1, args...)
{
static_assert(N > 0, "Too many elements for size of vector");
_d[0] = v;
}
_type operator+(const _type &a) const
{
_type r;
for (int i=0; i<N; i++)
r._d[i] = _d[i] + a._d[i];
return r;
}
// Swizzle is a common operation to extract vectors.
template<int M, typename ... Args>
LVector<T, M> swizzle(Args... args)
{
LVector<T, M> v;
_swizzle(v, args...);
return v;
}
// Cast to bool (enables operators to work)
operator bool() const
{
for (int i=0; i<N; i++)
{ if (_d[i] != 0) return false; }
return false;
}
// Comparators (we return masks as they may be multiplied + avoid type issues)
_type operator >(const T& a) const
{
_type r;
for (int i=0; i<N; i++)
{ r._d[i] = (_d[i] > a) ? 1 : 0; }
return r;
}
_type operator >=(const T& a) const
{
_type r;
for (int i=0; i<N; i++)
{ r._d[i] = (_d[i] >= a) ? 1 : 0; }
return r;
}
_type operator >(const _type &a) const
{
_type r;
for (int i=0; i<N; i++)
{ r._d[i] = (_d[i] > a._d[i]) ? 1 : 0; }
return r;
}
_type operator <(const T& a) const
{
_type r;
for (int i=0; i<N; i++)
{ r._d[i] = (_d[i] < a) ? 1 : 0; }
return r;
}
_type operator <(const _type &a) const
{
_type r;
for (int i=0; i<N; i++)
{ r._d[i] = (_d[i] < a._d[i]) ? 1 : 0; }
return r;
}
_type operator ==(const _type &a) const
{
_type r;
for (int i=0; i<N; i++)
{ r._d[i] = (_d[i] == a._d[i]) ? 1 : 0; }
return r;
}
// Easy indexing
T &operator[](int i) { return _d[i]; }
operator[](int i) const { return _d[i]; }
// C++11 utilities
static int size() { return N; }
T* begin() { return _d; }
T* end() { return _d+N; }
};


// Useful derived types
typedef LVector<uint8_t, 4> LColour;
typedef LVector<float, 2> LVector2;
typedef LVector<float, 3> LVector3;
typedef LVector<int, 3> LIVector3;


// Common offsets
enum
{
kX = 0,
kY = 1,
kZ = 2,
kW = 3,
kR = 0,
kG = 1,
kB = 2,
kA = 3
};


// Useful derived operations
template<class T, int N>
T abs(const LVector<T, N> &v)
{
T s;
for (int i=0; i<N; i++)
s[i] = abs(v[i]);
return s;
}


template<class T, int N>
T dot(const LVector<T, N> &l, const LVector<T, N> &r)
{
T s;
for (int i=0; i<N; i++)
s += l[i] * r[i];
return s;
}


template<class T, int N>
T max(const LVector<T, N> &l)
{
T s = l[0];
for (int i=1; i<N; i++)
{
if (s < l[i])
s = l[i];
}
return s;

}

Sunday, December 14, 2014

Social Assumptions Regarding Blogs

Often times the obvious just hits me.  Years later.  The obvious, this time, is the social encoding found within blogs.  There is a codified set of assumptions based upon how people will consume content which determine what content creators can do.

Yes.  Painfully obvious, isn't it.  Also, nefarious.

My latest project on this platform has been a short story.  Each post continues on the previous.  I find the exercise to be quite entertaining as it forces me to consider different types of scenarios and also my mind gets bored by the mundane and usual so I've allowed myself to come up with the atypical.  The latest, for example, is a spiral escalator.

Blogger enforces that newer posts appear first.  Is there a problem with that?  Inherently no.  Most blogs follow the right template.  New stuff is awesome, old stuff just gets stuck behind.  For example, product reviews thrive on the new.  Events thrive on the new.  Even documenting technology or how to do something can thrive on the new.

Of course, you could argue that if something isn't new and worthwhile, it will be linked to a million times voer and Google will provide an link to it.  Sure.

Now, the core of the issue - everything is independent.  There is no prescribed reading order.  People just are supposed to jump in at any given point in time and be able to pick up on the information.  What if I want to describe something complex in a linear format over severall posts?  Then I'd have to fight the digital system (as others have) to ensure that posts appear in te desired order, and that the front page would always be the first post.

Or, I could stop being lazy and could include small summaries of the story with each post.  It's all about the person reading the material - after all it's not as though they are starved for content/entertainment.  Even though I'd like whoever (if anyone) who reads that blog to read it in order, I should make it convenient to read from whenever.

That is if I cared about readers.  To me it's a nice platform to simply write.

Discouraging how I've turned around and through a royal meh and passively accepted my fate as a person writing using this service.  (probably since it's free and I don't feel like moving it anywhere else.

Sunday, December 7, 2014

Review of the Lego Big Ben (350 piece) model

Armed with a 20% off coupon, I ended up buying this small set of bricks.  The Whitehouse was the first set I got in the series, and I thoroughly enjoyed building it.  The series itself tends to do clever things with the bricks in sets that aren't too big or expensive (ie. the Parisian Cafe which I'd love to have).

Yes, it is a small model.  Very thin, very small.  And for that size, it has a lot of bricks.  Why?  it's the small detail and that there is very little, if any, empty space within the 3-brick-thick walls.

Most of the model uses bricks that I could find on my spaceships of yore - much of the detail comes from clever brick building.  And that is why I must write a blog post about this model.  I enjoyed following the instructions and building it since it achieved so much detail with so few bricks.  Even though I could tell from the box that they couldn't have built it in many other ways, the person who translated the model into lego did a great job.

It is the latest landmark to exist on my desk.  :)

Saturday, December 6, 2014

The Ire of Perpetual Change in Software

Software is becoming a special beast.  It is ever changing its face.

Just look at the applications that are "cloud" driven.  This is more of accepting the reality that application development has to follow the changes of the landscape (operating system, etc.) and that feature-wise many of these software are more than complete.

Consider Office.  You have styles, bibliography building, rudimentary grammar correction, layout, indexing, cross-referencing and whatnot.  Same features available in LaTeX if you can stomach the scripting.  I would argue that since 2000 the software has been sufficiently feature-complete for my needs and have been relearning to find the same features in reorganized menus since.

Windows is endemic of the problem.  Click advanced properties on a file and you get something reminiscent of Windows 2000.

Arguably, OS X has had no intention of preserving the old.  Yes, there is a new way to launch applications.  There is an updated look.  Updated usability.  A moving target for every piece of software.

If utensils were made by software companies, then each two years we would have a new way to eat.  A new easier way to hold them.  A new easier set of foods.  Something much more fashionable.  All the time.

I have no issue with progress, but do we have to slow down the machine.  Have fewer software developers.  More stability.

May be we don't need to change the user interface of our digital utensils every year.  Maybe once a decade.  Or less.

Yet again, new sells.  And in software that can be expensive.  Is it worth the cost?

Thursday, November 20, 2014

32 to 64 bit for the rest of us

Today I shall discuss the issues that arise when migrating 32 bit code to 64 bit.  Without falling into the typical jargon.

George is a city planner.  He likes to plan out cities and determine who will live where.

There's also the home builder Alan.  He likes building homes for people within cities.

Both have to work together when building new cities.  Alan needs space for his houses.  George needs to know how large Alan's houses will be.

Alan knows there are various types of houses.  Small, medium, and large.  They are 10 square feet, 15 square feet, and 20 square feet in usable floor space respectively.  Then there are the variants, such as a bungalow which takes the same amount of space as a small home and a mansion which takes the same amount of space as a large home.

Sometimes, some of Alan's clients ask him to change a small home for a bungalow, etc.  when this happens, he doesn't have to notify George since the amount of space needed is the same.

For years, the two have happily built houses forming complete cities without a hitch.  Actually, they just copy the same city all over the place.

However, one day, Prime Minister Slim looked at what was being built.  Bungalows, typically lived in by families, should be larger he ascertained.  He saw families squished into their miniature bungalows.  So, he put out a decree, all Bungalows shall be 15 feet, not 10.

For George, this entails he must alter how he plans the layout of his cities.  For Alan, he has a problem.  The interchangeable use of small houses and bungalows means he must inform George of which homes are larger than the initial plan.

And herein lies the problem with going from 32 bit to 64 bit.  The person making the software has made a lot of assumptions that held true for years but are no longer the case.

Sunday, November 2, 2014

SpriteKit and Normal Maps

Since iOS 8 SpriteKit now has some rudimentary lighting capabilities which has been a feature that I wanted for quite a while in a 2D engine.  Below you'll find my thoughts and details related to performance and aesthetics.

First, there are many potential pitfalls that may destroy the frame rate of your application on devices that do not have an A7, or later, chip.  The issues I discuss below tend to only crop up on low end devices.  We will look at batching, the fragment shader, and potential optimizations.

Batching, as I have discovered, can be broken by having various sprites at various angles when a light shines upon them.  As far as I can tell, the issue is that the implementation uses a single uniform to describe the angle of rotation when converting normals from view space to world space.

The fragment shader is hefty.  On older devices, multiple lights can take a significant portion of the time used to render a frame.  My intuition tells me that these devices are having trouble with the branching and looping found within the shader.

As an optimization, one option is to have lights affect as few objects as possible through the light mask.  Another option, which is a bit more extreme, would be to have a custom fragment program that is fine tuned for the number of lights present in the scene.  If you need to go further, then you may find yourself outgrowing SpriteKit and using Unity or a custom engine which tessellates around the image to minimize the number of times the fragment shader is run.  And if you go that far, you might want to consider moving to a deferred pipe where lights are much less expensive, even if the frame rate would be passable at best on the low end devices.

If you are using batching (a folder with a .atlas extension), have a separate atlas for the colour and normal maps.  If you don't, I've noticed SpriteKit generates its own rather than use the provided ones.

Second, aesthetics plays a pivotal role in whether this capability should be used.  My comments are divided between the shadows and the lights.

Shadows are not as expensive as I would expect them to be.  Shadows can be enabled through a mask to ensure only the most important objects are affected.  If you have a series of images that share edges, like a series of blocks piled upon one another, then be careful if there is anti-aliasing in the image since the shadow extends the alpha portion of the image which may lead to weird lines that are undesired (a break in what should be a continuous flat shadow).  Also, be sure to test on device as the algorithm seems to be slightly different. (It might be using the bounding box rather than the silhouette)

In terms of looks, I found that having a few lights led to some interesting results with little effort.  Unfortunately, I believe much more could be done.  What if the light is behind a sprite illuminating but its edges?  At the moment it feels like it's slightly above the sprites thus illuminating them directly.  A light is like a 3D object in this 2D world, limiting it to two axis reduces the number of possible effects.

In the end, SpriteKit introduces a very rudimentary concept of lighting.  It is not sophisticated, but sufficient to add a little extra detail to an application.  On the down side, it is too easy to hit the limits of what the implementation can do and be forced to change technology.

Edited on February 27th, 2015:  edited the text for legibility.  It seems to have been written when I was exhausted, hence barely comprehensible.  Certain details I did not have offhand (how shadows behave on device versus on the Mac), and will fill that in later when I get the chance.  Doesn't deviate from the fact that testing on device is always a good idea.

I have written a quick set of thoughts when SpriteKit first came out.

Sunday, October 19, 2014

The Code Fallacy

Once upon a time, there was a master in the arts of taping things together.  His works were shown in museums all over the world.  To the untrained eye, they may appear as loose balls of duct tape dangling from the ceiling, however they were built in a very particular fashion.

First, the master was given hundreds of strands of tape of various sizes.  Each strand was numbered.  Each numbered strand had to connect to a specific set of other numbered strands.  The master's work, which set him apart from the rest, was his ability to plan out and leave a lot of space between the strands of tape, minimizing the entanglement, and making it possible to easily add or remove connections between pieces of tape as needed.  And there were always changes.

Typically, the master worked at his own pace.  It felt frigid to most, as he'd spend much longer getting his initial ball of tape according to requirements.

One day, the master was asked to make a work and was given a standard set of specifications.  Except he had a month to do it.  He'd normally take three.  However, he had no choice, his secretary had already agreed on his behalf.

So he started planning.  He spent all of his days rather than reserve some time to rest.  By the second week, the locals described him as a zombie, barely aable to articulate himself, always forcing himself to work on the problem with which he was tasked.

By the third week, he had to start building his ball of tape.  As requests for changes would pour in the next day.  Except - has wasn't ready.  His plan had pieces of tape coming too close for comfort, but he had no choice but to continue.  Feeling sick to his stomach as he assembled a work that he, the master of tape, could never be proud of.

Then, the day before, requests for 150 new strands of tape to be added came in.  The ball would comprise of about 1000 strands of tape total.  He worked through the night, as his initial plan was half-baked, and any new piece of tape was frought with peril.  Often, he had to move hundreds of pieces of tape just to add a new one.  And with these changes, the stickiness of the tape waned.  And the master had to resort to using new pieces of tape to ensure the integrity of the old ones.

By morning, when he was done, he looked at his ball of tape, improperly drooping, knowing that it would damage his reputation.  He had done it on time, but it was his worse work.  And when it came to be put up, it looked as though it would collapse.  But it didn't.

The week after, the master got a request to add a few hundred more strands and to remove fifty.  In a day.  He looked at the ball.  He looked at the request, and replied that it couldn't be done.  He would neeed to spend two months to complete his plan and build it correctly.  His rejection was rejected, and was reminded that he must do the changes since if he didn't the museum would go bankrupt for having to refund thtickets to see the ball that it had already sold.

Not wanting the demise of a museum to be his fault, he got to work.  By morning, he still had a dozen strands to put up.  The museum's curator was angru with him, for not completing his work on time.  The museum suffered, as people requested refunds seeing that the ball of tape was not ready for viewing on time.  The master was blamed.

And so things continued for the rest of the contract.  Always having to deal with a ball of tape that should have been thought out more thoroughly, and regretting it untilt he completion of the contract.

The curator and the visitors couldn't tell it was improperly built.  They just saw a ball of tape.  It had all the right connections.  But to the master, it was an abomination.

Henceforth, he ensured that his secretaary nnever agreed to time limits again.  So he may do his work properly and be proud.

----

What does this have to do with software?

The ball of tape is a metaphore for software.  Aggressive schedules always backfire in the long run.  Like the ball of tape, how can you judge how well software is written when you only see a polished interface with an engine forever hidden bedhind it.

Monday, September 15, 2014

Ads within Blogger

Being the good capitalist, I thought to myself, why not have ads at the bottom of the page?  if what the reader reads is interesting, and they read it in totality, I doubt that they'd mind a simple little ad at the bottom of the page.

So it began, going through the simple few clicks to request the permission to put ads on this blog.  Things went as smooth as butter, I must admit.  Within a day it was approved!  All that was left was to agree to the TOS and finalize what would be presented and how.

As you may notice, there are no ads at the bottom.  The TOS has a new frightening set of clauses that I have not yet encountered before.  That of various clauses surviving indefinitely even after use of the service terminates.

Typically, I would see a timeframe on the survival, a few years at most.  And that is on NDAs that I've signed with previous employers.

It may be argued that the ads service is different - that it does offer a way to interact with various entities where abuse would lead to extra money for whoever benefits from placing the ad.  Sure.

However, everything is becoming a service.  Look at Photoshop - you just rent it.  Same for the developer tools from Apple.  Many things that you used to indefinitely license for a single large sum are being rented on a monthly basis.

MMOs, one of gamings rented games, can be abused like Google ads to make money.  These games typically have local economies and some people will pay real money for what others picked up over long periods of play.  Farming for gold pops to mind.  Should a video game have a contract with clauses that indefinitely survive termination?

For legal purposes, it is easy to assume that anything that is done over the Internet is logged.  Every conversation, every photo.  Be it by the state (see the NSA insanity) or by individual providers (wasn't it reddit that said they can't resist handing logs to suits?)...  of course this survival is used to ensure that if something sketchy appears after termination, it can be caught and dealt with.

But back to the issue - can the survival of termination be abused?  Could it ever become a boon years down the road as companies go back to these old contracts and try to find any reason to extract funds from old users?  I'm not implying any company would do this, but the door could very well be opened at some point.

Or so I believe.  Reading these myriad of software EULAs and TOS just bore me to death.  And given I'm not a lawyer, I'm sure I've misread a few as I sometimes read clauses multiple times to understand an English that, since it leaves no room to interpretation, can be quite dense.

But typically these end. Mor can be terminated if I got the gist wrong during the first reading.  This one doesn't forgive.

On a side-note, I can completely understand why no-one reads these things.  They are long, and typically can be summarized as "we are not responsible for anything (nor have any obligation towards you), you are responsible.  Oh, and give us money if it's a paid service!"...

Sunday, September 14, 2014

Aren't games counter productive?

For the longest time, I tried to reign in my desire to play games so I may be productive at other things.  The problem was, no matter how much control I exerted over myself, there was not net increase in productivity.

Then it dawned upon me: I'm a Sim.  There's a progress bar that craves the entertainment provided by video games.  And that bar was empty.

So I binged, and played about 14 hours of a game in two days.  By the end of it, I was fed up, my meter completely filled, I could then do something else such as work on a web comic.  Read, work on a web comic and be happy about it, laughing as the details came together.

It seems that any rhetoric that advocates for anything in the extreme is worrisome.  A balanced life requires play in addition to work.  And work can't proceed as efficiently until neglected needs are satiated.

That's my theory, and I'm sticking to it.  Mainly since it makes me happier.  :)

Thursday, September 11, 2014

Digging a bit further into SpriteKit

A few throw-away prototypes later, and a few things about SpriteKit have become apparent to me.

First -- SpriteKit is highly optimized for image data.  That is -- sprites.  It is very efficient, put your images in a ".atlas" folder and a texture atlas is built reducing your costly draw calls from dozens (or hundreds depending on your app) to one.

Caveat, that is what SpriteKit does best.

As of writing, a text node will defer to core text   Core text will create a texture.  That will be slapped onto, what I guess is, an SKSpriteNode.  Each text element will incur an additional draw call (even if the text is duplicated - each duplicate will make a new texture.  Copying the SKTextNode results in a copy of the texture as well).  For a simple HUD, this is perfectly acceptable.  I dreamt of a text adventure recently, and SpriteKit would need a bitmap font rendered as SKSpriteNodes even though another framework would be just as good.

The other is drawing filled rects.  My best guess is that they are there as placeholders for an actual image-based sprite object.  They too don't batch that well together, which did surprise me.

How to track the draw calls?  Two ways.  One is to do a frame capture while the application is running on device.  The other, which I find more convenient, is to set the "showDrawCount" property of the "SKView" to true.  Turning on that property was an eye opener.

If we return to the colour-based SKSpriteNodes, be sure to give them a separate zPosition so they blend properly with the other nodes.  I have noticed that the drawing order differs when batching becomes possible.

Speaking of "zPosition"; it is safe to assume that each "zPosition" will result in an additional draw call.  The furthest are drawn first in one call, the nearer in subsequent call.  The mental model that I create for myself is that of creating a bin for each "zPositon" and dispatching each bin at the end.

Before making an image for each possible colour combination, tinting does not affect the number of draw calls.  If you were a stubborn person, you could make a white rectangle, create a sprite, and tint it to your heart's desire.

Notice that I have not delved into physics.  None of my little experiments needed (sophisticated) physics so far hence I can't comment on how that part of SpriteKit behaves.

Overall, I'm actually quite happy with SpriteKit.  The caveats I mention are minimal.  Implementing (or finding an implementation of) a bitmap font for SpriteKit is rather trivial with building the font being the time consuming part.  And as mentioned, coloured blocks can be simulated with flat textures.

And, in most real-world use-cases, I would guess that the caveats I mention are neglible.  For example, when will you display 100 SKLabelNodes?  Or do heavy pixelation with 10,000 SKSpriteNodes?

Wednesday, September 10, 2014

Return to Class

It has been over 5 years since I last attended a lecture within a formal class setting.  Lately, some classes in mathematics have gotten my attention, and since I don't care about the degree anymore, why not just sit in and enjoy the show?

There were two classes that I requested to sit in, and the professors were very kind and said I was welcome as long as I didn't add any work.  Fair.

Not caring whether I passed or failed, I opted to go to the more advanced course first.  In this class, the students were silent and respected the professor.  It was also a challenging class, my mind needed to work quite a bit to follow what was being said.

Even though I could follow if I put in the effort, work was looming over me so I conceded and opted to try the lower-level class.  The culture was completely different.  Throughout I heard other students talking, playing games, navigating Facebook, eating lunch, questioning the professor...  (the prof knew his stuff inside out).  There was a sense of boredom, as though similar material has been seen over and over again (set theory is, admittedly, kind of basic -- and certain concepts can be seen in other classes such as linear algebra).  I felt bad for the students who just sat there playing your colour-matching game-du-jour; they would learn just as much sitting outside (it was this high-school-esque forced attendance rather than this "I wish to learn" voluntary attendance.

Then came the stark realization; I'm better off listening to the lectures that are put out by the major universities.  Even though I enjoy having forced times, these past few times I went to the lectures my mind wasn't thinking of math but of algorithms.

And then my thirst for knowledge would follow my work habits and be satiated when my mind is focused on the subject.

Since I don't care about grades.... why not?

Saturday, March 1, 2014

Codea, initial explorations of the iPad IDE

Codea, is, an IDE for the development of multimedia apps, specifically games.  It comes complete with a few images ready for use and has a built in shader editor to prepare visual effects before use in game.  There are some cute little demos, including a simple pixel-art image editor and rudimentary drum machine.

The API itself is often times made as simple as possible.  Images are referred by their string names, and the API handles the loading part.  You just draw with it!  Touch information is stored in a global variable for easy polling.  The game loop is already set up.  And there are plenty of utility shape drawing functions.

The downside is that the API is too simple at times - I could overlook this if the app didn't claim to provide an environment enabling a person to make completely polished games for the App Store.  The simple API is great for prototyping simple interactions.

Consider the simple task of a button.  A button is ubiquitous, it should handle presses and provide appropriate feedback.  Many of the more complex examples shipped with Codea use a button, yet each has its own abstraction.  Spiritely, the pixel art tool, goes just as far as to try to replicate the native iOS feel.  But that is difficult...

Let me explain, when a button is pressed, a typical UI will make it give user feedback.  Like get darker, bevel in, etc.  If the finger wanders off the button, but not off the touchscreen, then no other button should provide feedback.  Imagine that where the finger goes down on a button, all events go back to that button.  Such a feature requires planning, and above all simply reimplementing what's been already done a million times.

Yes, there are multiple interaction paradigms.  The home screen on iOS uses the one described above. 

In the end, if I were creating just the game scene on pong, then Codea would be perfect.  If I wanted menus and more, then maybe I'd want something similar to a rudimentary GUI framework.  Which I provide below.

One last note, the tabs are executed in order.  So a super class should appear before any inheriting classes in the tabs.

In the end, I recommend Codea for prototyping on the go.  Have an idea for something?  Prototype quickly and show it to people right then and there.  No need to lug a mac to fine tune interactions in a game prototype.  It's kind of nice that way,

Below are a series of objects to use in Codea that may prove useful for UI work.  It's in progress, but starting to make my development easier (I'm slowly progressing on it):

XControl = class()

function XControl:init(position, size)
    self.position = position
    self.size = size
    self.parent = nil
    self.children = {}
    self.onDraw = {}
    
    self.pvtxc = {}
end


function XControl:pvtDraw()
    self:draw()
    
    for i,v in ipairs(self.children)
    do
        pushMatrix()
        translate(self.position.x, self.position.y)
        v:pvtDraw()
        
        for ind, drw in ipairs(self.onDraw)
        do
            drw(self)
        end
        
        popMatrix()
    end
end


function XControl:addDrawFn(fn)
    local l = #self.onDraw
    self.onDraw[l] = fn
end


function XControl:draw()
end


function XControl:addChild(inChild)
    inChild:removeFromParent()
    
    local cid = #(self.children)+1
    self.children[cid] = inChild
    inChild.parent = self
    inChild.pvtxc.childId = cid
end


function XControl:removeFromParent()
    if self.parent == nil
    then
        return
    end
    
    local pcid = table.getn(self.parent.children)
    if self.parent.pvtxc.count ~= 1 then
        self.parent.children[self.pvtxc.childId]
            = self.parent.children[pcid]
        self.parent.children[self.pvtxc.childId].pvtxc.childId
            = self.pvtxc.childId
    end
    
    table.remove(self.parent.children)
end


function XControl:pvtGetTouchedControl(pt)
    for i,v in ipairs(self.children)
    do
        if v:isWorldPointWithin(pt)
        then
            return v:pvtGetTouchedControl(pt)
        end
    end
    
    return self
end


function XControl:isPointWithin(pt)
    return (pt.x >= 0 and pt.y >= 0
            and pt.x <= self.size.x
            and pt.y <= self.size.y)
end


function XControl:isWorldPointWithin(pt)
    return self:isPointWithin(self:world2local(pt))
end


function XControl:isTouchWithin(touch)
    return self:isWorldPointWithin(vec2(touch.x, touch.y))
end


function XControl:local2world(v2)
    if self.parent == nil
    then
        return v2 + self.position
    else
        return self.parent:local2world(v2 + self.position)
    end
end


function XControl:world2local(v2)
    if self.parent == nil
    then
        return v2-self.position
    else
        return self.parent:local2world(v2 - self.position)
    end
end


function XControl:pvtOnTouched(touch)

end
And for a button...

XButton = class(XControl)

function XButton:init(position, size)
    XControl.init(self, position, size)
    
    self.onPress = nil
    self.onRelease = nil
    self.onDrag = nil
    self.onTouch = nil
end

function XButton:pvtOnTouched(touch)
    if touch.state == BEGAN and self.onPress ~= nil
    then
        self.onPress(touch)
    end
    
    if touch.state == MOVING and self.onDrag ~= nil
    then
        self.onDrag(touch)
    end
    
    if touch.state == ENDED
    then
        if self.onRelease ~= nil
        then
            self.onRelease(touch)
        end
        
        if self:isTouchWithin(touch) and self.onTouch ~= nil
        then
            self.onTouch(touch)
        end
    end
end