でらうま倶楽部

バカってゆうか、ゲームを作る事しか能の無いプログラマの、面白おかしな日々を綴ってみる実験。

プログラム

MagicaVoxelのVOXファイルを直接読む

スクリーンショット 2019-10-08 19.13.12

コード書いとる?

ふとMagicaVoxelのデータ形式を調べてみたら割といけそうな感じだったのでパーサーをC++で実装してGitHubに上げました。


バイナリデータの解釈の仕方などで参考になれば光栄です。

リポジトリ名失敗しましたね... VOXゆーたら、ギターアンプとか作ってる老舗メーカーやんか!

ではまた次回!

Cinder0.9.1でアプリを作るなら雛形が必要ですよね!

スクリーンショット 2019-07-29 14.14.41

コード書いとる?

毎回毎回毎回毎回Cinderのプロジェクトを作るのがしんどかったので雛形を作って公開します。
拙作パズル&モナークで使っていた状態とほぼ同等の内容です。

未来の自分に貢献だ!


一部のファイルが100MB超えててGitHubにリポジトリをアップできないのでzip形式のファイルでの公開です。500MB超えてます。 約CD-ROM1枚ぶん。

- VisualStudio2017、Xcode(macOS、iOS)
- C++17でコード書けます
- boost 1.70.0
- glm 0.9.8.5

ではまた次回!

GLFW3.3で始めるOpenGL

スクリーンショット 2019-07-09 18.58.10

コード書いとる?

先日オリComi2にてnew game styleブースに立ち寄ってくださった方が「OpenGLの勉強を始めようと思ったのですが、サンプルプログラムがうまくビルドできなくて...」みたいな相談をされました。その時は「大変ですねぇ... 何かいい雛形あったっけ...」みたいな感じで受け答えしたのですが、それがずっと引っ掛かっていました。

そこで、GLFW3.3を使ったシンプルな雛形を作ってGitHubにて公開しました。 VisualStudio2017とXcode10のプロジェクトを同梱しています。

GLFWのExample codeまんまなんですけどね。

最近はOpenGLのAPIをいい感じに初期化してくれるgladという便利なライブラリもあるんですね。これも導入してみました。GLFWの公式サイトにはGetting startedを始めめちゃくちゃ資料が充実していてありがたい限りです。みんなも積極的に読もうぜ!

固定シェーダー機能も使えるはずです。「OpenGLを始めたいんだけど、最小環境が見当たらない...」という方、ぜひ試してみてください。

オリComi2で相談してくれた人にも届くといいなぁ...!!

ではまた次回!

GLFW3.3はこうしてビルドした

コード書いとる?

先日リリースされたGLFW3.3のビルド手順を自分メモ代わりにまとめておきます。
これで開発環境が更新された時(XcodeやVisualStudioのバージョンが上がった時とか)に「アレ...どうやったっけ...」っていうのを防げるはず!

1. GLFWの最新版のソースコードをダウンロードして展開する

2. CMakeのGUI版をダウンロードして実行できるようにする

3. CMake(GUI版)を起動
 
スクリーンショット 2019-07-06 16.09.04

4. Where is the source code: の欄にダウンロードして展開したGLFWのパスを入力

スクリーンショット 2019-07-06 16.09.04

ここでいうパスは、以下の場所を指し示しています。GLFWのソースコードやらCMake設定やら一式を含んだディレクトリです。

スクリーンショット 2019-07-06 15.59.25


5. Where to build the binaries: の欄にビルド設定やビルド結果を出力するパスを入力。

スクリーンショット 2019-07-06 16.09.04のコピー

どこでもよいのですが、とりあえずGLFWと同じ場所に「glfwbuild」というディレクトリで出力するようにしてみる。

6. Configure ボタンを押す

photo

出力先のディレクトが見つからない場合は「作っていい?」って聞いてきます。作ってよいのなら「Yes」を押して先に進みましょう。

7. どんな開発環境向けのプロジェクトを作るか聞いてくるのでXcodeなりVisualStudioなり選んで「Done」。

スクリーンショット 2019-07-06 16.11.05

