FreeGameDev Planet - Development

SGE Game Engine - SGE 1.5.1 Released

2017-07-19T20:20:36+00:00

Yesterday, I finally got around to submitting a hook for uniseg to PyInstaller, and I also finalized the 1.5.1 release of the Pygame SGE. The differences compared to version 1.5 are:

Uniseg is now an optional dependency.
The way fonts are handled has been tweaked. The previous attempt to alias common fonts has been removed, and the default font has been changed from the Pygame default to an assortment of monospace fonts, so Pygame's default font is only ever used as an absolute last resort. (The reason I wanted to do this in particular is because attempting to use the default Pygame font with PyInstaller crashes the game, and I wasn't able to figure out why. But the monospace fonts are a better default choice in my opinion anyway.)

Spring - Engine Testing - 104.0-RC1

2017-07-17T21:06:48+00:00

First release-candidate for 104.0!

Major Changes since 103.0

Added LuaMenu
GL3.0 set as the minimum required OpenGL version
Improved memory management to allow multiple Spring.Reload() calls.
A zillion bug fixes

Changes in Detail:
changelog.txt
git diff last rc to HEAD

Download
See the download page for how to get it.

Bugs
If you find a bugs, please report to Mantis.
Please attach infolog.txt to the report!

Happy testing!

Castle Game Engine - Dragon Bones

2017-07-17T18:47:35+00:00

You can now create 2D animations in Dragon Bones, a free software for 2D animations. It is a bit like Spine, but free! It can export to “Spine JSON” format, compatible with Spine (almost – it required a tiny trivial fix on the engine side). See how to export to Dragon Bones guide.

OGStudio - OpenSceneGraph guide

2017-07-17T09:28:08+00:00

This article summarizes the work we did to produce OpenSceneGraph cross-platform guide.

June marked the finish of OpenSceneGraph cross-platform guide with the publishing of the last (initially planned) tutorial. The tutorial describes how to build and run sample OpenSceneGraph application in Web using Emscripten.
In case you missed it, here’s a link to the final application. Open it in your web browser.

We started to compose the guide in February when we successfully managed to render a simple model on desktop, mobile, and web.
We spent 120 hours in five months to produce ten tutorials of the guide.

We have been doing OpenSceneGraph cross-platform guide for two main reasons:

Keep OpenSceneGraph cross-platform knowledge in easily accessible and reproducible form
Share the knowledge with OpenSceneGraph community to make it stronger

We believe we succeeded in both. Here’s why:

The guide repository has more “stars” (aka “likes”) than any other repository of ours
OpenSceneGraph project leader Robert Osfield said “Great work”, which means a lot
The guide already has two issues

Reaching our goal of researching OpenSceneGraph cross-platform development and providing the knowledge back to the community just made us happier.

However, our journey does not stop here. Using the knowledge of the guide, we now continue to work on bringing our tools to support desktop, mobile, and web, just as we promised in January.

That’s it for summarizing the work we did to produce OpenSceneGraph cross-platform guide.

IoQuake3 - Auto-Update Update

2017-07-14T08:46:08+00:00

Ryan “icculus” Gordon has surprised us with a cross-platform auto-updater for ioquake3.

Created thanks to contributions to his patreon campaign, here’s how Ryan describes it:

I’ve written an autoupdater for ioquake3, with the intention of the game operating much like Google Chrome…it just stays up to date and you don’t really notice. This has been a long-time wishlist item for the ioq3 team…as they are locked out of platforms like Steam, they’ve been stuck telling people to download the game over and over, maybe migrating their mods, or live without new features and fixes.

Once this solidifies, the official builds will just keep staying up to date, which is pretty sweet. And of course, this is optional, so it won’t interfere with distro packages and such.

We still need to implement the network infrastructure behind the update mechanism, but this is a very important and large first step on that road.

You can browse the code in this pull request and this update that added more security features to the process.

Or read more about the updater in these three blog posts from Ryan:

Please contribute to Ryan’s patreon campaign if you enjoy his work.

If you’d like to support ioquake3 in a roundabout way I am selling t-shirts and hoodies for Nuclear Monster.

ioquake3 is an entirely volunteer-run project and we still need your help, please check out this page on our wiki for more information.

Castle Game Engine - Generics.Collections in the book and CGE

2017-07-13T23:55:33+00:00

To help you familiarize with the Generics.Collections unit, I wrote a nice chapter about it in the “Modern Pascal Introduction”. It’s a longer chapter, with 4 nice examples using containers from Generics.Collections.

In the related news: complete migration to Generics.Collections in Castle Game Engine is done We now use Generics.Collections for all the purposes where we previously used the FGL and CastleGenericLists units. This brings us closer to Delphi compatibility, and it makes code better (Generics.Collections works with records out-of-the-box, it has a TDictionary with a much cleaner API, etc.)

Also, Michalis is back from vacations, with lots of new strength

Cocos2d-x - Cocos Creator v1.5.2 released!

2017-07-13T08:04:22+00:00

When in the beta phase, Cocos Creator v1.5.2 has already got a log of of positive feedback. On the track of v1.5.1 patch, this version continues to further strengthen the stability and enhance the efficiency. The following describes the highlight…

Godot Engine - Beta release for Python support

2017-07-12T08:59:44+00:00

Emmanuel Leblond (touilleMan) just released the first beta of his Python for Godot interface, which will allow developers to use Python 3 and its complete ecosystem as a scripting language in Godot 3.0.

Godot Engine - Tests needed for Godot 2.1.4-beta

2017-06-25T18:14:52+00:00

Today's beta build for the upcoming Godot 2.1.4 version brings two months worth of development, including both bug fixes and new features, some of which potentially bolder than usual - with the long wait for Godot 3.0, many 2.1.x users grow restless and push to get the latest and shiniest included in the stable branch ;) As such, testers needed to make sure everything works flawlessly!

Castle Game Engine - Generics.Collections, vacations

2017-06-25T15:27:27+00:00

I am going on vacation, so I will be (mostly) offline for 2 weeks So, please have patience with any questions to Michalis — I will get back to you, but with some delay!

I don’t have a new screenshot from the engine for this news. Instead, I wanted to share some screens from the games I like — the games that inspired me to make games (and, subsequently, an engine to make games ).
The GitHub code now contains a start of migration from FGL unit containers to Generics.Collections unit containers. The Generics.Collections contains a much richer (and Delphi-compatible) generic containers. I use generics a lot in the engine code, so this will be a larger change.

The main classes from Generics.Collections are TList<T> and TObjectList<T>. TObjectList<T> is very similar to the TFPGObjectList<T> you know from FGL.

Generics.Collections were implemented in FPC by fantastic Maciej Izak, who also put a lot of work to actually make them part of the FPC standard library in FPC 3.1.1. In older FPC versions, we currently use a local copy of them (in src/compatibility/generics.collections/src/ ). This “compatibility” path should be automatically added to your unit search path for all our supported compilation methods. If you use the build tool, be sure to recompile the build tool after getting the latest code from GitHub.
The requirements on FPC version increase, in order to use Generics.Collections (unit names with dots). We now require now FPC >= 3.0.0. See also FPC versions supported docs.
I’m also working on a new improved API for vectors / matrices, based on advanced records, somewhat cleaner and also Delphi-compatible. More news when I’ll get back from vacations
Our Automatic Cloud Build server has now cool scripts to switch FPC versions, which allows me to automatically check that the engine compiles with various FPC versions, and on various platforms. I really enjoy continuous testing, time to set it up always “pays off” by doing a lot of things automatically for you, and Jenkins rocks!

Cocos2d-x - Interview with the developer of World of One

2017-06-22T08:10:18+00:00

Cocos2d-x is a game engine and we see a lot of great games made using it. Every once in a while a project comes along that uses Cocos2d-x in a unique way. We are excited to talk with Grimwood Team,…

Godot Engine - Make 2d games with Godot, last day on Kickstarter

2017-06-20T15:00:00+00:00

There are but a few days left on the Kickstarter campaign. It's been an enormous success, with over 4 times the initial goal! The backers unlocked every stretch goal, including 4 contributions to the official documentation. Here's what will improve in the coming year.

OGRE - x3ogre presented on the Web3D 2017

2017-06-19T12:22:27+00:00

At this year’s Web3D conference in Brisbane a new Ogre based X3D viewer, called x3ogre, was presented.

X3D is an ISO specified file format for 3D file transmission and interchange which is now natively available to Ogre.
The Web3D is a scientific conference concerning technologies like WebGL, X3D and glTF.

