Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

14. July 2016

 

In the previous tutorial we looked at the basics of creating an application using the Defold engine, part of that included the built in Atlas type for displaying a sprite.  In this tutorial we are going to look further into sprites.  In case you are unaware, a sprite is simply a 2D graphic with position and is pretty fundamental to modern 2D games, even if sprites are actually faked in 3D.

 

There is an HD video version of this tutorial here.

 

In the previous tutorial we started with an Atlas created for us.  This time we are going to create one from scratch.  Don’t worry, it’s easy.  So what exactly is an Atlas?  It’s simply a collection of images in a single source.  The Defold engine itself is resposible for determining the ideal layout for the best performance.

 

Creating and Populating an Atlas

 

Creating an Atlas is simple.  In the Project Explorer, right click the folder you want to create the Atlas in and select New->Atlas File

image

 

Next name your Atlas file.  In this case I’m going with walker.  The extension is predictably enough .atlas.  Then click Finish.

image

 

Now we need some Image files to put in our Atlas.  In this case I am using a selection of images I created earlier but you can use whatever images you want.  If you are a Patreon backer, they are available in the Patreon Dropbox in the folder Art\AnimatedCharacter\Spritesheets\Raw\walk.  Whatever images you go with, simply drag and drop them to the images folder inside the main folder.  If you don’t have such a folder, simply right click and create one.

GIF

 

Now make sure Walker.Atlas is open in the editor, then go over to the Outline view, right click Atlas and select Add Animation Group. 

image

 

In the properties window, name the animation walk and set the default playback mode to Loop Forward.

image

 

Now right click the newly created Walk animation group and select Add Images.  In the popup dialog, select all our newly added images.  You can use CTRL or SHIFT to multiselect:

image

 

You will see that Defold automatically arranges all of our frames of animation together into a single atlas:

image

 

Be sure to save your Atlas before continuing.  You can preview the animation by right clicking “walk” in the Outline then choosing Play/Stop Animation.

GIF2

 

Creating a Sprite

Now that we’ve got our populated Atlas and a walk animation, how do we use it?  We create a Sprite.

To do so open up your main level .collection file.  In Outline right click Collection then choose Add Game Object:

image

 

I personally changed the ID of mine to walker.  Now right click the newly created game object and select Add Component.

image

 

In the Add Component dialog, choose Sprite.

image

 

With the sprite selected in Outline, we now need to define some properties, specifically Image and Default animation.

image

 

For Image, it will bring up a dialog box, select our recently created Atlas.  If the Atlas isnt shown, make sure everything has been saved.

image

 

Next select the Walk animation we defined earlier.

 

Now your game object Sprite will show in Collection.

image

 

In this case our sprite is centered about the atlas.  You can move the sprite using the W key.  ( E and R can be used for rotation and scaling as well ).

image

 

Each arrow represents the axis it will be moved along.  Or you can position your mouse inside the square and move freely in any direction.  Position your character then run your game (Ctrl + B) and you should see:

GIF3

 

Creating a Tile Source

You can also use a tile source instead of an Atlas.  A tile source is simply a grid of sprites already arranged into a single image.  To use a tile source instead of selecting Atlas, you select Tile source.  I wont be covering it in detail here ( I will cover tile sources later when we get to tile maps ), but if you want more details check the video where I did cover it.

 

You can also programmatically program the animation, get callbacks when animations complete, etc... but that requires knowledge of message passing... and that’s in the next tutorial!

 

The Video

Programming ,

13. July 2016

 

Spine 3.4 was just released.  Spine is a 2D bone based IK animation system I previously covered in depth here if you are looking for more information.  The 3.4 release brings a number of new features including:paths-tank

 

    • improved transform constraints
    • shearing (skew/squash/stretch)
    • paths and path constraints (see image to right)
    • spine-sfml, cocos2dx and objc now 3.4 compatible
    • spine-csharp, unity, xna and monogame all 3.4 compatible
    • cocos2d-x v2 runtime deprecated
    • new example projects illustrating path functionality
    • runtimes for Flash currently in progress
    • introduction of Beta versions

 

 

 

 

You can read more about the release here.

GameDev News

13. July 2016

 

Another day another Unity patch.  This one adds documentation for the display API and a handful of fixes including:

 

Improvements
  • Graphics: Documentation for Display API.
  • Lighting: Improved an error message about invalid data when baking probes.
  • Shaders: Removed an outdated comment in UnityStandardCore.cginc