開発環境がインストールされているかどうかは一切判定していません。手持ちの開発環境とバージョン番号含んで合致するのを選ぶ事! 特にVisualStudioは手持ちがVisualStudio2017なのにここでVisualStudio2019を選んでしまうと、後々エラーが出て作業が完了しません。

8. 諸々作業が進んで、プロジェクトを作る際の設定一覧が表示されます。

スクリーンショット 2019-07-06 16.15.17

出力するプロジェクト内の設定をここで変更できます。

9. 続いて「Generate」ボタンを押す

スクリーンショット 2019-07-06 16.15.17

10. 出力先ディレクトリ内にGLFW.xcodeprojが生成されているので開く

11. スキームをglfwに切り替える

スクリーンショット 2019-07-06 17.50.05

12. Edit Scheme...で設定画面を開く

スクリーンショット 2019-07-06 17.40.59

13. Run設定のinfoタブ内のBuild ConfigurationをReleaseに変更する

スクリーンショット 2019-07-06 17.41.49

14. ビルド!

15. 出力先ディレクトリ/src/Releaseにビルドしたライブラリファイルがあります

以上!

VisualStudioでも同じ感じでいけるかと思います。参考までにCMakeでの設定をば。
サンプルのビルド設定などは出力しないようにして、ライブラリをDLLで出力する設定になっています。

キャプチャ


ではまた次回!

GLFWを使ったプロジェクトでの大量の「Documentation issue」を一掃するには

スクリーンショット 2019-07-06 15.00.37


コード書いとる?

気づいたらGLFWが3.3になってました。古いバージョンだとmacOS Mojaveで「画面に何も表示されない」不具合があるし、サクッと更新してしまいましょう。


で、GLFW3.3をビルドして、雛形プロジェクトを作って...なんじゃこの大量の警告は!
 
スクリーンショット 2019-07-06 14.40.21

Documentation issue だと...??


これはXcodeがdoxygen形式のコメントに対応しているからこその警告です。doxygen形式のコメントの不備を指摘する警告なのですよ。なので、XcodeのBuild settingsでこの警告をオフっておけばよいです。

スクリーンショット 2019-07-06 14.47.18

これを「No」に切り替えればオッケー。

「自分もdoxygen形式のコメントを書いてるので、そっちは警告を出したい...」という人は、コード側で対処。
 
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdocumentation"

#include <GLFW/glfw3.h>

#pragma clang diagnostic pop

これで大量の警告があっさりと消えます。

スッキリ!

将来に備えて拙作をC++17に対応した話

スクリーンショット 2019-06-16 14.19.06

コード書いとる?

拙作パズル&モナークのダウンロード祭りも落ち着きまして、普段の日常が戻ってきました。
厄介なバグもほぼ片付きましたし、次回大型バージョンアップに備え、まずは開発言語のバージョンアップから!

以前からXcodeもVisualStudio2017もC++17に対応してますし、このタイミングで拙作もC++17に切り替えてみました。多少の修正は必要でしたが...無事C++17でのビルドが通りました。イェイ! 

以下そのメモです。

1. boostをC++17でビルド
macOS: ~/user-config.jam で定義しているビルドオプション内の「-std=c++14」を「-std=c++17」に変更
using clang : osx
            : xcrun clang -arch x86_64 -stdlib=libc++ -std=c++17 -mmacosx-version-min=10.11
	    ;

using clang : ios
            : xcrun clang -arch armv7 -arch arm64 -stdlib=libc++ -std=c++17 -miphoneos-version-min=9.3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/ -fembed-bitcode
	    ;

using clang : ios_sim
            : xcrun clang -arch i386 -arch x86_64 -stdlib=libc++ -std=c++17 -miphoneos-version-min=9.3 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/
	    ;

Windows:b2.exe の引数に cxxflags=/std:c++17 を追加してビルド
b2.exe -a link=static runtime-link=static threading=multi cxxflags=/std:c++17 variant=debug,release architecture=x86 address-model=64 define=_ITERATOR_DEBUG_LEVEL=0 --with-filesystem --with-date_time --with-regex