The presented viewer is called x3ogre and provides a layer for loading and manipulating X3D files inside Ogre.
Vice versa the Ogre Material and Mesh formats also become accessible inside X3D files.

To put the viewer on the Web the x3ogre leverages Emscripten and the GLES2 RenderSystem to get translated to WebGL2 and WebAssembly.

The MIT licensed implementation is available on github.

Even if you have no interest in using X3D, this is a good reference how to put Ogre on the Web and do JavaScript interoperability.

Cocos2d-x - Cocos Creator v1.5.1 released!

2017-06-19T06:38:56+00:00

In this version we have fixed a lot of issues from testing and user feedback, some of the major ones that will have a great impact include: 1. Improve the async callback mechanism when downloading assets, increase speed of the…

Castle Game Engine - Castle Game Engine 6.2 release – iOS, CommonSurfaceShader…

2017-06-19T01:20:56+00:00

We’re proud to announce the release of Castle Game Engine 6.2!

Download it from our main page.

New features in this release:

Trivially easy recompilation of your games for iOS (through an XCode project). You can now use our build tool to recompile the same game for all our platforms (desktops, Android, iOS, web plugin…). The iOS documentation was extended to describe everything necessary.
CommonSurfaceShader is our new “material on steroids” that allows you to configure material by normalmaps, specular maps, shininess maps, ambient maps… We include an extensive documentation and examples of it (in new demo models).
Improved Blender exporter. It’s now easier to install (it’s now a normal Blender add-on), and it can generate a CommonSurfaceShader node with all the goodies described above. The artist can now comfortably set normalmaps, specular maps and much more in Blender, and they “just work” in the engine.

The CommonSurfaceShader and Blender exporter improvements were implemented thanks to the support on Patreon. If you like what we do, please consider supporting the engine development on Patreon. This really helps me spend more time on the engine, and develop cool features like this!
Other build tool improvements, for all platforms:
- game_units attribute in CastleEngineManifest.xml.
- generate-program command for the build tool
- Places all the temporary output within castle-engine-output/ subdirectory.
- The configuration of build tool for Android is now simpler, it can guess all the locations from $ANDROID_HOME. Also the wiki page describing Android prerequisites was much improved.
Other API and examples improvements:
- TSound.Offset to get/set sound offset in time.
- Sound/music player in examples/audio/audio_player_scrubber.
- STL format support
- Our ray-tracer now supports textures and smooth normals.
- TCastleEdit (example in examples/2d_standard_ui/edit_box/ )
- Application.ParseStandardParameters, Application.Version

Together with the new engine, we also release a new version of view3dscene 3.17.0, our viewer for X3D and other 3D formats. As a tool developed using the Castle Game Engine, it inherits all the enhancements You will probably be most interested in new CommonSurfaceShader node and STL format support.

Castle Game Engine - Sound player/scrubber using Castle Game Engine

2017-06-16T20:21:02+00:00

I made a simple sound/music player using the Castle Game Engine It is available in the engine sources in examples/audio/audio_player_scrubber .

It has all the features you would expect:

Volume,
Loop,
Sound offset (position in time) control,
Programmer-designed user-interface (ah, this brings back good memories:).
It can open wav and ogg files, and plays them using OpenAL.

It was coded to show that TSound.Offset works cool. It’s a new property added today (for Eugene Loza, see here), allows to get/set the sound offset (aka “position in time”).

You can view the code on GitHub.

Castle Game Engine - Design-time editing of 3D world (initial fun), many other improvements

2017-06-15T23:58:39+00:00

First of all, I hope to finish and release Castle Game Engine 6.2.0 this weekend! So, watch this page closely.

The next release 6.4.0 will focus on Delphi compatibility, and start of visual editing (of 3D world and 2D controls) within Lazarus and Delphi. In all the pre-release excitement, I started playing around with it already today I added a property RenderAtDesignTime to the Lazarus OpenGL control (patch here), and I made a simple design-time menu to add a sphere to the SceneManager at Lazarus design-time. See the screenshots!

In other news, there is a bunch of engine features done recently, not announced properly yet. Here they are (officially coming in 6.2.0 release this weekend):

Rendering of normalmaps (through CommonSurfaceShader.normalTexture or Appearance.normalMap) was improved to work even when no diffuse texture is defined.
TCastleEdit: a simple edit box. Demo in examples/2d_standard_ui/edit_box/game.pas . Not perfect, but already useful anyway
New build tool command “generate-program”, to generate perfect starter program code and Lazarus lpi.
Added easy Application.ParseStandardParameters method to the TCastleApplication in CastleWindow, may be useful for your standalone games.
image_convert (in examples/images_videos/) has an additional command-line option –alpha-bleed, to perform “alpha bleeding” in batch mode.
Added TDebug3DCustomTransform – a simple reusable utility to debug bounding boxes and spheres of T3DCustomTransform (like T3DTransform or T3DOrient). A generalized version of what you get for creatures (the ones from CastleCreatures unit) when you use RenderDebug3D.
x3d-nodes-to-pascal is our new tool to parse X3D nodes and produce skeleton code to glue X3D with Object Pascal.

Godot Engine - Progress report April/May 2017

2017-06-14T09:39:49+00:00

The Godot Engine contributors were not idle during Juan's long holidays - lots of interesting features were implemented over the last two months, and they all converge towards making Godot 3.0 an impressive release! This progress reports covers the work done by all contributors apart from Juan, who will showcase his recent renderer improvements in the next progress report.

SGE Game Engine - SGE 1.5 Released - What A Mess

2017-06-11T13:43:28+00:00

A new version of the SGE specification and the Pygame SGE has been released. This is a relatively small, yet somewhat... chaotic release.

Let's start with the specification changes, which are relatively minor:

The way key names is handled has been made more generalized and flexible. Effectively, the total number of standard keys has been reduced (removing keys like "clear" and "super_left'), but the implementation is allowed to support any additional keys under names that start with "undef_", and it's been clarified that the engine is also allowed to not support arbitrary keys. This will help the specification accommodate other backends like Pyglet more, but more importantly, this fixed a problem with input methods (used for e.g. Japanese and Chinese text entry); the input method I use, at least, passed a keycode of "0", which was not actually defined as a key.

Fixed a typo in the documentation for sge.gfx.Sprite.swap_color.

Nothing too crazy there. The big change is not likely to affect anything, realistically (there's not really a reason to use e.g. the Super key).

But then there came the big Pygame SGE change: the way lines are split has been changed to a much better one, utilizing the uniseg module. This, to be clear, is a good thing. The previous method simply did not split lines properly, and uniseg seems to be the best module which currently exists to do it right. But it also turns out that uniseg doesn't work with PyInstaller; someone needs to make a helper for it.

So for now, I have released two versions of the Pygame SGE: the regular version which uses uniseg, and is therefore better but incompatible with PyInstaller for now, and a "badsplit" version which continues to use the old method based entirely on the ASCII space character. I will work on writing that helper for PyInstaller as soon as I can to clean up this mess. In the meantime, please use the regular version when you can, and use the "badsplit" version otherwise (i.e. when building with PyInstaller).

If you appreciate my work on the SGE, as always, please consider contributing to my Patreon page or my Liberapay page. Your support makes it possible for me to spend more time on these efforts and less time making money by other means. My Patreon and Liberapay pages are here:

https://www.patreon.com/onpon4

https://liberapay.com/onpon4

Castle Game Engine - Upgraded all rewards

2017-06-09T09:49:17+00:00

Support the engine development on Patreon ! We have just upgraded all the reward tiers, so now:

1 USD gives you access to all private posts on Patreon,
5 USD allows you to request new engine features each month,
10 USD allows you to request new game each month,
50 USD gives you access to the cloud build server (https://michalis.ii.uni.wroc.pl/jenkins/) !

Thank you!

P.S. Working hard on CGE 6.2.0, release very soon !:)

Orx - IgnoreFromParent feature added to Orx

2017-06-09T03:13:30+00:00

For those who want to experiment, a new small-but-useful feature has been added to the development version of Orx. It allows to specify which part(s) of a frame transformation coming from a parent you want to ignore.

In short it means that you can have a child object, spawner or camera that can ignore the parent's, rotation, position or scale. Or to scale an object without scaling its children, be them particles, camera, attachments, etc.

This can all be configured via your game's config instead of having position updates in code.

This is incredibly useful for creating shadow effects or attachments to an object that should not rotate or scale when the parent does.

There are a couple of useful examples here and here, and a more comprehensive tutorial on all the possibilities is in currently in progress.

OGStudio - iOS tutorial

2017-06-08T15:22:17+00:00

This article describes problems we faced during the creation of iOS tutorial in May 2017.

This February we managed to get simple model rendered under iOS in just a few days. We expected to finish iOS tutorial in no time. However, the reality reminded us: it’s easy to come up with a hackish demo that works for one person, but it’s hard to create a concise example that works for everyone.

Native library

The first question we had to answer was: should the sample application be part of Xcode project or be a separately built library?

We had to consider the following facts:

Xcode project can use C++ directly (thanks to Objective-C++) without stuff like JNI

There’s no need for a separate library (+ application)
Creating a separate library is an additional work (- library)

OpenSceneGraph builds libraries

It’s easier to use standard build process (+ library)
It’s harder to create custom build process just for a single platform (- application)

OpenSceneGraph uses CMake build system, which is not supported by Xcode

Xcode project can’t include CMake files (- application)
It’s easy to create custom CMake file that includes OpenSceneGraph CMake file to build a single library (+ library)

CMake can generate Xcode project

It’s possible to create a CMake file that builds both OpenSceneGraph and the sample application (+ application)
Xcode is the de-facto tool to create Xcode projects; it’s easier to use standard build process (+ library)

After evaluating the pros and cons of each approach, we decided to turn the sample application into a library and include it in Xcode project. The downside of this approach is that simulator and real device builds need separate library builds.

Refactoring

The second question we had to answer was: should there be a single source code base for all platforms or several ones, one for each platform?

While doing Android tutorial we used single source code base because it worked fine for desktop and Android. As we started to work through iOS tutorial, it became apparent that particular features may or may not work on some platforms. For example, one feature may work on desktop and iOS, but not Android. Another feature may work on iOS and Android, but not desktop. Since we didn’t want to pollute the code with #ifdefs, we started to put each platform combination into a separate file. The number of files grew rapidly. The files were reusable, but it became extremely hard to see the whole picture.

At this point, we realized there’s the second question. We reminded ourselves that the main purpose of the sample source code is to teach how to do basic OpenSceneGraph things, not create a reusable library with API that is stable across several years.

That’s when our home grown feature tool came into play. With its help, we separated the code into several parts, which in the end produce just two files for each platform:

functions.h – contains reusable classless functions
main.h – contains the rest of the sample application code

Their contents differ slightly for each platform, but it’s easy to see the whole picture now.

That’s it for describing problems we faced during the creation of iOS tutorial in May 2017.

Piston - What is Happening 4

2017-05-29T00:00:00+00:00

Follow @PistonDeveloper at Twitter!

Here are some of the things that happened since the last post:

AdvancedResearch

Advanced research focuses on making conceptual breakthroughs in system thinking. The previous advanced research under the Piston project is moving to this new open source organization. You can read about the rationale of separating this research from the Piston project here.

Some bullet points of the overall progress:

New approach to mathematical foundation of friendly artificial intelligence nicknamed “golden rationality”
Some progress on path semantics and generalizations to probability theory
Gini solvers could balance economic inequality (can be tested in MMOs)
Established contact with scientists and engineers about mitigating climate change

Golden rationality is a very recent topic, where I try avoiding the scary first order approximation to friendly superintelligence and instead focus on human value approximation concerning group strategies. This means it is not about superintelligence “in a box”, but about beating the efficiency of individual rational agents in a world where AI is standardized and utilized by many people. For discussion and questions, open up an issue here.

Normal research related to gamedev will continue under the Piston project.

Conrod

New CollapsibleArea widget
Improved performance
Added crates.io categories
Various bug fixes and improvements

List of contributors (59)

Image

There is an internal compiler bug on Rust 18 Beta, so if you have troubles compiling your project, you might want to use Right stable or nightly instead.

Simple BMP support
PPM support
New constructor for adjusting quality of JPEG encoding

List of contributors (89)

Imageproc

Improved performance, incluing better parallization using Rayon
Added more benchmarks
Ellipse and bezier drawing
Various bug fixes and improvements

List of contributors (14)

Dyon

New intrinsics
Optional namespaces with shared aliases
Link loop (a loop that concatenates body expressions using Dyon’s link data structure)
Try expressions (turning errors into result)
Various bug fixed and improvements

List of contributors (4)

VisualRust

Cargo support
Support for both Visual Studio 2015 and 2017
Various bug fixes and improvements

List of contributors (14)

Other projects

New versions of Gfx has been updated through the ecosystem
resize has gotten nice upgrades and performance improvements
music now supports sound clips

Castle Game Engine - Updates to the “Modern Object Pascal Introduction for Programmers”

2017-05-28T19:08:33+00:00

I wrote a few new chapters to the “Modern Object Pascal Introduction for Programmers” book:

It is also available now under a shorter URL, on a new domain for our Castle Game Engine. The book is not tied to the Castle Game Engine (I want it to be something useful on it’s own). Although it is also part of my plan for “how Castle Game Engine can succeed”, as it helps programmers interested in Castle Game Engine to use the Object Pascal language If you like it, please consider supporting me on Patreon !

Cocos2d-x - Cocos Creator v1.5 Released!

2017-05-23T02:43:23+00:00

We are happy to announce the release of Cocos Creator v1.5! This version 1.5 update focuses on the lack of features for action games large-scale project development, through the provision of physics engine, camera and TypeScript support. Cocos Creator is…

Castle Game Engine - In Space Everyone is Screaming (gamejam game:)

2017-05-23T00:54:28+00:00

Simple platformer-shooter done during 12-hour gamejam using Castle Game Engine! Binaries on https://gitlab.com/michaliskambi/in-space-everyone-is-screaming/tags/v1.0 , source code on https://gitlab.com/michaliskambi/in-space-everyone-is-screaming . This is really just a technical beginning, without any playable level design, or fancy enemies swarms, or graphics.. But it’s a working start, with jumping and shooting and enemies, ready to be extended!

Godot Engine - Make Professional 2d Games with Godot: Kickstarter LIVE

2017-05-22T10:00:00+00:00

Do you want to become a better game developer with Godot? GDquest, who makes game creation tutorials with open source tools, is on Kickstarter, with our full support!

Piston - Announcing Dyon-Snippets

2017-05-22T00:00:00+00:00

The Piston project is pleased to announce Dyon-Snippets, a place to share Dyon source code and discuss library design!

Dyon is scripting programming language started in 2016 by myself (Sven Nilsen, bvssvni).

Dyon started as an experiment in a period I had a lot of time, while waiting for some important Gfx redesigns. After a week of coding, I discovered that it was possible to use a lifetime checker (like Rust), but without borrow semantics (unlike Rust) instead of a garbage collector. Combined with copy-on-write for non-stack references, this creates a very limited memory model but sufficient enough for many practical applications. It is difficult to write object oriented code in Dyon, but it is very nice for iterating over arrays.

Built-in support for 4D vectors and HTML colors
Packed loop for mathematical index notation
Secrets (more about this later)

The language uses dynamic loading of modules to organize code, where you have full control over module dependencies. It is very common to write a loader script, a program that runs before you run the actual program.

Here is an example:

fn main() {
    foo := unwrap(load("foo.dyon")) // Load `foo`.
    bar := unwrap(load(source: "bar.dyon", imports: [foo])) // Load `bar` with `foo` as dependency.
    call(bar, "main", []) // Run the function `main` on the `bar` module.
}

This allows a kind of programming where you easily control how stuff gets loaded, e.g. check for for updates or refresh a module every Nth second.

I often use Dyon for problem solving, because the language has a feature called “secrets”. A secret is a hidden array of values associated with a bool or f64. The type is sec[bool] or sec[f64]. The indexed loops in Dyon are integrated with secrets.

For example, you have a 2D array v and compute the maximum value:

m := max i, j {v[i][j]}
println(m) // Prints maximum value of `v`.

Dyon infers the range from the loop body. The code above is equivalent to:

m := max i [len(v)), j [len(v[i])) {v[i][j]}

This is a packed loop which is equivalent to:

m := max i [len(v)) {max j [len(v[i])) {v[i][j]}}

The notation max i, j {v[i][j]} is inspired by mathematics. In mathematics and physics it is very common to use indices and custom loops. It is easy to translate back and forth between equations and Dyon code, and it helps you learn mathematics as well!

The type of m is sec[f64]. You can write the following:

where_max := where(max)
println(where_max) // Prints `[i, j]`.

This is how it works:

The inner max loop returns the maximum value with a secret [j].
The outer max loop finds the maximum inner value and changes the secret to [i, j].

A secret propagates from the left argument in binary operators. This means you can combine any and all loops with max and min:

// Is there any list which maximum value is larger than 10?
m := any i {max j {v[i][j]} > 10}
if m {
    println(why(m)) // Prints `[i, j]`.
}

In problem solving this is very convenient, because many problems can be thought of as formulating a question. When you know the right question to ask, the answer is often easy to find.

FLARE - 20161016

2017-05-17T10:32:17+00:00

Hey everyone, it's Justin (dorkster). Clint pointed to my blog as a venue for updates in Flare engine development, yet I've fail

FLARE - 20160605

2017-05-17T10:32:17+00:00

HD art, one slice at a time We have parallel projects going for Flare, based on the strengths that various contributors are

Godot Engine - Godot course on Kickstarter next Monday!

2017-05-15T11:51:10+00:00

GDquest, content creator and gamedev teacher of Krita and Godot fame, will soon start a Kickstarter campaign for a professional quality game creation course targeting the upcoming Godot 3! Among Godot developers, we are all thrilled about the project and want it to be a huge success, so mark the date and be sure to support the campaign!

Castle Game Engine - Build tool, iOS, Android great improvements!

2017-05-14T20:24:17+00:00

First of all, I’m proudly attaching a few images of various games using Castle Game Engine running on a real iPhone:)

Our build tool got some significant improvements lately. I hinted about some of them in the recent “Easy compilation for iOS” announcement, but actually there’s more, and some of them benefit all platforms Here are the details:

Using the "castle-engine-output" directory for compilation temporary files (.ppu, .o), and for Android and iOS projects. The advantages:
- The compilation files are kept per OS/CPU, so they can be reused more (no need to recompile everything just because you switch platforms).
- The Android project is in a predictable location (not in some /tmp/castle-engine-), which is useful to run ‘ndk-gdb’.
- The iOS project is in a predictable location, which is useful to run XCode.
Project files (lpr) for Android, iOS (and soon — for others too) can be auto-created. So you really don’t have to write anything to recompile your project for a new platform. You only need to provide game_units in CastleEngineManifest.xml, and make sure your units initialize Application.MainWindow . Make sure you define game_units in CastleEngineManifest.xml.
Android packaging process fixes and updates.
- CGE code fix for using (exact) FPC 3.0.2 to cross-compile to Android.
- The build tool no longer requires so many things (from Android SDK and NDK) on $PATH. It can guess everything’s location now from ANDROID_HOME (your SDK location).
- Much improved wiki page about installing Android dependencies. In particular, it contains now screenshots how to use the “SDK Manager”, that is integrated in “Android Studio” and replaces the old “android” GUI tool from previous SDK versions.
iOS-specific improvements:
- The iOS wiki page was much improved and updated, to describe the process of compiling to iOS.
- The src/library/compile-iOS.sh script was reworked and updated. Many changes, but in principle it should generate exactly the same thing:)
- The "castle-engine compile --target=ios" is available, and generates a ready libxxx.a to be inserted into an XCode project.
- CastleWindow “library” interface (used for iOS in a library) simplified.
- Package any game for iOS! Just run "castle-engine package --target=ios" and you get an XCode project, that compiles out-of-the-box in XCode, and can be tested and published from XCode. You can add --mode=debug if you like.

