The new game we're making calls for drawing some stippled lines. This is for the map where connections will be drawn with stippled lines, like in Monster RPG 2. In Monster RPG 2, I didn't use shaders and didn't want to use OpenGL directly so opted to create images of all of the lines. This time I didn't want the extra work, and we're using shaders from the start.

Below is a shader that can be used to draw stippled lines. It takes a few parameters:

The most critical part of this shader is taken from Paul Bourke's excellent guide, located here. The function, called closest_point in the shader, gets the closest point on the line (sx,sy -> dx,dy) to a given point -- this is important because we want to draw thick lines, and without this the stipples will look slanted the wrong way. Here is that function:

x1,y1 is the start point of the line, x2,y2 is the end point, x3,y3 is the point and x,y are the output.

Now that we have the closest point on the line, we need to calculate which pixels should be drawn and which not drawn. Doing so is fairly simple. We get the distance of the point (after calculating the point on the main line) to the start point. A floating point modulus gives us the distance travelled in a run of run_sz1+run_sz2 length. Comparing that to run_sz1 tells us if the point should be drawn or not. Here is the main function:

The only part that remains to be explained is the viewport_h-gl_FragCoord.y part. Since I'm using Allegro and Allegro positions the origin at the top left of the drawing target, to get the actual y position we need to invert it, since OpenGL's default origin (the one gl_FragCoord uses) has the origin at bottom left.

Here's a random screenshot of the function using 10 pixel run1_sz and 30 pixel run2_sz:

And here's a link to the full source code in a format easily usable in an Allegro 5 program:

Source code.

There's very little to this and it can be done outside of the Allegro core, so there's no point in putting it there.

The way the iCade controllers all work is by sending keys (as in keyboard keys) via Bluetooth, but the situation on iOS isn't ideal. You can't read key up/down events on iOS at the moment (IOKit is a private framework) so the iCade sends letters only, and on top of that, different letter for key down than key up. It's documented in the iCade documentation, so check that out.

So what you need to do in a game is create a hidden UITextView to receive the text input and have a delegate attached to that that pumps events into an Allegro event queue. We user Allegro's user events for this purpose. We take care that the text view doesn't fill with many characters by removing them as we generate events for them.

I haven't received my "8-bitty" yet but I've tested this with a regular bluetooth keyboard. So first things first, we need a few event ids.

Using ALLEGRO_GET_EVENT_TYPE is important, kind of, because it should ensure your events are within an appropriate range and do not collide with Allegro core events.

When you read events with Allegro's al_get_next_event (and related functions), event.type will equal one of these constants when you get an iCade event. To make inter-operation with regular key events easier, I set event.keyboard.keycode to the generated keycode rather than using event.user.data*.