2. Cinder 0.9.1をC++17でビルド
macOS: Xcodeでビルドオプションを変更。同じフォルダ内のfullbuild.shを使ってビルド
Windows: VisualStudioでC++17を使うようビルドオプションを変更。/Zc:__cplusplus も追加。バッチビルドでDebugとReleaseをまとめてビルド

3. 拙作をC++17でビルド
macOS: Xcodeでビルドオプションを変更してビルド
Windows: VisualStudioでC++17を使うようビルドオプションを変更。/Zc:__cplusplus も追加してビルド

macOS版(とiOS版)はビルドオプションの変更だけでC++17へ移行できました。
Windows版は少しCinderへの修正が必要でした。

1. include/cinder/Filesystem.h
   boost::filesystem を使うようプリプロセッサを修正(3箇所)
#if defined( CINDER_UWP ) || ( defined( _MSC_VER ) && ( _MSC_VER >= 1900 ) && (__cplusplus < 201703L) )

2. src/AntTweakBar/TwMgr.cpp
std::binary_functionが削除されたので修正
struct StructCompare    // : public binary_function<TwType, TwType, bool>
{
    template<typename TwType>    // 追加
    bool operator()(const TwType& _Left, const TwType& _Right) const
    {
        assert( g_TwMgr!=NULL );
        int i0 = _Left-TW_TYPE_STRUCT_BASE;
        int i1 = _Right-TW_TYPE_STRUCT_BASE;
        if( i0>=0 && i0<(int)g_TwMgr->m_Structs.size() && i1>=0 && i1<(int)g_TwMgr->m_Structs.size() )
            return g_TwMgr->m_Structs[i0].m_Name < g_TwMgr->m_Structs[i1].m_Name;
        else
            return false;
    }
};


これでオッケィ!
でも実は他にも修正箇所があるかもしれません。手元のCinderは色々手を入れているので...

よっしゃこれでC++17を学びつつアプリのバージョンアップができますね!

iOS12から非推奨なOpenGLについてはまだ未着手ですけどね!
モヤモヤ...!!

ではまた次回。


boost 1.69.0 を試してみたよ。

30

コード書いとる?

気づけばboostライブラリも随分と新しくなっていたので、隙間時間に更新してみました。
そこでboost 1.67.0→1.69.0でいくつかハマった点を共有しまーす。


最初にここに目を通しておけばよかった!という内容ですので、お急ぎの方はリリースノートを呼んでください(苦笑)


いつものようにboost1.69.0をビルドして、Cinder0.9.1をビルドして、拙アプリをビルド...あれ? この警告が出ますか...


これはライブラリをビルドした際に「内部シンボルが全て公開状態なのか、必要なものだけ公開状態なのか」の設定があって、アプリからリンクした時に2つの設定が混在していまっせ!という趣旨の警告です。えーそれって随分前に統一していたハズなのにー!

これリリースノートに「設定を変更しました」と書いてありました。すいませんすいません。という訳でCinderのビルド設定とアプリの設定を同じに変更して終了!

Build Settings内の「Symbols Hidden by Default」Yesに変更するだけです。

あともう一点! Cinder0.9.1のビルド中にエラーになりました... マジか...

これリリースノートに「boost::Logicに破壊的変更を加えたよ!!」って書いてありました!すいませんすいません。という訳で static_cast を加えて無事ビルド通過。

警告も出力されなくなり、無事新しいboostに更新できました!!


最後に、boost::systemはヘッダオンリーになったので、当該ライブラリファイルをリンクする必要はもうありません。素晴らしい!

ではまた次回!!

ipa形式のファイル作成〜実機転送は思った以上に簡単だった...!!

スクリーンショット 2019-03-17 0.47.23

コード書いとる?

拙作「パズル&モナーク」の新しいバージョンをそろそろリリースします。
 
一番要望の多かった「制限時間の無いモードが欲しい!」に応えた形となりますが...これいいですね。制限時間が無くなると全く違う攻略法が必要になりますね。パズモナの新たな切り口を見出せたような気がします。

で!

