Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
20. July 2015


In this “A Closer Look at”, we will be taking an in-depth look at the Stencyl game engine.  The Closer Look At series is a cross between a preview, review and getting started guide and should help you determine if a game engine is right for you.  Stencyl is a cross platform 2D game engine with tools that run on Windows, Mac and Linux and capable of targeting all of those, plus Flash, Android and iOS.  Stencyl is free to use for the Flash target with additional platforms coming with a fee.  Stencyl provides a high level Lego block type programming experience but coders need not fear, you can drop into code easily if you want.  Amazingly enough, you may find you do not actually want to!


There is an HD video version of this guide available here.



The Editor


Stencyl is a relatively self contained providing almost all of the tooling you need in a single editor.  When you first launch Stencyl this is your initial view of the editor:



It comes with a sample game included and one nice feature of Stencyl is the ability to seamlessly download additional assets from their website including additional examples and editor extensions.  Once you’ve actually created a project you’ve got even better integration with their online store ( misnomer, as everything currently is free ).


The Dashboard is the home page of your game.  The game itself is broken up into Scenes and scenes are composed of Actors, Backgrounds, Fonts, Sounds and Tilesets.  Created resources are available across all scenes. 




Scene/Level Editor

Loading  a Scene brings up the scene editor



The editor has several modes available across the top (Scene, Behaviors, Events, Physics, Atlases and Properties).  The Scene editor (shown above) enables you to paint scenes using tiles for a tileset, or to place your various actors within the world.  The editor supports multiple layers of tiles with various blending modes available.  The tile placement experience is very smooth with functionality you would expect like snapping, flood filling (painting an entire region with a single tile) and grids. There is also support for defining regions, placing physics joints, adding rows and columns of tiles all at once and more.  The ability to paint with multiple textures is also present:



The Tilesets themselves are created as a Tileset resource at the dashboard:





You can then edit each tile in the tileset:


Three things can be set for each tile, a custom piece of metadata that can be access by code (perhaps a text description of the tile), the collision shape for the bounds of the triangle, using either a default shape or defining your own, and finally the frames of animation for animated tiles.  Should you require more precise collisions than the default shapes, you can define your own Collision Bounds:



The Create A Polygon tool is a bit clunky but gets the job done:



Back to the Scene editor, you will notice the next two tabs after Scene are Behaviors and Events:


These are basically the way you “program” your Stencyl game and we will revisit both shortly.  Just remember them for now.  Physics enables you to configure some global level physics properties for you scene:



Atlases are akin to spritesheets in other game engines.  It enables you to bundle like minded resources into a single file to improve performance.  This is more of an implementation detail, so we wont cover it in depth.



Finally Properties enables you to set some critical details of the scene that you otherwise set during creation.



Basically Scene is your game level and Stencyl provides a complete and comprehensive level editor with most of the required tools for placement, physics, etc.  You will notice at this point that Stencyl is highly configured for creation of 2D tile based games and if your game doesn’t fit this description, Stencyl becomes less and less useful.




Next let’s take a look at the Actors interface.  An Actor is basically any game entity that isn’t a tile.  So your main character, your main menu, a high score widget and enemy sprites may all be actors.  As you will see, the interface for actors is remarkably similar to Scenes:



An actor can contain multiple animations, each of which is composed of frames of animation.  You can define as many animations as you desire and each animation you can control the order of frames and the duration that each one lasts.  Animation frames use the same interface as loading a tileset.


You may notice across the top there are several editor options for Actors available as well.



Appearance is the editor you see in the above screenshot were you specify the animations of your Actor.  Behaviors and Events are the programming interface and once again, we will cover those shortly.  Collision enables you to define the collision properties of your Actor:


One unfortunately missing feature is the ability to define a collision shape per frame of your animation.  This means if the collision volume changes massively as your Actor is animated you will either need to split it into separate animation groups or settle for less than accurate collisions.  Hopefully this functionality is added in the future.


The Physics tab enables you to set the Physics properties of your actor:



Note the various sub settings you can set:



This is perhaps the most accessible and least confusing physics integration I have ever seen in a 2D game engine.  Physics properties are often cryptic and simply figuring out what a particular setting does is an exercise in frustration, especially for new game developers.  So bravo for making a complicated subject dead simple.


Finally there is the properties section:



Which contains the button for launching the Collision Group interface:



Collision groups are handy for determining how various groups interface with each other.  For example, a Bullet may collide with Actors, but not other bullets.  One nice feature with Stencyl is the link to help on each topic:



If the purpose of an editor isn’t obvious to you, you can click the How do ____ work button and be brought to a well written help web page.  This should keep newer developers from getting overly lost and encourages exploration.


Programming in Stencyl


As I mentioned earlier in both the Scene and Actor sections, programming is done via Behaviors and Events in Stencyl.  Behaviors can be added to both scenes and actors and each is a distinct thing.  The same is true for events.  If you are coming from another game engine or programming language, Behaviors are analogous to methods or functions and can be re-used ( a scene behavior can be used on several scenes, while an actor behavior can be used across multiple actors ).  There is also a variable type named an Attribute, which can be though of the same way you would consider a property.  If that made no sense think of it this way… a Behavior makes a scene or actor do stuff, while an Event tells a scene or actor that stuff happened while an attribute stores information about stuff.


Programming itself can be accomplished either by using predefined behaviors or by defining your own using a building block type programming interface.  Let’s take a look. 


We can create a simple actor like this one:



We can easily add an instance to our Scene using the Add to Scene button, or by going to the Actors panel in the Scene editor:



Now let’s add some logic to our Actor.  In the Dashboard, select your Actor and choose edit.  Now select Behaviors and you will be greeted with:




Clicking it allows you to select a pre-created Behavior or one you have already defined for your game:



There are several pre-defined behaviors and more you can download from StencylForge.  Let’s add a simple behavior to our Actor.  We simply want to move left and right automatically.  Select Motion->Back and Forth Horizontally



You can then set configurable attributes of that behavior:



Now run your game by hitting Test Game and your actor will move left and right 100 pixels:



So you can add functionality to an Actor as simply as adding a behavior to it and an instance of that actor in your Scene.  Obviously in this case our animation isn’t ideal as it only makes sense when traveling to the left.


Let’s now flip the character if he’s going right.  This means our first programming experience.  We can do this either in the scene or in the character itself, in this case we do it in the Scene.  Edit the Scene, select Events then add a new Event.



First click Add Event, then Basics->When Updating.  These are the three lifecycle stages.  This will create a brick named always that we can then drop other bricks in to program the behavior of our game.  Create the following structure:



This brick will be called every frame.  We check to see if the user is going left (negative) or right(positive), in the case of positive, we scale –100% in width, which is the same as flipping.  Now running the code we see:



You can also bundle together functionality it re-usable components using virtually the same manner with Behaviors



Now one of the coolest features of Stencyl, all this visual programming you’ve been doing… it’s ultimately just a code generator using the Haxe programming language.  Click Preview Code and you can see the code generated behind the scenes:


You can even edit the code using an external editor like Flash Develop or IntelliJ, the process of which I describe here.  This turns Stencyl into a rapid development Haxe/OpenFL code generator and you can define the remaining game logic using a traditional programming interface if you prefer.  You can also extend the Stencyl editor itself (using Java), as well as create new blocks completely, using Haxe.    It’s a good thing this functionality exists too, as it helps make up for one of Stencyl’s biggest flaws… there is no debugger.  You can do Print style output to the log which can be viewed in the Log Viewer, but there is very little debugging functionality (breakpoints, watches, etc ) built in.  You can however debug your code in an external IDE if you are comfortable working in the Haxe language.


Documentation and Community


One of the impressive features of Stencyl is it’s documentation.  Almost none of it is local however, so if you do not have an internet connection you are in trouble.  The Stencylpedia is your starting point for help.



There is also a class reference for Haxe programmers, as well as guides for programming extensions and more.  The quality of the documentation is quite solid, especially the more entry level materials. 


In addition to the Stencylpedia there is StencylForge, a built-in (free) store for downloading behaviors, actors, scenes, sounds and even complete games.



There are a few existing books on Stencyl including Stencyl Essentials and Learning Stencyl 3.1.


There is also an active community forum available here.



The Flaws


Of course no tool is perfect and there are a few negatives to Stencyl.  The first and biggest limitation is it is limited mostly to 2D games with a tileset approach to level design.  If you aren’t creating this style of game Stencyl is probably not the right tool for you.  Perhaps the most glaring flaw with Stencyl is a memory leak that seems to be present.  I often received a message “You have reached 90% of memory usage, please restart”, sometimes quite almost right after loading Stencyl, other times after several hours had passed (it can be fixed though).  There have been a few other times where I wasn’t getting the behavior I expected and had to restart to fix things.  Saving changes is also quite slow and seems to be an all or nothing prospect.  Finally the debugging support is extremely weak.


