Libgdx - Generate Bitmap Fonts for Any Screen Size With Minimal Loading Time.

UPDATE: I got some requests, so I created a github repo to make it easy to include this functionality into your project.  This the best way to use this code.

https://github.com/jrenner/gdx-smart-font

This post will show you how to use the FreeTypeFontGenerator (a libgdx extension) and the BitmapFontWriter (included in gdx-tools) to dynamically generate your bitmap font to suit the screen size of the device the app is running on.  We will also optimize the process so that the fonts are only generated if there is no previously generated version found.

FreeTypeFontGenerator is not part of the core libgdx package (not in gdx.jar), to learn how to include it in your project, or use it in general, see this page on the wiki.

BitmapFontWriter is also not part of libgdx core.  It is located in the gdx-tools.jar.  Fortunately, it has little dependencies, which means you can just copy/paste the code of the BitmapFontWriter class directly into your project as a single file, and get it working with little alterations.

Once you get those two things setup, you are ready to go.  Below is the code you need to accomplish font generation/loading.

We get three main benefits from this code:
#1 No need to pre-render font bitmaps using Hiero or some other tool

#2 Fonts are perfectly (more-or-less) sized in proportion to whatever screen size the app is launched with.  Screen-size changes in between launch are also handled. (For mid-game resizing, you would have to do some more work)

#3 By saving the generated fonts to file, we can load from file in subsequent startups where the screen size has not changed (On Android, it should never change).  In my case, this cuts down the loading time for fonts dramatically, make the app start up much snappier.

In my case, where I generate 4 fonts, generating fonts took 3765ms, while loading the pre-generated fonts only took 325ms.  That's more than 3 seconds shaved off of app startup time!

In the images below, notice how despite the different window sizes, the fonts retain the same proportion.  The same effect will occur on Android screens.


1280x720

800x480

First, let's take a look at the code generating the fonts:

	private static void generateFonts() {
	// if fonts are already generated, just load from file
	Preferences fontPrefs = Gdx.app.getPreferences("org.jrenner.superior.font");
	int displayWidth = fontPrefs.getInteger("display-width", 0);
	int displayHeight = fontPrefs.getInteger("display-height", 0);
	boolean loaded = false;
	if (displayWidth != Gdx.graphics.getWidth() || displayHeight != Gdx.graphics.getHeight()) {
	Tools.log.debug("Screen size change detected, regenerating fonts");
	} else {
	try {
	// try to load from file
	Tools.log.debug("Loading generated fonts from file cache");
	smallGeneratedFont = new BitmapFont(getFontFile("exo-small.fnt"));
	normalGeneratedFont = new BitmapFont(getFontFile("exo-normal.fnt"));
	largeGeneratedFont = new BitmapFont(getFontFile("exo-large.fnt"));
	monoGeneratedFont = new BitmapFont(getFontFile("lib-mono.fnt"));
	loaded = true;
	} catch (GdxRuntimeException e) {
	Tools.log.debug("Couldn't load pre-generated fonts. Will generate fonts.");
	}
	}
	if (!loaded || forceGeneration) {
	forceGeneration = false;
	float width = Gdx.graphics.getWidth();
	float ratio = width / 1280f; // use 1920x1280 as baseline, arbitrary
	float baseSize = 28f; // for 28 sized fonts at baseline width above
	// define other sizes
	int size = (int) (baseSize * ratio);
	int smallSize = (int) (size * 0.75f);
	int largeSize = (int) (size * 1.5f);
	// store screen width for detecting screen size change
	// on later startups, which will require font regeneration
	fontPrefs.putInteger("display-width", Gdx.graphics.getWidth());
	fontPrefs.putInteger("display-height", Gdx.graphics.getHeight());
	fontPrefs.flush();
	FileHandle exoFile = Gdx.files.internal("fonts/Exo-Regular.otf");
	int pageSize = 512; // size of atlas pages for font pngs
	smallGeneratedFont = generateFontWriteFiles("exo-small", exoFile, smallSize, pageSize, pageSize);
	normalGeneratedFont = generateFontWriteFiles("exo-normal", exoFile, size, pageSize, pageSize);
	largeGeneratedFont = generateFontWriteFiles("exo-large", exoFile, largeSize, pageSize, pageSize);
	FileHandle libMonoFile = Gdx.files.internal("fonts/LiberationMono-Regular.ttf");
	monoGeneratedFont = generateFontWriteFiles("lib-mono", libMonoFile, smallSize, pageSize, pageSize);
	}
	}

