ImaginationOverflow

Hi guys, I've awesome news! We just joined Patreon! In case you're wondering, Patreon is a simple way to contribute to our app/game development every month, and get great rewards in return. You will love rewards I promise! Go check it out! 

Our newest app is on the market, the first that we done using Xamarin.Forms, it is available on Android, iOS, Windows check it out! Or just visit the app website: https://loyca.imaginationoverflow.com

We are proud to announce that Stellar Interface has been finally submited into Steam Greenlight!

You can check and vote for our project by clicking right here.  Make sure to check out our awesome action-packed Greenlight release trailer!

STELLAR INTERFACE is a rogue-like, permadeath space shooter with randomized perks, providing the player an unique experience every run!

The backbone of any game, behind the graphics, sound, gameplay, is the code. As seasoned app developers we are used to play with the application architecture, to experiment and try different things, making it easier to reuse or modify the source in the current and future projects.

In games things aren’t so easy, the shear size of the code is ridiculous. Up until now, the biggest project that we ever worked, in both code size and feature length, was Pages Manager for Facebook. But StellarInterface is easily ten times bigger both in code size, features and complexity (and it is only about half done!).

Looking into it, it is quite simple to understand why we didn’t make a rogue like Space Shooter, but made an entire framework to make Space Shooters. Despite of its complexity, adding content to the game is very easy: most of our favorite perks are made with less than a dozen lines of code, we have a complete game, run, level and wave cycles automatized, one can even change enemy behaviors without changing a single line of code (configuration FTW :D).

It was probably a mistake, and we talk about it a lot, to make such huge infra-structure, but the liberty that we gained, to pretty much implement anything that comes to mind, is very powerful. Specially in game design where testing ideias quickly is a must in order to proceed forward.  Dividing our game in the classic three layer architecture will yield the following.

Data Layer

Our database, can be divided in three components: resources, configurations and game generated data. 

The resources are what one would expect: strings, spritesheets, audio, etc. The configurations have all the data about the weapons, enemies (and their behaviour). Finally the game generated data is simply the usual saved games and the metric database.

Most of our database is access through data storages, which transforms the raw data into objects that our game know how to work. 

The SLAM (Statistics Logging Achievements and Missions) is a “super” data storage that reads/writes metrics and transforms them into knowledge. As an example, an event logging a projectile hit will obtain information such as average damage taken, how many times it destroyed a spacecraft, what spacecraft does it hits more often, etc. All this information will then be consumed by the rest of the SLAM system, the one that actually “listens” to data updates and act when certain conditions are met (and voila an achievement and mission system).

The application layer is a little more complex and looks like the following.

Here we have our framework. The logger is pretty much the producer of data, used across all the game. The level generation deals with the graph generation, what spacecrafts will appear on the next level, how will they appear, how will they act (Pathing) and what will they fire. The features (base name for the perks and consumables) is one of the most important aspects of the game (that is why we already have more than 80 perks implemented!). These services offers the foundations for the perks/consumables activation, configuration and overall handling.

The controllers are the hard workers of the game, they handle pretty much everything that need to be done. They work directly with the DAL and the service layer in order to expose the game features and logic the graphics components.

Finally the presentation layer.

This is a crazy layer, mainly because we really didn’t understand how to work with it at the beginning and are still figuring out all the details (the game loop is a scary thing xD).

Everything that you will see, hear and feel, the graphics, the audio, the SPX, all the physics, collisions and overall behaviors are in here.

In the near future we will probably dive deeper into this awesome technical adventure that we called Stellar Interface, until then, follow us on the usual places:

It's on! A rogue-like-ish space-shooter, STELLAR INTERFACE is on the way.

Run and explore through space, with a permadeath mechanic breathing over your neck! Find and install numerous software-perks which will boost your spacecraft.

Well, it might not always boost... we currently developed nearly one hundred perks, and the fact they are beneficial is not consensual! Some perks change the game play mechanics radically and need some time for adjustment. So, if you are in a tight spot, they might not be the wisest choice... but once you master them, you will certainly gain a big advantage.

With countless weapons of different types to assemble in your spacecraft, your strategy must change quickly in your deep-space run. And the symbiotic nature of the perks will scale even more the uniqueness of game experience.

Of each weapon type (cannon, missiles, mines, among others) you will find dozens and dozens of variations. However, we intend to take you out of your comfort zone: even if you feel comfortable to play only with cannons, are you gonna ignore that +1000% Grenade Damage perk? Or when you get some different drone perks, you might even don’t care what are your weapons!