これまでのバージョン1.0、1.1から大きくセーブデータ内容が変わったので、起動時にセーブデータを変換する処理を追加しました。これまでの記録を良きに計らってですが...おかげで動作確認項目が増える増える。
  • バージョン1.0(無課金) → バージョン1.2
  • バージョン1.0(課金) → バージョン1.2
  • バージョン1.1(無課金) → バージョン1.2
  • バージョン1.1(課金) → バージョン1.2
ああ〜めんどくさい!(笑)

さすがにテストの度に古いバージョンのビルド→インストール→動作確認→最新バージョンのビルド→インストール...とかやってられんわ!

と思って調べてみたら...アプリをipa形式で出力しておけば再ビルドせずとも実機に転送できるのね!

やり方はこうです。

  1. 対象のスキームを選んだ状態でメニューから「Product→Archive」

    test1
  2. ビルドが終わるとオーガナイザが開く
  3. Distribute App

    test2
  4. Developmentを選んで次へ

    test3
  5. Automatically manage signingを選んで次へ

    test5
  6. Export!!

    test6
これでipa形式のファイルが出力できます。

これを実機に転送するには
  1. 「Window→Devices and Simulators」

    test7
  2. 「+」のボタンを押してipa形式のファイルを選択

    test8
これで実機にアプリをインストールできます。

こりゃ便利!

ではまた次回。

[spacemacs]magitだとcherry-pickも簡単です

53690334_2851227494895360_2061324392134082560_n

コード書いとる?

先日は人生初即売会で「パズル&モナーク イベント限定PC版」が売れて上機嫌の拙者です。次はTokyo Sandboxだ!

イベント限定版向けにブランチ切って作業を進めるじゃないですか。
 
途中でイベント限定版とは関係ない仕様を実装するじゃないですか。
 
でも時間に追われてるとそのまま作業進めるじゃないですか。
 
イベントが終わってはたと「イベント限定版で追加した実装の一部をメインブランチにマージしたいんだけどどうすれば?」ってなるじゃないですか

そこでcherry-pickの出番ですよ!(受け売り)

gitのcherry-pickは、とあるブランチのコミットを別のブランチにマージする機能です。

拙者はspacemacsを使っているのでmagitが標準装備です。magitはポチポチキー入力するだけでgit操作が出来る超優秀なemacsの拡張機能です。今回もいくつかキー入力をするだけでcherry-pickできてしまいました。

まずは「SPACE-g-s」でstatus画面

スクリーンショット 2019-03-11 21.30.01

そしたら「l-b」でリポジトリ全体のログを出す
 
スクリーンショット 2019-03-11 21.39.39

続いてcherry-pickしたいcommitにカーソルを合わせて「v」で選択

「A」(SHIFT-a)でcherry-pick

スクリーンショット 2019-03-11 21.44.49

さらに「A」でPick!!

超簡単!

magitでのcherry-pickを使い方はこちらのサイトが参考になりました!!

ではまた次回!!

頼れるXcodeの機能「Address Sanitizer」

コード書いとる?

先日勉強会にて「教えて!Xcode」という内容を発表してきました。
その補足です。

XcodeのAddress Sanitizerは「ビルドは通るが実行時の挙動が不安定」という状況で役立つ機能です。
主に実行時のメモリ破壊や未定義動作を検知して教えてくれます。

使い方はScheme内のRun設定→Diagnosticsで「Address Sanitizer」にチェックを入れるだけ! 専門的な機能が使いやすいってほんと大事!

スクリーンショット 2019-03-08 13.24.48

するとこういう状況のメモリ破壊や未定義動作でプログラムが一時停止します。
 
int main() {
  int array[5];
  array[5] = 0;      // おっと!!
}

で、さらに「Detect use of stack after return」にチェックを入れると...

スクリーンショット 2019-03-08 13.24.48

こういう状況も見つけてくれます。
 
int* getArray() {
  int array[5];
  return array;
}

int main() {
  int* p = getArray();
  *p = 0;            // おっと!!
}

こういうのもあります。char* → std::string の暗黙の変換にやられるパターン。
 
void execDelay(const std::string& text) {
  // 引数をキャプチャして時間差で処理する的な
  delayContext.add([text]() {
       std::cout << text << "\\n";
     });
}