view raw generate.java hosted with ❤ by GitHub

Now, let's see how we save the generated fonts to file.  These methods could be directly copied and pasted into your project without alteration.

	/** Convenience method for generating a font, and then writing the fnt and png files.
	* Writing a generated font to files allows the possibility of only generating the fonts when they are missing, otherwise
	* loading from a previously generated file.
	* @param fontFile
	* @param fontSize
	*/
	private static BitmapFont generateFontWriteFiles(String fontName, FileHandle fontFile, int fontSize, int pageWidth, int pageHeight) {
	FreeTypeFontGenerator generator = new FreeTypeFontGenerator(fontFile);
	PixmapPacker packer = new PixmapPacker(pageWidth, pageHeight, Format.RGBA8888, 2, false);
	FreeTypeBitmapFontData fontData = generator.generateData(fontSize, FreeTypeFontGenerator.DEFAULT_CHARS, false, packer);
	Array<Page> pages = packer.getPages();
	TextureRegion[] texRegions = new TextureRegion[pages.size];
	for (int i=0; i<pages.size; i++) {
	Page p = pages.get(i);
	Texture tex = new Texture(new PixmapTextureData(p.getPixmap(), p.getPixmap().getFormat(), false, false, true)) {
	@Override
	public void dispose () {
	super.dispose();
	getTextureData().consumePixmap().dispose();
	}
	};
	tex.setFilter(Texture.TextureFilter.Nearest, Texture.TextureFilter.Nearest);
	texRegions[i] = new TextureRegion(tex);
	}
	BitmapFont font = new BitmapFont(fontData, texRegions, false);
	saveFontToFile(font, fontSize, fontName, packer);
	generator.dispose();
	packer.dispose();
	return font;
	}
	private static boolean saveFontToFile(BitmapFont font, int fontSize, String fontName, PixmapPacker packer) {
	FileHandle fontFile = getFontFile(fontName + ".fnt"); // .fnt path
	FileHandle pixmapDir = getFontFile(fontName); // png dir path
	BitmapFontWriter.setOutputFormat(OutputFormat.Text);
	String[] pageRefs = BitmapFontWriter.writePixmaps(packer.getPages(), pixmapDir, fontName);
	Tools.log.debug(String.format("Saving font [%s]: fontfile: %s, pixmapDir: %s\n", fontName, fontFile, pixmapDir));
	// here we must add the png dir to the page refs
	for (int i = 0; i < pageRefs.length; i++) {
	pageRefs[i] = fontName + "/" + pageRefs[i];
	//Tools.log.debug("\tpageRef: " + pageRefs[i]);
	}
	BitmapFontWriter.writeFont(font.getData(), pageRefs, fontFile, new FontInfo(fontName, fontSize), 1, 1);
	return true;
	}
	private static FileHandle getFontFile(String filename) {
	return Gdx.files.local("generated-fonts/" + filename);
	}

view raw font-writing-saving.java hosted with ❤ by GitHub

A convenient desktop launcher class for libgdx

I use this in my libgdx project to make switching screen sizes and emulating the dimensions of various phones easy to do.  I thought I'd share it here:

	import com.badlogic.gdx.backends.lwjgl.LwjglApplication;
	import com.badlogic.gdx.backends.lwjgl.LwjglApplicationConfiguration;
	public class DesktopStarter {
	private static final short FULLSCREEN = 0;
	private static final short GALAXY_S3 = 1;
	private static final short NEXUS_ONE = 2;
	private static final short EVO3D = 3;
	private static final short BIG_WINDOW = 4;
	private static final short SMALL_PHONE = 5;
	// choose size here
	private static final short DEBUG_SIZE = 5;
	public static void main(String[] args) {
	LwjglApplicationConfiguration cfg = new LwjglApplicationConfiguration();
	cfg.title = "Strategy Game";
	cfg.useGL20 = true;
	if (DEBUG_SIZE == FULLSCREEN) {
	cfg.width = 1920;
	cfg.height = 1080;
	cfg.fullscreen = true;
	} else if (DEBUG_SIZE == GALAXY_S3) {
	cfg.width = 1280;
	cfg.height = 720;
	cfg.fullscreen = false;
	} else if (DEBUG_SIZE == EVO3D) {
	cfg.width = 960;
	cfg.height = 540;
	cfg.fullscreen = false;
	} else if (DEBUG_SIZE == NEXUS_ONE) {
	cfg.width = 800;
	cfg.height = 480;
	cfg.fullscreen = false;
	} else if (DEBUG_SIZE == SMALL_PHONE) {
	cfg.width = 480;
	cfg.height = 320;
	cfg.fullscreen = false;
	} else if (DEBUG_SIZE == BIG_WINDOW) {
	cfg.width = 1900;
	cfg.height = 1020;
	cfg.fullscreen = false;
	}
	cfg.resizable = false;
	cfg.vSyncEnabled = false;
	cfg.audioDeviceBufferCount = 16;
	new LwjglApplication(new Main(), cfg);
	}
	}

