xcode 8.0 で clang-format を使えるようにする方法

xcode 8.0 でプラグイン周りの仕様がだいぶ変わってしまったようで、今まで外部プラグイン（Alcatraz）で入れていたclang-formatが使えなくなった（参考）らしい。という訳で、Alcatrazを使わずにxcode 8.0に新しいプラグイン方式に対応したclang-formatを探してみて、幾らか方法が見つかったのですが、どれも面倒くさそう...

まぁ、Alcatraz自体、元から面倒くさかったんですよね。

xcodeをアップデートする都度、一時的に使えなくなったりするので。

という訳で、
・xcodeのアップデートに動じず
・commit時に漏れなく簡単に全ソースにclang-formatを実行でき
・楽であること
という全ての条件を満たす方式を考えることにしました。

その結果、
「普通にmakefileで書くのが一番楽では？」
という結論に至る。

という訳で、私のxcode projectでmakefileを使ってclang-formatの実行を半自動化したやり方を書いておきます。

まず、xcode projectのディレクトリ直下に以下のようなシェルを作成

■format.sh

#!/bin/sh echo formatting: $1 clang-format -assume-filename=.clang-format <$1 >.work diff .work $1 >/dev/null if [ $? -eq 1 ] then cat .work > $1 fi \rm -f .work

このシェルがやっていることは、

1. 引数に指定されたソース に clang-format を掛けたソース（.work）を作成

2. 元ソース と .work を比較

3. 差分があれば元ソースの内容を .work の内容に書き換える

ということ。

毎回無条件でclang-formatを掛けてしまうと、差分ビルドに時間が掛かってしまうので、clang-formatの結果変化があるソースのみを書き換える感じです。

そして、同ディレクトリに以下のような makefile を作成

■makefile

HEADER = $(shell for file in `find . -name *.h`;do echo $$file; done) C_SOURCE = $(shell for file in `find . -name *.c`;do echo $$file; done) CPP_SOURCE = $(shell for file in `find . -name *.cpp`;do echo $$file; done) OBJC_SOURCE = $(shell for file in `find . -name *.m`;do echo $$file; done) SOURCES = $(HEADER) $(C_SOURCE) $(CPP_SOURCE) $(OBJC_SOURCE) all:     for SOURCE in $(SOURCES); do make format SRC=$$SOURCE; done format:     @sh format.sh $(SRC)

上記のmakefileでは現在のカレントディレクトリ（find .）から拡張子 .h .c .m のファイルを検索して見つけたリスト（SOURCES）を作り、そのリスト内のファイルをひとつづつ先程のシェル（format.sh）に指定して実行するという感じのものです。

あとは、git commit をする前に一発makeを叩けば、全ソースのコードフォーマットが掛けられるという感じになります。（findの所はプロジェクトによっては若干書き換えが必要になることがあるかもしれませんが）

今開発中の Invader Block 6 のプロジェクトでこの makefile を叩いてみた結果は以下のような感じです。

$ make

for SOURCE in IBLOCK6/AppDelegate.h IBLOCK6/ball.h IBLOCK6/bird.h IBLOCK6/bomb.h IBLOCK6/bonus.h IBLOCK6/check.h IBLOCK6/dot.h IBLOCK6/draw.h IBLOCK6/enemy.h IBLOCK6/ft.h IBLOCK6/game.h IBLOCK6/hanabi.h IBLOCK6/hit.h IBLOCK6/laser.h IBLOCK6/player.h IBLOCK6/replay.h IBLOCK6/stage.h IBLOCK6/teki.h IBLOCK6/utility.h IBLOCK6/vgs2.h IBLOCK6/VGSLayer.h IBLOCK6/VGSView.h IBLOCK6/ViewController.h IBLOCK6/wall.h IBLOCK6/ball.c IBLOCK6/bird.c IBLOCK6/bomb.c IBLOCK6/bonus.c IBLOCK6/check.c IBLOCK6/dot.c IBLOCK6/draw.c IBLOCK6/enemy.c IBLOCK6/game.c IBLOCK6/game_lv1.c IBLOCK6/game_lv2.c IBLOCK6/game_lv3.c IBLOCK6/game_opening.c IBLOCK6/game_ranking.c IBLOCK6/game_result.c IBLOCK6/game_title.c IBLOCK6/hanabi.c IBLOCK6/hit.c IBLOCK6/laser.c IBLOCK6/player.c IBLOCK6/replay.c IBLOCK6/stage.c IBLOCK6/teki.c IBLOCK6/utility.c IBLOCK6/vgs2api.c IBLOCK6/vgs2i.c IBLOCK6/wall.c IBLOCK6/AppDelegate.m IBLOCK6/main.m IBLOCK6/VGSLayer.m IBLOCK6/VGSView.m IBLOCK6/ViewController.m; do make format SRC=$SOURCE; done