The Verdict

I came into Stencyl expecting one thing and discovered something much different.  I had fairly low expectations, a simple click and build type experience that while accessible and easy to use, it would ultimately prove to be quite limited.  I was wrong.  Stencyl is certainly accessible, and provides a simple drag and drop visual style of programming experience.  What I was shocked at was the flexibility, wealth of tools included and advanced coding options.  Stencyl is not for everyone; if your game isn’t 2D tile/scene based for example.  However if you are just starting out or even if you are an experienced developer creating a relatively simple game, Stencyl might be the perfect tool for you.


In fact, Stencyl maybe just maybe became my primary recommendation for new developers looking to get started in game development.  It’s an approachable well documented game engine that has a long runway to explore as your skills improve.


The Video


12. March 2015


I absolutely LOVE version 1.0 releases.  Yeah, it’s just a number but it’s a critical number.  One that says “this is no longer just a toy and we are ready to stand behind it!”.  It’s not really the product that changes, but the attitude attached to it.


Well, RoboVM just hit that critical milestone.  What the heck is RoboVM you may be asking, especially if you aren’t a Java/LibGDX developer.  Well, from a game centric perspective, RoboVM is the technology that enables the Java based LibGDX to be run on iOS.  Basically it’s a set of tools that allows you to compile Java code, using the various Java libraries, and have it run on iOS.  If you think “Hey, that sounds a lot like Mono from Xamarin!”.  Well yeah, the Mono VM is basically the same thing for the .NET runtime instead of the Java development stack.


Well anyways, RoboVM just turned one yesterday.  Now one really crappy thing about software turning one is that’s often when they start charging for it.  This is “kinda” the case with RoboVM, but not in a bad way.  Basically you can use it as you use it today free of charge.  There are now some value add and support related options for commercial licenses…


Heck, why don’t I just post the announcement after all…


After months of hard work we are proud to announce our first stable release, RoboVM 1.0! This would not have been possible without the help from our fantastic community who provided feedback, filed issue reports and worked with us to track down bugs. A big THANK YOU to all of the over 2000 beta subscribers!


With the 1.0 release, we hope to grow our community even further. For this reason, we’ll also take a look under the hood of RoboVM today, giving newcomers a bit of insight what RoboVM is, how it works, and what our motivation behind it is. If you want to know more, jump to “What’s RoboVM?”


What’s new?

Many new features and bug fixes went into 1.0:

  • The debugger has received another round of updates. All JDWP functionality is now implemented.
  • Support for RAM disk caches. This can help speed up the compilation and linking process on slow HDDs.
  • Support for HFS+ file compression. All files put into the cache are now compressed, further speeding up the compilation process and reducing the amount of space used for the RoboVM cache.
  • Initial project template and Maven archetype support.
  • A new Eclipse project wizard, using the templates project
  • Support for invoking tools via robovm.xml. We currently support the TextureAtlas tool, with more to come.
  • Cleanup and simplification of Objective-C bindings, see the binding status page
Announcing Commercial Licenses

First off: nothing will change for users of our OSS core! You will continue to be able to create apps without any artificial limitations, free of charge. With our new commercial licenses we add convenience features and support services on top of the OSS core. This will allow us to support our work on the free OSS core and ensure the longevity of the project as a whole.

Our commercial license scale with the size of your business, covering solo developers, startups, SMEs and big enterprises. Depending on your plan, you’ll get access to the following features and services:

  • JDWP compliant debugger for both simulator and on-device debugging
  • Improved crash reporting
  • Private e-mail support, with and without SLA
  • JavaFX support
  • Hotfix support
  • Alpha channel access to new commercial features

Our full pricing information is available at

Over 2000 developers have subscribed to our beta program over the last few months. You have provided invaluable feedback for which we’d like to thank you with more than just words.


All beta users are eligible for a discount of 50% for the solo and startup license tiers (one year subscriptions)! Please sign up for a trial with the e-mail address you used for the beta. We’ll get back to you with a discounted license in the next 14 days!

What’s next?

