投稿

iOS (iPhone / iPad) の BCC メールの文字化け

イメージ
知人の iPad(iOS 15.3.1)で送信メールが見れなくなるという症状が発生した。次のようなエラーメッセージが表示される フォーマットの方法に問題があるため、このメッセージは表示できません。別のフォーマットまたはメールプログラムを使ってメッセージを再送信するように送信者に依頼してください。 text/plain ネットで日本語検索しても、「機種依存文字ガー」などといった、素人騙しのアフィリエイター系の受け売り情報ばかりで何の役にも立たない。 試行錯誤して問題を絞り込んでみたところ、どうも、BCC で自分宛てにメールの控えが送信されるようにしている場合に、さらにメールの題名に日本語が入っているとこの症状が発生する。 日本語の情報は全く役立たずなので、改めて英語で検索したところ、Apple の公式フォーラムの情報( Q: “This message cannot be displayed” )に行き当たった。 ここでは、 問題のメールを一旦、削除する 削除したそのメールをゴミ箱から Inbox に戻す という「とりあえず」の対処方法がコンセンサスを得ていた。この確かに有効であった。 しかし、僕がこのスレッドの膨大なメッセージの中で最初に着目したのは、 Hornet49 氏の回答 である。 それは「メールアプリを再起動する」というもの。なぜか彼の回答はスレッドの中で注目を浴びていなかったが、結局、僕が最初にピンと来た彼の回答だけが、完全な解決方法だった。僕は、iOS は普段は使っていないので、知らなかったのだが、iOS デバイス自体の再起動や、アプリ履歴の消去では、アプリのちゃんとした再起動はされず、キャッシュがクリアされない。今回、初めて知ったが、アプリそのものを適切に再起動するには: 電源ボタンの長押し(デバイスのシャットダウンの場合と同じ) 電源スライダーが表示されたら、デバイスをシャットダウンせずに、ホームボタンを長押し アプリが再起動される(実際にはシステムへの再ログイン?) これで完治した。ただし、過去にこの症状になってしまった送信メールまでは復活しない。今後新しく作成する送信メールは問題が解消される。 Hornet49 氏の考察によれば、メールアプリの動作中に iOS

OpenGL FrameBuffer オブジェクト(FBO)

Grafika の RecordFBOActivity を見ながら、FBO(FrameBuffer Object)について勉強中。 DRAW_TWICE (draw x2) レンダリング(描画処理;draw メソッド)自体を(デフォルト framebuffer と動画ファイル用に)丸々 2 回行っている。 FBO (draw x1 + blit x2) オフスクリーン用の FBO にレンダリング(draw)を行い、それをデフォルト framebuffer と動画ファイルそれぞれに blit している。 BLIT_FRAMEBUFFER (draw x1 + blit x1) GLES 3.0 の glBlitFramebuffer を使い、デフォルト framebuffer にレンダリング(draw)したものを、先に動画ファイルに blit してから、画面表示用に swap している。 draw は描画オブジェクトの数、blit は転送するデータ(画面)サイズに依るので、DRAW_TWICE がいいのか、それ以外が良いのか一概には言えない。だが明らかに、BLIT_FRAMEBUFFER(draw x1 + blit x1)は FBO(draw x1 + blit x2)より確実に効率が良さそうである。 他、参考:LearnOpenGL: Framebuffers

Beginning Android Games(Android ゲームプログラミング A to Z)その 2

イメージ
前回の記事 その 1 の続き。 前回は本( libGDX の創始者である Mario Zechner 氏の著書“ Beginning Android Games ”(邦題は『 Android ゲームプログラミング A to Z 』))の 7 章の内容がベースだったが、今回は 8 章の内容がベースになる。 7 章では OpenGL ES 1.x そのものの使い方の解説(インプット)に主眼があったのに対して、8 章では「OpenGL そのもの」というよりは、いよいよ「OpenGL を使って」様々なグラフィックス表現を実現する、アウトプットの段階になる。 前回の記事では、Mario Zechner 氏のサンプルプログラムと同じ結果を実現するために、最近の Android プログラミングの事情に合わせて、Kotlin と最新の Android API をベースとし、さらに OpenGL は 2.0 に準拠するため自前のシェーダーを用意して、自分流のサンプルプログラムとライブラリーを構築した。 Game クラスと Screen クラスの構造、そして OpenGL をグラフィックスエンジンとして使用するための GLSurfaceView.Renderer クラスを用意し、その他のファイル入出力やサウンド、タッチ入力などの部分は、Android の API をそのまま使えばいいだけじゃないかということで、サンプルプログラム化、ライブラリー化の対象外としていた。 しかし、8 章では、タッチ入力をサンプルプログラムで使用するので、これだけはどうにかしなければならない。もちろん、Android プログラミングのタッチ入力に熟達している人ならば問題ないが、タッチイベントは独特のノウハウがあるので、普通はかなり面倒な代物である。本の 8 章のサンプルプログラムの側では、3 〜 6 章の過程で用意したライブラリーのタッチハンドラーがあり、そのタッチハンドラーから得られるイベントによって動作するように記述されているので、タッチ入力に関しては、この 8 章の個々のサンプルプログラムで直接扱うよりは、相当するタッチハンドラー用のクラスを用意して対応するのが無難である。 TouchHandler( 本家 ):本はかなり古い時代の Android API を基準としてい

