Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

22. March 2017


One thing many programmers struggle with is finding art for their game.  There is a new site, The Open Pixel Project that aims to make life somewhat easier for people.  It’s essentially a community for publishing, requesting and downloading pixel art graphics.  It just went live and there are already hundreds of tiles and sprites available, all under the Creative Commons Zero license, which is about as liberal as they come.


I did a quick hands-on video on the Open Pixel Project available below.


The only immediate recommendation I have, beyond fixing the png links, is that they publish to a much higher resolution.  It’s easy to go down in resolution, but not so easy going up!  It will be interesting to see how this project turns out.

GameDev News, Art

21. March 2017


KDevelop started life as a Linux based IDE created by the KDE group.  In the last year however it has expanded to have beta support for Windows while a Mac OS version is also under development.  They just released KDE 5.1.0 bringing tons of new features to the IDE including LLDB support, cppcheck, OpenCL language support, improved Python language support, in-IDE theme selection, Perforce integration and more.


Details from the release announcement:

LLDB support

We had a great student for GSoC 2016 implementing LLDB support in KDevelop. The end result is that we now have a debugger framework which can be used both for the GDB & LLDB MI communcation. The LLDB plugin teaches KDevelop to talk to the standalone LLDB MI Driver (lldb-mi); so now it's possible to use LLDB as an alternative debugger backend for KDevelop. One interesting thing with LLDB that it's also potentially useful on OS X & Windows for us, especially when the Windows port of LLDB is getting more and more stable.

Analyzer run mode

With 5.1, KDevelop got a new menu entry Analyzer which features a set of actions to work with analyzer-like plugins. During the last months, we merged analyzer plugins into kdevelop.git which are now shipped to you out of the box:


Cppcheck is a well-known static analysis tool for C/C++ code. Cppcheck is useful for taking a closer look at your source code checking for common programming faults such as out of boundsKDevelop accesses, memory leaks, null pointer dereferences, uninitialized variables, etc. pp. With the Cppcheck integration in KDevelop running the cppcheck executable is just one click away. KDevelop will pass the correct parameters to cppcheck including potential include paths and other options.

Other analyzers in the pipeline: Valgrind, clang-tidy, krazy2

While the Cppcheck plugin is shipped out of the box, other analyzers are not considered 100% stable yet and still reside in their own repositories. The clang-tidy plugin looks super promising (another static analysis & refactoring tool for C/C++) as it really easy to use from the command-line and thus easy to integrate into our IDE. We plan to import more of those analyzers into kdevelop.git so they'll be part of the kdevelop tarball and are thus available to you without having to install yet another package.

Initial OpenCL language support, CUDA support upcoming

Since 5.1 KDevelop is able to parse code written in the Open Computing Language (OpenCL). The OpenCL language support inside KDevelop is backed by our Clang-based language support backend and thus just required minimal changes in KDevelop to start supporting it. Support for handling NVidia's CUDA files will be part of 5.2 instead. Stay tuned.

Note that for KDevelop to detect .cl files as OpenCL files, an up-to-date shared-mime-info package which contains this patch is required. Alternatively, you can add the mime type yourself by creating the file /usr/share/mime/text/x-opencl-src.xml with appropriate contents and re-running update-mime-database yourself.

Improved Python language support

Python language support now supports Python 3.6 syntax and semantics. In addition, thanks to the work of Francis Herne, various long-standing issues in the semantic analysis engine have been fixed:

  • Loops and comprehensions infer types correctly in many more cases, including on user-defined types with __iter__ and __next__ methods.
  • Type guessing works for arguments named by keywords (not only **kwargs), and works better for class/staticmethods.
  • Property accesses get the return type of the decorated method.
  • Types are inferred correctly from PEP-448 syntax in container literals.
  • Unsure types are handled in subscripts and tuple unpacking.
  • Uses are found for __call__() and __get/setitem__().

These improvements were accompanied by cleaning up dusty code, making future changes simpler as well.Furthermore, our style checker integration has been rewritten, making it much faster and easier to configure.

Perforce integration

Thanks to Morten Danielsen Volden we now have Perforce integration in kdevplatform.git, which can be used freely starting with KDevelop 5.1. Perforce is a commercial, proprietary revision control system. The Perforce integration in KDevelop simply works by running a local version of the p4 executable (needs to be installed independently of KDevelop) with appropriate parameters. This is similar to how KDevelop integrates with other VCS, such as Git & Bazaar.

Color scheme selection inside KDevelop

It is now possible to select the current color scheme from within KDevelop, a feature which has been requested several times in the past. This is especially useful for when KDevelop is run under a different desktop environment than KDE Plasma, where the color scheme settings may not be easily accessible.

Ongoing support for other platforms

