Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

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

15. November 2016

 

Welcome to the getting started tutorial in the ongoing BabylonJS Tutorial Series.  Today we are going to look at creating our first simple Babylon application setup and running.  As always there is a HD video version of this tutorial available here or embedded down below. 

 

To get started with BabylonJS, we need a web page containing a <CANVAS> tag to host our application.

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Title</title>

    <style>
        #canvas {
            width:100%;
            height:100%;
        }
    </style>
</head>
<body>
<canvas id="canvas"></canvas>
</body>
</html>

 

Nothing special here.  We simply create a canvas tag named canvas, style it so it takes up the entire page and that’s about it.  Now we need to link to the BabylonJs library.  You’ve got a few options here, you can download it locally or host it from a content delivery network (CDN).  I’ll take this approach, as it’s generally the fastest option for end users.  You can even create a stripped down version with only the required features here.

 

The options for using BabylonJS include:

 

Babylon.max.js is the most human readable of the versions, making it the easiest to debug but the slowest to load.  During development, this is the version I am going to use.  Simply link to this library somewhere within the <HEAD> tag of our HTML.

<script src="http://cdn.babylonjs.com/2-4/babylon.max.js"></script>

 

We have our host webpage setup and Babylon linked, time to finally get down to some code.  Below our canvas, add the following code:

    <script>
        window.addEventListener('DOMContentLoaded', function(){
            var canvas = document.getElementById('canvas');

            var engine = new BABYLON.Engine(canvas, true);
            var createScene = function(){
                var scene = new BABYLON.Scene(engine);
                
                scene.clearColor = new BABYLON.Color3.White();
                var camera = new BABYLON.FreeCamera('camera1', new BABYLON.
                Vector3(0, 0,-10), scene);
                camera.setTarget(BABYLON.Vector3.Zero());

                var box = BABYLON.Mesh.CreateBox("Box",4.0,scene);
                
                return scene;
            }

            var scene = createScene();
            engine.runRenderLoop(function(){
                scene.render();
            });

        });
    </script>

 

When we run this code we should see:

image

 

Humble beginnings certainly, but our first running app is complete.  So what are we seeing here?  It’s an unlit cube viewed by a camera looking at the origin from –10 units down the z-axis.  Let’s take a quicker look at the code that got us here.  First we create a function that we call on DOMContentLoaded event fired, so basically when our page is loaded, this function is called.  Let’s walk through the function.

var canvas = document.getElementById('canvas');
var engine = new BABYLON.Engine(canvas, true);

This code gets a reference to the canvas tag we created in our HTML file.  We then use this canvas to create an instance of our Babylon game engine.

var createScene = function(){
    var scene = new BABYLON.Scene(engine);
    scene.clearColor = new BABYLON.Color3.White();
    var camera = new BABYLON.FreeCamera('camera1', new BABYLON.Vector3(0, 0,-10),
    scene);
    camera.setTarget(BABYLON.Vector3.Zero());
    var box = BABYLON.Mesh.CreateBox("Box",4.0,scene);
    return scene;
}

Here we are creating a function that will setup our scene.  First we create a new Scene using our newly created engine.  We then set the clear color to white.  The clear color is the color that each frame is cleared with between calls, essentially setting the background color to white.  Next we create a FreeCamera named “camera1”, located at –10 along the Z axis in our scene.  Next we set the target to the origin (0,0,0).  We will go into more detail on cameras shortly, so let’s skip over this for now. Then we create a cube at the origin named “Box” that is 4x4x4 in dimensions.  Notice in both when we create the Camera and Box we pass the scene in.  This causes these entities to be created in that particular scene.  Finally we return our newly created scene from our function.

var scene = createScene();
engine.runRenderLoop(function(){
    scene.render();
});

 

Next we create our scene by calling our just defined createScene() function.  We then start our game loop calling engine.runRenderLoop().  The game loop can be thought of as the heart of our game.  This is a loop that will be called over and over as fast as possible.  If for example your game is drawing at 60FPS, this function is called 60 times in a second.  For now all we do is call scene’s render() method, which causes the contents of that scene to be drawn.

 

Here now is the code in it’s entirety.  ( A WebStorm project is available in the GFS Patreon Dropbox directory Tutorial Series –> Babylon for backers )

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
    <script src="http://cdn.babylonjs.com/2-4/babylon.max.js"></script>

    <style>
        #canvas {
            width: 100%;
            height: 100%;
        }
    </style>