formatting: IBLOCK6/AppDelegate.h

formatting: IBLOCK6/ball.h

formatting: IBLOCK6/bird.h

formatting: IBLOCK6/bomb.h

formatting: IBLOCK6/bonus.h

formatting: IBLOCK6/check.h

formatting: IBLOCK6/dot.h

formatting: IBLOCK6/draw.h

formatting: IBLOCK6/enemy.h

formatting: IBLOCK6/ft.h

formatting: IBLOCK6/game.h

formatting: IBLOCK6/hanabi.h

formatting: IBLOCK6/hit.h

formatting: IBLOCK6/laser.h

formatting: IBLOCK6/player.h

formatting: IBLOCK6/replay.h

formatting: IBLOCK6/stage.h

formatting: IBLOCK6/teki.h

formatting: IBLOCK6/utility.h

formatting: IBLOCK6/vgs2.h

formatting: IBLOCK6/VGSLayer.h

formatting: IBLOCK6/VGSView.h

formatting: IBLOCK6/ViewController.h

formatting: IBLOCK6/wall.h

formatting: IBLOCK6/ball.c

formatting: IBLOCK6/bird.c

formatting: IBLOCK6/bomb.c

formatting: IBLOCK6/bonus.c

formatting: IBLOCK6/check.c

formatting: IBLOCK6/dot.c

formatting: IBLOCK6/draw.c

formatting: IBLOCK6/enemy.c

formatting: IBLOCK6/game.c

formatting: IBLOCK6/game_lv1.c

formatting: IBLOCK6/game_lv2.c

formatting: IBLOCK6/game_lv3.c

formatting: IBLOCK6/game_opening.c

formatting: IBLOCK6/game_ranking.c

formatting: IBLOCK6/game_result.c

formatting: IBLOCK6/game_title.c

formatting: IBLOCK6/hanabi.c

formatting: IBLOCK6/hit.c

formatting: IBLOCK6/laser.c

formatting: IBLOCK6/player.c

formatting: IBLOCK6/replay.c

formatting: IBLOCK6/stage.c

formatting: IBLOCK6/teki.c

formatting: IBLOCK6/utility.c

formatting: IBLOCK6/vgs2api.c

formatting: IBLOCK6/vgs2i.c

formatting: IBLOCK6/wall.c

formatting: IBLOCK6/AppDelegate.m

formatting: IBLOCK6/main.m

formatting: IBLOCK6/VGSLayer.m

formatting: IBLOCK6/VGSView.m

formatting: IBLOCK6/ViewController.m

開発状況2（IB6）

ステージ2をもりもり作成中。
Invader Block variatio 6 のステージ2は Battle Marine 仕様です。

ゲーム内容については、だいたい旧Battle Marineを去就した形になっています。敵の種類やグラフィックは流用。
プログラム的な部分は完全にゼロから作り直していて、コンボの爽快さなどを追求。

今週夏休みなので今日中ぐらいにステージ2を完成させるつもりですが、やや遅れ気味。

ステージ1（Invader Block仕様）からステージ2に進むまでの演出を凝らせていたら、作り始めるまでに結構時間が掛かってしまいました。

