December 9, 2016

Box2dLights crash

Recently I started to use Box2dLights again and encountered frequent crashes resulting in the following output:
Program: C:\Program Files\Java\jdk1.8.0_112\bin\java.exe
File: ./Box2D/Collision/b2DynamicTree.h, Line 209
Expression: r.LengthSquared() > 0.0f


The cause is Box2dLight trying to raycast with identical start and end points in PositionalLight:
    protected void updateMesh() {
        for (int i = 0; i < rayNum; i++) {
            m_index = i;
            f[i] = 1f;
            tmpEnd.x = endX[i] + start.x;
            mx[i] = tmpEnd.x;
            tmpEnd.y = endY[i] + start.y;
            my[i] = tmpEnd.y;
            if (rayHandler.world != null && !xray) {
                rayHandler.world.rayCast(ray, start, tmpEnd);
            }
        }
        setMesh();
    }


Patching the light class with a simple check solved the issue:
            if (rayHandler.world != null && !xray && !start.equals(tmpEnd)) {
                rayHandler.world.rayCast(ray, start, tmpEnd);
            }


Instead of calling equals you could also directly call
NumberUtils.floatToIntBits

October 4, 2015

Spring Boot Tomcat logging configuration

I had a hard time in getting a SpringBoot Tomcat application configured in such a way that configuration files are read from TOMCAT_BASE/conf and log files are written to TOMCAT_BASE/logs. It should work from Eclipse as well as for an external Tomcat. Many questions and answers could be found about similiar problems, but this is what finally worked for me:

Put a bootstrap logback.xml into the classpath root and let point to the actual logging configuration:
<configuration>

            <include file="${catalina.base}/conf/myApp-logback.xml" />        

</configuration>

The logging configuration in ${catalina.base}/conf/myApp-logback.xml that writes to ${catalina.base}/logs/myApp.log looks something like this:      

<included>
            <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
                        <encoder>
                                   <pattern>%d{HH:mm:ss} [%thread] %-5level - %msg%n</pattern>
                        </encoder>
            </appender>

            <appender name="FILE" class="ch.qos.logback.core.FileAppender">
                        <file>${catalina.base}/logs/myApp.log</file>
                        <encoder>
                                   <pattern>%d{yyyy.MM.dd HH:mm:ss} [%thread] %-5level - %msg%n</pattern>
                        </encoder>
            </appender>

            <root level="WARN">
                        <appender-ref ref="FILE" />
                        <appender-ref ref="STDOUT" />
            </root>

            <logger name="de.myPackage" level="DEBUG"/>            
</included>

Other application settings are in a file at ${catalina.base}/conf/myApp.properties and configured like this:

@PropertySources(value = {@PropertySource("file:${catalina.base}/conf/myApp.properties")})
public class Application extends SpringBootServletInitializer {           

            public static void main(String[] args) {

                        SpringApplication.run(Application.class, args);

            }
}

Finally, when running from Eclipse, catalina.base is defined as VM argument:
-Dcatalina.base=.

December 13, 2013

A Layered Game Architecture III - Scenes and Directors

Scenes and Directors

Apart from actor AI, states and physics as describe in the first backend post, there is much more to be controlled in a game like:
  • handling collision events
  • watching actor's life power
  • collecting visible actors for each player
  • using gadgets like invisibility, super speed, damage doubling, etc.
  • walking upon special tiles for powering-up
  • opening and closing doors
All this is controlled by various directors. A director is the controller counterpart in a MVC architecture. Its models are actors and scenes.




Scene directors control game scenes. A scene is the model of one part of a running game. Games can have one or multiple scenes.
Examples for scenes are:
  • a shop to buy new weapons 
  • the battlefield where the action takes place
  • a screen to switch levels 
  • a built in mini game
  • an underground dungeon as opposed to the day light world
Now, just like in the real world, directors like to delegate work. Here, there are various sub directors, each specialized for one kind of task. For all the listed tasks at the beginning of this post, there is one sub director.
There are two given abstract implementations of sub directors:
  1. Directors that operate on a (dynamic) list of actors of one defined type, like for example:

    BlackHoleDirector - for droids and bullets
    Loops through its actors and drags them into nearby black holes if applicable.

    ActorLifeDirector - for droids
    Removes droids with a power of zero.

    PhysicsDirector - for droids, bullets and level gadgets
    Listens for added and removed scene actors and notifies the physics module about it. Creates appropriate events for actor collisions.
     
  2. Directors for tasks that are not bound to given actor lists, like for example:

    BulletDroidCollisionDirector
    Does not work on a list of actors, but on incoming collision events between droids and bullets detected by the physics director.

    InvisibilityGadgetDirector
    Does not work on a list of actors either, but on incoming player requests to become invisible. Activates and publishes according looks and disables invisibiltiy after a given time span.

    VisibilityDispatchDirector
    Does not work on a list of actors but on the list of current players. Each player gets a personal list of currently visible actors.
If neither AbstractSubDirector or AbstractActorsSubDirector suits a given task, ISubDirector can be implemented and plugged in as well.

Some important characteristics of sub directors:
  • They allow to modularize game control into smaller maintainable tasks.
  • They are invoked one after another from the game loop.
  • They can be invoked for each game frame or after a defined time span, like every 100ms.
  • They realize a plugin concept for the whole game direction sub system.
  • They can be enabled and disabled at runtime.