</head>
<body>
    <canvas id="canvas"></canvas>
    <script>
        window.addEventListener('DOMContentLoaded', function () {
            var canvas = document.getElementById('canvas');
            var engine = new BABYLON.Engine(canvas, true);
            var createScene = function () {
                var scene = new BABYLON.Scene(engine);
                scene.clearColor = new BABYLON.Color3.White();
                var camera = new BABYLON.FreeCamera('camera1', new BABYLON.
                Vector3(0, 0, -10), scene);
                camera.setTarget(BABYLON.Vector3.Zero());
                var box = BABYLON.Mesh.CreateBox("Box", 4.0, scene);
                return scene;
            }
    
            var scene = createScene();
            engine.runRenderLoop(function () {
                scene.render();
            });
        });
    </script>
</body>
</html>

 

That’s it for now.  In the next part we will explore cameras in more detail.

 

The Video

GameDev News , , ,

15. November 2016

 

First off, I apologize for the pun, I felt obligated to make it.  In a nutshell, Godot 2.2 won’t be happening, so stop waiting for it.  Don’t worry though, it’s for a good reason.  They just posted a status update on Godot game engine development and they have decided to skip the planned Godot 2.2 release and instead focus on Godot 3.0 development. 

In a nutshell, Godot 3.0 is going to have some pretty major low level changes (including new renderers) that would result in a great deal of the features expected as part of 2.2 to require reworking.  So instead these features will be delayed until after the release of 3.0.  So, what features were included in 2.2?  The marque features were C# support, Visual Scripting and the rudiments of networking support.  Don’t worry however, these features are still coming, simply delayed.

The main motivation for changing the roadmap is to release Godot 3.0 sooner. Within the Godot development team, our priority is always to work on what the community needs most at a given point in time - for the past year and a half, the focus has been on greatly improving the usability of the editor, as well as enhancing the 2D tools. Nowadays, Godot is a great engine for making 2D games, and the interest of the growing community is starting to move on to 3D, with corresponding needs for improvements.

For more than a year, Godot 3.0 has been promised to our users as the version that will bring a new state-of-the-art 3D renderer (albeit compatible with a wide range of graphics drivers, hence our choice for GLES 3.0 instead of Vulkan for the time being), and solve many issues and requests users have formulated regarding the current 3D renderer in Godot 2.1.

By skipping the 2.2 release, we allow ourselves (and mostly Juan, our renderer expert) to avoid a lengthy bug fixing and stabilization period on 2.x features. We are therefore aiming for a release of Godot 3.0 in early 2017, which would not have been possible if we had to focus on 2.2 right now.

 

Frankly I agree with this approach.  Most of the features of 2.2 are “nice to have”, while the functionality of 3.0 is more in the “need to have” category.  Fortunately there is some good news as well.  We should expect the 3.0 release to happen faster.  Lead developer Juan Linietsky has been hired full time for 6 months to work directly on Godot thanks to a Mozilla grant:

Last but not least, you might know that we were awarded a hefty sum by Mozilla as part of its MOSS Mission Partners program. This award was aimed at helping us improve Godot's HTML5 export by implementing the brand new WebGL 2.0 and WebAssembly technologies. As the former is basically the same API as GLES 3.0, it's best for us to work on both of them at the same time, so that we can ensure that GLES 3.0 / GL 3.3 and WebGL 2.0 will behave similarly.

Therefore, we decided, together with our non-profit home Software Freedom Conservancy to hire Juan Linietsky full-time for 6 months to work on the objectives funded by the MOSS award. This encompasses in particular the new renderer that will be done for 3.0, and extensive work on the HTML5 platform that might be done partly for 3.0 and in full for 3.1. As Juan is the project leader and our more prolific contributor, this will enable Godot to grow even faster than it has over the last couple of years.

 

Considering how much this guy has managed to accomplish when *not* dedicated to development, just imagine what he can do focused full time?

 

One last piece of bad but somewhat expected information in this update… Godot 3.0 wont be perfectly backward compatible with Godot 2.x and earlier.  I’ve always been pretty impressed with how well they’ve managed to support backward compatibility till this point.  Some of the underlying changes are unfortunately going to break compatibility.  Thankfully they will be providing tools to mitigate this as much as possible:

The new 3D renderer is the opportunity to do some important refactoring of Godot's internals. We also want to use this opportunity to revamp, homogenize and enhance some parts of the API, to make Godot 3.0 a solid base for the further development of the engine and of Godot games.