Fixes
  • (808817, 805086, 801150) - Android: Fixed clip() in ES3 shaders on some Adreno GPUs.
  • (796182) - Android: Screen.dpi always returns densityDpi now.
  • (798640) - Camera: Stop silently disabling cameras that have non-existing target display set on them.
  • (798576) - Editor: Fixed an issue where the Editor would freeze if the user attempted to import a model without normals when the selected graphics API is OpenGL 2.
  • (785131) - Graphics: Fixed Display.main not always being Display.displays[0] in multi-display configurations.
  • (809864) - IL2CPP/PS4: Corrected the exception "System.Net.Sockets.SocketException: System call failed" which could occur when UDP sockets were used.
  • (809995) - IL2CPP: Corrected an exception during code generation with the NPOI library.
  • (808536) - iOS/IL2CPP: Fixed an error in generated C++ code due to duplicate extern declarations when an extern method in C# is overloaded.
  • (800289) - VCS: Updated VCS plugins from Bitbucket with improved support for IPv6 server connections on Windows and OSX and SSL server connections on Windows, OSX and Linux.
  • (810310) - Windows Store: Fixed enlighten crash on startup when Unity splash was used.
  • (810753) - Windows Store: Fixed an issue where plugins marked for .NET scripting backend were still being used even if building to il2cpp scripting backend or vice versa.

 

You can download the patch here.

GameDev News

12. July 2016

 

Earlier today I somewhat belatedly mentioned the Godot 2.0.4 release.  In that post I mentioned the upcoming 2.1 release... well I should have waited a few hours, as Beta 2.1Godot has just been released.  Keep in mind however, it is a Beta so buyer beware.  If you are working on a production project, you may be wise to wait for the full release.  The 2.1 release has been focused on improving usability.

 

The features of this release include:

  • New asset sharing platform: Godot has a new platform for sharing assets between users. It's still rough, but it will improve with time. As of now there is almost no content to test it with, but we will upload some plugins and the demos there in the coming days.
  • New plugin API: Downloaded assets can be used as plugins to extend the editor functionalities. Our first attempt at offering an API for this is still probably incomplete, so help us improve it with your feedback.
  • Support for dynamic fonts: Load TTF and OTF font files directly into your projects. This aids enormously with internationalization.
  • Fully internationalized editor UI: Godot can now be used in several languages and displays all unicode characters properly (including CJK). Right-to-left language support is still unimplemented though.
  • Editor visual customization: Change font sizes or set custom fonts, set custom themes, etc.
  • Customizable keybindings: Most keybindings can now be customized and there is a new binding editor in the editor settings.
  • Live script reloading: Saved scripts in the editor will be reloaded in the running game automatically, and tool scripts will also be automatically reloaded.
  • Profiler & frame profiler: Godot has a fully featured profiler (with graph plotting), which allows going back in time and see the performance numbers and most used functions frame by frame.
  • Remote scene inspector: Inspect the scene tree of the running game live, including nodes and resources.
  • HiDPI/Retina support: Godot detects high resolution monitors and offers the editor UI with native resolution. All Godot icons were redone in vector graphics for the occasion, thanks a lot to @drjmwho did almost all of them!
  • Drag & drop support: Godot now supports drag & drop editor-wide. Dragging assets from filesystem explorer to Godot will also open the relevant import dialogs.
  • Contextual menus: Godot now also supports contextual menus where relevant.
  • Script editor usability improvements: Incremental search, better highlighting, smart function matching in code-completion, etc.
  • Improved asset pipeline: Automatic re-import and reload of assets and scenes when changed.
  • Improved thumbnailer: Previews are updated in real-time, and thumbnails of resources will appear in the inspector.
  • New AnimatedSprite features: Labelled animations, and the ability to play animations without an AnimationPlayer.

You can download the release here, scroll down to locate the beta link.

GameDev News

12. July 2016

 

Today Torque 3D released version 3.9 and in a somewhat odd release blog post they spoke mostly about the plans for the next release.  Torque is an MIT licensed open sourced 3D game engine written in C++.  This release constitutes 515 commits with the major releases being proper roll over to deferred renderer, an initial implementation of entity/component and DirectX 11 integration.

 

As mentioned earlier, the majority of the release blog post covers features intended for the 4.0 release:

So, here's a main features list that we're looking at bringing into Torque for 4.0:

  • Physically-Based Rendering. This is, unsurprisingly a pretty big one. Luckily, it's also most of the way done! The only main piece that needs finishing is reflection probes, and the core features are in. From there it would just be a matter of dialing in the supporting art pipeline and tweaking the math to make it look as good as possible.
  • MacOS support. This was originally slated for 3.9, if you look at the 3.8 release blog, but a lack of machines to test on, and the age-addled old platform code made it impractical to really tackle initially. The good news is, near the end of 3.9's development, with SDL and epoxy to take a LOT of the workload off, huge strides were made and it's actually almost completed. There's still some issues with rendering on some machines and catching errors and warnings that crop up, but it's looking very practical to have MacOS as an official platform for 4.0! You can see Timmy's screenshot in the 3.9 RC thread showing off T3D running on MacOS with his and JeffH's work now.
  • SDL as the main platform layer. Torque3D's supported SDL for quite a while now, and it's naturally the main platform layer for Linux(and MacOS). However, it's been a little bit of a red-headed stepchild to the Win32 platform code. For 4.0, that's changing and SDL will be adopted as the core platform layer with whatever glue needed sitting atop it. This will drastically simplify the platform code and make it easier to maintain. It also offers a good bit of future proofing should any other platforms come into the equation down the line. SDL's stuff is very nearly at parity with the Windows side, it's pretty much just a matter of jumping over the last bits and doing cleanup/bugfixes to make it rock-solid.
  • New Project Manager The old project manager was useful, but was hacked together with QT and php, so maintaining it was a little sketchy and fell by the wayside for the more standard CMake gui. However, there's lots of management things CMake can't do, which is why the Project Manager will be making a comeback, it'll just be a graphical frontend sitting upon the more standard cmake project generation. This new PM will let you manage your updates, and hopefully in the future hook into online repositories for easier grabbing and integration of updates as well as fetching content packages without hassle.
  • New Shadergen As great a job as the current workhorse does of generating shaders for all the many materials you need to make a game, updating and expanding it has proven to be a pretty annoying thing to deal with due to how it's structured. Excellent peice of tech, but a chore to maintain, just like ye olde German tanks in WW2. As such, we'll be looking into restructuring shadergen to not only make it easier to update and expand upon in the backend-sense, but also easier to build materials/shaders for the end user as well, up to, and probably including a node-based approach for engineering your fancy shaders for your fancy materials.
  • Graphics API refinements DirectX 9 has proven to be a monstrous workhorse of the graphical APIs, reliably serving well beyond what anyone though it would. However, while it has proven to be a rock-solid API, the time has come to retire the poor girl and send her off to the glue facto-eeeer, the farm. Yes. As such, DirectX 11 will be taking over as the main Dx rendering API, and will continue to see refinements to bring it up to speed now that Dx9 isn't hampering it or OpenGL. Timmy's been poking at this and has noted improved performance in Dx11 by quite a lot, and some gains in OpenGL as well.
  • Threads. Threads for days One major blocker to rendering performance that even dropping Dx9 won't help is that we curretly don't thread or do much to optimize out the render calls themselves. That'll change in 4.0. We've been brainstorming the optimal approach for a few months now and have a pretty solid plan of attack that will see the render calls threaded out, and also proper batching of rendered geometry where appropriate. So fewer, faster drawcalls for the same workload. We'll also be looking at threads for handling resource loading and spawning of objects to cut out all those hitches when the map starts or stuff is created.
  • Hardware Skinning Another thing that's been pretty much complete outside a few oddball behaviors we'll be getting in there is Hardware Skinning. When it's behaving, the current implementation already notes a huge improvement in performance for animated meshes, so getting it polished up and in should be a huge, immediate performance boon.
  • Physics API T3D's had a physics abstraction layer for a long time now, and it's been pretty useful in letting the end user decide if they wanted PhysX or Bullet. However, Torque's stock physics has still served a useful niche in being network-reliable, or lightweight for basic physics mechanics, and some people find it to be a pretty workable thing. As such, the Torque physics will be converted over into a Physics plugin, so all physics and collisions will go through the Physics API and standardize all the behavior for that across the engine, cleaning up quite a lot and making it easier to maintain.
  • Entities, Components, and Assets This is the big one from non-rendering side. 3.9 already has the initial implementation of the entity/component stuff, as well as the Assets/Modules systems, but they're not yet fully utilized. That'll change in 4.0. If you've been checking out my work blog with the recent updates, I've been covering work I've been doing on the improved asset pipeline, as well as continued work with the Entity/Component stuff. For 4.0, this will become the standard, and all existing gameplay classes(Vehicle, Player, Item, Shapebase) will be replaced with GameObjects built of entities and components to do the same work. The idea is to give users a similar base to what is in Torque now in terms of starting objects, but remove all the bulky, hardcoded functionality. It should be a standard point, not an anchor, after all. Tying to that, we also will have:
  • Assimp support This was actually mostly done back in the day, just some issues with animation stuffs and a few other minor problems. I'd poked at this with some R&D time a while back, so it shouldn't take much tweaking to get it polished up and hooked into the assets system, which will allow quite a few new 3d model formats, including FBX.
  • A new base template This is also basically complete. This will be a much more streamlined starting template intended to easily drop in modules, assets and the like into to build up your game project, as opposed to having to spend time stripping out the stuff you don't need. Numerous ancillary improvements also help load times, easier to read and comprehend code and the like. This will replace the empty and full templates, cutting down on the effort needed to maintain(no need to duplicate changes).
  • Vive support This comes from our own Mango's efforts. It's pretty much done, but didn't quite squeak in for 3.9. It will be going into 4.0 for sure.

GameDev News ,

Month List

Popular Comments