それ以上に、このタイミングでデレステを始めてしまい、それに時間が取られた感が否めない。
本当はコーヒーブレイク用に始めたのですがね。
ソシャゲって体力回復待ちがあるから、体力が尽きるまでプレイして、回復するまでの間に開発。そして、回復したらまたプレイみたいな風にすれば割と良い感じなんじゃないかと。
しかし、実際には無料石を回収し、石を使って（ガチャには回さず）体力回復してプレイを延々と繰り返し、そのコーヒーブレイクにIB6の開発を進めていた感が否めない。
夏休みはあと4日（木、金、土、日）で、土曜は予定があるから、流石に木、金は石を使った回復は自重するなどの縛りを入れねば。

開発状況（IBV6）

タイトル画面やらチュートリアルをザックリ作成。

システム的には NSWindow でのフルスクリーンモード（安定している方）にしておきました。

ウィンドウモードはナシです。

チュートリアル（というかHOW TO PLAY）は、昨今のチュートリアルと違ってかなりアッサリしたもの。アーケードゲームのインストに書いてある相当の情報量以上は入れないつもり。

ゲーム本編としては、ステージ1がだいたい完成したというところ。

Invader Block 5からの要素的な意味での変更点は、

・画面上部に吹き抜け（左右ループ）を入れてみた

・画面下にブロックを配置

・（メダルを消費して）ショットを撃てる

・（Battle Marineの）鳥が登場する

といったあたり。

かなりカオスな感じです。

難易度的なところはより一般向けに低くしています。

インベーダーを数グループ撃破するとステージクリアになって、Battle Marineシステムのステージ2に進む予定。

ステージは、

・Invader Block

・Battle Marine

・RENCON

・Invader Block（裏）

・Battle Marine（裏）

・RENCON（裏）

の全6面にするつもりで、特定条件を満たせば周回ループ（最大2周）できるようにしようかなと思っています。まだステージ1までしか作っていなくて、そこで色々と鬼調整をしているところなので、ステージ2以降は完全に未定。

ちなみに、今のところMac版しか作っていないですが、Windowsへの移植もすぐにできます（ゲーム本体はVGSで書いているので技術的には移植は一瞬でできる）。今秋ぐらいまでにMac AppStoreでの販売開始が目標で、その後Greenlightに出して成功すればSteam版（Steamのスコアボードやアチーブメントに対応したもの）を作ろうと思っています。（要するにGreenlightを通らない限りWindows版は世に出さないつもり）

課金要素としては有料販売のみで追加課金ナシ。

Mac AppStore版は1usd、Steam版は5〜10usdの間ぐらいにする予定。

Nintendo Developer Portalに登録した

任天堂から、Nintendo Developer Portal なるものが個人向けにも解放されたので、個人名義で登録しておきました。（ビジネス名はSUZUKI PLANにしておきましたが）
https://developer.nintendo.com/

NTSCみたいなものだろうか？（実務での任天堂ハードでの開発経験はゼロなので、その辺の詳しいことはよく分からない）

登録自体は無料でできるので、個人/同人のゲームデベロッパはとりあえず登録しておけば色々と見えてきて面白いかと思います。
とりあえず、3DS or WiiU向けの開発ならできそうです。
実際に開発を始めようとすると、開発機材の初期費用がそこそこ掛かるので、中々敷居が高いですが。

私自身も、実際に3DS向けゲームの開発に乗り出そうとして登録した訳ではなく、どういうSDKがあってだいたいどんな感じの仕様かを把握しておく為に登録しました。恐らく、今回のNDP解放は次（NX）に本格的にインディー開発者を取り込む流れにするための布石ではないかと思ったので。（5年前ならともかく、今から3DSだとミニマムの開発費用20万円をペイすることすら個人だと難しいんじゃなかろうかと）

3DSのSDK（nativeの方）の仕様書をまだ読み途中で、SDKがC++だったのは予想通りですが、Unitiyなんてものもあるんですね。
使いませんが。