int main() {
static const char* text = "Hello!!"; execDelay(text); }

さらにさらに「Undefined Behavior Sanitizer」にチェックを入れると...

スクリーンショット 2019-03-08 13.24.48

こういう状況を見つけてくれます。
 
int main() {
  int i = 1;
  i <<= 64;           // おっと!!
}

Debugビルドでは基本「Address Sanitizer」を有効にしておきましょう!! ただしメモリ使用量を監視できませんが...

そしてこの機能、Swiftでは使えません...orz


ではまた次回!!

C++14から拡張された文字リテラル

logo-sun

コード書いとる?

C++14から使えるbasic_stringリテラルを使うと、for文がこう書けるのね...

#include <iostream>
#include <string>

using namespace std::string_literals;

int main()
{
  for (const auto& s : { "hoge"s, "fuga"s, "piyo"s })
  {
    std::cout << s << "\n";
  }
}

これは便利だ!!

C++17から導入されるstd::anyを使う時にも
 
#include <iostream>
#include <string>
#include <any>

using namespace std::string_literals;

int main()
{
  std::any value;
  value = "hoge"s;
  std::cout << std::any_cast<std::string>(value) << "\n";
}
 
const char*との曖昧さが無くなって良い!(たまにうっかり間違える)

ではまた次回。

Xcodeでの警告「GPU Frame Capture」とは

スクリーンショット 2019-02-11 10.16.13

コード書いとる?

以前からiOSアプリのデバッグ時にXcode上に「GPU Frame Capture」という見出しで警告が出ていたので、それに関して調べてみました。

これ、「ビルド設定で、デプロイ対象のiOSバージョンが古いので便利な機能が使えませんよ」という意味でした。最新のiOSバージョンにしたらあっさり解決。

スクリーンショット 2019-02-11 10.16.58


GPU Frame Captureに関してはこちらがとても参考になります!

ではまた次回。

macOSのGateKeeperと仲良くなる

2_gatekeeperopening

コード書いとる?

今年はいろんなイベントに出てパズモナの宣伝するぞー!! そうだ、イベント限定PC版とか作って頒布しよー!! そもそもmacOSやWindowsでも動くように作ってあるかんねー!! アプリをビルドしてzipに固めてアップロードして、それを別のPCでダウンロードして...ぎゃあああ..!!!!

ってなったので、その対策をメモ。

GateKeeperは、macOS上でアプリを安全に実行するための仕組みです。 ⇒公式による解説

インターネットからダウンロードしてきた野良アプリを開こうとして警告が出るアレです。 

ただこれ救済策が用意されていて「アプリアイコンを右クリック→開く」でアプリは開けます。自己責任でってやつですね。GateKeeperはmacOSを脅威から守ってくれる賢い番犬ですので、くれぐれも設定でオフったりしないように...

ここで問題となったのが、アプリのセーブデータを保存する場所です。パズモナmacOS版では アプリのコンテンツ内 としていたのですが... GateKeeperが発動していると、アプリはサンドボックス環境で実行されます。 この環境がファイル書き出し禁止になっていて、セーブデータを書き出せない状況になりました。これは困った。

で、これをどう解決するかというと、macOSが用意してくれているデータを書き出す場所を使えばよろしい。

~/Library/Applucation Support/[アプリのバンドル名]

こんな感じの場所です。

これをどうやって取得するかというと... Objective-Cで書く訳ですね...

これでオッケィ。無事所定の場所にデータを書き出せるようになりました!!

さてこのGateKeeper、今後は野良アプリを開けなくする可能性があるそうな。 ⇒解説記事

というわけで、アプリへの署名と公証を得る手順も調べてみました。macOSのDeveloper登録は無料枠でもいいらしいです。 ⇒公式資料


まずはアプリへの署名手順
  1. Xcodeのアカウント設定にて証明書を取得する
    step1

    step2
  2. プロジェクト設定でSigningを有効にする(Autoで良い)
    step3
  3.  ビルド設定でHardened Runtimeを有効にする
    step4
  4. ビルドが通れば署名成功