Our internal "spacencyclopedia", the Stellar.Net, will provide you numerous objectives to complete in the STELLAR INTERFACE's vast universe: collect, kill, try, explore. Stellar.Net is your informational Hub to check your progress, what have you seen and, maybe, what you still have to see.

STELLAR INTERFACE is scheduled to launch in Steam’s Greenlight quite soon. After that, Early Access is right on the corner. We wish to involve the community in our development process. We are currently a team of three (two programmers, 1 designer) who has been developing the framework for almost 3 months. But we want your input, your opinion. You are the player, the game is for you. By providing an Early Access to the community, we will be able to present the best end-product possible.

Plans for a X-Box One version and PS4 are in our pipeline, and even a mobile version of STELLAR INTERFACE. That, of course, will depend on the reception of our game and on what you think.

Stay tuned for the latest developments, and your comments and input are certainly warmly welcome!

https://www.facebook.com/stellarinterface/

One of the many dreadful tasks that we have as app developers is generating the assets for the app and store. With the new dev center, we have even more banners and icons to upload and with the proliferation of the windows phone and windows in general, having our tiles and assets in multi resolutions is a must for an overall good user experience.

Today I’ve pushed to github two scripts that automates all those annoying images. The usage is simple design your tile (it should at least be 1024x1024), run the scripts and voilá everything automatic generated, some notes:

The scripts are configured to look for two specific layers:

Background – If you wish the scripts to automatically fill the configured images with your background color, create a layer named Background and let it visible before calling the scripts. NOTE if your background is not unicolor do not use this feature.

AppTitle – Store promotional banners and the splashscreen should have the app name, but other images don’t. To accomplish that behavior the scripts also look for a layer named AppTitle, when found it will make the title visible on the configured images.

Using both your photoshop layers should look something like the following:

Now what images does it generate? You can check the scripts WinAppAssets.jsx and WinStoreAssets.jsx and see and edit the configurations.

The following images illustrate the usage of each of the configuration fields:

The only not present is the background, if background were configured to true, the script would fill the background with tile color, If it was false the blue background wouldn’t also be present, in the above image is just to explain the size field.

You can check on our OneDrive the outputs of the scripts, for the app assets and store assets (the images with black background are actually transparent).

Last Time, we talked about how a Linux kernel usual boots, today we will dig into the rootfs.

Linux operating systems are usually defined as distributions, these consists on an image that contains a bootloader, a kernel and a platform. The platform is usually what names a distribution like Android, Ubuntu or Fedora.

Tizen is a Linux based open-source operating system that supports a wide range of devices, such as smartphones, tablets, televisions, smart cameras, smart watches and In-Vehicle Infotainment (IVI). Tizen is sponsored by the Linux Foundation and supported by some of the biggest enterprises on the IT world, like Fujitsu, Huawei, Intel, KT, NEC CASIO Mobile Communications, NTT DO- COMO, Orange, Panasonic Mobile Communications, Samsung, SK Telecom, Sprint and Vodafone. Tizen has a public Software Development Kit (SDK), enabling third party developers to make and deploy applications into the platform. The SDK supports two kind of applications:

Native applications made using unmanaged code, they allow almost a complete control over the platform resources and features.

Web applications built using HTML, CSS and JavaScript, they allow the con- struction of portable applications between the Tizen platform (as well other mobile platforms). The platform integration is offered via a web API.

Architecture

Tizen architecture can be divided into three layers: the kernel; core; and framework. The framework component, as seen in the picture below, is divided in two to support the different type of applications that the system holds.

The Web Framework supports most of the W3C and HTML5 standard like video, audio, geolocalization, web sockets, etc. It also contains web APIs to access internal devices like Bluetooth, NFC, alarms, etc. The concept behind this kind of appli- cation is to enable developers to port existing applications or create new ones that run across platforms.

The Native Framework contains total access to Tizen APIs and supports third party libraries like glibc, libxml2, OpenGL, OpenAL and OpenMP. It also enables developers to port applications due to its support to many open-source libraries. This framework is specially designed to enable games, real time applications or applications that due to requirements can’t be done using Web Framework (e.g. need to use some API that isn’t available on web framework).

The Core layers contain all the system features. It consists of open-source libraries and some platform specific features:

Application Framework - provides mostly control operations to applications, like the launch of other applications given an Uniform Resource Identifier (URI), events to report current memory state, battery, push notifications or screen orientation changes.

Graphics & UI - supports the graphic component of all the system profiles: Mobile (native) - consists mainly of a port of Bada OS.

IVI & Mobile (web) - based on WebKit and WebKitEFL.

Location - provides information about geolocalization like current position, geocod- ing or satellite information. This information comes from many sources like Global Positioning System (GPS), Wi-Fi Positioning System (WPS), sensors, etc.

Web  - Tizen platform web API to devices and sensors. 

Security - responsible for the system access control, certificate verification and other security aspects.

System - an aggregation of system features, devices, sensors and energy control. It also handles hardware related events like Universal Serial Bus (USB), charger, Subscriber identity module (SIM), etc.

Base - contains the support for databases, xml parsing and internationalization.

Connectivity - where all the control for communication devices is at. Wi-Fi, 3G, Bluetooth and Near field communication (NFC) devices are handled in this module.

Personal Information Management (PIM) - contains the access to user local information, like calendar and contacts.

Folder Structure

Tizen source is available to the community via Git repositories. There is a single repository that contains all the tools, documents and source needed to the build and deploy, the picture below displays the folder structure after a clean download of Tizen sources.

The folder adaptation contains third-party projects from open-source libraries that were ported or integrated with Tizen, the folder contains projects like xorg, OpenGl and multi-touch handling. It’s also in this folder that the sources of the Hardware Abstraction Layer (HAL) are stored.

All the source of the default apps (calendar, calculator, email, etc) provided with Tizen can be found on the apps folder.

In external are external tools and libraries used by the platform.

Framework contains all the Core layer source code, described earlier.

The meta folder contains specific build configurations to each of the platform pro- files, like mobile, IVI or Personal Computer (PC).

Finally, in the pkgs folder, it’s possible to find the source from the tool mtools, in pre-built there are some pre-built packages for both x86 and ARM architectures, in profile there are high level system configurations for specific devices, at last, in sdk the source of the public SDK.

Building

Tizen build process is divided in two phases: a compile phase that generates all necessary rpm packages and an image creation phase that generates all the necessary deliverables.

Compiling

Tizen uses a tool called GBS to build its sources. It has the capability to build from local, remote or a configuration of the last two. This features are selected and configured under a configuration file name .gbs.conf, as displayed in the listing below.

Firstly it starts looking for a profile definition, in this example tizen3.0_mobile, then recursively finds out which repositories it should use, and after that it gets which packages should be built by checking the buildconf file and starts building.

To compile Tizen the execute the following command:

The compilation outputs a set of .rpm packages to be used on the image creation phase.

Image Creation

Just like the compilation, Tizen image creation allows to be configured to use local or remote rpm repositories. The image creation is done by a tool named mic. Mic uses a kickstarter file as a configuration to produce the system images.

In the listing above, is possible to observe a repository and some packages configurations. This file can also define the target system partitions, commands to be run on the boot sequence and other in device configuration.

Finnaly, the command presented in the listing below will generate the system   images.

Deploying

Tizen produces three images (can be configured otherwise) when successfully built:

platform.img  - The rootfs of the  system.

data.img - The container of the default applications their supporting libraries.

ums.img - Where the default media content is located.

Tizen has a more complex partition scheme than that presented in the first series posts, although the first two partitions remain the same other two need to be created, as seen in the below picture

The need to have more partitions is to isolate each type of data into a separate container ensuring that the data isn’t corrupted by mistake.

Consider, as an example, that instead of partitions Tizen used an offset scheme, where the data and platform location where on a known offset from the end of the platform image. Besides being harder to access, the system could override data from the other two images.

Finally the partition scheme allows the system to mount each of the images from different places (e.g. one from the SD Card, one from the Flash).

Today we are happy to announce that our most popular app just got updated to 2.4

The new update includes the following changes:

Added Pages News Feed, you can now like/comment/share on posts made by other pages that you liked.

Improved share posts experience.

Fixed the page settings issues.

Revamped the notification system.

Random crash bugs fixed (thanks to all that shared them)

The app has two version, the free lite version has the basic features and some ads, the pro version ($1.99) has all the features for an advanced Facebook page manager. Both versions have an universal counterpart on the Window store.

Store Links