We're continuously improving the Windows version of KDevelop and we're planning to release a first KDevelop version for OS X soon (yep, we're repeating us here, please stay tuned!). For the Windows version, we upgraded the KF5 version to 5.32 and the LLVM/Clang version to 3.9.1.


KDevelop is completely free and available for download here.

GameDev News

21. March 2017


There is a new release of the Lua powered Defold Game Engine, bringing it to version 1.2.100.  In addition to several bug fixes, the release added a new Lua module for creating and manipulating memory buffers.  If you want to learn more about using the Defold game engine, we have a complete tutorial series available here.


Details of the release:


  • DEF-2483 - Added: Added buffer Lua module for creating buffers and manipulating streams
  • DEF-1217 - Fixed: Spine keyable draworder
  • DEF-1688 - Fixed: Fixed issue of not flushing all purchases on Google Play after reconnecting to wifi
  • DEF-2024 - Fixed: Multi touch gave inconsistent input messages
  • DEF-2500 - Fixed: Extensions are now only initialized once
  • DEF-2519 - Fixed: CONSTANT_TYPE_WORLD is set to the identity matrix for model components
  • DEF-2538 - Fixed: When issue of last sound having gain 0, muted all audio
  • DEF-2547 - Fixed: Removed unused shader constants from builtin shaders
  • DEF-2554 - Fixed: Detect configuration change and reenable immersive mode
  • DEF-2558 - Fixed: Fix discrete sampling midpoint calculation in Spine animations
  • DEF-2561 - Fixed: Handling reset keys for spine draw order offsets
  • DEF-2565 - Fixed: Debug rendering for circles in 2D physics
  • DEF-2568 - Fixed: Typo fix for dmGraphics::GetNativeiOSUIWindow


  • Added examples for gui scripts
  • Lots of minor fixes

20. March 2017


In this tutorial in our ongoing HaxeFlixel tutorial series we are going to look at using Sprites in HaxeFlixel.  Sprites are fundamental to HaxeFlixel development and can be simply thought of as a graphic that can move.  We are going to look at a couple different examples, one procedurally creating the graphic to draw, while the other loads the sprite from an image.  We are also going to quickly take a look at how we can move our sprite around the screen.  If you were curious, the term Sprite was coined by Texas Instruments for one of their early graphics chips.  The reason the term Sprite was chosen according to Wikipedia:

The term was derived from the fact that sprites, rather than being part of the bitmap data in the framebuffer, instead "floated" around on top without affecting the data in the framebuffer below, much like a ghost or "sprite". By this time, sprites had advanced to the point where complete two-dimensional shapes could be moved around the screen horizontally and vertically with minimal software overhead.

It was common in the early days of consoles and graphics cards to have dedicated hardware for drawing sprites (non-stationary images) and the number of supported sprites was a key selling feature for computers and consoles.  In HaxeFlixel, Sprite is actually a very important class, the FlxSprite.  Behind the scenes there is no special hardware for drawing sprites anymore, in fact a sprite is ultimately a 3D object that is parallel with the camera, but the terminology has stuck.  Ok, enough history, let’s actually jump in with some code.


In this first example, we are simply going to create a FlxSprite programmatically.


import flixel.FlxSprite;
import flixel.FlxState;

class PlayState extends FlxState
   var sprite:FlxSprite;
   override public function create():Void
      sprite = new FlxSprite();
      for(y in 0...300){
         for(x in 0...300){
            if(x%2 == 1 && y%2 == 1)
            if(x < 5 || y < 5 || x > 295 || y > 295 )

   override public function update(elapsed:Float):Void
      sprite.x += elapsed * 100;

When we run this code we should see:



As the program runs the sprite will slowly advance to the right until it is off the screen.  Let’s just in and figure out exactly what is happening here. 

First thing to notice is the base class of our sprite is FlxSprite.  We allocate a new one then call it’s makeGraphic() method.  This gives us a 2D image to work with, in this case one that’s 300 pixels wide by 300 pixels high and filled with the colour WHITE.  As you can see HaxeFlixel has a handy utility class containing the numeric value of several of the most common colours available in flixel.util.FlxColor.

Now that we have a 300x300 white canvas to play with we simply loop over all the available pixels in the graphic, looping row by row, then through each pixel in that row.  We can then directly set the color value of a given pixel by accessing the setPixel() method of the pixel member of FlxSprite.  The parameters are the x and y location of the pixel within the graphic, relative to the top left corner, as well as the color to set it.  Notice in this example instead of using a predefined colour (which we could have if we preferred) we instead us a hexadecimal encoded number.  If you’ve ever done any HTML coding, this color scheme should be immeidately familiar.  If not each two digits represents first the red, then green, then blue component of the color from 0 to 255 ( or 0 to ff in hexidecimal).  So in this case we set every other pixel of blue ( no red, no green, full blue == 0x0000ff ).  We also have another check to see if we are within 5 pixels of the image edge and if so, draw the pixels in white.  This causes a 5 pixel wide border to appear around our image.

After creating our simple white bordered checkboard image you will notice a call to add().  This call is EXTREMELY important, as it adds the FlxSprite to the object collection of our FlxState derived class PlayState.  Being in this collection will cause the sprite to automatically be drawn and updated each pass through the game engines main loop.  Speaking of updating, notice we have also overridden the update method.  This is called every pass through the game loop and is where you should update the logic of your game world.  In this case we simply increase the x value of our sprite by elapsed * 100.

So... why did we do this?  What exactly are we saying with the line:

sprite.x += elapsed * 100;

This is actually a really common tactic in game development.  One of the challenge of creating games is getting them to run the same speed on various different computers.  If you are running a fixed game rate loop, say a game running at 60fps, and it never runs below that rate, it’s not a problem, you know how fast things are going to update.  However on faster or slower computers this is trickier to determine.  This is why elapsed is so important.  This is a value passed in to the update() function each pass through the game loop and it tells our game how long has elapsed in seconds since the last pass through the game loop.  You can then multiply this value by the amount you want to move by to get a consistent update regardless to the machine you are running on.

For example, if your game was running at 10 frames per second, the value of elapsed will be 0.1.  So to hit our target of 100 pixels per second, this means in updates we will move by 100 * 0.1 or 10 pixels.  However if we were running at 60 fps instead of 10fps, the value of elapsed will instead be 1/60 or 0.016.  So to hit our target of 100pixels per second we update instead by 0.016 * 100 or 1.66 pixels.  Over the course of a second, regardless to framerates, the sprite will be updated by the same total amount.

Before we move on it’s important to know the process of working directly with each pixel in a sprite like we just did is an extremely costly process!  This is the kind of task you want to perform very occasionally, not every frame!

Next, instead of creating an ugly graphic programmatically, lets load a sprite from an image file.  Let’s jump straight into the code.


import flixel.FlxG;
import flixel.FlxSprite;
import flixel.FlxState;
import flixel.tweens.FlxTween;

class PlayState extends FlxState

   var sprite:FlxSprite;
   override public function create():Void
      sprite = new FlxSprite();
      sprite.x = 100;
      sprite.y = 0;

      FlxTween.tween(sprite, { x: FlxG.width - sprite.width, 
                         y: FlxG.height - sprite.height, 
                         angle : 360.0 }, 5, { type:FlxTween.PINGPONG });

   override public function update(elapsed:Float):Void

Now when we run the code, we see:



Notice in this case that our sprite is still a FlxSprite, although instead of creating it from scratch using makeGraphic() we load if from file using loadGraphic passing in the value AssetPaths.enemy__png.  In this case enemy.png is the name of the image we are using for our sprite.  If yours has a different filename, this value will change.  A bit of a note on the image, I added it to the directory assets/images that was automatically created when we created our project.



As we add new assets to these folders, Haxe is smart enough to automatically create a reference to it for us.  This is a handy feature of the Haxe language and is invoked by this code in AssetPaths.hx:


@:build(flixel.system.FlxAssets.buildFileReferences("assets", true))
class AssetPaths {}

Throwing any applicable asset in the assets directory will automatically generate file references that we can then use in code, like so:



Very cool.  Behind the scenes loadGraphic is actually doing a lot more than you might think.  In addition to loading the file into memory, it’s actually caching it.  This means that if other code loads the same asset it will get the version from cache instead of creating yet another version.  This improves performance and reduces memory usage.

So now that we have our sprite loaded from an image we set it’s initial x position to 100 pixels.  Notice that graphics are drawn relative to their top left corner and the top left corner of the applications window.  So an image with x = 100 and y = 0 is drawn starting at it’s top left corner 100 pixels right of the top left corner of the window and 0 pixels down from the very top of the application window. 

The final detail of this example is the use of a Tween, called via FlxTween.tween().  FlxTween is another cool way of handling updating your game objects, but it takes care of the timing and calculations for us.  Instead of moving our sprite each pass through the game loop via update() like we did earlier, we simply fire off a Tween and it takes care of things for us.  Tween comes from  “In-Between” and basically it’s a function that you give an end goal and a timeline and it figures out all the in-between calculations required.  In this case we are saying “take this sprite, move it to the bottom corner of the screen, rotating 360 degrees over a period of 5 seconds” and HaxeFlixel figures out how much it needs to move each frame and does it for us.  The final parameter we are saying we want to ping pong the tween, which is to say repeat it, but in reverse forever.  There is a ton more we can do with Tweens and we will cover them in more detail later.


That’s it for sprites for now, but there is a lot more we will cover later including texture atlases, animations and more, stay tuned!


The Video

Programming , , ,

20. March 2017


Epic have released a new hotfix for Unreal Engine, 4.15.1.  This update is composed entirely of fixes, including:

Fixed! UE-42385 Crash adding an AnimComposite to itself
Fixed! UE-41929 Crash on reimport animation when there is an additive animation track and fbx frame number is different
Fixed! UE-41921 Crash Re-Importing animation with Additive Layer Tracks after adding a bone to the hierarchy
Fixed! UE-41817 Crash when manipulating Bone Space IK before setting EffectorSpaceBoneName
Fixed! UE-40025 Inconsistant Line Trace behavior
Fixed! UE-42756 UnrealVS not installing correctly for VS2017
Fixed! UE-42321 Unable to launch project from Visual Studio using installed engine build
Fixed! UE-42411 Resource files are not recompiled when Version.h changes
Fixed! UE-42205 Hot reload reported as failed in Visual Studio for projects opened in the Editor after having hot reloads performed successfully previously
Fixed! UE-42507 check(PIEInstanceID != -1) fails when executing SeamlessTravel
Fixed! UE-42480 SetVectorParameterValueOnMaterials In Construction Script Not Working in Packaged Game
Fixed! UE-42459 BP nativization doesn't work with localized text
Fixed! UE-42166 Crash when pressing Ctrl-Z after creating a blueprint function
Fixed! UE-41893 Child blueprints cannot override functions if their parent was nativized
Fixed! UE-41168 Crash opening blueprint when a node class has been removed (e.g., anim blueprint with Ragdoll node with Immediate Mode plugin disabled)
Fixed! UE-42209 Incorrect error message when child actor mobility doesn't match
Fixed! UE-42253 Enum Element Names Reset on Project Upgrade
Fixed! UE-42375 No input received from Raw Input device when packaged for 32bit
Fixed! UE-39884 Foliage LODs do not appear to use the base LODs lightmap any longer
Fixed! UE-42390 Ad banner is displayed incorrectly on Android 7.0 devices
Fixed! UE-42361 Slate UI asset colors washed out on iOS
Fixed! UE-42191 Scene Captures not working on Android
Fixed! UE-42036 Exposure Is More Extreme In High-End Mobile Preview Modes
Fixed! UE-42368 Find Sessions Consistently Returning Results Length of 0
Fixed! UE-42452 No textures listed when selecting material
Fixed! UE-42789 Rebuilding lighting not saving rebuilt light data
Fixed! UE-42196 Static meshes with auto-generated LODs can no longer share lightmaps between LODs
Fixed! UE-42179 Crash in FStreamingTextureLevelContext::GetBuildDataIndexRef
Fixed! UE-42165 [CrashReport] UE4Editor_Renderer!FReflectionEnvironmentSceneData::ResizeCubemapArrayGPU() [reflectionenvironment.cpp:215]
Fixed! UE-42102 Cooked build size increase due to MIC problem
Fixed! UE-41950 GitHub 3252 : Added MobileMaterialInterface to UsedMaterials
Fixed! UE-29491 Eye Adaption is incorrect at any size other than Fullscreen in PIE
Fixed! UE-42554 Regression: Visibility property is not seen in the animation track in UMG
Fixed! UE-42210 Crash when using Ctrl+Z to undo a single digit change in the size of a widget
Fixed! UE-41829 Crash scrubbing through sequencer when playing montage from old assets
Fixed! UE-42665 Update default super search engine to Bing
Fixed! UE-42428 Enabling "Show Only Modified Properties" causes details panel menu to disappear
Fixed! UE-42312 Crash when saving a Data Table that is referencing itself in a Data Table Row Handle
Fixed! UE-35606 Crash when Importing .OBJ using the File > Import into Level Option
Fixed! UE-42669 "Package localization ID mismatch during cook!" log spam
Fixed! UE-41797 Update to Korean localization
Fixed! UE-42106 Edge case where cursor can become hidden in gameplay
Fixed! UE-42631 Stereo off while prox sensor uncovered causes low framerate
Fixed! UE-42576 Oculus crash on "stereo on" when the proximity sensor is not triggered.
Fixed! UE-42101 [daydream] Black screen with FirstPersonTemplate and 4.15P4
Fixed! UE-41604 Integrate fix for improper failure case for allocation of RenderTargets in Oculus
Fixed! UE-41568 Need to enable GearVR on Win64 platforms


As always, the hotfix is available for download in the Epic Game Launcher.

GameDev News

Month List

Popular Comments