view raw Desktop.java hosted with ❤ by GitHub

dirhelp - understanding Linux's Filesystem Hierarchy Structure

A while back I created a command line utility to help with learning the linux filesystem hierarchy structure (FHS), it's called dirhelp.

Here is some example usage:

jrenner@main:/$ dirhelp
[/] Primary hierarchy root and root directory of the entire file system hierarchy.
jrenner@main:/$ dirhelp opt
[/opt] Optional application software packages.
jrenner@main:/$ cd /var/log
jrenner@main:/var/log$ dirhelp
[/var/log] Log files. Various logs.
jrenner@main:/var/log$ dirhelp /usr/share
[/usr/share] Architecture-independent (shared) data. This directory contains subdirectories with specific application data, that can be shared among different architectures of the same OS.  Often one finds stuff here  that  used  to live in /usr/doc or /usr/lib or /usr/man.
jrenner@main:/var/log$ dirhelp /usr/local
[/usr/local] Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin/, lib/, share/.
jrenner@main:/var/log$ cd /usr
jrenner@main:/usr$ dirhelp *
'/usr/games' - no information found
'/usr/lib32' - no information found
[/usr/bin] Non-essential command binaries (not needed in single user mode); for all users.
[/usr/include] Standard include files for the C compiler.
[/usr/lib] Libraries for the binaries in /usr/bin/ and /usr/sbin/.
[/usr/local] Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin/, lib/, share/.
[/usr/sbin] Non-essential system binaries, e.g., daemons for various network-services.
[/usr/share] Architecture-independent (shared) data. This directory contains subdirectories with specific application data, that can be shared among different architectures of the same OS.  Often one finds stuff here  that  used  to live in /usr/doc or /usr/lib or /usr/man.
[/usr/src] Source code, e.g., the kernel source code with its header files.
[/usr/X11R6] X Window System, Version 11, Release 6.

Getting Into Open Source as an Inexperienced Self-Taught Programmer

I often see questions from newer programmers like myself asking how they can start getting involved in open source projects. On Reddit's learnprogramming subreddit, it is #9 on the FAQ list.

I want to share my own experience.

After about a year and half of teaching myself programming, I had dabbled in a variety of languages and a few different programming environments.  I had a little experience in a large range of fields: Android development, Python desktop applications, network servers and clients in C and Go, and various toy game projects in a variety of frameworks.  While this provided me with a lot of useful learning opportunities, it never left me feeling skilled enough in any one area to meaningfully contribute to an open source project.

Some time in 2012, I heard about Glances, a curses based system monitor program written in Python.  I thought it was a nice program, downloaded it, and used it from time to time.

Eventually, in February of this year (2013), I came across Glances again when I was looking for open source projects to contribute to.

Python was the language I first started to learn programming with, and it is probably still the language I feel most comfortable in, so the project was a good fit for me.

The most difficult part of getting involved in a new project is understanding the project structure and the code base.  Fortunately for me, it wasn't necessary to understand the entire code base before I started making some changes.  By starting with a very small change, you can hopefully avoid affecting other parts of the code.  If you want to continue contributing to the project, it will eventually be essential to understand how everything works together, but changing some string formatting here and there, or adding a new data piece to an object might not be that big a deal.  You should still do your best to tread carefully.  The best case scenario is your pull request gets reject with some nice comments asking for changes.  The worst case scenario is you introduce bugs into the project that go undiscovered until it's too late.

I began to contribute to the project by adding small, easy to implement features.  Specifically, I added options for displaying network traffic data.  I think this is an excellent way for newer programmers to start contributing, but it is important to keep in mind that the maintainers of the project may not necessarily be interested in adding these features, depending on their vision for the project.  Communication is important if you don't want to risk wasting your time.  It doesn't hurt to first send an email laying out your plans, and asking for opinions, or even just asking for help.