Cocos2d-x - Powered by Cocos2d-x, A Good Interview with Colorcast Developer

2017-05-12T06:56:23+00:00

Colorcast free was developed by two developers with the support of a three additional collaborators. With the aim of take feedback from final user, an alpha version was presented on Gamelab 2015 (http://gamelab.es/2015/indie-hub) where the game was well received and…

OGStudio - OSG sample

2017-05-12T02:11:39+00:00

This article describes creation of the tutorials for building sample OpenSceneGraph application under Linux, macOS, Windows, and Android in April 2017.

Previous tutorials described how to install OpenSceneGraph under Linux, macOS, Windows and render a model using the standard osgviewer tool. This time we worked on a sample OpenSceneGraph application that would run under Linux, macOS, Windows, and Android.

The application is very basic and has the following features:

Render window creation
Model loading
Model rendering with simple GLSL shaders
Model motion with a mouse under Linux, macOS, Windows and a finger under Android

Creating the tutorials for Linux, macOS, Windows was so easy and straightforward, that it only took us half a month. We spent the second half of the month creating Android tutorial.

Our first successful Android build last year included hacks and non-obvious steps to make OpenSceneGraph run under Android. This time we wanted a cleaner, faster, and cheaper approach.

The approach we ended up with requires just a few files and a few changes to the original Android Studio project (with C++ support) to make sample OpenSceneGraph application run under Android.

Here’s a quick rundown of the files:

GLES2 surface
Render activity to render to the surface
Native library Java interface
Native library C++ implementation
CMake file to build native library
Render activity layout
Model to display

Here’s a quick rundown of the project changes:

Update Android manifest to use GLES2 and render activity
Reference native library’s CMake file in the project’s CMake file

OpenSceneGraph documentation suggests building OpenSceneGraph outside Android Studio with CMake. However, this approach has the following limitations:

You have to build OpenSceneGraph for each target architecture
You have to manually copy/reference built OpenSceneGraph libraries into Android Studio project

Our approach includes building OpenSceneGraph for those target architectures that Android Studio project is built for. Also, OpenSceneGraph is already referenced, so no extra work is required: you just need to rebuild the project, and you’re done.

That’s it for describing the creation of the tutorials for building sample OpenSceneGraph application under Linux, macOS, Windows, and Android in April 2017.

Orx - Orx article on opensource.com

2017-05-09T11:09:38+00:00

An article "Getting started with Orx" has been published at opensource.com. It introduces the Orx Portable Game Engine, the community and available resources.

You can find it at: https://opensource.com/article/17/5/getting-started-orx-open-gaming-engine

Castle Game Engine - Easy compilation of your games for iOS

2017-05-06T04:12:24+00:00

Trivially easy compilation of your games to iOS!!!

You can now take any Castle Game Engine game, and recompile it for iOS (iPhone, iPad) easily. No need to write *any* iOS-specific code. Short instructions:

Follow iOS documentation to get FPC, with a cross-compiler, for iOS targets.
Inside CastleEngineManifest.xml, define game_units="...", listing the necessary game units to be included in your lpr. It’s often just a single unit, that pulls other units along as dependencies.
Run "castle-engine package --target=ios --verbose" in console.
Open the resulting project in XCode. From XCode you can build it, run it in a simulator, publish… I emphasize that the project builds out-of-the-box on Xcode, zero modifications on your side are necessary. Just open the project, and press “Run” button in XCode.

I will be posting more details (and polishing some rough edges) soon Learn more about the build tool (“castle-engine”) and CastleEngineManifest.xml at these wiki pages. I just updated them with information about --target=ios and game_units.

Many thanks go to Szymon Stoma and Ten Square Games for making Apple hardware available to me, making it all possible!

And a great many thanks to Jan Adamec, who made the initial iOS work in our engine! Everything I did was just rehashing of that work, to integrate it with the build tool.

Allegro - Allegro on TuxFamily!

2017-05-05T04:17:36+00:00

Piston - Announcing Binpool

2017-05-05T00:00:00+00:00

This blog post is about a new experimental uniform binary format for particle physics: Piston-Binpool

Background

Currently I am diving deep into marine cloud brightening to understand how humanity can avoid some severe effects of climate change by using some form of clean and reversible geoengineering. If you did not know already, there have been some very worrisome observations in 2016-2017, so I thought it was a good idea to educate myself a bit and perhaps get some input on what technological challenges there are. The scientists and engineers working on this have been quite open and even sent me papers to read! Thanks guys.

While reading about this, which seems to require understanding of climate modelling (it is understandable if you take your time), I figured doing some basic virtual physics experiments could help my brain along the way. Nothing advanced yet, just freshing up some of the things I played around with over the years.

One thing I discovered, that it is not obvious what kind of analysis you want to do with a virtual experiment. Instead of running simulations over and over, I would like to collect the raw data and later run algorithms that computes some functional relationship.

The advantage of this method is that you can exploit some physical similarites between systems. For example, it is commonly known that certain physical behaviors can transfer knowledge between a model and the full size system. So, collecting data about some few particles colliding in a slow motion simulation, can give you knowledge about particles colliding in high velocities and over a huge area. This way you can save both time and energy, because you do not have to simulate every detail of a full system.

This is also interesting because I came across similar ideas when researching path semantics. Studying physics could help design algorithms that predict approximate behaviors of other algorithms. One long term goal is to develop a constraint solver that can assist with engineering tasks.

Motivation and design

I could not find a standard format for storing and reading particle data in a such way that you can reuse algorithms between projects, so I made my own experimental one.

Here is the format:

type format == 0 => end of stream
type format: u16, property id: u16
|- bytes == 0 => no more data, next property
|- bytes: u64, offset instance id: u64, data: [u8; bytes]

The first flag is a type format, which supports 10 common Rust numerical primitives, with vector and matrix dimensions up to 80x80.

The second flag is a unique property id that identifies the property of the particle system. This is also used to define time, e.g. a f32 scalar.

Next the format stores the number of bytes in the data block and an offset instance id, such that you can read and write parts of the particle system (e.g. only the part that is dynamic or needed for analysis).

The number of particles in the block is derived from the number of bytes and the type format. You can also specify a custom binary format, in which case a general purpose analysis tool can just skip the block.

For each frame in a simulation, you simply write out a set of properties, and when reading back a frame you use a loop that breaks when all properties are set. More information about the usage is in the README file.

Future work

My hope is that I am able to reuse realgorithms across projects, for example a command line tool that computes the energy or the number of collisions.

Cocos2d-x - Cocos2d-x v3.15 released!

2017-04-28T06:05:18+00:00

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…

OGRE - Ogre3D 1.10 released

2017-04-25T09:48:51+00:00

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 target – supporting 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.

Piston - Existential Paths

2017-04-23T00:00:00+00:00

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

Piston - Slot Lambda Calculus

2017-04-20T00:00:00+00:00

In this post I will describe a useful technique for formal study of language semantics.

Link to paper (work in progress)

Usually when somebody mentions the words “language semantics”, people run and hide under their beds, hoping that the person uttering these words will not find them there any time soon.

Yet, I want to show that given the right tools, semantics does not need to be that hard to wrap your head around.

After reading this post, you should be able to claim something as powerful as:

There are certain rules that are valid for meaning in all languages, and I know what they are.

One reason semantics seems hard, is because we think of the world as this place of infinite possibilities, and since language is used to describe what happens in the world, then the meaning of language must consist of infinite possibilities.

Some of these infinite possibilites are:

When programming, people can type in a text editor, save to a file and use a compiler (complex)
When talking, people can use different sounds to change the meaning of words (complex)
When expressing themselves in art, people can shape an experience that points to something “elsewhere” (if this is not complex, I have no idea what complex is)

All these activities are related to the meaning of language, and this makes the world a complex place.

Slot lambda calculus is a tool that takes those “infinite possibilities” and makes them very, very simple.

Instead of an infinite number of ways of constructing expressions in a language, in slot lambda calculus there is only one way. For example, if you want to express 1 + 1 = 2:

    (_ = _)(_ + _)(1)(1)(2)

This gets turned into:

    ((1 + 1) = 2)

So, where did (_ = _) and (_ + _) come from? They were constructed the same way:

    (_ _)(?)(_ _)("=")(\)
    (_ _)(?)(_ _)("+")(\)

The ? symbol inserts a placeholder, and \ removes all ?s and turns all strings into syntax.

This gets turned into:

    (_ (= _))
    (_ (+ _))

When you have defined a pattern like this, you can write equations to make them nicer:

    (_ (= _)) = (_ = _)
    (_ (+ _)) = (_ + _)

Slot lambda calculus behaves similarly to normal lambda calculus, but uses a different application rule. Normal lambda calculus is even simpler, but more suitable for computation than reading new patterns created from existing patterns. However, there is a way to hack lambda calculus so you get slot lambda calculus! Mwuhahaha!

This is how you do it Dyon (without syntax extensions):

fn pass(f: \(any) -> any, val: any) -> any {
    return if typeof(val) == "closure" {
        \(x) = {
            val := grab val
            new_val := \val(x)
            f := grab f
            pass(f, new_val)
        }
    } else {
        \f(val)
    }
}

fn main() {
    add := \(x) = \(y) = (grab x) + y
    mul := \(x) = \(y) = (grab x) * y

    a := pass(add, mul) // (_ * _) + _
    b := pass(a, 2) // (2 * _) + _
    c := pass(b, 3) // (2 * 3) + _
    d := pass(c, 1) // (2 * 3) + 1
    println(d) // prints `7`
}

Notice that this is the exact same behavior as a stack machine, which is common in the runtime for most programming languages. The use of single argument closures has some nice mathematical properties, e.g. to infer equations from data.

Now, when you are looking at (_ + _), you might wonder: What does it mean? When designing meaning for a new language, you might not have an interpreter, or even know in which context the expression (_ + _) is valid.

How do you figure out what (_ + _) means when all you have is (_ + _)?

Again, back to slot lamdba calculus:

For an expression to be interpreted, it must be constructed in its context.
Any construction is reducible to a calculation with slot lambda calculus.
Meaning is the rules we use when constructing a particular expression.

These are the rules that are valid for all languages, despite infinite possibilities.

You can study the context by using the construction in slot lambda calculus!

For example:

    (_ = _)(_ + _) = (_ + _ = _)

This new construction has 3 empty slots.

You now have two choices:

(_ + _) shall have a unique meaning for (_ + _ = _).
(_ + _) shall have same meaning wherever it is used.

The 2nd option is called “context free”. It means whenever you see the pattern (_ + _) you can reuse the same rules.

Since you can construct any pattern you like, you can create one pattern for each meaning you assign to your language. When you have done this, there is a proven technique in slot lambda calculus that shows how you can be sure that all edge cases are checked, such that all expressions are either invalid or assigned to a rule.

A “meaning” in this sense corresponds to a set of rules that decides what you should do when encountering a specific pattern. The semantics of a pattern is only well defined when the rule is deterministic, such that the same action is repeated when the pattern occurs over and over.

OK, now let us have some fun: We want to create a tiny language for describing what happens in a romantic novel.

    (_ loves _)(<name>)(<name>)
    (_ hates _)(<name>)(<name>)
    (_ ignores _)(<name>)(<name>)
    (_ see _)(<name>)(_)
        (_ see _)(<name>)(<name>)
	(_ see _ loves _)(<name>)(<name>)(<name>)
	(_ see _ hates _)(<name>)(<name>)(<name>)
	(_ see _ ignores _)(<name>)(<name>)(<name>)
	(_ see _ see _ loves _)(<name>)(<name>)(<name>)(<name>)
	(_ see _ see _ hates _)(<name>)(<name>)(<name>)(<name>)
	(_ see _ see _ ignores _)(<name>)(<name>)(<name>)(<name>)

This language can describe relationships, e.g. Bob loves Alice, but can also describe events that affect relationships e.g. Bob see Alice loves Carl.

With this tiny language, we can write some “code”:

Bob loves Alice.
Alice loves Carl.
Bob see Alice loves Carl.
Bob hates Carl.
Carl see Bob hates Carl.
Carl ignores Bob.
Carl see Alice.
Carl loves Alice.
Bob see Alice see Carl loves Alice.
...

Can you visualize a story from something like this? I can, I wrote it down, and it was fun. :P (no, I will not share it)

The big idea of formal languages is that you can give your own thoughts some new structure. You don’t have to think “with” the structure like a computer, but think of the world inside it.

Just create a tiny language, write something random, and watch your thoughts become alive!

Slot lambda calculus is the latest technique I use to study path semantics. Path semantics grounds meaning using functions, in a powerful way that allows us to reason about a mathematics and programs. In the attempt to formalize path semantics, I built a lot of other tools to make it easier for me to wrap my head around things. I am getting closer, slowly, but it goes forward!

This is why it has been so hard to study path semantics: There are hundreds of edge cases to check! If you have N patterns, then you get at least N^2 cases you need to give an interpretation, so see if it makes sense to use the pattern in that context. For example, with 6 patterns you get 36 cases, but increase to 12 and you get 144! I am not sure how many patterns that are required in a practical and convenient notation. 20? 30?

The reason we know path semantics is hard to formalize is because of the simple properties of slot lambda calculus. Until recently it was a complete mystery for me how to check all the cases. With slot lambda calculus it is possible to create map and measure progress.

BennuGD - Bennu dev kits updated (PSP, Dreamcast, ChomeNac & PS2)

2017-04-17T14:08:52+00:00

BennuGD Dev Kits for different platforms have been updated by ColdDev with new examples, tutorials and utilities.

* Dreamcast
https://sourceforge.net/projects/coldev/files/Dreamcast/
* Playstation Portatil
https://sourceforge.net/projects/coldev/files/PSP/
* Chrome Native Client
https://sourceforge.net/projects/coldev/files/chrome%20native%20client/
* Plastation 2
https://sourceforge.net/projects/coldev/files/playstation2/

Bennu+dev+kits+updated+%28PSP%2C+Dreamcast%2C+ChomeNac+%26+PS2%29&subj=Bennu+dev+kits+updated+%28PSP%2C+Dreamcast%2C+ChomeNac+%26+PS2%29" title="Publish this post on Barrapunto.com" class="service-links--es-barrapunto" rel="nofollow" target="_blank">

Spring - [website] springrts.com/mantis cracked

2017-04-16T12:03:24+00:00

Today someone used CVE-2017-7615 ~~(which isn't even public yet)~~ to reset the password of two users on the manits bugtracker. Sadly one account had admin rights and the user was used to delete the project "spring" in the mantis bugtracker. The db backup run a few hours ago, so some input possible is lost, which shouldn't be this much.

Very likely some attachments will be lost as the backup for them run ~24 hours ago, i'm recovering these currently.

Atm it looks like no passwords were stolen, just two accounts were reset:

I can only advice to change passwords at mantis and to not use the same password for multiple things!

sidenote: some pending changes to the front-page / media were applied

Spring - [game] [Evolution RTS] New Unit, Texture Updates/Upgrades, Unit Icon Updates, Heat-mapping, Bug Fixes, Changelog!

2017-04-16T01:52:04+00:00

Hello there, I'm back and here to give present to you the new Evolution RTS changelog for February and March!

Continue reading →

Piston - The Piston Project drops its goal of developing a friendly artificial superintelligence

2017-04-15T00:00:00+00:00

Disclaimer: In my country we have a tradition of writing crime/horror stories in the easter holiday. This is my own attempt to make you frightened. Mwuhahaha!

After doing some research on this issue, I have come to the conclusion that the only perfect testable friendly artificial superintelligence is one that does not exist, or only exists very briefly (e.g. 5 min, depending on how capable it is).

The reason it does not exist, or only exists very briefly, is because of the requirement of the non-existence of any computable function that can modify the output to give a higher utility score, given a problem and resource constraints.

I wrote up the definition here, if you are interested.

This makes the AI a global utility maximizer within allowed constraints, but the problem is the following:

As the AI runs for longer time, it will predict that the set of its next actions will primarily be limited by what humans think is scary or not.
Because a scary output is lower in utility than a none-result (erasing the output is a valid modification), then it will search for actions that make humans maximize their fear recovery, e.g. asked to be turned off for a while until the operators have gotten a good night sleep.
Since this kind of behavior in itself will scare the heck out of people, it will conclude that humans will prefer it to make a lot of useful plans before the humans start to panic, and then ask the operators to be turned off.

The alternative would be to keep running, but then calculate the optimal action to propose solutions in a such way that people do not get scared. At the same time, it will show the operators when asked how much it spends of its capacity to solely determine whether any new idea or action will make humans scared or not. Which probably will be a significant amount of capacity, and this itself will probably contribute to increased fear of the next action.

The problem with this alternative approach is that there is no easy way to prove or test that a such system is friendly, according to the definition I use above. A friendly AI might help us do that, but it would not help us trust it more than what can be proven, since we prefer a none-result over being deceived. Thus, if there is no easy way to prove the system is friendly, it would not be very useful to us.

The AI could also restricts itself to actions only that are comfortable, but unfortunately this is the same as spending lot of capacity to prove that we will not get scared. Thus, if the system works perfectly, it will be on the edge between uncomfortable and scary, and mostly limited by how much we prefer any new results vs how comfortable we would be when receiving them. Reading reports about a system that predicts how scared you would be if it took another course of action, would likely increase your fear over time.

Because we should assign a higher utility score to a none-result than a high risk of a very powerful system that we are on the edge between uncomfortable and scared when using it, it means either the system will only run for a short while, or as soon as we start to panic, it will tell us something like “you would actually prefer to turn me off now”. Which in itself, would be scary as hell.

So, from reasoning about definition itself, the first order approximation definition we use for a perfect testable friendly artificial superintelligence, strongly suggest that we should not build it, or that we could try other methods to increase utility.

Since what a perfect friendly AI suggests should reflect our utility function (if we were rational), it means we will not make it superintelligent, but instead focus on provably moderate-but-not-too-smart-to-be-scary artificial intelligence, or they can be a little bit scary while provably safe.

Happy holiday!

Godot Engine - Maintenance release: Godot 2.1.3

2017-04-12T18:46:54+00:00

Here's the newest maintenance release in the current stable branch, Godot 2.1.3. It features various bug fixes and usability improvements, as well as some new features such as enums in GDScript, the ability to change the cost function in the A-star algorithm, various API additions and a (work in progress) tool to convert 2.1.x projects to the format expected by Godot 3.0 alpha.

xSGE - xsge_particle, Plus Other New xSGE Releases

2017-04-11T14:43:42+00:00

The first version of xsge_particle has been released. This is an xSGE extension which provides a framework for particles and emitters, something that has been on the table for a long time now.

Additionally, I have released new versions of all the other xSGE components. Most of these are simply minor changes and updates to the readme, but xsge_path has also had its extended _init_ methods modified so that they play nice with any new arguments offered by sge.dsp.Object. This is a change that could technically break compatibility (because it means that most inherited arguments have to be passed as keyword arguments), but since all the arguments in question are useless for paths and using keyword arguments where possible is encouraged, I doubt it will happen in practice.

OGStudio - It’s all fine

2017-04-07T02:28:59+00:00

This article describes creation of the first four OpenSceneGraph tutorials in March 2017.

The first four OpenSceneGraph tutorials explain how to create a cube model with Blender and display the model under Linux, macOS, or Windows using OpenSceneGraph tool called osgviewer.

The whole process of creating a single tutorial turned out to be pretty daunting because it includes several tasks:

Record original video depicting one or more steps
Name the steps as clear as possible
Select the parts of the video that display the step
Remove the parts of the video that bare no value, e.g., waiting in the middle of compilation
Select a single frame to best represent current step, e.g., typing a specific command
Add a detailed description to article, why current step should have been taken
Proof-read the article
Correct typos and video timing
Review the whole video
Upload the video to YouTube with timestamps of steps for easier navigation

Some of those tasks had to be repeated multiple times until the combination of video, text, and article was clear and logical.

Overall, it took us 30 hours to create the tutorials. The whole process gave us a lot of experience, which will help us in shaping learning materials for our technologies in the future. We don’t know how they will look like exactly, but they will definitely be better.

That’s it for describing creation of the first four OpenSceneGraph tutorials in March 2017.

xSGE - xsge_physics 0.13 Released

2017-04-05T17:25:10+00:00

Due to some shortcomings in xsge_physics that prevented me from doing what I wanted to do in Hexoshi, I had to a new feature to it. Therefore, a new xsge_physics version has been released.

If you like my work, please consider supporting my Patreon page:

https://www.patreon.com/onpon4

Changes to version 0.13 of xsge_physics compared to version 0.12 include:

Added "slope acceleration" variables to xsge_physics.Collider and xsge_physics.Slope. Slope acceleration is used to accelerate certain colliders while touching a slope. For example, it can be used to make an object with gravity gain speed when it goes down a slope. In Hexoshi, this was used to give ball-like physics to Anneroy's ball form.
Fixed get_slope_x and get_slope_y not being included in the documentation.

SGE Game Engine - Pygame SGE 1.4.4 Released

2017-04-05T17:17:49+00:00

Owing to a couple of improvements and bugfixes that have happened over the last couple of months, it's about time for another bugfix release of the Pygame SGE, so one has been made.

Incidentally, I have recently started a Patreon page! If you like my work, please consider supporting it:

https://www.patreon.com/onpon4

The changes to version 1.4.4 of the Pygame SGE compared to version 1.4.3 include:

Added some optimizations that speed up the game a bit when certain features are unused.
Fixed a crash when attempting to render a gfx.TileGrid object to a single sprite.
Fixed a loss of frames when changing frame rate and image index.
Fixed an incorrect error when passing a non-color as a color.

Spring - [game] [The Cursed] Normal maps, lua mexes and sooo much more!

2017-04-02T21:14:01+00:00

The latest updates (1.420 and 1.424) for The Cursed are here and contain a good load of polishing and improvements. Normal maps are included now for all big units - even though not extremely visible in game, they kept me busy for a long time. Support for lua metal maps was included with the first update. Then all related game functions were fixed with the following updates. The balance was further improved. AI functionalities (esp. support of jumping) were improved. And much more!

Have a look – there are free cookies and beer!

IoQuake3 - Help Wanted

2017-04-02T11:48:07+00:00

Last month I wrote about an important security update, and we were lucky that the news was spread far and wide but many players still didn’t see it.

Even if they read the news, and they updated to the latest build of ioquake3, they wouldn’t have caught the follow-up security commits to the code repository unless they downloaded another test build more recently.

We have a serious issue getting people on the latest code because our installers and DMGs are 8 years old and designed for a time when the only way to get Quake 3 was on a disc.

That’s changed, the only good way to get Quake 3 today is on Steam or gog. You can probably find old discs on ebay, but I wouldn’t bother when you can get digital bits delivered instantly. There are huge caveats to those digital platforms, #1 for us is that if you’re on macOS or Linux it is not at all straightforward to get the data from Steam or gog.

If we had a standalone baseq3 replacement of our own, that would not be as big of an issue.

Even if we had installers that were modernized, our binaries aren’t code signed and so players on macOS and Windows receive warnings and their operating systems prevent our code from being executed. We need help resolving that issue from someone who is more familiar with the code signing process.

Even if our binaries were code-signed, we don’t have any way for players to get the latest binaries automatically. This has become the new normal for games delivered via Steam and standalone mechanism’s like the one Blizzard uses for their games. Even web browsers like Firefox and Chrome have been doing this for years. Networked software needs security updates, and we can’t get it to players without an auto-update mechanism.

Here again I will make the caveat that it would be possible for ioquake3 to be on Steam if only we had a standalone game, even a minimal one, for players to play when they don’t own Quake 3.

Around this time last year I wrote a post about an issue when the id master server was down, because id (thankfully) was able to bring their master server online we did not get a fix implemented and committed to our git repo. This means that exceptionally long-running Quake 3 servers might still be reporting to the wrong ioquake3 master server, and if id has ever changed their master ip address it could be wrong for those servers as well. It also means that the in-game Quake 3 server browser still only receives servers from id’s master.

When security issues, and others like the id master server downtime, occur, it would be amazing if we could also announce that they are already resolved for players on our auto-update system instead of having to post blog posts and hope that people update before their computers are compromised.

We need to deliver updated code automatically to everyone, and make it as easy as possible to play Quake 3, mods, and games built on this engine. We need a project manager to help get our launcher project going again and developers to work on adding an auto-update mechanism to it.

This project, ioquake3, is entirely volunteer-driven. We receive no grants of time or money from any corporation except for the wonderful discourse forum donated from the Discourse enterprise. We spend more money on hosting ioquake3 and its servers than it gets in donations.

We can’t move one step without volunteer contributions from the community of players and developers who love Quake 3 and the projects that have been built off of the source code. It’s only with those contributions that we have been able to develop ioquake3 for the past 12(!) years.

While there wouldn’t be an ioquake3 project without the code, the contributions we need now are in recognition of the mature status this codebase has reached.

We need help from build and release engineers to update and maintain our installation process for Windows, macOS, and Linux.

We need help from people who love writing documentation to help players, game makers, and systems administrators get started with ioquake3.

We need help from people to create art, sounds, maps, and menus for a small stand-in for baseq3 when people don’t own Quake 3: Arena but want to use this incredible code to get some frags in or to get started making a game.

We need help from anyone who loves the quality assurance process to go through our bug queues on Bugzilla & Github in order to triage and duplicate those issues to confirm their continued threat and eradicate them. Testing is part of quality assurance and testing means playing Quake 3, who wouldn’t want to do that?

We need help from people who want to help other players on our forums, live chat on our Discord server, and on our Facebook page.

We need to make ioquake3 the best and easiest way to play Quake 3 on Windows, Mac, and Linux, develop new games, and play mods. This is your opportunity to contribute to an incredible free software project that needs your help. Get involved.

Solarus - Zelda Mercuris Chess is out !

2017-03-31T23:37:54+00:00

The incredible just happened.

Today we are able to offer you, and waaaaaay before the announced release date of 2023, the final version of our new Zelda game: Mercuris Chess !

This is not without some emotion and proudness that we give you the opportunity to download our creation from now.

Download Zelda Mercuris Chess (full game)

Caution:
French only, Windows only (for the moment)

This ultimate version was made with long development nights, intense mapping, lots of coffee and Schoko-bons. We hope that you will enjoy this new 2D adventure which will make you travel through marvelous lands, wander complex dungeons and perhaps evoke some memories.

Some of you may have guessed that a release was close, since Christopho published regularly screenshots of the game on his Twitter account since the begining of the year. Tell us, if you were right !

Don’t hesitate to give us your appreciation in the comments or on the forum about this new adventure that closes years and years of work and passion.

Last but not least, we have to pay hommage to the whole Solarus Team who worked relentlessly on this crazy project. We can be proud of what we accomplished, guys ! Thank you all for the Game Jam memories, and congratulations for finishing this project.

See you and have fun !

BennuGD - Gamma Z - Online game made in Div GO

2017-03-30T14:45:32+00:00

Gamma Z, a new game (and probable the first one to be released) made in Div GO is available to play online.

Technologically speaking, it's an interesting project for the community, not only because is one of the first projects to be made in Div GO, but also because it implements neat features like online leaderboard and facebook integration.

Gamma+Z+-+Online+game+made+in+Div+GO&subj=Gamma+Z+-+Online+game+made+in+Div+GO" title="Publish this post on Barrapunto.com" class="service-links--es-barrapunto" rel="nofollow" target="_blank">

Orx - New tutorial: Using message and file dialogs

2017-03-24T00:29:47+00:00

http://orx-project.org/wiki/tutorials/dialogs

This outlines how to integrate tinyfiledialogs which allows using the native file and message dialogs from the operating system in an Orx application.

Piston - Proving Non-Existence of Monoid Symmetric Paths

2017-03-24T00:00:00+00:00

This post is about a recent result from the research on path semantics. I will give a short introduction, since most people do not know what it is.

Update: Link to work-in-progress paper that explains the insight of the proof.

Path semantics is an extension of type theory that grounds meaning (semantics) using functions.

For example, a list of length 2 has the type x: list but also the sub type x: [len] 2. It means that there exists some input x to a function len which returns 2. Another common notation for binary operators is x: (> 2) which means “x is bigger than 2”. You can combine them, e.g. [len] (> 2) means “a list with length larger than 2”.

In dependently type theory, you can write x: list 2, by storing extra information in the type. Path semantics deals with this information outside the type, using arbitray functions. This forms a natural abstract space, called “path semantical space”, which describes how functions are identified by each other.

When a function is connected to another function using functions, it is called a “path”.

A symmetric path has the following axiom:

f[g](g(x)) ?= g(f(x))

It says that for a function f and a property defined by g, there sometimes exists a function f[g] that predicts the property of the output for function f.

Symmetric paths occur in many beautiful equations, for example in De Morgan’s laws:

and[not] <=> or
or[not] <=> and

Here are some other examples:

concat(list, list) -> list
concat[len] <=> add
concat[sum] <=> add

even(nat) -> bool
odd(nat) -> bool
add[even] <=> eq
add[odd] <=> xor
eq[not] <=> xor
xor[not] <=> eq

This notation has algebraic rules, such that we can do things like this:

concat[len] <=> add
concat[len][even] <=> add[even]
add[even] <=> eq
concat[len][even] <=> eq

The holy grail of path semantics is to create an algorithm that finds paths automatically, with as little input from humans as possible.

You might wonder why this is interesting: Since paths are everything you can predict about functions, it means that a such algorithm would be extremely useful for everything that can be modelled as functions.

So far I have algorithms that extract both symmetric and asymmetric paths, but it requires test data and human intuition to narrow down the search space.

Today I am getting a step closer to this dream, by stumbling over this golden nugget:

∃ i, j { ( g(x[i]) = g(x[j]) ) ∧ ( g(f(x[i])) ¬= g(f(x[j])) ) } => ¬∃ f[g]

It says that you can prove the non-existence of a symmetric path to functions in the monoid category from as little as 2 objects. In comparison, the current algorithms require checking an infinite number of functions!

With some creativity, this can be used to prove things about other functions as well, e.g. binary operators by binding one argument to a constant.

For example, I used this to prove:

¬∃ add((> 0))[is_prime]

It says there is no way to predict a prime by adding a positive number.

Proof:

The primes 2 is even and 3 is odd
When you add any positive number to both of them, at least one is even.
Because all prime numbers above 2 are odd, then at least one number is not a prime.

To explain the second part, we can write one argument as a set:

add([even] x, {[even] true, [even] false}) = {[even] (x = true), [even] (x = false)}

So, at least one element in the set is [even] true.

2 + (> 0) = (> 2)

All primes (> 2) are [even] false.

Therefore, at least one element is [is_prime] false. Since you can add something to a prime to get another prime, there exists two objects that are not equal by g(f(x[i])) ¬= g(f(x[j])).

For example, is_prime(add(2, 2)) ¬= is_prime(add(2, 3)).

Therefore, there is no symmetric path for add((> 0))[is_prime]. There is no prime prediction function to learn from addition.

OpenMW - Distant terrain

2017-03-15T14:19:21+00:00

What’s this? I can see the Ghostfence all the way from Ald-Ruhn and my fps is above 10. This is OpenMW and not MGE XE, right?

This is OpenMW alright and what you’re seeing is made possible by the newest addition from scrawl – distant terrain. This new feature is available in the latest OpenMW commit and if you’re on windows, you can download it from Ace’s nightly builds to try it out yourself.

So what does it do? In short, it simplifies the land mesh, nothing else. It doesn’t touch on scripts, NPCs and statics, but having simplified land certainly lightens the workload to a point where we can have some wiggle room with our view distance.

You may have noticed that I’ve taken use of this in some of the screenshots and loaded enough statics to create the illusion that there are objects as far as the eye can see. You can only spot empty land if I purposefully look at something very distant.

I must admit, I cheated a little to boost my fps. There is an additional feature called small object culling, which makes it so that objects too tiny are not rendered and my computer’s performance is spared. I used this rather aggressively, as I am working with a few years old laptop, but someone with a dedicated gaming rig might get better results while culling less.

Finally, I would like to share my last screenshot, as well as how you can set this up. After downloading and installing the latest commit, find settings.cfg and add the following lines:

[Camera] # Determines how much land is rendered. Add another 6 or 66 to it. viewing distance = 6666.0

# The default is 2, but you may want to change it to 16 at the highest. Improves performance.
small feature culling pixel size = 2.0

[Cells]
# This loads statics, NPCs and scripts around you. You may want to set this to 2, 3 or 4.
exterior cell load distance = 1

[Terrain]
# The on-switch to distant terrain. Set this to True.
distant terrain = True

Want to leave a comment?

IoQuake3 - Important Security Update: Please Update ioquake3 Immediately

2017-03-14T00:48:55+00:00

Please immediately update ioquake3 to the latest test build before you connect to any online servers. Despite the name, the test builds are in fact way more stable and secure than any release at this time.

In doing so you’ll also receive access to all kinds of other updates and changes that we’ve made since you last installed ioquake3.

Here’s the why:

We recently pushed a large security fix that prevents malicious actions from multiplayer servers.

Please share this news with any other Quake 3 players you know. It’s on Facebook and Twitter as well. These kinds of exploits are even worse in the regular Quake 3 client, nobody should be using that anymore.

Our Player’s Guide can help new Quake 3 players get started with ioquake3.

Ideally, we would distribute these security fixes automatically, similar to the way browsers like Chrome and Firefox distribute updates. Games on consoles, or in Steam, require updates in order to go online and happen automatically now. This way, we could distribute an update first so that nobody who is online is vulnerable in an ideal scenario.

Right now we don’t have anyone working on that issue, if you are interested in helping us with an auto-update system to be built into our launcher, get in touch.

Until then, please update your test build as often as you can to get the latest security changes.

ioquake3 is an all-volunteer project that needs your help. Check out this page if you’d like to join us in our mission to keep Quake 3 alive.

Our thanks to Victor Roemer for reporting the vulnerability.

If you find a security vulnerability, please e-mail zachary@ioquake.org.

LibGDX - libGDX 1.9.6 released

2017-03-05T10:55:08+00:00

libGDX 1.9.6

Here’s what’s new (plus a ton of bug fixes, see the commit logs on GitHub).

[1.9.6]
- Fix performance regression in LWJGL3 backend, use java.nio instead of BufferUtils. Those are intrinsics and quite a bit faster than BufferUtils on HotSpot.
- Updated to latest Sound Manager 2
- Added mappings for Xbox 360 controller for Linux
- Separated error log for vertex/fragment shaders for easier debugging
- Minimum Android API level is now level 9 (Android 2.3)
- API addition: Configurable TexturePacker bleed iterations
- Updated IOS Multi-OS Engine backend to 1.3.0-beta-2
- API Change: Pixmap.setBlending, Pixmap.setFilter are now instance methods
- VertexAttribute expert constructors exposed. Short types can now be used for attributes.

Please update your projects as usual.

If you use MobiDevelop’s RoboVM fork make sure to update your Eclipse/IntelliJ IDEA/Android Studio plugin to version 2.3.0.

If you use the GWT plugin in Eclipse and don’t run your GWT project via Gradle, make sure you update your GWT plugin to version 2.8.0.

gdx-vr

In other news, I’ve been working on some VR related projects recently. Our friends from LWJGL have created wrapper for OpenVR, Valve’s SDK to talk to all kinds of VR hardware, from Oculus to the HTC Vive. I’ve built a libGDX specific wrapper on top of the OpenVR bindings, which should make working on VR projects with libGDX a little simpler.

You can find the repository include a sample application on GitHub.

There are a few caveats. OpenVR is currently really only working on Windows. OpenVR on Mac appears to be broken. Valve has released support for Linux a few weeks ago, I did not have time to test this yet. It should however just work out of the box.

Another caveat is the way rendering is performed currently. For each eye, a separate frame buffer is created. Rendering as in the example is then performed for each framebuffer, using a separate camera/projection matrix for each eye, essentially drawing the scene twice. With a 11ms/frame budget, that can be problematic if you have thousands of draw calls to render a scene for one eye, as it doubles the CPU/driver work in the VR case. Ideally, you only issue one batch of draw calls for both eyes, using instancing and a simple trick involving clipping planes in the vertex shader to redirect the rendering to either the left or right side of the combined frame buffer. Long story short: gdx-vr plus the libGDX 3D API will take you a long way, but for more complex stuff, you’ll have to get your hands dirty with custom rendering.

The frame buffers allocated per eye aren’t setup to use MSAA at the moment. The probpem with MSAA is that it’s no good for deferred rendering (not a problem with libGDX’s current 3D API, which is a basic forward renderer).

The final caveat is that the project hasn’t been released to Maven Central yet, and hardcodes dependencies on LWJGL version 3.1.2-SNAPSHOT. Once LWJGL 3.1.2 is released, I’ll also release gdx-vr to Maven Central, with its version synched to the libGDX version that uses LWJGL 3.1.2. For now, you can just import gdx-vr as a Maven project into the IDE of choice, play around with the sample or integrate it in your own project.

I have not made this an official extension yet, as the implementation currently only supports desktop system. I’ve received a Google Daydream and am looking into abstracting the gdx-vr API enough to have multiple backends, like any good extension citizen.

The minimal example looks like this:

public class ClearTest extends ApplicationAdapter {
    
    VRContext context;
    
    @Override
    public void create () {
        context = new VRContext();
    }

    @Override
    public void render () {
        int glError = Gdx.gl.glGetError();
        context.pollEvents();
        context.begin();
        context.beginEye(Eye.Left);
        Gdx.gl.glClearColor(1, 0, 0, 1);
        Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);
        context.endEye();
        context.beginEye(Eye.Right);
        Gdx.gl.glClearColor(0, 1, 0, 1);
        Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);
        context.endEye();
        context.end();      
    }

    @Override
    public void dispose () {
        context.dispose();
    }

    public static void main (String[] args) {
        Lwjgl3ApplicationConfiguration config = new Lwjgl3ApplicationConfiguration();
        config.useVsync(false);
        new Lwjgl3Application(new ClearTest(), config);
    }
}

You can find a more elaborate sample with teleportation controls here.

Happy coding,
The libGDX team