Unityをディスっている訳ではなく、私の場合、ネイティブで動くVGSエミュレータを先に作り、その後ゲームを開発するというスタイルで、それはプラットフォームがどのように変化しようとも変わらないことなので、そうなるとUnityという選択肢は無意味だということ。

しかし、結構最近のコンソール開発環境って色々充実している感じなんですね。
無駄に充実しているというか。
Visual Studio統合って何なんですか（要らない）。

NXでは、CTR_SDK（CLI）のLinux版やMac版が欲しいところです。
あと、ハードは実機+USBケーブル+PCだけで開発できるようになっているといいなぁ。

Macでフルスクリーンゲーム開発のつらみ

macOS用のゲーム開発ですが、NSViewのフルスクリーンで開発すると中々つらい。というのも、落ちる系のバグが残っていると、電源OFFして止めるしか無い状況に陥る。そして、電源OFFにすると落ちる系のバグを特定できる情報が飛んでしまうとか。

という訳で開発中はウィンドウモードで作っておくことにしました。

ウィンドウの大きさに応じてアスペクト比を保った状態でゲーム画面を拡大。
そして、余白は（とりあえず）黒塗り。

余白がある場合は下図のような形になります。

上図は試験的にインタレース描画にしているので、若干画面が暗いな。

緑ボタン（or NSWindow の toggleFullScreen）でフルスクリーンにしてやれば、結果的にはNSViewをフルスクリーンにした場合と見た目は同じになります。なので、こっちの方法でフルスクリーン対応しておくべきかも。

macOSでフルスクリーンのアプリ（主にゲーム）を作る方法としては、

・NSViewをフルスクリーンにする方法（OSX 10.5以降）
[self.view.window.contentView enterFullScreenMode:self.view.window.screen withOptions:nil];
・NSWindowをフルスクリーンにする方法（OSX 10.7以降）

[self.view.window toggleFullScreen:nil];

の2種類があるのですが、どちらかといえば後者で対応した方が良いのだろうか... 前者の方が色々と考える事が少なくて実装が楽になるのですが。

前者にも色々とトラップ（※）がありますが。

※ドキュメントから抜粋: On OS X v 10.5, invoking this method when the view was not in a window would cause an exception. On OS X v 10.6 and later, you can now send this message to a view not in a window. For applications that must also run on OS X v 10.5, a simple workaround is to place the view in an offscreen dummy window.

まぁ、古いOS（10.6以下）を救うメリットはWindowsと違ってほぼ無いので、素直に新しい方（後者）で対応しておいた方が良いのではないかと思います。

後者での対応は色々と面倒臭いのですが。

最小化を考慮した対応、Windowサイズの制御、Storyboardをいじってメニューをちゃんと作らないとMac AppStoreへ出す時の審査でよくリジェクトされたりなど。

INVADER BLOCK variatio Ⅵ

SUZUKI PLAN というサークル名で活動を初めてからそろそろ丸8年経とうとしています。

8年やって当たったモノといえば 東方BGM on VGS ぐらいですが、これはノーカウントで。（純粋にオリジナルのものではないので）

特に生活が掛かっている訳でもないので、好きなゲームを好きなように作っていけば良いのではないかと思っています。

私が好きなゲームというと、例えばドンキーコング、アルカノイド、スペースインベーダーなどのような固定画面アクションゲームで、だから SUZUKI PLAN が最初に作ったゲームはINVADER BLOCKだったし、その後もBATTLE MARINE、CANON SNIPER、LUNATIC CRAYといった固定画面アクションゲームの比率が高い感じになっています。

中でも INVADER BLOCK は、最初に作ったためか特に思い入れが強く、私が新しい開発環境でゲームを作る時、必ず最初に作るのは INVADER BLOCK のリメイクという形になっています。

・ファミコン版: INVADER BLOCK FC（※未発表）
・スマートフォン（iOS, Android）版: INVADER BLOCK 2
・VGS mk-II版: INVADER BLOCK 3
・HTML5版: INVADER BLOCK 5
という具合。

