Daniel Sefton

Slider Menu Widget v2 for Titanium Alloy

Slider Menu Widget v2

There has been an incredible amount of buzz around my iOS Slider Menu Widget for Titanium Alloy. So it’s about time I worked on a new version.

Here’s a Vine of it in action: https://vine.co/v/bV3g9D5An3O

Changes

  • Android support
  • Slide both ways, left and right
  • 3.1 GA+ support, using the new convertPointToView function
  • More closely resembles the latest Facebook app, including sliding from the navigation bar

How to get it

  1. Open Terminal
  2. cd ~/Documents/Titanium_Studio_Workspace/
  3. git clone https://github.com/danielsefton/AlloySliderMenu.git
  4. Open Titanium Studio. Make sure it’s up to date and you have 3.1 GA installed.
  5. File -> Import… -> Existing Mobile Project
  6. Navigate the AlloySliderMenu folder and hit Finish
  7. Run it on the iPhone simulator

Known issues / missing features

  • Android: Table view has no section headers, button images are not centered (see TIMOB-13995), zIndex changing is broken
  • Missing shadow support, unless this pull request is applied to the SDK
  • Sliding isn’t as smooth as I’d like it to be (see TIMOB-7999)
  • There’s a logic hack in widget.js due to me running out of time, cleanup contributions welcome

License
MIT – Do what you like, as long as you include this somewhere in your source code:
Copyright (c) 2012-2013 Daniel Sefton

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

As you can see there is still quite some work to be done before it’s perfect. Contributions are more than welcome!

Education in Third World countries through Technology

A 14 year old built an electricity generator from scratch by reading a physics book from a library, producing irrigation for an entire village.

This shows that education in Third World countries has self-sustaining and long-term value as opposed to funding temporary infrastructure built by First World countries.

The question is: How can we supply that book, and many more, to the millions of people without access to a library?

The answer is not build more libraries, or print more books. The answer is smaller, cheaper, and can hold far more books.

Tablets!

One Laptop Per Child builds and distributes cheap portable computers powered by solar electricity to Third World villages. Each one capable of holding an entire library, and more.

The most powerful learning method is self-learning, and technology enables that.

Imagine if every child could build their own electricity generator.

I will be posting more about this subject over the next few years, stay tuned!

Building Ogre 3D for Android on Mac OSX

Prerequisites

Building Ogre

Extract the Android NDK and SDK and move the folders to a suitable location.

Add the following to ~/.profile or ~/.bash_profile:

export ANDROID_SDK="/path/to/androidsdk"
export ANDROID_NDK="/path/to/androidndk"
export PATH="$PATH:$ANDROID_SDK/tools:$ANDROID_SDK/platform-tools:$ANDROID_NDK"

Extract the dependencies package and move the Dependencies folder to the root directory of Ogre.

Open CMake. Point “Where is the source code” to the root directory of Ogre. Now copy and paste that path into “Where to build the binaries” and add “/build” to the end.

Add Entry -> ANDROID_NDK, PATH, /path/to/android/ndk
Add Entry -> OGRE_DEPENDENCIES_DIR, PATH, /path/to/ogre/deps
Add Entry* -> OGRE_CONFIG_ENABLE_GLES2_GLSL_OPTIMISER, BOOL, TRUE

*Optional – the RTSS renders incorrectly on some devices. Enabling the GLES2 optimiser fixes that, but does cause some instability for certain samples like compositor and cubemapping. Ideally the RTSS should not be used on Android, and custom shaders should be written instead.

According to this post we need to edit ogreroot/CMakeLists.txt and change:

else()
include(TestBigEndian)
test_big_endian(OGRE_TEST_BIG_ENDIAN)
endif()

to:

else()
#include(TestBigEndian)
#test_big_endian(OGRE_TEST_BIG_ENDIAN)
set(OGRE_TEST_BIG_ENDIAN FALSE)
endif()

Press Configure.

It should say “Build directory does not exist, should I create it?”. Choose Yes.

“Specify the generator for this project” should be “Eclipse CDT4 – Unix Makefiles” and “Specify toolchain file for cross-compiling” should be checked. Click Continue. In “Specify the Toolchain file”, point to ogreroot/CMake/toolchain/android.toolchain.cmake

Click Done and wait until configuration has finished. There may be errors, but we can ignore them.

ANDROID_NATIVE_API_LEVEL -> Change to 9

Press Configure again. The config values should turn white.

Press Generate.

In Terminal, cd to the build directory. Run “make”.

If it fails with “Error 2” or “Error 127”, just run make again and it should go away.

cd to the SampleBrowserNDK directory. Run:

ndk-build all -j4
android update project --target "android-17" --path ./
ant debug install

iOS Slider Menu Widget for Titanium Alloy

UPDATE: Slider Menu Widget v2