Lite: http://www.windowsphone.com/s?appid=9704533b-2324-4a6c-abc2-9fb8d47d0582

Pro: http://www.windowsphone.com/s?appid=40a2e489-5479-4092-a71d-31d727b04898

Media you can find the press kit here

Today we are happy to announce the release of our first AdMesh app. AdMesh for pubCenter.

The app allows you to:

View custom reports

Check all your application insights

Fine grained app insights via its ad units

General report insights, such as, last week, last month, last 7 days,last 30 days, etc

Fully customizable live tile, enabling you to select witch reports you want the tile to display.

Fully customizable toast notifications, letting you choose what revenue you wish to be reported on a periodic basis.

The app was designed with two purposes, the first to give you a quick glance on state of your revenue, that is accomplished by the first thing you see when the app opens. 

You can quickly see, your today, yesterday and average revenue when you open the app. Drilling down, you have the revenue by app in the last 30 days and finally how your revenue is evolving in the last 30 days.

For power users that wish to know everything about how their revenue is evolving we offer the regular insights:

Finally if you really want to keep track of everything, our detailed report view, let’s you keep track of all the metrics available. By offering minimalist insights and plotting the overall values in a graph.

All these features are available for your overall data or by application or adunit, letting you decide which data do you wish to see and evaluate.

The other good news is that AdMesh for pubCenter isn’t a solo project. AdMesh will be a suite of apps that will let you keep track of all your earnings of ad networks. 

So we would also like to announce that the second AdMesh app is already in the making, AdMesh for Admob will be released in the next month, allowing you to keep track of your admob revenue.

Finally you can download the app using the following code or following the direct store link:

Store Link

To commemorate the app launch we leave 10 links that unlock all of the app features:

http://go.microsoft.com/fwlink/?LinkId=532540&mstoken=HCMWW-D76YJ-Q7K4H-HW72C-2FGTZ http://go.microsoft.com/fwlink/?LinkId=532540&mstoken=7CHYT-F4XR4-WJ23J-P6GPJ-H6PTZ http://go.microsoft.com/fwlink/?LinkId=532540&mstoken=RQH4R-92FHT-WKDRH-7JCR9-2WC4Z http://go.microsoft.com/fwlink/?LinkId=532540&mstoken=D3FMM-XX9HY-6MVHJ-J6GPK-R9KMZ http://go.microsoft.com/fwlink/?LinkId=532540&mstoken=HYRC9-7Y7DQ-4KV23-YHTQH-29HGZ http://go.microsoft.com/fwlink/?LinkId=532540&mstoken=RMRJT-XC9Y2-V6C29-69DXG-33PDZ http://go.microsoft.com/fwlink/?LinkId=532540&mstoken=FFVKK-XTHVF-W3MG4-FYXQ6-GFJYZ http://go.microsoft.com/fwlink/?LinkId=532540&mstoken=Q6JJ9-6WFG7-MG3GX-RDPFF-RHJPZ http://go.microsoft.com/fwlink/?LinkId=532540&mstoken=C3QH6-773J6-RQXF2-JTG7X-2DYJZ http://go.microsoft.com/fwlink/?LinkId=532540&mstoken=64D4T-HC2DR-CM9JJ-JRXJ3-DJFGZ

To use one of these links please follow these steps:

On your phone make sure that you are logged in on the browser with the same live id that you have on your phone.

Click on one of the links, and redeem the code.

Install app (if you haven’t installed it yet).

Open the app, expand the app bar and click unlock features.

Confirm that all of the premium features are unlocked.

If the features aren’t unlocked, click on the Full Version.

We are happy to announce that our Revenue for DevCenter app just got updated.

The app lets you keep track of the revenue that your Windows apps made. It has a lot of features like checking your proceeds, your payment statements and your daily revenue.

The 1.3 changelog is the following:

Added

Daily insights, check your average, max and min revenue by a daily basis

Dutch and French support

Fixed

Background notifications now work correctly

Login issues

Misc crash issues

Download Link

We gladly to announce that our app AdMesh for pubCenter is finally under private beta testing.

If you wish to help us test the app you can register in the program on wpbeta.me.

AdMesh for pubCenter is an app that allows you to keep track your applications revenue. Right now the app supports: 

View custom reports 

Application insights 

Application related reports 

Application ad unit reports 

Overall reports such as, monthly, weekly or yearly. 

Customizable live tile report presentation. 