There is one thing you must remember when you use this! Every time you pull an event out of an event queue (even with al_peek_next_event!) you must call al_unref_user_event on it (only if it's a user event, which you can check with ALLEGRO_EVENT_TYPE_IS_USER()), otherwise you'll have a memory leak. So let's look at the rest of the code, which is quite short.

If you read this carefully you'll see that the events you get are always the ones listed as DOWN events in the iCade documentation, to make things easier. For example, an X means direction down is pressed and a Z means direction down is released in the iCade documentation. But in this implementation, you'll get a USER_KEY_DOWN and USER_KEY_UP, both with ALLEGRO_KEY_X as the keycode. This code will also generate a USER_KEY_CHAR event after each USER_KEY_DOWN event. In real life I'll probably wrap this in some code that makes USER_KEY_CHARs repeat like a real keyboard while the button is pressed, but that's left as an exercise to you.

To use this, first register the event source with the event queue you want the events to go to (that being user_event_source). Next, call initiOSKeyboard(). And that's it. You should start receiving those USER_KEY_* events in your event queue. Happy gaming!

P.S.: In case you didn't notice, this is Objective-C code, so it needs to be compiled as such. The rest of your program can still be C or C++.

Disclaimer: There may be an easier way to do this. I'm not an expert when it comes to Android. This is the first and only thing I managed to find that did what I want.

So what does it do? With this input method activated, key-presses and releases get sent to your app almost untouched and "raw". This is good for games. I found the default input methods would automatically send a key up event with MOST (but not ALL D:) key down events which is not good when it comes to games. The default is meant for text input, this is meant for games.

I said almost. The only other thing it does is insert a 150 millisecond (change one constant to change the delay) key repeat delay.

I still haven't looked into how, or if it's even possible, to bundle and automatically activate this from a game. Here's hoping!

This can also serve as a complete example of how to make a simple input method from scratch. You can build on it. Use it how you like! The structure is there which took me a little time to figure out so you don't have to. Make it better! Make the key repeat delay configurable and add an initial delay that's longer.

To use this in your application you can use the onKeyDown and onKeyUp methods of SurfaceView (or GLSurfaceView.)

The source code.

I've been busy going through the bug/feature request list and fixing/adding things. Monster RPG 2 1.13 is going to have a lot of small and medium sized tweaks/fixes. I've got 15 left (some of the larger ones are still left to do) at the time of writing this. For those interested here's a list of what I've done for this release so far (the Raspberry Pi port already has the first few of these since it was done after and separate from 1.12 on other platforms):

• Textured all of the 3D models
• New Russian translation
• Indiegogo sponsor credits at the end of the game
• More believable/passable "Breath of Fire" attack from the dragon
• Missing data no longer causes crashes (it will ask you if you want to proceed, which will usually crash if you say yes)
• Autosaves on PC (they've been on the iOS and Android versions all along)
• Custom mouse cursor
• You can inspect the library shelves to see book titles
• All party members close their eyes when sleeping
• A notice is shown when you trade for an item
• F8 (default) auto-sorts your inventory when in the pause->items screen
• In the pause menu (and other places where player profile "mug shots" are shown), a purple border is shown around poisoned members
• Red and green down/up arrows are shown when inspecting items, letting you know if the item is better or worse than what everyone already has
• Game Center support was added on Mac OS X
• All those thousands of tiles are in a zip file now (I'm embarrased about this, I was too lazy before)
• The biggest window that's an integer scaling factor of the games native res will be chosen by default (if you have a config file already, delete it to get this behaviour)
• Odd looking tree overhangs fixed in jungle
• Some odd behaviour when using mouse or touch screen was fixed (clicking an object would not take you there)
• Fixed two tiles that were solid and not solid when they should have been opposite in the forest
• Screensaver will no longer activate when the game is running on Linux
• Alien items are now all stronger than Light items
• Item stacking behaviour is better in inventory
• Bartender's juice stacks correctly now
• Juice now has a distinct sound when used (used to be same as Cure)

And a few other minor ones.

One of the Code Monkey requests from the Monster RPG 2 Indiegogo campaign was to allow using SVG with Monster RPG 2. I spent weeks on the problem, but it didn't look like it would come to an end any time soon. So I searched the web and found libsvgtiny, part of the Netsurf web browser project.

This is a perfectly competent library for most modest needs. I implemented an Allegro 5 renderer using the test program. Unfortunately, the code I wrote cannot handle self-intersecting paths. As far as I know that's the main limitation. It renders many SVGs perfectly.

This code is now in the Monster RPG 2 git repo. I'll also include the single C++ file as it stands right now at the bottom of this post. Hopefully at some point I will be able to solve the intersecting path problem. For now, it's good for many needs if you keep that in mind.

a5_svg.cpp

NOTICE: You can download this tutorial from git along with the library itself. The version in git is the one which will likely receive the most TLC and updates. See below for the command to get TGUI from git.

TGUI has been around since I returned to making games in around 2002. It has changed a lot at times and I still consider it an evolving API. I've never written any reference or tutorial on how to use it -- until now (ok, I still haven't written it, but I'm getting to that.) This tutorial assumes the reader has knowledge in C++ and has an Allegro 5.1 development environment already set up.

The first step -- get TGUI2! You can do so with git: git clone git://nooskewl.com/tgui2.git

I presume you know how to build software from source, but the skinny is:

Substitute for things in <>'s. The -D... part it wholey optional -- you should know if you need it.

Ok, so let's break down the fundamental concepts before making a hello world program. TGUI is split into some setup functions and a few core functions you'll call within your game loop. The setup functions create and add widgets to your view. A simple TGUI program with just two buttons you can click on would start out like this (rough pseudo-code in part so we focus on the TGUI stuff:)

A quick breakdown of each call is: tgui::init is always called before any other TGUI functions -- pass it the ALLEGRO_DISPLAY you're going to work with; tgui::setFont allows you to set the font TGUI will use for things with text, such as the buttons (this is not currently optional if you're using widgets that display text); The next two "new TGUI_Button" lines create two different buttons with different text and positions but the same size; tgui::setNewWidgetParent is not necessary here since the default is 0 (meaning the parent of added widgets is the display), but you will get into situations such as adding child widgets to a window where it's needed; The calls to tgui::addWidget will add the widgets to the scene so they are processed and drawn as we'll see soon; and finally, though also not necessary in this simple mouse driven example, tgui::setFocus gives the input focus to a widget.

Those are the main functions you'll deal with during setup, besides creating different types of widgets. There are other functions you can use of course, but they won't be covered here.

The next part of a TGUI program is pretty simple, and as I said it's the game loop integration.

First look at a typical Allegro 5 game loop:

TGUI integrates very easily with loops similar to this:

You'll see three main changes here, marked with *#* comments. tgui::handleEvent does all of the magic input handling, passing input events along to widgets to react to. You define these callbacks yourself when you create custom widgets or inherit from existing ones. tgui::update is special and we'll get to it in more detail in a minute, but you will place your game logic that reacts to the GUI elements after receiving the return value from this call. tgui::draw is simple, it just draws the GUI elements you added with tgui::addWidget.

So now onto responding to GUI events at the game level. We want button1 to change the clear color of the screen to something random, and button2 to quit the app. We modify the tgui::update call and add a few lines like so:

So tgui::update returns a tgui::TGUIWidget. tgui::TGUIWidget happens to be the base class that all widgets used with TGUI must inherit from. What widget gets returned depends on what events were passed to tgui::handleEvent (for default widgets, you can come up with any logic you like for custom widgets.) If no widget needs action, tgui::update returns NULL. In our case TGUI_Buttons return a pointer to themselves when clicked, so if button1 is clicked, button1 is returned from tgui::update. We check for each button being pressed and react appropriately.

That is all there is to it. Below I'll put a complete code listing for a working demo using the bits from above. Happy coding!

After a month of work I have a skeletal animation software for use with Baryon. It was a really benefitial experience. TGUI improved a lot because of it, and now we can add some really interesting enemies to Baryon that won't consume massive amounts of disk space. As usual I like sharing the tools I make if I think they'd be useful for others, so I'll link below to the binaries for Windows, Mac and Linux. I'll also link to a Youtube video that shows off just a small bit of the potential of the software.

The editor will output some XML data. It expects to find images and XML files in data/skeletons/parts and data/skeletons/xml from the directory of the executable. The XML format is mostly self explanatory, but if someone wants the low-down I can post it. Also, there is code to load and display these things but it's in Baryon-core. If anyone is serious about using this in a game, I'll make that code available.

Skeled for multiple platforms (binary)

I've been updating my fireworks demo each year for a couple years now, and I decided to update it again this year. No major changes, just some minor "bugs" fixed, and a small (303KB) standalone exe with icon.

WARNING! This can get LOUD.

Stand-alone fireworks demo (exe, 303KB)
7-zip archive including binary and source code (about the same size)