A fairly recent design pattern has emerged on iOS in the form of a slider menu, used by apps including Facebook, Gmail, Path and YouTube. I decided to re-create this pattern using Appcelerator‘s new Alloy framework. Alloy is an MVC framework designed to streamline app development and can be extended with reusable widgets. You can get alloy here.

Features

  • Tap button to open and close.
  • Drag finger horizontally on left edge to open and close.
  • Shadow drawn with native bezier path.
  • Swap views like a tab group.
  • Reusable Alloy widget.

Limitations

  • To get the shadow effect you need to build a version of the SDK and apply this pull request. Or simply build the SDK with this repo. Use this guide on how to build Titanium Mobile from source.
  • iOS only (for now).

Source Code
https://github.com/danielsefton/AlloySliderMenu

Screenshots

 

License
MIT – Do what you like, as long as you include this somewhere in your source code:
Copyright (c) 2012-2013 Daniel Sefton

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Evolution of Mobile Games

One looming question for mobile gaming is, where do we go from here? Here’s my perspective on the possible evolution of mobile games.

(I’m sure there are better examples than the few I listed, but hopefully you get the idea)

What is Depth?
“Depth” is a pretty broad term, you could actually argue that depth doesn’t translate well to mobile, and that successes will continue to come out of simple front end gameplay.

It’s easier to explain if you think about what games like Farmville lack – they’re a big layer of social front end with some smart graphics to boot, nothing more. In my opinion, this era has past its glory. Not that there won’t always be a market for such games, but players are starting to want something more.

Mobile Budgets
The biggest barrier to producing a game that incorporates both deep gameplay and a polished front-end is time, funding and effort required. A lot of developers simply don’t have this, so right now you’ll see a lot of games that are either really deep with little social implementation, or flat with social in your face. As competition grows however, developers may not have a choice in the matter – budgets will have to go up to stand out from the noise. Bigger and better could be king.

How will indies compete?
There’s no question that tools available to indies are getting better and better. Engines like Unity 3D have advanced significantly, and I’m seeing an increasing number of indie developers using tools like this to boost productivity and focus on gameplay. Then there’s social bolt-ons like GREE and Mobage that can help. In all honesty, there’s no better time than now for small outfits to create new innovative experiences that larger companies struggle to offer.

Casual vs Hardcore
The big problem with this evolution theory is the market split between casual and hardcore gamers. Is bigger and better really the future that will bring greater success on the mobile platform? Will casual gamers become alienated? There is undoubtedly a balance to be made, but I definitely think that certain design choices could have casual gamers enjoying games with a lot more depth than an isometric simulator.

Immersion vs Bursts
The other adaptation mobile requires is gameplay in short bursts. As games become more complex, will that take away their ability to be picked up for a couple of minutes? In my opinion, not at all. But the game has to be designed so that it can take advantage of both, not forgetting that mobile is the new home entertainment system.

Takeaway
My overall prediction is that we will start to see games on mobile which have a deep, quality gameplay experience equal to its polished front end implementation, social functions and monetisation strategy.

Texture Atlases for UIKit with TexturePacker

I use UIKit for my UI, but one issue I was facing is the sheer number of separate image files I was building up in my project. Texture atlas generation is common in OpenGL libraries like cocos2d, and TexturePacker has an export option specifically for these libraries. I couldn’t find anything for UIKit however.

I wrote a quick function to parse TexturePacker’s “Generic XML” data format and generate an NSDictionary of UIImages.

It depends on XMLReader, so you’ll need to include that in your project too.

Updates

  • 13/01/13 – Fixed unnecessary allocation of UIImage which caused a leak.
  • 27/10/13 – Fixed scaling issue on retina devices (thanks Justin!).

UIImage+Sprite.h

// Created by Daniel Sefton, 2012
// Do what you want license
 
#import <Foundation/Foundation.h>
 
/**
 UIImage category to handle parsing of TexturePacker's Generic XML format.
 */
@interface UIImage (Sprite)
 
/**
 The method returns a dictionary of UIImages. Use this function once and reference its contents.
 @param filename the XML file to load, which should be added to your project's bundle
 @returns dictionary of UIImages
 */
+ (NSDictionary*)spritesWithContentsOfFile:(NSString*)filename;
 
@end

UIImage+Sprite.m

// Created by Daniel Sefton, 2012
// Do what you want license
 
#import "UIImage+Sprite.h"
#import "XMLReader.h"
 
@implementation UIImage (Sprite)
 