続いて、公証を得る手順 ⇒公式資料
  1. Product→Archive
    スクリーンショット 2019-01-24 17.25.12
  2. オーガナイザを開くとArchiveされたアプリが登録されている
    スクリーンショット 2019-01-24 17.25.58のコピー
  3. Distribute Appボタンから進む
    スクリーンショット 2019-01-24 17.25.58のコピー2

  4. Developer IDを選んで次へ
    スクリーンショット 2019-01-24 17.26.49
  5. Uploadを選んで次へ
    スクリーンショット 2019-01-24 17.27.12
  6. Automacically manage signingを選んでUploadボタンから進む
    スクリーンショット 2019-01-24 18.00.44
  7. アップロードに成功すると、しばらくして通知が飛んでくる
  8. Export Notarized App ボタンを押すと、公証済みのアプリが出力される
    スクリーンショット 2019-01-24 17.25.58
以上!! 割とあっさり。これでアプリの配布が捗りますね。ただ...ここまでの手順は記憶を頼りにまとめたので、うまくいかない場合には公式の資料を参照してください。


ではまた次回。

iOSアプリ提出のつまづきポイント[2018年版]

スクリーンショット 2018-11-03 11.16.16

コード書いとる??

拙作アプリ開発もいよいよ佳境です。

約3年ぶりというのも手伝って提出作業準備に四苦八苦しとりますが、その中から厳選して引っかかった事を三点ほどメモ書きしときます。

1. Distributionビルドでリンク時に「bitcodeを含めてよ」と言われる

Cinderライブラリのビルドはコマンドラインから実行しますが、この時bitcodeを含める指定が足りないのが原因です。Xcode上の設定だとONになってるので見落としがちなんですよね...

xcrun xcodebuild -project ${CINDER_XCODEPROJ} -target cinder_iphone -configuration Release -sdk iphoneos OTHER_CFLAGS="-fembed-bitcode" $@

2. DestributionのValidationで「LaunchScreen.storyboadを指定しないとダメですよ」と怒られる

LaunchScreen.xibあるのに怒られるんですよねー。で、ダメ元で Launch Screen File の指定から拡張子を取ったらValidation通過しました。マジかよ...w

スクリーンショット 2018-11-03 16.55.35


3. iPad向けAppプレビュー動画もiMovieから書き出しできる

iMovieのメニューから「新規アプリケーションプレビュー」でプロジェクトを作ってからiPadでキャプチャーした動画を放り込めば大丈夫だった... やるなぁ!!

スクリーンショット 2018-11-03 16.57.04


ではまた次回!!

C++ラムダ式のキャプチャを使って多態性を表現する

コード書いとる??

スクリーンショット 2018-10-25 11.17.44

拙作アプリ開発も終盤に差し掛かってきました。本作は C++14で追加された機能を 積極的に使おうとしてなかなかに苦戦しております。

使ったのは...「2進数リテラル」「std::make_unique」「std::random_shuffle()が非推奨になったので代わりにstd::shuffle()を使う」... 少な!!

習うより慣れろです!! ...歩みは遅いですが...

そんな中C++11から追加されたラムダ式が大活躍です。コールバック用の関数を別途用意する必要がなく、その場で書けて楽チンです。

void callback() { /* do something */ }

int main()
{
  Widget obj;

  // 従来の書き方
  obj.setCallBack(callback);

  // ラムダ式だとその場で処理を書ける
  obj.setCallBack([](){ /* do something */});
}

ラムダ式が強いのはキャプチャでローカル変数を取り込めること。これを従来の方法で実現しようとするとなかなかに難しい!!

int main()
{
  Widget obj;

  int a = 0;
  obj.setCallBack([a](){ /* キャプチャしたaの値を使える */});
}

さらにこうすると...

int main()
{
  std::function<void ()> func_list[2];

  int a = 0;
  func_list[0] = [a](){ /* do something */ };

  int b = 5;
  int c = 10;
  func_list[1] = [b, c](){ /* do something */ };

  for (auto& f : func_list)
  {
    f();
  }
}

おお!! なんかキャプチャが構造体定義の代わりになってるんじゃね?? 継承使わなくても多態性を表現できるっぽい??

