FreeGameDev Planet - Development

Also check out the games planet.

April 28, 2017

Cocos2d-x

Cocos2d-x v3.15 released!

We are happy to announce the release of Cocos2d-x v3.15! This release brings bug fixes and API maintenance, as well as these highlights: Full Android Studio supports: include editing, compiling and debugging c++ codes: doc Audio engine uses tremolo and

by linshun at April 28, 2017 06:05 AM

April 25, 2017

OGRE

Ogre3D 1.10 released

We finally tagged the Ogre 1.10 branch as stable (tag: v1-10-4), making it the new current and recommended version. We would advise you to update wherever possible, to benefit from all the fixes and improvements that made their way into the new release.
This release represents more than 3 years of work from various contributors when compared to the previous 1.9 release. Notably, it includes the following three GSoC 2013 projects:

The ResourceManager redesign GSoC was superceded by the strict mode CMake switch.
Enabling the strict mode is highly recommended, however the default is legacy mode to ensure compatibility with existing projects.

Additionally it includes the changes from the git fork that got merged back into default. The fork formally did the 1.10.0 release, thats how we ended up with 1.10.4 here.

Currently we don’t have any published SDKs yet, since we still rely on team and community members to help with the building and packaging process and that takes some time of course. We will update the download page as they become available and also try to update the announcement thread in the forums.

Changes

For an detailed overview of the new features see the New And Noteworthy Document. Among the highlights are:

  • Python bindings as a component
  • vastly improved GL3+/ GLES2 renderers with GL3+ now being the recommended choice on *nix systems
  • Bites Component for rapid prototyping of applications
  • Emscripten platform targetsupporting Web Assembly & WebGL2
  • improved build system, automatically fetching all required dependencies.
  • A new HLMS Component implementing physically based shading
  • Unified Documentation: the API docs, the manual and some Wiki pages have been merged and are now managed with Doxygen. As a consequence, the Wiki is outdated when it comes to OGRE 1.10. If you find something particularly missing, feel free to submit an additional tutorial.

Despite the amount of new features OGRE 1.10 provides the smoothest upgrade experience between OGRE releases so far. See the API/ ABI change overview for OGRE 1.7 – 1.10 that is kindly provided by ABI-laboratory.
Note that some components are marked as [BETA]. This does not mean that they are likely to crash, but that we can not give any API stability guarantees for them right now. You should expect their API to change without a deprecation period while we we iron the warts out as the Component get more exposure.

In turn for the core components, our deprecation list has grown considerably. You can keep using these APIs for now, as we intend to support them until OGRE 1.11. Speaking of which; to make OGRE releases predictable, we will switch away to a feature based to a time based release model for the 1.x branch. This means that you can expect OGRE 1.11 in April 2018.

Contributors

We would like to thank everyone who helped us make this release possible. The following list shows a list of contributors for 1.10 based on the git logs:

Pavel Rojtberg, Eugene Golushkov, David Rogers, Jesse Johnson, Murat Sari, Lior Lahav, Peter Szücs, Philip Allgaier, Matías N. Goldberg, Sasu Robert, Assaf Raman, Jannik Heller, lunkhound, Juan Borda, Daniel K. O., Jan Drabner, Transporter, Ahmed Allam, Flavien Bridault, Lf3T-Hn4D, J. Edward Sanchez, Mattan Furst, Shenjoku, arkeon, nxgraphics, 0xc0deface, Alexpux, Caleb Bartholomew, Christian Refvik, Harald Reingruber, Stefania Pedrazzi, Unknown, ja0335, threax, Al Reay, Andrew Piper, BAntDit-PC\BAntDit, Bastian Köcher, David Reepmeyer, Inifinity, Joel Croteau, Tomáš Kováč, tangren, Arroy One, Charles Prévot, Chris Burns, Daniel Brall, Daniel Gouvêa, Jean-François Verdon, Joël Lamotte, Matthew Fletcher, Misha, Oleksiy Ivanov, Simon Willshire, al2950, xantares, Alex Peterson, Alexey Knyshev, Andrew Fenn, Arroy, Bruno Sanches, Carsten, Crashy, Dainius Vaiksnys, David Avedissian, Denis CARLUS, Francesco Guastella, Gauthier POGAM–LE MONTAGNER, Glenn Ramsey, Holger Frydrych, J W, James Chen, Joe Brown, Justin Grant, KoenMertens, KungFooMasta, Mako_energy, Marcin Juszkiewicz, Michaël Broutin, Osamu Takasugi, Richard Plangger, Robert Hildebrandt, Robin Norrman, Ryan Thoryk, SNiLD, Sam Hocevar, Steve Peters, TheOnlyJoey, Ziriax, emilie.harquel, mkultra333, philiplb

BTW: if you want to contribute to OGRE, you can now use github as well.

by Pavel Rojtberg at April 25, 2017 09:48 AM

April 24, 2017

Castle Game Engine

Ray-tracer improvements (aka “Did you know our engine has ray-tracer?”)

I was playing with the ray-tracer inside Castle Game Engine this weekend. Although the focus of our engine is real-time rendering (not a software ray-tracer), but there is a distinct pleasure when you’re able to generate pretty images without the help of OpenGL:)

New ray-tracer features:

  • It can now use smooth normal vectors.
  • Classic ray-tracer supports now 2D textures, with bilinear or nearest filtering.
  • It looks at Background.skyColor.