What does this mean for users? Moving from Godot 2.x to Godot 3.0 will require porting the existing projects to take into account the API changes and the new way resources will be setup in 3.0.

We will provide tools to help with the conversion as well as extensive documentation, so do not worry. You can continue (or start) using Godot 2.x already, as most of the API and workflow will still stay the same, so 98% of what you are doing in 2.x will still be relevant in 3.0.

 

If you were currently waiting on C# or Visual scripting support, this news might be a bit of a let down.  Over all though, I think everything announced makes a great deal of sense.

GameDev News

15. November 2016

 

Epic have just released a new version of the Unreal game engine, 4.14.   Visual Studio 15 support, a new forward shading renderer, Sequencer improvements and more fill out this release’s key features.

 

From the release notes:

WHAT’S NEW

Unreal Engine 4.14 introduces a new forward shading renderer optimized for VR, enabling crisp multi-sampled anti-aliasing in your games. The new Contact Shadows feature renders beautifullyUE414 detailed shadows for intricate objects. We've also introduced a new automatic LOD generation feature for static meshes that does not require a third-party library.

We’ve streamlined the animation tools to help you be more productive, and added many new features to Sequencer (UE4’s non-linear cinematic tool), as well as improvements to vehicles, clothing and animation Blueprints.

For mobile developers, Vulkan support is ready to use on compatible Android devices! And, we've added various new mobile rendering features such as reading from scene color and depth, and the ability to draw 3D objects on top of your UI.

On the Windows platform, C++ programmers can now use Visual Studio "15" for development. Visual Studio 2015 is still supported.

 

As always you can download the newest version using the Game Launcher.  You can read a great deal more about the new features here.

GameDev News

15. November 2016

 

Microsoft leaked a bit of announcement ahead of their upcoming connect(); developer conference.  Visual Studio is coming to Mac OS!  While getting a bit long in the tooth, Visual Studio is perhaps the best IDE available today – it’s certainly leagues better than Xcode.  Then again, writing your code using Morse code is better than Xcode.  As someone who does a fair bit of cross platform development, I was pretty stoked by this development.

 

*Was*

 

Sadly the announcement is nowhere near as good as it at first sounds.  Turns out it isn’t Visual Studio they are bringing to MacOS.  Instead they have simply rebranded Xamarin Studio (which they acquired earlier this year) as Visual Studio for Mac.  Boo. 

 

Although Microsoft took down the premature release, it is available via Google cache:

Below the surface, Visual Studio for Mac also has a lot in common with its siblings in the Visual Studio family. Its IntelliSense and refactoring use the Roslyn Compiler Platform; its project system and build engine use MSBuild; and its source editor supports TextMate bundles. It uses the same debugger engines for Xamarin and .NET Core apps, and the same designers for Xamarin.iOS and Xamarin.Android.

Compatibility is a key focus of Visual Studio for Mac. Although it’s a new product and doesn’t support all of the Visual Studio project types, for those it does have in common it uses the same MSBuild solution and project format. If you have team members on macOS and Windows, or switch between the two OSes yourself, you can seamlessly share your projects across platforms. There’s no need for any conversion or migration.

 

Sadly this means no C++ support.  I think the worst part of this release is it basically guarantees that the “real” Visual Studio is never coming to OS X.  Perhaps more worrying... perhaps the future of Visual Studio on Windows is this rebranded Xamarin Studio.  Given that they just released Visual Studio 15 preview 5 this seems unlikely.

GameDev News

Month List

Popular Comments

PlayStation Mobile Development Cookbook now available for download and listed on Amazon
Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


Home > >

26. March 2013

 

As I mentioned earlier this week, I just finished publishing my first book, the PlayStation Mobile Development Cookbook.  Since then it has been making it's way through the publishing chain.

 

 

Right now it is much more widely available.  

 

 

You can purchase and download a digital copy on Packt's website now.  Digital copies are available in epub, mobi and PDF formats.  The source code bundle is also available.  Just a bit of a warning, it weighs in at a hefty 158MB.  What can I say… there's lots of code in this book.  You can also order a print copy from the Packt website.

 

 

The book is also now on Amazon.  The Kindle version is available for download right now.  The print version ships on March 28th ( Thursday ).

 

It should also be up on Barnes and Noble and Safari Books Online shortly, I will update when links are available.   I have to say, seeing your name up on Amazon.com is a rather cool feeling! :)

, ,

blog comments powered by Disqus

Month List

Popular Comments