The 1.0 release marks an important milestone for us. But we are far from being done. We’ll continue with our fast paced releases, with the following features scheduled for the near term future:

  • Improved documentation, users guides and screencasts
  • Intellij IDEA & Android Studio integration, a preliminary Gradle-based plugin is available
  • Interface Builder integration (commercial feature)
  • Support for extensions (dynamic libraries) to enable peripherals like Apple Watch
  • Support for statically linking RoboVM into Objective-C apps


Exciting times ahead! With all of this out of the way, let’s take a look at what’s under the hood of RoboVM.


All told, good news for the LibGDX community and congratulations to RoboVM on the critical release!


17. November 2014


As you may be able to tell from some of my recent posts I’ve been working more and more often on my iPad when it comes to creating pixel graphics.  When working on my PC or Mac I have my trusty Wacom Intuos tablet, but on iPad its obviously a much different beast.  First off, unlike say the Surface Pro, the iPad screen simply isn’t made for working with a tablet, so most of the tablets that are on the market are basically glorified fake fingers.  This however is slowly changing as we will see shortly.


When it comes to choosing an iPad stylus you are given an amazing variety of options, but actually remarkably little in terms of difference.  Essentially what I am saying is, although there are literally hundreds of stylus available, other than ascetics, they are basically 99% identical.  Let’s look at the various types available.


The Fake Finger


As I said earlier, most stylus on the market are basically just a fake fingertip on a stick.  When you go to your local Best Buy, 95% of tablets fit this description.  Here is my trusty virtual finger:



This is a generic Targus stylus, which can be had on Amazon for about $10.  I picked this one because I found it attractive and comfortable to hold.  If you are looking at a stylus and its $20 or under, all of the following probably applies to it.  They will do the deed, but your contact can be best described as… mushy.  Here is the stylus in action:



Let’s just say, high precision work isn’t going to be fun with these.  Basically its about the same as using your finger tip, just without the rest of your hand to get in the way.


The Good

  • Cheap
  • More pen like than using your finger
  • Works on any device with any application

The Bad

  • low precision
  • resistance when dragging on screen can be awful
  • palm on screen gives applications fits.



Personally, I wanted a stylus with a bit more precision, which lead me…


The More Precise Finger


When you want to do highly detailed and sharp lines, a standard stylus is not a great option.  The contact surface is simply too fat and you have to spend a lot of time extremely zoomed in to pull it off.  Fortunately there is an option and it works incredibly well.

The Adonit Jot.  The Jot can be had for about $30, here’s mine:



As you can see, the tip is actually a clear flat disk on a pivot.  As I said earlier, it’s fragile, so you really want to make sure you put the cap on it when not using it.  It’s also magnetized, so it can stick to the side of your device.  I personally find it annoying as hell because it means I have to pull all the change of it before I can use it, and I’m not exaggerating either, the magnet on this thing is stupidly strong…


Here is a typical scene when I remove it from my pocket:


There is a nice rubberized grip, but the key feature is that tip, here it is in action:


It really does enable you to create very highly precise lines and the friction between the tip and screen is somewhat similar to paper and pencil.  The palm detection will get infuriating though, although I have found a very simple work around Ill share later.  I also have found at certain angles it stops tracking occasionally.


The Good

  • Reasonably inexpensive
  • Works on any device with any application
  • High Precision
  • Comfortable


The Bad

  • highly fragile tip, always use the cap when not in use!
  • 2 – 3x more money than a typical stylus
  • doesn’t track right at about a 45 degree angle
  • palm on screen causes fits


For high precision drawing, this is hands down my favorite.  The difference between using one of these and a standard stylus is night and day.  However sometimes the LAST thing you want is to be super precise.  If for example you are painting, you’d rather have that painterly feel instead.  Well, there is a stylus for you too!


The Paint Brush


Next up is Nomad Paintbrush Stylus, which retails for about $40.  Here’s mine:


The key feature here is the paint brush style tip:



It really feels like a paint brush when you use it.  It’s an impressive trick they have pulled off and it allows you to achieve effects, like feathering and flicking, that you simply can’t with other stylus.  That said, this is useful for painting and that is absolutely it.  Precision is almost impossible ( that’s kinda the point ), and even selecting buttons and such can be a bit irritating.


The Good

  • Effectively mimics a paint brush
  • It’s cool, admit it, you find it cool.  It looks cool, it feels cool, so far as stylus go, this one is pretty freaking cool.
  • Most “natural” feel all of stylus used, glides nicely on surface
  • Works on any device