あぁ、INVADER BLOCK 4が無いですね。まぁ、2と3は未発表のファミコン版を飛ばして採番しているので、INVADER BLOCKシリーズは実質5作品あることになります。
実のところHTML5版は公開しているもの（enchant.jsを使用）とは別のゲームエンジンを使ったバージョンもあったりしますが。

どれもそんなに大ヒットはしてません。
どちらかといえば試作的に作ったものなので当然ですが。
しかし、SUZUKI PLAN は今まで結構な数のゲームを作ってきましたが、その中で大ヒットの芽があるであろう作品は INVADER BLOCK だろうと思っています。

そこで、今の私ができ得る最大限のクオリティのINVADER BLOCKを作ろうと思いたち、現在開発中です。
タイトルは INVADER BLOCK variatio Ⅵ（仮）

対応プラットフォームはMacとWindowsで、最初にMac版だけAppStoreで出し、反応が良ければSteamでWindows+Mac版（AppStore版とは別でSteam関連のアチーブメントやリーダーボード等を実装する予定）を出そうかなと計画してます。

Steamで出すにはグリーンライトを通過する必要があるので、出ない可能性もありますが、AppStore版については今秋ぐらいまでには販売開始しようと思っています。

なお、スマホ版は今のところ予定していません。
VGSで開発しているので、スマホにはほぼノーコストで対応可能ですが、今回はタッチパネルではなくゲームパッドやジョイスティックを前提としたゲームプレイにしたいので、タッチパネル操作という足かせを付けながらのゲームデザインは避けようと思っています。
完成後であれば、スマホ移植する可能性が無い訳ではないです。
（要するにスマホファーストではないというだけのこと）

gamepad-osxの実装詳解

前回記事で書いた gamepad-osx の実装内容を軽く解説。

まず、mac OS (OSX) や iOS で HID（Human Interface Device; キーボード、マウス、ゲームパッドといった入力デバイス）へのアクセスは HID Manager 経由で行うので生成。

IOHIDManagerRef hid_manager = IOHIDManagerCreate(kCFAllocatorDefault, kIOHIDOptionsTypeNone);

次に、取得対象のデバイス情報を指定した CFMutableArray を作成する。
Objective-cなら割と簡単にできるが、Core Foundation を用いる必要があるので物凄く面倒くさい。

static void append_matching_dictionary(CFMutableArrayRef matcher, uint32_t page, uint32_t use)

{

    CFMutableDictionaryRef result = CFDictionaryCreateMutable(kCFAllocatorDefault, 0, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);

    if (!result) return;

    CFNumberRef pageNumber = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType, &page);

    CFDictionarySetValue(result, CFSTR(kIOHIDDeviceUsagePageKey), pageNumber);

    CFRelease(pageNumber);

    CFNumberRef useNumber = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType, &use);

    CFDictionarySetValue(result, CFSTR(kIOHIDDeviceUsageKey), useNumber);

    CFRelease(useNumber);

    CFArrayAppendValue(matcher, result);

    CFRelease(result);

}

余談ですが、Core Foundation を C/C++ で書いたコードを見ていつも思うのが「無駄なオーバーヘッド要因が異様に多い」ってことですね。その代わり拡張性は高い。これが所謂 Mach の設計思想から引き継がれたオドロオドロしい部分なんだろうと思います。要するに効率性ではなく柔軟性・拡張性みたいなところに特化した仕組みで、だからNeXTSTEPは実用に耐えられなかったのだろうと。iOS世代もそのCFを内部で引きずり続けているから、結局のところ処理効率はそんなに良くない。何故スマホ初期の頃にピュアなLinux Phoneが出なかったのかと今でも思っています（今となっては商業的な意味で手遅れですが）。

上記関数の page は kHIDPage_GenericDesktop で use は以下のような値を指定する。
なお、ジョイスティックとゲームパッドは別useになっているので注意。私の手持ちのゲームパッドの場合, kHIDUsage_GD_GamePad を指定しないと認識しませんでした。
・kHIDUsage_GD_Joystick : ジョイスティック
・kHIDUsage_GD_GamePad : ゲームパッド
・kHIDUsage_GD_Keyboard : キーボード
・kHIDUsage_GD_Mouse : マウス（トラックパッド）