と思って盛り上がったのですが... ラムダ式を乱用するとソースコード上で処理の検索性が異様に悪くなるので...一長一短ですな。


ではまた次回。

Oculus Go の開発を macOS Unity で始める

スクリーンショット 2018-05-16 17.29.16

コード書いとる?

Oculus Goが手元に届いてゴニョゴニョ始めたので、macOS向け環境導入メモを残しておきます。

・Xcode Command Line Toolsをインストール

Unity 2018.1.0f2 をインストール。

Java Development Kitをインストール
 ・Java SE Development Kit 8u172をダウンロードしてインストール

・Android Studioは要らんので、Command line toolsをダウンロードして解凍。

・tools というフォルダを適当な場所へ移動。 拙者は ~/Library/Android/ に置いた。

こちらのサイトを参考に、環境変数 JAVA_HOME を設定。

・ターミナルを開き sdkmanager のあるフォルダへ移動

・sdkmanagerを使って必要なファイルをダウンロード。 toolsと同じ階層にインストールされる
tools/bin/sdkmanager "platform-tools"
tools/bin/sdkmanager "build-tools;27.0.3"
tools/bin/sdkmanager "platforms;android-25"

・tools/bin/avdmanager をテキストエディタで開き、3行目くらいに以下を追加

JAVA_HOME=`/usr/libexec/java_home -v 1.8`

 ・これでUnity EditorでBuildした時のエラーが解消できる。

Oculus公式サイトで開発用にアカウントを作る

・アプリを実機で動かすのに必要になるので、ここで何か団体を登録しておく

・アプリを実機で動かすためにOculus Signature Fileを作っておく。
 ・サイトにファイルの置き場所も書いてあるので確認しておく。

公式サイトからOculus Utilities for Unityをダウンロードしとく
 ・後で自分のプロジェクトに手動でインポートする

・Unity Editorにて環境設定を開き External Tools 内 AndroidのSDKとJDKのパスを適切に設定

・PlatformをAndroidに変更

・Playerの設定を開き Other Settings内Target API LevelをAndroid7.1に変更

・XR Settings 内 Vertual Reality Supported のチェックボックスを入れ、Virtual Reality SDKs に Oculus を追加

スクリーンショット 2018-05-16 17.30.30

・プロジェクトにOculus Utilities for Unityをインポートしとく

・実機の開発者モードをONにしとく

・実機をUSBケーブルでMacに繋ぐと、開発者モードで繋ぐ?と実機側で表示されるので必ずOKしとく

・サンプルシーンをビルドして実機で動けば成功!

これで実機で動作します。たぶん。
 
ただEditor上ではライブラリが見つからずにエラーとなってしまいますのでなんとかしたいです!

ここに至るまでにかなり難儀をしたので誰かビールを奢ってくださいw

ではまた次回!!

Cinder で色々値を調整するci::params::InterfaceGlをちょこっと使い易くする

コード書いとる?

Cinderに搭載されている ci::params::InterfaceGl を使うとリアルタイムに値の調整ができてとても便利です。
内部では AntTweakBar を使っているようですね。

で、普段は邪魔になるので隠したいじゃないですか。

これは ci::params::InterfaceGl::show で実現できるのですが、実現できるのですが、これが邪魔やねん! この左下のが!!
photo1

イラっときて調べてみたら、こんな議論を見つけました。

早速試してみる。
extern "C" {
  int TwDefine(const char *def);
}

TwDefine("TW_HELP visible=false");

photo2

ウム!スッキリ!!

ではまた次回。

Cinder0.9.1 メモ

18

コード書いとる?

最近よく使っているFrameworkのCinderで若干気になる事があるのでメモ書き。
  • iOS版はOpenGL ES3.0ベース。ES2.0対応にしたい場合はプリプロセッサにCINDER_GL_ES_2を定義して再ビルド
  • 文字のレンダリングにFreetype2を使っている??
    →Android版のみが利用(まだ非公式)
  • macOS・iOS版はリンカーの設定で、「prelink」が有効になっているのだが、これが原因でリンクに時間が掛かる
    →設定を外して、プロジェクトごとにリンクするライブラリを指定するようにした方が良さげ
  • iOS版にてサウンド再生を使う場合は自前でイヤフォンの抜き差しに対応する必要がある
    →AudioSessionを使う
  • iOS版はGLKitを使っていないのでXcodeにてCPUの占有時間が正しく測れないw
