Implement a particle system with the following requirements:

• particles can be attached to game objects and share the same z-index
• particles get removed when their respective object gets removed
• detached particles which leave the world bounds will get removed

Setup this repository for Maven Central according to these requirements and OSSRH Guide.

The relevant request ticket can be found here.

Tasks

• request braingdx repository on Sonartype
• change pom.xml to deploy to Maven Central
• setup GPG signing within TravisCI. (example)
• integrate Javadoc deployment into pipeline (example)
• update README.md to use official Maven Central Nexus
• promote staged artifacts into Maven Central (Release)

Apparently the GLSL shader code does not consider alpha values of applied frame buffers.

Since layered shader support (see #27) does not work properly, roll back to combined shader support for now. Apply all shaders on the sam texture.

Apparently the PostProcessor class used for shader computing does not work since it is designed in a way for Single Usage. Defining multiple processors breaks the rendering of shaders. Instead, use PostProcessor as a storage of all kind of effects for each render pipe and enable/disable shaders respectively for each layer.

Add basic svg support to render SVG files to textures.

This particular feature consists of the following parts:

• providing an API
• loading of SVG data (XML parsing)
• processing of SVG commands
• rendering to a texture

Right now only Orthographic tiledmaps are supported by braingdx. Add support for isometric tiledmaps.

Depends on #30.

Depends on #30.

Create a class which loads TiledMap objects from an input stream which provides ASCII characters. These characters can be translated into tiles and objects respectively.

e.g.:

xxxxxxxxx
x a   b x
xxxxxxxxx

where x is a wall texture (collision), whitespace means air (walkable) and a and b are game objects, specified by the loading instructions.

The v0.1 animation API is quite messy to play with. It is feature rich but needs separation of concerns. Also, it should integrate with the animation class of libgdx.

The current API has several drawbacks:

• hard to configure: it requires a lot of boilerplate code
• ambiguous classes and APIs, similar to the one of libgdx itself
• high coupling: the API is not easy to extend

The solution to this is a reworked animation API with separation of concerns.

Separation of Concerns

The main focus of the new API is separation of concerns, without sacrificing usability and abstraction:

• animation and tileset properties such as animation delay, direction of animation (horizontal or vertical), tileset origin
• rendering of animations
• configuration styles such as yaml or Java
• handling of animation state

Particle effects should follow players accordingly. Instead, their positioning seems to be wrong.

Depends on #12

Introduce a more general rendering pipeline to support shaders for UI and graphics and single components also. Each layer consists of a rendering sub-layer and a post-shader layer.

Each post-shader layer can have two different rendering modes:

• Additive: renders on top of the previous layer, including all shader operations.
• Single: renders on top of the previous layer. However, all shader operations apply only to this layer.

Example

For example there could be two default layers:

• world (Additive, default)
• user interface (Single)

Depends on #11, #19

I already asked the author. He allowed me to fully copy&paste the existing Universal Tween Engine into this project.

The new tooltip has:

• multiscreen support (configurable)
• 2 mode: quering and stacking
• multi instance support

Current shader implementation does not support alpha channels and renders on a black texture instead (if no pixels are provided as texture). This is why layered shader support by using frame buffers does not work. Alpha blending is not an option because lose all alpha information after shading is applied.

Support game servers and server-client communication via kryonet.

Depends on #13

The new render pipeline does not work with various libgdx viewports. Expected behavior is that viewports are applied correctly (also resizing the screen should work). Currently resizing the screen causes the whole screen to resize incorrectly. Also viewports do not behave as intended!

When applying shaders to the combined render pipeline while a camera is active the resulting framebuffer breaks.

This is caused due to the fact that there is only 1 wrapper in use. It overrides behavior and does not work with multiple music played simultaniously.

Introduce and facilitate a mechanic to slow down time, including TweenManager support.

💡

Support movement in rasters only. Depends on #31.

Depends on #18

This prevents braingdx to get deployed via gradle desktop:dist since dependencies are not packed properly.

Compile custom native dependencies and use them instead.

Fix it by using https://jitpack.io/#bitbrain/box2dlights/master-SNAPSHOT as a dependency instead.

This feature offers extended support for the TiledMap implementation. It will integrate smoothly with braingdx and provides easy configuration.

Motivation

The TiledMap implementation provided by libgdx gives general support for using tiled maps. However, when creating games for game jams it is always time-consuming to write the render pipeline for tiled maps and levels all over again. Also having an API which provides easy support for collision detection and object handling is one goal of this story.

Rendering and z-indexing

One particular problem when implementing this story is in which order to render layers and objects. The rendering itself can not be implemented as an own RenderLayer since GameObject instances should get rendered before or after a certain layer. In addition GameObject instances for layers should not be taken into account for collision detection or world deletion. This can be achieved by treating a MapLayer as a game object and assigning own renderers for each layer individually. Afterwards braingdx needs to calculate the z-index for every GameObject to decide in which order to render:

index = (layerIndex + 1) * rowCount + yPosition

Explanation: first of all the z-index needs to be higher on a higher layer, regardless of how big the index is in the layer beneath. This can be ensured by multiplying the current index of the layer with the total number of rows. Afterwards the current yPosition of the GameObject is added.

Tasks

• implement active/inactive mode for GameObject
• implement z-index calculator and z-index assignment for GameObject instances
• implement MapLayerRenderManager (generating individual ids for render layers and assigning own renderers to it)
• implement MapLayerRenderer
• implement collision cache
• implement TiledMapManager to load tiled maps and populate the world with defined objects
• implement TiledMapAPI to provide access like collision checks, indexed-based field checks (neighbours, layers)
• implement support for moving game objects between layers at runtime (configurable via TiledMapConfiguration)
• introduce a TiledMapConfiguration in order to define how to parse attributes like collision, game objects, items etc.
• Implement collision detection

This is probably caused by the environment lighting set to black by default.

Right now renderers can only be applied per GameObject type. Instead, make it configurable to apply renderers for individual game objects instead of whole types. This is a dependency of #35.

Add support for animating SpriteSheet animations.

Right now objects are compared for collision detection and behavior via the bruteforce strategy. An implementation of a quad tree leads to better performance since we should not check collision for objects which are too far away.

This feature allows transitions between 2 screens.

List of supported transitions

• FadeTransition fades the alpha value of the current screen to 0 and the alpha value of the new screen to 1 simultaneously.
• SwipeTransition moves the current screen to [top | left | right | bottom] and the next screen moves to the middle.
• ColorTransition fades the current screen to a color specified and fades from the color to the next screen.

Notes and considerations

• the buffer texture of the current screen can be obtained by the rendering pipeline
• the buffer texture of the next screen could be obtained by the rendering pipeline. However it may not be configured correctly. Additionally the pipeline may depend on assets which are not loaded. Make sure to support screen transitions for lazy-loading of assets later on!
• if a texture can not be obtained correctly, do not fade at all and show a warning in the log.

Depends on #11, #14

Right now animations are not affected from movement direction.

Simpliar to the Animation API this needs some cleanup. Movement<Type> is not sufficient and creates too much boilerplate code.