Beginning Android Games(Android ゲームプログラミング A to Z)その 1

イメージ
Android を始めとするマルチプラットフォームの Java 用ゲーム開発フレームワーク libGDX の創始者である Mario Zechner 氏の著書“ Beginning Android Games ”(邦題は『 Android ゲームプログラミング A to Z 』)だが、原著は 3 版が 2016 年、初版の日本語訳版は 2011 年に出版されたきりであり、いずれにしても、最新の Android API からは隔絶した内容のものとなってしまっている。 初版は 10 年を経過(!)しているので、Android API 以外の内容にも古さは否めないが、とはいえ原著の 3 版にしても、ごく一部の Android API に関する部分を 2016 年の時点に合わせて修正したのみで、本の構成内容自体は全く更新されていない。特に、初版の時点では、OpenGL ES の 2.0 が出始めたばかりで普及しておらず、OpenGL ES 1.x を対象にしたのはわかるが、版を重ねても、OpenGL 2.0 以降に対応させてはいない。1.x と 2.0 以降では大きな違いがあるので、そこを変えるとなると大幅な書き直しになってしまうからだろう。また、本を読む初心者にとっても、2.0 以降のプログラマブルシェーダーについての学習のハードルが加わることになり、Android ゲーム開発全般をテーマとする本書のスケールを上回ることになる。 この本の良さはそういった Android プログラミングで直接使える技術の情報源として以外の部分にあるので、依然として一読の価値ある本だと思う。Amazon ではほとんど送料だけみたいな価格で古本が売られていたりするので、興味が湧いたら是非、一冊入手してみることをお勧めする。 自己流ゲームライブラリーの構築 本書を参考にして、自分流のゲームライブラリーを構築してみようと思う。最新の Android API 対応は当然として、その他の要点は次の通り: 2D OpenGL ES 2.0+ Kotlin プラットフォームは Android 専用とし、インターフェース化してマルチプラットフォーム化を意識した設計にするようなことはしない。例えば、ファイル入出力なども、直接 Android API を駆使し、ゲ

スペースインベーダーの謎

イメージ
ふと、スペースインベーダー(元祖アーケード版)の仕様について興味が湧いたので、メモを兼ねてまとめてみる。 画面の解像度 256x224(註)を横倒し状態で使っている。8x8 の文字キャラクターに換算して、ピッタリ 32 列 28 行になる。 さらに、自機下部の画面を水平に区切る赤線を除いて、上下左右におそらくアナログ時代なので表示用のマージンとして各 1 文字分ずつが空けてある。その分を考慮に入れると 240x208(30 列 26 行)となる。 また、画面上部の 3 行分はスコア表示用の領域として使われ、画面下部の 1 行分は残機やクレジット表示用の領域として使われているので、これらの分も除いたゲームのメイン画面の表示領域は 208x208(26 列 26 行)の正方形となる(画面が横倒しになっている点に留意)。 註: Computer Archeology で Screen Geometry 情報として 2400 - 3FFF (1C00 bytes = 256 * 28) 28*8=224. Screen is 256x224 pixels. と記されているように、VRAM のアドレス割り当てから 256x224 であるという技術的根拠が明確である。一方、なぜか日本語の Wikipedia には 260x224 と記載されており、それを元にしたものと思われる日本語のブログ情報の多くが 260x224 としているが、間違っていることになる。MAME でキャプチャーすると 260x224 で画面キャプチャーされるため、それを元に日本語の Wikipedia に誰かが記載し、そこから流布したのだろう。Linux を「リナックス」と読んだり、Indie game(s) を「インディーズゲーム」と読んだりして、普及初期の誤ちが流布してそれが正しいものと思い込んでいたりするようなものか。 メイン画面の行構成 上記、メイン画面として残った 208x208(26 列 26 行)の部分について分析する。 行↑ 行↓ 色 用途 25 0 赤 外れた自弾が爆発 24 1 紫 UFO 22 ~ 23 2 ~ 3 青 18 ~ 21 4 ~ 7 緑 エイリアン 14 ~ 17 8 ~ 11 水色 エイリ