Next, after doing more work on small features and various bug fixes, I implemented a feature that allowed Glances to run without collecting processes data, which was the vast majority of CPU overhead.  This allowed Glances to run on my Raspberry Pi, using only 2-4% of CPU, instead of 20% (!).  Of course, it meant sacrificing data for individual processes, but a system monitor app that takes 20% CPU is of questionable usefulness anyways.

This, is in turn, gave me an idea for how I could further contribute.  Glances can run in server mode, and using an XML/RPC api, it can deliver its data in json format.  I run my Raspberry Pi headless, so this seemed like it could be really useful when ssh is not an option.

As I mentioned above, I had some experience with Android, so I spent a month or so implementing the Glances API in Java, which is technically the first open source project of any usefulness that I have created.

The next step after that was to create the Android app. It uses the Java Glances API to collect the data and display it to user:

The final product can be downloaded here

Or you can view the Github repo

Interestingly, shortly after the creation of the repo, a contributor helped out by adding a French localization (Glances is popular in France, the home of its creator) and also the cpu and memory utilization bars seen in the above screenshot.

I  think the key to getting involved in your first open source project is to aim small, be polite, and don't be afraid to ask questions.  Things can really ramp up from there.

Making a Guided Missile in libGDX with Box2D

To see an example, take a look at this video:


Or this one with overhead strikes:

Finally here is a video that shows a large number of missiles chasing another missile:


To create a guided missile like this, you have to do a few things:

1. Have a target, that is updated every frame with its current position
2. (Optional) set some fixed waypoints on the way to the target to alter the flight path, this creates the overhead strike you see in the video, and is one way to improve accuracy
3. Create a "steer point" that will guide your missile towards the next waypoint/target, but corrects for velocity of the chaser and the chased
4. Turn the body of the missile until it is facing the steer point.
5. When we are happy with the facing of the body, we accelerate it.
6. If you want the missile to explode, you can check distance from target, or use Box2D's contact listener

Setting the targeting and updated it's Vector2 position should be easy enough, so I won't explain it here. Let's skip to step 3.

Assuming we have a target, let's face the target

	void steerToDesiredFacing() {
	if (desiredFacing == null) {
	return;
	}
	float facing = getForwardFacing();
	// this contrain method keeps the angle between 180 and -180
	float diff = constrainAngle180(facing - desiredFacing);
	// steer within n degrees of desired facing, use this to control precision
	float angularThreshold = 1;
	float angularVel = body.getAngularVelocity();
	// if we are turning too fast for the remaining turn distance, we slow down with this hack
	// this can prevent an over-steering behavior that causes wobble
	if (Math.abs(angularVel / diff) > 0.1f) {
	body.setAngularVelocity(angularVel * 0.90f);
	}
	float torque = rotationForce;
	// turn one way
	if (diff >= angularThreshold) {
	body.applyTorque(-torque, true);
	// or turn the opposite way
	} else if (diff <= -angularThreshold) {
	body.applyTorque(torque, true);
	// if we are within 5 degrees of desired facing
	// we want to kill our turn gradually, but strong enough to stop
	} else if (diff < 5) {
	if (angularVel < 0.2) {
	// turning slow enough to be on target
	body.setAngularVelocity(0);
	removeDesiredFacing();
	} else {
	body.setAngularVelocity(angularVel * 0.5f);
	}
	}
	}

view raw faceTarget.java hosted with ❤ by GitHub

let's correct for velocities: 

	private Vector2 getVelocityCorrectionSteerpoint(Vector2 waypoint) {
	if (waypoint == null) {
	return null;
	}
	Vector2 selfVel = body.getLinearVelocity().cpy();
	// if this is not a regular waypoint, but instead a point we should chase
	// (like a moving enemy target) then we want to correct for the target's velocity as well
	if (isChaseTargetPosition(waypoint)) {
	// add target's velocity to the waypoint, so we can predict movement
	Vector2 targVel = targetEntity.body.getLinearVelocity();
	waypoint.add(targVel);
	}
	Vector2 selfPos = body.getPosition();
	// desired velocity is target's position minus our position
	Vector2 desiredVelocity = waypoint.cpy().sub(selfPos);
	// The correction we need to make to the waypoint is
	// the difference between desire velocity and current velocity
	Vector2 steeringCorrection = desiredVelocity.sub(selfVel);
	// new waypoint = old waypoint + steering correction
	Vector2 steeringCorrectionPoint = steeringCorrection.add(waypoint);
	return steeringCorrectionPoint;
	}