そして、作成したCFMutableArrayで指定したものが取得したいデバイスだということを HID Manager へ通知して、そのデバイスが接続されたことと切断したことを検出するコールバックを登録。

IOHIDManagerSetDeviceMatchingMultiple(hid_manager, matcher);

IOHIDManagerRegisterDeviceMatchingCallback(hid_manager, device_attached, c);

IOHIDManagerRegisterDeviceRemovalCallback(hid_manager, device_detached, c);

なお、接続（切断）のコールバックの形式は以下のような感じ。（detachedも同じ）

void device_attached(void* ctx, IOReturn result, void* sender, IOHIDDeviceRef device);

このコールバックでは、接続（切断）されたデHIDの情報を教えてくれるだけなので、そのHIDからの入力を検出したり解除するには、更に別のコールバックを設定する必要があります。（詳細は後述）

あとは、HID Managerを動かすrun-loopをスケジュールしてOpenすれば、デバイスの接続と切断が検知できるようになります。

IOHIDManagerScheduleWithRunLoop(hid_manager, CFRunLoopGetMain(), kCFRunLoopCommonModes);

IOHIDManagerOpen(hid_manager, kIOHIDOptionsTypeNone);

ここまでが、HIDの接続・切断を検出するまでの手続きです。

あとは、接続を検出したHIDに対して入力を受け付けるコールバックを設定してあげれば、入力された内容を検出することが可能になります。

これは接続時のコールバックで次のように実行すればOK。

IOHIDDeviceOpen(device, kIOHIDOptionsTypeNone);

IOHIDDeviceScheduleWithRunLoop(device, CFRunLoopGetCurrent(), kCFRunLoopCommonModes);

IOHIDDeviceRegisterInputValueCallback(device, device_input, c);

デバイス入力コールバックの形式は以下のような感じです。

void device_input(void* ctx, IOReturn result, void* sender, IOHIDValueRef value);

最後に、この入力コールバックで以下を発行すれば入力された情報が検出できることになります。

IOHIDElementRef element = IOHIDValueGetElement(value);

type = IOHIDElementGetType(element);

page = IOHIDElementGetUsagePage(element);

usage = IOHIDElementGetUsage(element);

val = IOHIDValueGetIntegerValue(value));

ね、簡単でしょ？

Steamで購入したとある日本製のゲームが、ゲームパッドに対応できていない（海外製のゲームはだいたい対応できている）ので、そのサポートに対して「簡単だからゲームパッドの入力に対応してくれ」とお願いしてみたのですが、日本語でIOKitの仕様を正しく解説できているサイトがほぼ皆無だったんですよね...

そういう事情もあって、もしかすると多少ニーズがあるかもしれないと思い、かなり簡単な手続きでmac OSのアプリでゲームパッド入力に対応できるライブラリ（gamepad-osx）を作ってみた感じです。

まともな資料は英語しか無かったけど、冷静に読めば結構簡単なことしか書いていないので、特に困る人が居ない→だから日本語資料が無いのかもしれませんが。

ちなみにこのIOKitというフレームワークですが、mac OS（OSX）の中ではかなりベーシックなもので、Wikipediaなんかを見ても（かなりあっさりとだが）MachやBSDと同列に解説されています。要するに、mac OS（OSX）の仕組みを理解する上でかなり重要な部分なので、技術書ぐらい幾つかあるんじゃないかなと思ってAmazonで検索してみたのですが、見事に皆無。
https://www.amazon.co.jp/s/ref=nb_sb_noss?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&url=search-alias%3Daps&field-keywords=IOKit&rh=i%3Aaps%2Ck%3AIOKit
Appleによる情報統制でも掛かっているのかな？
まぁ、このブログは妄言ということで許される（のだろうか^^;）