Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

21. November 2016

 

A new version of the cross platform 2D game engine Defold has been released, this one version 1.2.93.  The primary new functionality in this release provides greater control over Spine based animations.  If you want to learn more about the Defold engine, we have a complete tutorial series available here.  If you want to learn more about creating animations using with Spine, we have this hands on guide.

From the release notes:

New API for Spine animations. The new API allows for greater control of the playback of the animation by exposing the animation cursor and the playback rate.

  • spine.play_anim(id, anim_id, playback, [properties], [completed_func])
  • gui.play_spine_anim(node, anim_id, playback, [properties], [completed_func]

Where [properties] is an optional table that currently takes blend_duration, offset, playback_rate. For the Spine component the values for cursor and playback_rate are exposed as properties and can be get/set and even animated as such. Property cursor is normalized [0,1], and playback_rate is a non-negative multiplier to the animation playback rate. For example:

  • go.get(id, "cursor")
  • go.set(id, "cursor", 0.5)
  • go.animate(id, "cursor", ...)

Note: Spine events may not fire as expected when manipulating the cursor by set or by animation.

Added functions for setting and getting skin for Spine in gui.

  • gui.get_spine_skin(node)
  • gui.set_spine_skin(node, skin)

Added the ability to use multiple gamepads at the same time. Input messages from joysticks/gamepads will have a new gamepad field in the action table, which correspond to a gamepad index/id for the current input data.

Fixed bug regarding random selections when browsing for textures in the editor

Fixed bug where .ipa was not installable through X-Code

Engine

DEF-2248 Added: Implement spine animation cursor- and playback control
DEF-2130 Added: Setting skin at runtime for spine GUI nodes
DEF-1416 Added: Connect several controllers (gamepads) of the same type and get input individually
DEF-1568 Fixed: Layouts > Defaults randomly gets selected when browsing a texture for a GUI-object node
DEF-1672 Fixed: iOS: Set executable bit on executable

GameDev News

20. November 2016

 

You may recall that earlier this week it was announced that Godot would be skipping the 2.2 release to focus instead of getting Godot 3.0 out to the market faster.  This doesn’t mean they wont still be doing minor, more maintenance focused releases.  In fact Godot just released version 2.1.1.  For a maintenance release, there is actually a pretty surprising amount in there.

 

Highlights of the release from the Godot blog:

HIGHLIGHTS

  • Gamepad support for OSX!
  • Generic AStar implementation - relatively fast and useful for situations where Navigation doesn't cut it
  • More drag and drop possibilities (and fixes) from and to the SceneTree, Filesystem and Viewport. Try things, some intuitive actions should now be functional (e.g. dragging a scene from the Filesystem to the Viewport to instance it)
  • OpenGL compatibility enhancements: improved compatibility with older OpenGL 2.1 drivers, and prevent crashing when OpenGL 2.1 is not supported
  • Third party libraries refactoring: now shipped in a separate folder and they can be easily unbundled (thus linking against system libraries) on Linux (especially relevant for Linux packagers)
  • Usability and quality of life improvements all over the place
  • Dozens of bug fixes
  • Many class reference documentation updates
  • Editor translation updates

 

You can read the full release notes here.

GameDev News

17. November 2016

 

Corona Labs just released a new update for their cross platform Lua powered game engine Corona, version 2016.2992.  This release contains several fixes and improvements across all facets of the SDK.  They also made some changes to their EULA requiring monetized plugins to be published in their marketplace.

From the announcement blog.

Corona Simulator
  • Introduction of a new Welcome window. We’ve made useful links more, well, “useful.” You also have a better view of your recent projects.
    screen-shot-2016-11-09-at-9-46-27-pm
  • We now attempt to validate keys and values in build.settings and config.lua. For example, if your app requires a key like FacebookAppId and you enter FaceBookID instead, Corona will alert you that the key isn’t recognized, helping you pinpoint potential issues before you build your app.
  • With iOS 10, Apple made changes to how they scan submitted apps and, as a result, we now provide default values for the various NSDescription strings required by Apple. If you use these permission-based features, however, we strongly recommend that you provide actual values for these strings.
  • macOS 10.12, Xcode 8.x, and iOS 10.x brought considerable changes that needed to be reflected in the Simulator and build process. This build of Corona will require you to use Xcode 8.1 since we now default to iOS 10.1 as the primary SDK.
  • Introduction of Corona live builds (beta) from the Corona Simulator for macOS. These builds are a powerful and efficient way to see exactly how your in-development Corona app will appear on real devices.
  • New borderless skin for testing the iPad Pro.
  • The Simulator for macOS now supports the hardware “back” button when you use an Android or WP8 skin — just select HardwareBack from the main menu.
  • Minor improvements to the console log screen introduced in the previous public build.
Core
  • Widget picker wheels are now resizable so that you can incorporate them into your UI with much greater flexibility. Keep an eye out for an upcoming announcement which summarizes this addition and other new features.
  • Improved splash screen controls including per-platform support. You now have the ability to use a unique splash screen image for iOS and another for Android. You can also enable and disable the splash screen for each platform, if desired.
Windows
  • Previously, the default behavior for Windows Desktop builds was to allow multiple instances of apps to run. Most apps, in particular games, only allow one version to run at a time. We have changed it so that Windows desktop apps are now single-instance by default. However, if you are building an app that needs multiple instances, this can still be enabled via a build.settings entry (see here for details).
  • We have improved command line parameter handling for desktop builds and added applicationOpen support to single-instance Win32 desktop apps.
macOS
  • Similar to Windows, improved command line parameter handling for desktop builds.
Android
  • We’ve worked to improve the way video plays on Android. With improvements to native.newVideo() and media.playVideo(), you should now have more success pausing and seeking within videos loaded from remote sources.
  • Corona Enterprise for Android developers get new APIs for creating AlertDialog.Builders such as:
    CoronaActivity.createAlertDialogBuilder()
    CoronaActivity.createDarkAlertDialogBuilder()
    CoronaActivity.createLightAlertDialogBuilder()
  • New PackageServices Enterprise APIs for interacting with Android packages.
iOS
  • Corona Enterprise for iOS developers get a new API, CoronaEventDataKey().
tvOS
  • Updates to support the latest version of the tvOS SDK as required by Apple, including new graphic asset requirements like a “top shelf wide” image.
  • Support for native.showPopup( "appstore" ) on tvOS. This is the popup that lets you easily rate, review, and download apps.

 

Further details are available in the release notes.

GameDev News

16. November 2016

 

Construct 2, a popular “code-less” HTML5 based game engine, just released the beta release r240.  As this is a beta release, you know the story… expect warts, don’t use for production, etc.  The biggest feature in this release is basic WebGL 2 support, which was just turned on by default in Google’s Chromium browser.  The release also saw new functionality in the form of new triggers and pointer events.

 

Full change log of the release:

image

GameDev News

16. November 2016

 

The graphics world has pretty much gone all in on shaders as the foundation of modern graphics hardware. DirectX, OpenGL/Vulkan and Metal all take a shader-centric approach to the graphics pipeline.  Unfortunately each has a different shader language!  DirectX uses HLSL, OpenGL uses GLSL while Metal uses MSL.  Each is very similar yet quite different.  So, what does this mean for game developers, especially those responsible for developing renderers?  Well it means one of three things.

  • you pick a single renderer and develop for it exclusively
  • you create multiple “back ends” for each rendering architecture
  • you create a tool to translate between them

 

The last option is exactly what Unity have done.  Built on top of HLSLCrossCompiler developed by James Jones, they created HLSLcc which as of today is available for download on Github.  Essentially its a C++ library that takes HLSL byte code and translates it to GLSL, GLSL ES, Vulkan and/or Metal format.

 

From the GitHub readme:

This library takes DirectX bytecode as input, and translates it into the following languages:

  • GLSL (OpenGL 3.2 and later)
  • GLSL ES (OpenGL ES 3.0 and later)
  • GLSL for Vulkan consumption (as input for Glslang to generate SPIR-V)
  • Metal Shading Language

This library is used to generate all shaders in Unity for OpenGL, OpenGL ES 3.0+, Metal and Vulkan.

Changes from original HLSLCrossCompiler:

  • Codebase changed to C++11, with major code reorganizations.
  • Support for multiple language output backends (currently ToGLSL and ToMetal)
  • Metal language output support
  • Temp register type analysis: In DX bytecode the registers are typeless 32-bit 4-vectors. We do code analysis to infer the actual data types (to prevent the need for tons of bitcasts).
  • Loop transformation: Detect constructs that look like for-loops and transform them back to their original form
  • Support for partial precision variables in HLSL (min16float etc). Do extra analysis pass to infer the intended precision of samplers.
  • Reflection interface to retrieve the shader inputs and their types.
  • Lots of workarounds for various driver/shader compiler bugs.
  • Lots of minor fixes and improvements for correctness
  • Lots of Unity-specific tweaks to allow extending HLSL without having to change the D3D compiler itself.

 

The code is released under the MIT license make it free and open to use by just about everybody.

GameDev News

Month List

Popular Comments