view raw velocityCorrection.java hosted with ❤ by GitHub

Now let's seek the waypoint:

	void seekWaypoint(Vector2 waypoint) {
	Vector2 pos = body.getPosition();
	float dist = waypoint.dst(pos);
	// you should set a threshold for arrival distance
	// that is good enough to be considered "arrived" for your purposes
	if (dist < arrivalThreshold) {
	if (waypoints.contains(waypoint)) {
	// if we are chasing a target, don't remove the waypoint upon reaching arrival distance
	waypoints.remove(0);
	waypoint = getCurrentWaypoint();
	if (waypoint == null) {
	return; // no more waypoints
	}
	} else if (waypoint.equals(chasePoint)) {
	// just keep chasing!
	}
	}
	// accelerate towards the waypoint, since it is beyond arrival distance threshold
	// here is where we used the velocity correction method from above
	Vector2 correctiveSteerpoint = getVelocityCorrectionSteerpoint(waypoint);
	Vector2 destination = correctiveSteerpoint;
	// to avoid over correction, we have a minimum distance from target for correction to occur at
	// if we are under the minimum, just head towards the original waypoint
	if (correctiveSteerpoint.dst(pos) < minSteeringDistance) {
	destination = waypoint;
	}
	// we set the desired facing, so we now where to turn to face our destination
	setDesiredFacing(getAngleFromAtoB(pos, destination));
	// only accelerate if we are pointed at the destination
	if (getSteeringDifference() < maxSteeringErrorForAcceleration) {
	accelerate();
	}
	}

view raw seekWaypoint.java hosted with ❤ by GitHub

And that's about it.  Here is the code for constraining the angle to 180 and -180 degrees:

	public static float constrainAngle180(float angle) {
	while (angle > 180) {
	angle = angle - 360;
	}
	while (angle < -180) {
	angle = angle + 360;
	}
	return angle;
	}

view raw constrain180.java hosted with ❤ by GitHub

Now you need to implement acceleration and contact/explosion handling on your own.

Air Resistance in Box2D

I've seen many questions asking how to implement air resistance (drag) in box2d, and the most common solution is to use body.setLinearDamping.  After just a little bit of research, I discovered that calculating air resistance is not that difficult.  Here is an example in Java using box2d.
Note: this is not a full simulation of aerodynamics, it only affects linear velocity.
After reading the source, check out the algorithm in action in this video.

	float dragForce;
	Vector2 appliedDrag = new Vector2();
	float dragAngle;
	float p, A, Cd, v; // elements of the formula see wikipedia entry for Drag (physics)
	/*
	ρ is the density of the fluid,
	v is the speed of the object relative to the fluid,
	A is the cross-sectional area
	Cd is the drag coefficient – a dimensionless number.
	sample drag co-efficients (http://en.wikipedia.org/wiki/Drag_coefficient)
	cube = 1.05
	sphere = 0.47
	streamlined-body (smooth wing shape) = 0.04
	*/
	// it's not necessary to calculate fluid density as I have, try 1.0 and change it until it looks nice
	p = FLUID_DENSITY_OF_AIR * getAtmosphericDensity(ent.getAltitude()); // density of the fluid
	// we can just leave this, cross-sections are beyond the scope of what we want to simulate
	A = 1.0f;
	// a very sleek object
	Cd = 0.05f;
	v = (float) Math.pow(ent.getSpeed(), 2); // speed squared
	dragForce = 0.5f * p * v * Cd * A;
	// we need the angle of the body's current velocity to know which angle we should set the drag force
	dragAngle = ent.body.getLinearVelocity().angle();
	// create a vector based on our dragForce
	appliedDrag.set(dragForce, 0);
	// align the drag to the same angle as our velocity
	appliedDrag.setAngle(dragAngle);
	// drag should slow down velocity when added to current velocity, so we make it negative
	appliedDrag.scl(-1);
	ent.body.applyForceToCenter(appliedDrag, true);

view raw box2d_air_resistance.java hosted with ❤ by GitHub

Python - A Graphical Representation of Binary Search Trees

I used Python and pygame to create a navigable, graphical representation of a binary search tree.