The Bad

  • low precision, its by design of course, but it can get annoying
  • getting pretty pricey at $40
  • palm gets in the way



The Next Generation


The future is here and two new stylus are leading the pack!


The first is from Wacom, the Intuos Creative Stylus 2 for $80 and the Adoit Jot Touch for $100.  These two products are very similar in strengths and weaknesses.


The Wacom Intuos:



The Adoit Touch with PixelPoint:



Both of these offer 2048 levels of sensitivity, something unique to them in this roundup.  Both are Bluetooth powered.  Both have small “nubs” and both have palm detection software to prevent the annoyances that all of the above offer.


Neither is ready for prime time either, which is infuriating, as I so wanted to buy both of them!  That’s my inner gadget addiction talking, and that is a very strong addiction indeed.


So, what’s wrong?  It’s two fold, software support and execution.


The biggest problem is, in order to take advantage of what these stylus have to offer, it needs to be supported in the application.  Sadly each has only about half a dozen applications that support them.  When an application does support them, the reviews seem to be mixed.  I read review after review for both products trying to decide which one to purchase and in the end decided neither appears ready for prime time.  Too many applications I use ( ProCreate, iDraw, OneNote ) simply aren’t supported yet.  Many reviews state that palm detection didn’t work, or spoke of constant disconnects.


Make no mistake, Bluetooth stylus are the future, it’s just not quite the future yet.  Apparently when you use the right application and the device works properly, the experience is amazing.  I hope they get the kinks worked out quickly.


Palm Detection, Ghetto-Style


One common problem with all but the newest stylus is palm detection.  When you draw with pen and paper, the worst that happens if your palm touches the screen is you might smudge your work slightly.  On a tablet however, the outcome is quite different.  Either your drawing is disrupted completely, or worse, you draw where your palm touches.


The work around?



I decided to try drawing wearing my workout gloves.  Standard weight lifting gloves have a leather pad across the palm, and at least on an iPad Air, it completely prevented my palm from registering.  Of course, you do have to get used to drawing with a pair of gloves on, but really it becomes natural almost instantly.  A pair of cycling gloves should probably do the trick, you just want to make sure it’s thick at the point the palm makes contact.


31. October 2014


Now that we know how to create vector graphics on iPad, let's take a look at the process of getting them into and using them in Codea.  This part is insanely easy, in fact if this was all there was to it, I could cover this entire process in a single Tweet!  Let’s do it.


First of course you need to create a vector graphic in some application and save it as PDF to your Dropbox folder.

Then fire up Codea, create a new project with the following code:

function draw()
    background(40, 40, 50)


Yeah... that's it.  Select the image from your Dropbox, run it and you will see:




So basically vectors are treated exactly the same as bitmaps as far as Codea is concern.  Well, with a few exceptions… you can scale them as much as you want and never lose visual fidelity.


You can scale by passing in the width and height to the sprite call, like so:



So then, vectors are easy to load, look great, scale well are pretty easy to draw... perfect no?

Well… no, there is a catch.  Performance.

Let’s take a quick look at how vectors perform, using the following code:


-- VectorTest
function setup()
    fill(255, 0, 25, 255)

function draw()
    background(40, 40, 50)

    local outString = "fps:" .. math.floor( 1/DeltaTime)
    local dimensions = textSize(outString)

    for i= 1,100 do
        local x = math.random(WIDTH)
        local y = math.random(HEIGHT)
        sprite("Dropbox:Jet 2",x,y)


Here it is running on my iPad Air with drawing 100 vectors:




60 FPS is as good as we can get, so so far so good!  Now lets see what happens when we crank the number up to 500.





From my tests, you can draw about 200 vector images before framerate starts to drop down.  You can easily draw twice that many normal sprites without seeing a noticeable drop in framerate.  


Right now our simple frame rate counter is changing far too often to be of much use.  So instead I am going to sample and average across minutes.  Basically every frame we take a sampling of framerate, after a second elapses we move that sample to other array, average and display the results.  So basically we sample the data per frame, but average it out over the span of a second.  This should give us a much smoother frame rate total.  Here is the updated code:



-- VectorTest
frameRateSamples = { 60 }
fpsSampledPerSecond = { 60 }
elapsedTime = 0
function setup()
    fill(255, 0, 25, 255)