これくらいかな?
 
ではまた次回!! 

iOSアプリを「OpenGL ES3.0」必須にする

コード書いとる??

年明けから絶賛製作中のアプリですが、絶賛製作中です。

利用しているFramework Cinder 0.9.1 がOpenGL ES3.0必須なので、「それどうやってXcodeで設定するんだ?」と思って色々調べた結果をメモ書き。

UnityとかUE4とか使ってる人には多分関係ない。


GameCenter対応とかiCloud対応ならXcodeのCapabilitiesにて設定できますが、そこに「OpenGL ES3.0必須」という項目が無い。

39


そこでAppleのドキュメントを調べてみたらここに書いてありました。公式ドキュメント大事。

Info.plistにRequired device capabilitiesを追加、さらに子供の要素で文字列 opengles-3 を追加すれば良い。

08


これで手持ちのiPhone5ではアプリを起動できなくなりましたw

26


ではまた次回!!

macOS High Sierra での Processing 3.3.6 の動作不具合

test
コード書いとる?

macOS High SierraにバージョンアップしたらProcessingのメニューバーが表示されなくなりました… アプリの終了すらままなりません(涙) 

こりゃさすがに不便でしょ!ってんで調べたら公式のGitHubリポジトリに報告が上がってました。まあみんな困ってますよね。

とりあえずの対策はターミナルを起動して以下のコマンドを実行する。

defaults write org.processing.app AppleLanguages '(en)'

スッキリ!

ではまた次回。

記事検索
電子書籍発売中

「チュートリアル形式で始めるOpenAL」
サウンド怖くない。C++による8つのチュートリアルで始めるOpenALプログラミング。さああなたも、自作アプリに魅力的な音効を添えてみませんか??
⇒Kindle版 ⇒iBooks版


「iPhoneアプリ『ういろう』のレシピ」
ゲームってどうやって作ってるの?? 拙アプリ『ういろう』の製作過程を本にまとめました。もちろんソースコードつき
⇒Kindle版 ⇒iBooks版


『チュートリアル形式で始めるOpenGL[2D編]』
OpenGL怖くない。C++による16のチュートリアルで始めるOpenGLプログラミング[2D編]。さああなたも、ゲーム作りを始めてみませんか?
⇒Kindle版 ⇒iBooks版
自作ゲーム配信中

『Puzzle & Monarch』
「君主候補となって国作り!! ただし制限時間は90秒。」森を作って道をつないで...あなただけの国を作ってみませんか??
⇒AppStore


『BRICK & TRIP』
咄嗟の判断に、あなたの指先はついてこれるか?! 爽快フリックアクション!! 様々な難関をくぐり抜けて旅の終着点を目指そう!!
⇒AppStore


『ういろう』
名古屋土産ういろうがiPhoneで大活躍?! 白ういろうを守れるのはあなただけ。ひゅーん、ぼよよーん!!
⇒AppStore ⇒LITE版


『こなへん』
ヒマラヤ山脈、大西洋、世界で一番深い湖… それって地球のどこにあるのか知ってるかな?『全方位直感地理クイズ』という新ジャンルに挑戦!あ、それ。地球をくーるくるw
⇒AppStore ⇒LITE版


『GEOSPOT』
ヒマラヤ山脈、大西洋、世界で一番深い湖… それって地球のどこにあるのか知ってるかな?『全方位直感地理クイズ』という新ジャンルに挑戦!あ、それ。地球をくーるくるw
⇒Windows ⇒Mac


『TieGunner』
マウス片手に大宇宙へ飛び立とう!『しっぽシューティング』というジャンルを作って頂きました^^; WinでもMacでも動きます。ソースもあるでよw
⇒Windows ⇒Mac
QRコード
QRコード
  • ライブドアブログ