You can try it out e.g. using view3dscene Ctrl + R (“Display -> RayTrace!” menu item). From code, you can use the CastleRayTracer unit.

The ray-tracer in CGE is still just a toy subproject for me. Our ray-tracer does not try to compete with professional, full-featured ray-tracing renderers existing today. But it is a nice demo that, using Castle Game Engine API, you can take a scene and create a decent ray-tracer, because

  1. All the necessary information about the 3D scene is available,
  2. You have a fast structure (octree) to perform ray collisions.

I hope that you enjoy it!:) If anyone here is interested in putting more work into this way of rendering (we have classic ray-tracer and a path-tracer), if you dream about creating a real, full-featured physically-based solution, than please join the development of CGE! I would happily see someone extend the CGE ray-tracer to render some really cool stuff! 🙂

An old gallery of images is here.

by michalis at April 24, 2017 05:47 PM

April 23, 2017

Piston

Existential Paths

In this post I will report a big breakthrough in the ongoing research on path semantics.

Link to paper: Existential Paths (work in progress)

Since people asked me what the heck is path semantics, I made an Illustated History of Path Semantics with Stick Figures.

I also made an introduction to the notation in the last blog post about non-existence of monoid symmetric paths. Since then I have figured out how to expand the technique to asymmetric paths.

Path semantics is the idea that some functions have secrets, and those secrets can be expressed as functions, which in turn can have other secrets, and those secrets can also be expressed as functions etc.

This is very different from how most computer treats functions, because they only use them for computation.

For example, if you define a function:

add(a, b) = a + b

In most programming languages, the computer only see this function as a computational procedure. You give it some values as arguments and you get a value out.

However, in path semantics, you can write things like this:

add[even] <=> eq

This means that add hides secretly the behavior of eq that is unlocked using the even function.

When you have functions connected to other functions by functions, it gets confusing, so you say add has a path to eq by even.

A path is a function in some mysterious space called “path semantical space” where all functions are connected. When you explore and learn about this space, you can “backproject” paths as patterns to tell something about large number of functions.

It also happens that these paths are predictors, so you can use them in machine learning.

Path semantics is actually closely related to type theory, because you can use the notation to define sub types:

fn concat(a: [], b: []) -> [] { ... }
fn len(a: []) -> usize { ... }

// When concatenating two lists, you can think of it as sub types `[len] n` and `[len] m`
// returning a sub type `[len] n + m`.
concat(a: [len] n, b: [len] m) = [len] n + m

// Short form.
concat[len] <=> add

Creating a type checker for path semantics turned out to be a seemingly impossible problem…

…until today!

The new breakthrough is the discovery that there are other kinds of paths out there, and one particular kind called “existential path” is closely connected with normal paths.

In fact, it is so closely connected, that it might be possible to make a type checker using them some day.

Simply put, if you have e.g. a: [len] 0 then there exists a function len' such that:

a: [len] 0

0: [len'] true

This checks the sub type for all a. In this case, we know that there are lists of all lengths:

len'(x) = x >= 0

// Alternative notation.
0: (>= 0)

Since we have a concrete value 0, we can just evaluate len'(0) and check if it returns true.

Actually, this f' function corresponds to the post-condition of f, and a lot of smart people have already worked on this already. This means we can reuse current tools for theorem proving!

You might notice that there should also be a function len'' such that:

0: [len'] true

true: [len''] true

This is correct! It could go on forever, right? Luckily this leads to a repeating sequence:

// There are only two options for all functions.
f'' <=> {id?, true_1?}

id' <=> true_1
true_1' <=> id

So, after 2 steps, we can just hard code everything in the type checker there is to know about these functions.

This is a very recent breakthrough, but I am already thinking about how to set up the inference rules.

For example, if you type this:

a: [len] 0 & [len] (< 2)

Since these sub types are using the same function len, and 0 is a concrete value, one can reduce it to this:

0: (< 2)
0: [len'] true

April 23, 2017 12:00 AM

April 22, 2017

Castle Game Engine

CommonSurfaceShader in view3dscene and Castle Game Engine implemented:)

I’m proud to announce an initial implementation of CommonSurfaceShader in Castle Game Engine and view3dscene! CommonSurfaceShader acts as a powerful “material on steroids” X3D node, in particular with support for normal maps (bump mapping).

1. The documentation

2. The demos

3. To try this *now*, you can use view3dscene from our “nightly builds”. Or you can compile any of the engine tools (like examples/3d_rendering_processing/view_3d_model_basic ) using the engine code from GitHub.

This is happening thanks to the support on Patreon (https://www.patreon.com/castleengine). Robert Daniel Murphy sponsored improving the Blender exporter to be able to export normalmaps (and specular maps and similar) from Blender to Castle Game Engine easily. I took the idea a little further, and implemented it by adding the CommonSurfaceShader node to the engine, and then the Blender exporter will export an X3D file with the CommonSurfaceShader.

This way the Blender exporter will be improved for everyone, e.g. Instant Reality / X3DOM users will also benefit by having an exporter that can write CommonSurfaceShader.

More work is yet ahead (the Blender exporter, and the specular maps are not done yet). But the CommonSurfaceShader, with many basic fields, and normal maps, is supported now!

The CommonSurfaceShader works both for interactive rendering, and for our toy raytracer. It is also understood when editing materials in view3dscene (Edit->Edit Material->… menu items).

P.S. If you like view3dscene, or you’d like to request more view3dscene features like that, please support me on Patreon !:)

by michalis at April 22, 2017 08:33 PM