function mean( t )
  local sum = 0
  local count= 0

  for k,v in pairs(t) do
    if type(v) == 'number' then
      sum = sum + v
      count = count + 1

  return math.floor(sum / count)

function draw()
    background(40, 40, 50)

    elapsedTime = elapsedTime + DeltaTime
    if(elapsedTime < 1) then
        print("Second elapsed")
        framerateSamples = {}
        elapsedTime = 0
        -- ever 360 seconds reset the table so it doesnt grow forever
        if #fpsSampledPerSecond > 360 then
            fpsSampledPerSecond = { 60 }

    local outString = "fps:" .. mean(fpsSampledPerSecond)
    local dimensions = textSize(outString)

    for i= 1,200 do
        local x = math.random(WIDTH)
        local y = math.random(HEIGHT)



Now when we run it, we get the follow values, after letting each run for over 60 seconds to take the seed value out of the equation:

Image Type FPS at 100 FPS at 250 FPS at 500 FPS at 1000 FPS at 1500 FPS at 2000
Vector 58 38 21 23 15 9
Bitmap 58 37 21 21 17 10


Hmmm, that's interesting.  So once the framerate sampling is smoothed out, the performance between vector and bitmap graphics is basically identical.  In both cases too, oddly enough, 500 sprites caused a drop in performance compared to 1,000…  very very very odd.


Now let’s take a look at if scaling is a factor.  In this test we will scale the vector down to 32x32, vs drawing a fixed 32x32 sprite and see if it impacts performance.


As a 32x32 pixel image, at 2000 sprites, the framerate a solid 57.

As a vector scaled down to 32x32 in the sprite call the framerate at 2000 sprites is 57.


There you have it, contrary to my initial findings, the performance between identically sized bitmap and vector images in Codea is about the same.  Internally, Codea must be rasterizing vectors before drawing them.


So, why did my initial tests show a massive improvement in bitmap performance over vectors as the count increased?  Well, that’s because I compared apples to oranges… I used a “nearly the same dimensions” graphic for the test, and that was a huge mistake. Something critical you can take away from this experiment is the size of the sprite being blitted has a huge impact on performance, much more so than the type of sprite.  As you saw above, we can blit > 2000 32x32 pixel images without a drop in performance, while the same number of 200x200 pixel images brings it to it’s knees.


So, in a nutshell, its equally as valid to use a vector with code than it is a bitmap.  And as you can see, it uses the exact same code.  Oh, and if you are by chance wondering why we were toping out at 57-58FPS instead of 60 you would expect, that is simply because I floored() the results (aka, rounded down) to make the numbers prettier.  Since I was measuring relative performance, not overall performance, the actual framerate really didn’t matter all that much.


29. October 2014


As part of the ongoing Guide to Creating a Game Entirely on an iPad series, we recently looked at a number of 2D raster and vector graphics programs available onidraw_large_icon iOS.  One of the programs that really stood out was iDraw, a vector drawing program.  I’ve actually used iDraw for a while now, going back to the concept art I did for the Blender tutorial series and I am certainly a fan.  Although both Inkscape (Desktop) and Inkpad (iPad) are available for free, I find both to be pretty unwieldy at times.  iDraw just hits that sweet spot between usability and functionality, at least for me.


In this video I take a more in-depth look at iDraw. 


In this video I show the functionality available in iDraw.  THe first half of the video I complete this game art tutorial that was written for Inkscape, so if you are familiar with Inkscape, you can see how iDraw works at the same task.  If you’ve got no experience with vector graphics at all, this video should certainly give you the basics.   The last half of the video is a tour of iDraw’s additional functionality.




If you have a Mac or iPad and are looking for a vector graphics solution, iDraw is certainly worth checking out.  iDraw is available for $8.99 on the AppStore for iPad, while it is also available (with almost identical functionality) on the Mac for $24.99.   If you are looking for a tutorial on creating vector graphics, or are looking for more details on using vector graphics for game dev, 2dgameartforprogrammers is a great resource you should check out.


… I still hate the name iDraw though.  I hate an irrational hatred for all iNaming iProducts, I think many others do too!  Get over the name though and you will find an excellent product.


Next up, I will look at using Vector graphics from a Codea code perspective, to see how it’s done and what the performance is like.  Stay tuned!


AppGameKit Studio

See More Tutorials on!

Month List