Showing posts with label tools. Show all posts
Showing posts with label tools. Show all posts

Friday, September 20, 2013

Closure

Lua and Javascript are surprisingly similar languages, as I was happy to learn (coming from a Javascript background). Both of them are very loose in handling data types, don't require classes, and have a nice feature called closure. That's by no means an exhaustive list of similarities, of course. However, today I thought I'd write about some differences in how each of them handles closure. Take a look at the two code samples below:

Lua:
 
function main()
    local printFunctions={}
    local i,j
    for i=1,10 do
        local printi = function()
            print(i)
        end
        printFunctions[i]=printi
    end
    for j=1,10 do
        printFunctions[j]()
    end
end

main()

Javascript:
function main()
{
    var printFunctions=[]
    var i,j
    for(i=0;i<10;i++)
    {
        var printi = function()
        {
            console.log(i);
        }
        printFunctions[i]=printi
    }
    for(j=0;j<10;j++)
    {
        printFunctions[j]()
    }
}

main()

Both of these would appear to be identical. They create 10 functions which simply print the value of i. Then, each of the functions is called. You would expect the result to be "0 1 2 3 4 5 6 7 8 9," right? That's correct in Lua, but not for Javascript. Javascript prints "10 10 10 10 10 10 10 10 10 10."

UPDATE:
The following explanation is not accurate. See this Stack Overflow question for details.

Inaccurate explanation:
So why does this occur? It occurs because Lua and Javascript handle closure in different ways. Lua treats the closure as part of the function reference itself (see this reference), and therefore each time you create a function reference you get a new copy of the variable. The function is created 10 times, with i having values from 0 to 9 during those initializations, and therefore the numbers 0 to 9 are printed.

Javascript, on the other hand, creates a closure based on the variable declarations (see this reference). Since i was declared in the main function, i can only have one value for each time the main function was called. The main function was only called once, so i has only one value, and that value is 10 at the point when the functions are called.

Perhaps this is better explained with another example. What if we changed the anonymous function to print j instead of i? In Lua, nil is printed 10 times because at the point where the function is declared, j is nil. By contrast, in Javascript, the numbers 0 through 9 are printed, because at the point where the function is called, the j from the main function ranges from 0 to 9.

Hopefully that was helpful to anybody else familiar with Javascript and trying to learn Lua. If anybody else has a better way of explaining the difference, please feel free to leave a comment.

Useful Tools and Thank Yous

Now, I know that my Credits blog post already thanks all the groups who helped make Flight Odyssey possible. However, that was kind of cold and legal, so I'd like to take this opportunity to talk a little bit about each of the services that were most helpful. The purpose is twofold: first, to give out some well-deserved credit, and second, to help other developers who are trying to build apps without a huge infrastructure of support.

Let's start off with Clker.com, one of the most crucial resources in my search for images. Clker.com provides clipart/vector images licensed under CC0 (effectively public domain). It has a huge variety of images, and the price is right! The majority of my images come from this website, so I am incredibly grateful.

That said, let me point out a few caveats that may be of aid to other developers. First of all, the search engine built-in to Clker.com is pretty awful. My recommendation is to just use Google Images, but limit the search to Clker.com using the advanced search options. The other major issue is the ads. When I initially found Clker.com, I was using Chrome AdBlock, so I didn't realize that this was a problem. However, as soon as I switched to Firefox, I suddenly realized the website's ulterior motive in providing this great public service: lots of ads! (In fact, I was so surprised by the ads that at first I though they were being inserted by a virus on my computer.) Related to this is the fact that many images on Clker.com are actually downloaded from openclipart.org, so it may pay to try that site as well and see which you prefer.

Next, Bitbucket. I hate to admit it, but this is my first project where I've used a formal version control system. I can assure you wholeheartedly that I will be using it for my next project as well. At least once or twice I was spared from hours of work by a backup in Bitbucket, and several times the reassurance that the backup was there let me be more aggressive in making changes. To put it bluntly, version control is awesome, and Bitbucket implements it really nicely. Not only do the provide you with free private repositories for up to 5 users, they also have a nice GUI (SourceTree), a decent issue tracking system, and everything you would expect out of a paid Version Control system (despite being free). One caveat: they don't have an official mobile app or a mobile-friendly website (helpful things when testing on devices and reporting issues), but BitBeaker is an Android app which interfaces through their REST API and works nearly as well as an official app would.

TexturePacker logoAnother major issue I've faced in my project is performance. Some performance issues, of course, are related to memory consumption, while others are more complex. One tool, though, that I believe has greatly improved Flight Odyssey's performance is TexturePacker. I first discovered TexturePacker when I read this article/video. Just like Corona SDK, that video made some pretty bold claims about the performance benefits of TexturePacker, but they appear to be true. I'll admit I was skeptical at first, particularly when the initial impact of the software was to increase texture memory usage by a factor of 6 (since all images had to be loaded, not just the ones in use). Nonetheless, when I ran my app on a device, performance appeared to have dramatically improved. I still don't really know how that worked, but I suppose the theories presented in the video must be accurate. Not only does TexturePacker improve performance, it also provides a better way of organizing sprites, unlocks several features of Corona SDK that are only available with sprite sheets (like easy animations), and can decrease the size of the app. The biggest drawback is that it costs $40 to get the full version. Fortunately, you can use the essential mode for free (though it lacks some of the optimizations) and bloggers/framework developers can get a free license for the full version.

Some other helpful tools include GIMP (a great way to fine-tune the free clip art from Clker.com for a specific purpose), Paint.NET (like GIMP but lighter weight), ImageAlpha (for image compression), and Notepad++ (once I discovered that you can create a workspace in the sidebar, I never had to use another text editor).

Built with Corona SDK And of course, this list could never be complete without Corona SDK. I've mentioned before how impressive it is, to the extent that it inspired me to create this app, but it can't hurt to repeat it.

That's all, and thanks for reading! If you would like to suggest any other helpful tools for independent game development, feel free to leave comments!