+ (NSDictionary*)spritesWithContentsOfFile:(NSString*)filename
{
	CGFloat scale = [UIScreen mainScreen].scale;
	NSString* file = [[filename lastPathComponent] stringByDeletingPathExtension];
	if ([[UIScreen mainScreen] respondsToSelector:@selector(displayLinkWithTarget:selector:)] && (scale == 2.0))
	{
		file = [NSString stringWithFormat:@"%@@2x", file];
	}
	NSString* extension = [filename pathExtension];
	NSData* data = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:file ofType:extension]];
	NSError* error = nil;
	NSDictionary* xmlDictionary = [XMLReader dictionaryForXMLData:data error:&error];
	NSDictionary* xmlTextureAtlas = [xmlDictionary objectForKey:@"TextureAtlas"];
	UIImage* image = [UIImage imageNamed:[xmlTextureAtlas objectForKey:@"imagePath"]];
	CGSize size = CGSizeMake([[xmlTextureAtlas objectForKey:@"width"] integerValue], 
		[[xmlTextureAtlas objectForKey:@"height"] integerValue]);
 
	if (!image || CGSizeEqualToSize(size, CGSizeZero)) return nil;
	CGImageRef spriteSheet = [image CGImage];
	NSMutableDictionary* tempDictionary = [[[NSMutableDictionary alloc] init] autorelease];
 
	NSArray* xmlSprites = [xmlTextureAtlas objectForKey:@"sprite"];
	for (NSDictionary* xmlSprite in xmlSprites)
	{
		CGImageRef sprite = CGImageCreateWithImageInRect(spriteSheet, CGRectMake(
			[[xmlSprite objectForKey:@"x"] integerValue], 
			[[xmlSprite objectForKey:@"y"] integerValue], 
			[[xmlSprite objectForKey:@"w"] integerValue], 
			[[xmlSprite objectForKey:@"h"] integerValue]));
		[tempDictionary setObject:[UIImage imageWithCGImage:sprite scale:scale orientation:UIImageOrientationUp] forKey:[xmlSprite objectForKey:@"n"]];
		CGImageRelease(sprite);
	}
 
    return [NSDictionary dictionaryWithDictionary:tempDictionary];
}
 
@end

Usage

self.mySprites = [UIImage spritesWithContentsOfFile:@"mysprites.xml"];
 
UIImage* myImage = [self.mySprites objectForKey:@"myimage"];

Building boost 1.49 with clang++, iOS 5.1 and Xcode 4.3

UPDATE: For the latest boost and iOS 6, clone this repo instead, it should “just work”: https://gitorious.org/~galbraithjoseph/boostoniphone/galbraithjosephs-boostoniphone Thanks Galbraith!

First of all, Apple haven’t updated the path given by xcode-select since 4.3. xcode-select -print-path will output “/Developer”. To update it for Xcode 4.3’s new pathing, simply run:

sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer

I have cloned the git repository of the excellent boost iOS framework script found here: http://goodliffe.blogspot.co.uk/2010/09/building-boost-framework-for-ios-iphone.html

You can download all the necessary files from here, which most importantly contains the updated shell script:

https://gitorious.org/~danielsefton/boostoniphone/danielseftons-boostoniphone

(You will find an xcode directory in there: I haven’t touched this and it probably won’t work – but this method is easier, trust me).

We’ll need to sacrifice some automation for now. I have commented out functionality for automatically unpacking the tar.bz file. Once you have cloned the repo, follow these steps:

1) Unpack boost_1_49_0.tar.bz2

2) Apply the “xcode_43.diff” patch from here: https://svn.boost.org/trac/boost/ticket/6686 – Note: This is a temporary fix until boost officially supports Xcode 4.3. This may be an unnecessary step in the near future. When it is, it will be safe to re-enable auto unpacking by uncommenting “rm -rf $BOOST_SRC” in “cleanEverythingReadyToStart()” and “unpackBoost” after “Execution starts here”.

3) Run:

bash boost.sh

4) Wait and enjoy!

5) Note: If for any reason you wish to run the script again, because the script will not clean the boost build folder due to the patch we applied, you will get duplication errors in tools/build/v2/user-config.jam. Simply open it up and remove any code under “Python configuration”. Then you can happily re-run the script.

A final thanks to the following link for helping me update the script:

http://stackoverflow.com/questions/9100723/using-boostfilesysystem-path-from-framework-on-ios

Game Engine Lessons Learned – Put Performance First

After a 2 year stint of developing a fully featured game engine, I can now look back on what went right and what I should have done differently. One of my regrets is putting design over performance.

It’s very tempting (and lets face it, easier) to write code to satisfy your natural logical thinking – I don’t know if there’s a term for it, but I’ll refer to it as “direct programming”.

Object-Oriented design could in (many) cases be considered direct programming. It’s parallel to the way we see things – as objects. We design systems the way they are because it “makes sense” to us conceptually.

What you end up with is a pretty set of logical classes and functions that directly address your problems, and while you’re proud of your amazingly flexible and extensible architecture, things start to drag – and that’s when you begin to optimise.

Too late!

Do yourself a favour and think about cache coherence, memory management and parallelism before anything else. I’m not saying that you shouldn’t design a pretty architecture (you should), but if you design and write code without hardware in mind you’ll regret it later.

« Older posts

Copyright © 2016 Daniel Sefton

Theme by Anders NorenUp ↑