Identical Games

Name:	Bt Builder
Version:	0.5.8
Author:	Dennis Payne
License:	GPLv3
Operating System:	Unix and Windows
Website:	http://identicalsoftware.com/btbuilder/

Pocket CHIP

With the arrival of Pocket CHIP, I quickly set about building Bt Builder on the new device. Once the system was updated, it was easy to download all the development tools needed. The compiler worked it's magic to convert the source code to an executable. A few seconds latter, Bt Builder started up or at least it should have.

Expecting that SDL was not initializing properly, I developed a standalone test program. It worked perfectly. The program hung while processing the command line before starting SDL. The option parsing function getopt_long was not returning -1 when it completed. In truth it was returning -1 but Bt Builder stored the result in a char. On the ARM platform, char defaults to unsigned. The documentation for getopt_long correctly documents the result was an int not a char. Running programs on multiple operating systems or machine architecture can often find these kinds of errors.

SDL2

With Bt Builder running, I showed off the new device to my coworkers. The first comment was about it being hard to read. She was correct. The 480 by 272 display is not bad but Bt Builder only used 320 by 200 of it.

Bt Builder has the ability to scale the display by whole number multipliers. To scale to the screen of Pocket CHIP, two options were considered. SDL_gfx has scaling functions. Alternatively in the years since the development of SDL1.2, game developer have found it valuable to not change the screen resolution and instead of simply scaling the results to the current screen. SDL2 incorporated this idea.

SDL2 is not backward compatible to the 1.2 library. The migration guide explains various changes to convert to the new library. The attention to this detail is evident in the API. SDL_ConvertSurface includes a flags argument which is listed as "a leftover from SDL 1.2's API. When given a choice between a "perfect" interface or something that will help developer's convert to the new library, they chose the later.

Things did not get off to a good start when converting the SDL_mng library. For unknown reasons, the SDL_RWSeek didn't work with negative numbers with SEEK_CUR. I don't know why that fails. To solve the issue, I converted it to use SDL_RWtell and SEEK_SET for now. Looking at the source to SDL2 doesn't reveal an obvious bug so more debugging is needed to uncover the root cause.

Most of changes were very easy to get Bt Builder running. Currently Bt Builder is not talking advantage of the new SDL_Texture. It may be possible to make the animations more resource efficient by using them but that can be explored another time.

The biggest change for Bt Builder was keyboard input. In SDL 1.2, on keyboard input the library provided a field called unicode. It converted the input to unicode characters. This was useful if you wanted to get 'A' without having to check for a key press of A while shift is pressed. Unfortunately this didn't work for Asian languages where you use an input method editor. SDL2 eliminated the unicode field.

The library introduces a new function called SDL_StartTextInput. When that is called text input events will be sent. On some platform this may also cause the on screen keyboard to display. Bt Builder doesn't use this feature. The game includes a simple 8x8 monospace font. Supporting Asian (and possibly even accents) is not possible without correcting this. For simplicity, Bt Builder sets ups two maps keycodes, one when no modifier keys are pressed and another for the shift key.

There is another reason that Bt Builder doesn't use the text input events. All input in Bt Builder gets down to the BTDisplay::readChar function. At that point, the code has no idea if the user is entering a string or typing individual characters to perform actions. I could have still used the text input but I was concerned about how text input works. Testing discovered that when text input is turned on you receive both the key press and text input event. Some keys like up and down do not produce text input events. While it would be possible to implement Bt Builder using that, refactoring the code to understand when to use text input would be a better solution.

With the release of Bt Builder 0.5.9, I transferred the files to the Pocket CHIP and started the game. It immediately failed. The signatures for the SDL_RWops functions had changed. This is mentioned in the migration guide and the compiler warned of the problem. With a minor fix and the addition of the new size function, Bt Builder started up on the Pocket CHIP.

SDL2 Try Two

After porting Bt Builder, I converted Troll Bridge to use SDL2 as well. To my surprise the program ran slowly on the Pocket CHIP. I assumed it was due to the 8-bit color surfaces and tried various solutions to fix the issue. Having no luck I wondered if Bt Builder might be encountering the same problem.

Loading the game editor, I selected the monk image. Instead of the quick movements, he slowly moved through his routine. As a turn based game, slow graphics aren't necessarily a big problem for the game. As a kid I played the Bard's Tale series on an underpowered machine but I doubt modern players would accept that. In this case Bt Builder is not slow, only the animations in the game. You could play the game without much of a problem.

The reason for the slow rendering was because SDL2 tried to use hardware acceleration. Pocket CHIP does not currently have a hardware accelerated graphics driver. The simple solution was to pass SDL_RENDERER_SOFTWARE to SDL_CreateRenderer. This forces it to use a software renderer. A new command line argument was added to implement this option.

Loading on Pocket CHIP filled the screen initially. But once you start doing anything, it drew only a 320 by 200 section in the upper left corner. I could have given up on SDL2 at this point and tried SDL_gfx or tried SDL2_gfx. Reverting to older libraries is not very appealing. The SDL2_gfx library is available on Fedora 24 but a MinGW version for cross-compiling a Windows program is not. To avoid losing the windows build, I wrote a simple nearest-neighbor scaling algorithm to convert the image to the full screen.

SDL2 Porting

In general SDL2 porting was easier than SFML2. All the information was presented in the migration guide with links to the documentation. No forum searching needed. The lack of hardware acceleration on Pocket CHIP was disappointing but thankfully SDL2 allows software rendering until the graphic drivers are available.