Last time we introduced some basic concepts of embedded Linux, today we will dig into the boot process of an embedded device.

Toolchains

There are two set of toolchains necessary to download to build the linux systems. A bare metal toolchain, that must be used to build the bootloader, this toolchain strips down the available libraries to its core, removing any filesystem or input/output functionality. The other toolchain is a regular one for the target architecture (we will be using arm). The bare metal toolchain can be downloaded from https://launchpad.net/gcc-arm-embedded or if the host machine is running Ubuntu a regular apt-get command (apt-get instal  gcc-arm-none-eabi).

The regular toolchain can be found in https://www.linaro.org/downloads/ or installed using the usual apt-get install command (apt-get  install gcc-arm-linux-gnueabi).

To conclude, bootloader or any other bare metal source, should always be compiled using bare metal toolchains. Linux kernel, Android, Tizen or any other source can be compiled with regular toolchains.

Boot

When a device is turned on, there are a strict number of phases that it must successfully complete before it can start doing what it was meant to. These phases are called booting and their main purpose is to initialize the device hardware and software. The number of phases that the boot process contains may vary depending on what kind of device it is and on what kind of software it contains.

Considering modern devices that run full-fledged operating systems, generically, the boot process can be divided into five phases:

System Startup - very dependent on the device and architecture, but usually this step copies a chunk of data from a fixed address on the device Read-only Memory (ROM), Flash or SD Card to the device Random-access Memory (RAM) and starts running what it just copied. Usually what is stored on that chunk of data is a bootloader.

Hardware Setup - also known as stage 1 bootloader - has the primary responsi- bility to configure and turn on specific device features so that the bootloader can execute correctly (e.g. turn on CPU cores). It’s also used to load an- other bootloader when, for instance, the bootloader size is bigger than the one supported by the system startup.

Bootloader - is responsible for all the initial hardware setup and configuration. This includes memory and peripherals setup as well as loading the kernel to memory and executing it.

Kernel - initializes all the components necessary so that the operating system can work correctly like device drivers, services and the user interface.

Platform initialization - is where all the user information, applications and ser- vices are initialized and started.

U-Boot

U-Boot (Das U-Boot) is an universal open-source bootloader used in embedded systems; it supports a wide range of architectures like ARM, AVR32 or MIPS.

Its main goal is to prepare all the hardware to the kernel or application setup. The initialization routine is the following:

Hardware Setup initializes exception and interrupt handlers, configure the CPU and memory (MMU, stack, etc).

Board Setup configures board hardware, load device DTB and start peripherals.

Kernel Boot copies the kernel to ram, prepare the kernel parameters and call its init function.

The above image, illustrates a part of the original U-Boot source tree. The api contains the core Application Program Interface (API) to be used by target applications and fs and net have the necessary source to handle different filesystems and network operations respectively.

The spl folder contains the framework for the Secondary Program Loader (SPL) a bare bootloader which purpose is to load the U-Boot into memory, the Hardware Setup explained before.

The arch folder contains the sources to support a given CPU for a specific archi- tecture. The architecture generic source is held under the lib folder.

Just as Linux, U-Boot has a hierarchical makefile system which can be configured via environment variables, but in this case only the toolchain vari- able is mandatory. The device selection works the exact same way as Linux, their configurations can be found under the folder configs.

The build can generate more than one deliverable, if the target device requires a stage one bootloader the build process will generate two deliverables, the U-Boot and SPL images.

Deploying  to Wandboard using SD  Card            

Wandboard uses an i.MX6 micro-controller configured to boot from the SD Card. The SD Card must be arranged in specific partitions and the bootloader (Program Image in the following picture) must be on a known location. 

The processor will copy the first 70 KB from the address 0x400 of sd card to the ram and start run what it just copied. In this example we will use u-boot two stage bootloader feature (aka SPL). When SPL takes over the hardware, the location of u-boot and kernel becomes responsibility of the configuration and not the hardware, meaning that SPL knows how to retrieve u-boot and that u-boot knows how to get the kernel image.

Basic Partitions

There are two generic default partitions, boot, and rootfs. First a boot partition that must be configured as an fat32 filesystem with the boot- loader and kernel, then a partition with any desired filesystem type (ext2, ext3 or ext4 as examples) containing the rootfs. To create the basic partitions the tool fdisk can be used, as shown below.

Bootloader and Kernel

With the partitions created, the final step is to setup the bootloader and the kernel into the SD Card.