投稿

輪廻

イメージ
※ 特に断わる必要があることではないが、当ブログの仏教記事について、仏教知識の素材源は上座部仏教(パーリ経典)。一方、知識素材を組み立てた結果の有機的イメージは筆者のオリジナル。なので、組み立てられた結果物が上座部仏教に存在しなかったり矛盾するものとなっていても不思議ではないが、かといって素材レベルでは筆者がでっちあげた手前味噌な(大乗経典群のような)妄想物というわけでもない。 人間界・畜生界のような自然界的な発生(胎生・卵生・湿生)と対照的に、各界は化生が転生のベースとなっている点に留意すると理解しやすい。 なぜそのような化生(転生)となるかと考えると、悪趣は貪・瞋・痴(三毒)の悪業の結果、善趣はそれらの三毒の対治としての不貪・不瞋・不痴の善業の結果。 輪廻とは 輪廻とは、このような各界の中で転生を続けることを一般に言うが、より狭義な見方をすると、人間界とそれ以外の界との転生ループを堂々巡りで繰り返すことではないか。つまり、例えば、地獄界に転生する者は、そこでの寿命が尽きてせっかく人間界に戻っても再び瞋恚による悪業で地獄界に堕ちる。餓鬼しかり、畜生しかり。そして、善趣しかり。そういった堂々巡りのループを打破することを「輪廻から解脱する」と考えることができるのではないかと。 もちろん、これは一般に流通している仏教の「輪廻からの解脱」像とは食い違ってきている。後者(一般に流通している解脱像)の場合は、この各界のループで成立している全体像としての世界そのものから解脱するという風に解されており、要するにこの世から存在が消滅するようなものと解された上で、その是非を論議されている。 化生とは まず、本来的に仏教の知識外の人向けにわかりやすい説明をすると、化生というのは世間で思われているところの死後の世界とか心霊世界とか呼ばれているようなものと考えればわかりやすいかもしれない。ただし、本当はそうではない。世間のイメージ的にそんなようなものに匹敵するものというだけの話。つまり、今我々が生きていて認識しているこの物質的現実世界とは違う別の世界という程度の意味。 言葉の定義的に心霊世界という言葉の定義にどちらかというと匹敵するのは、「無色界」である。物質がなく心だけの世界。 ここで、世間の人が抱く、死後の世界のイメージとの考え方の違いに気付く。世間の人は、

悪貨は良貨を駆逐し、紙きれとなる

ここのところ、YouTube で岡田斗司夫と山田玲司にハマっている。あくまでも、無料で視聴できる範囲だが。 まず、岡田さんが面白いのは、あの「黒さ」。今は YouTube ベースなのでかなり猫をかぶっている感じがするが、もともとニコニコ動画主体だった頃はもっと黒オカダ全開バリバリだったんじゃないかと思わせる(自分は最近岡田さんの動画を観るようになったので、実際は知らないが)、時折ふとした拍子に見せる毒舌。 ちなみに、いつの話かわからないが、過去のある選挙では、岡田さんは、期日前投票で共産党に入れてきたと明言していた。消去法的にアンチ与党票として「他に選択肢がないでしょ!」というような言い方をしていたから、必ずしも共産党そのものは支持してない感じ。一方でアンチ自民であることはほぼ確実。「二世三世議員に票を入れるのは、入れる側の選挙民の側がアホすぎる、タレント議員の方がはるかにマシ」という趣旨の発言をしており、世襲議員が一番多いのは自民党。 山田玲司さんのことは、岡田斗司夫の YouTube 動画を観ていたら、お勧めによく登場し、二人で対談している動画などを観たのがきっかけで知った。彼の本職は漫画家で音楽活動もされているようだが、僕は彼の作品を読んだことがない。漫画と音楽を中心とする日本のポップカルチャーに造詣が深く、戦後の世代論を軸にした各種分析は圧巻。 山田さんの場合、あまり政治的発言は目立たないが、どちらかというの日本社会については、かなり悲観的な感じに見受けられ、本来権力に逆らうロックミュージシャンという出で立ちからも、右というよりは左寄りのリベラル肌な気がする。 岡田斗司夫と山田玲司も、それぞれ仏教や宗教についてもたまに語っていることがあるが、そちらについては、自分的にはあまり聞くべきものがあるようには感じなかった。日本人のインテリ層のテンプレートのような、東洋西洋の相対化の中での東洋的なるものの一つとして日本の仏教や精神性を位置付ける考え方。自分にとっては陳腐な考え方の域を出るものではない。 最近、ふと、無神論というか唯物論者というのは、死後、無色界に行くのではないかという気がした。悪い意味で、である。もちろん、三悪趣ではないのだが、どうも無色界というのは、瞑想で一過的に散策する境地としてはいいとして、死後の転生先として行く場所としては、

センチメンタルナショナリズム

今回の参議院選挙では、消去法で参政党を支持した。 消去法というのは、特にこれといった積極的な支持理由があったわけではなく、消極的な不支持理由で各政党を除外していくと、基本的には参政党やN党やれいわ党のような泡沫政党の中からしか選べなくなる。例えば、自民党系を選べば米国に国益を収奪され続けるわけだし、旧民主党系だと中国に国益を収奪されるから、結局、右か左か的な選択方法では、どちらで選択しても売国に加担する選択肢しかない。 それで参政党に参加していた武田邦彦さんだけ以前から書籍などで知っており、この人なら、主義主張の個々の内容ではなく、人柄的に、まだ信頼できるタイプかなと思ったので、彼の所属している参政党に入れただけ。彼がN党に参加していたらN党に入れただろうし、れいわ党なられいわ党に入れていただろう。なので、参政党そのものには、実は完全にニュートラルで、積極的な支持理由はない。 結局、党首の神谷氏だけが当選する結果になった。選挙が終った後になってから、今さら、暇つぶしがてら、YouTube で参政党の選挙演説などを視聴している。意外と、日本の国益を重視している党らしく、その点では、元々ほとんど「武田さんが参加している」ということを手がかりにした勘で選んだだけだが、それほど大外れはしていなかったように思われる。 しかし、かといって、参政党に積極的な支持を追認的に感じるようになったかというと、依然、そこは消極的な選択に留まる。例えば、歯科医の吉野氏の健康や食に対する問題意識など、個別の問題については、賛同できるものは少なくない。ただ、個々の問題、物事の是非よりも、その問題に対して、感情的になっている点が気にかかる。その熱意や動機が例え善なるもの、正義感、義憤などであって、感情で政治は成功しない。明治維新以後の日本人は、感情で動いたから、太平洋戦争の憂き目に遭ったわけだ。いくら、米国ポチでも中国ポチでもなく、自国の国益を最優先に考える愛国心を持った政党を目指すと言っても、愛国心という錦の御旗の下、結局のところ「感情に駆られて動い」たら、敗北の歴史を繰り返すだけだ。 党首の神谷氏は、他の党員よりは比較的抑制的な感じだが、それでも、例えば太平洋戦争について、「アメリカの陰謀によって、日本が戦争するように誘導された」といった発言をしていたので、ちょっと危ういと思った。武

Google Play Games Services v2 を使ってみる

イメージ
Google 公式の サンプル が古く、API が刷新された v2 には対応していない。サンプルが旧 API でグチャグチャとやっていることが、v2 ではライブラリー側に隠蔽された感じになっており、グチャグチャやっているサンプルを参照すると、却って無駄に学習コストを浪費する面もある。 Google Play Games Services は基本的には Firebase のようなクラウド BaaS のようなものであり、Google Play コンソールからサーバー側の設定作業を行うものの、Google Play そのものとは独立した代物と考えた方がいい。 学習面で Firebase(Analytics や Crashlytics)よりも一段ややこしいハードルがあって、それは、アプリ認証(OAuth)をインプリメントしなければならない点である。サーバー側での適切な設定と、アプリ側での適切な設定を、協働させて行わなければならない。独学で誰にも意見を聞けない状態で、上手く動作しない場合に、どこに原因があるのか、学習段階で突き止めるのは非常にストレスフルである。一旦、成功してしまえば、後から振り返って検証するのは難しくはないのだが。 Firebase プロジェクトを選択する 既に Firebase Analytics/Crashlytics は組み込み済だったので、それに追加する形で Games Services をセットアップする。 Firebase プロジェクトを選択する 既に Firebase Analytics/Crashlytics は組み込み済だったので、それに追加する形で Games Services をセットアップする。 認証情報を追加 ここで認証情報を追加するためには、OAuth クライアントを作成する必要がある。 OAuth クライアントの作成 ここで表示された情報を使って、Google Cloud Platform にて OAuth クライアントを作成する流れになる。 Google Cloud Platform での OAuth クライアント ID の作成 直前の Google Play コンソール側で表示された情報を使って Google Cloud Platform 側で OAuth クラ

父の死 14 相続税の申告

本日、ようやく、相続税の申告書を税務署に提出してきた。 申告書の作成にあたって、一番頭を悩ませたのは不動産の評価額だったが、どうにか国税庁の路線価図などを基にして算出して、固定資産税と比較しても矛盾のない金額になることを確認したりして、まとめ上げた。 法定相続割合のままだと少々相続税が発生する状況ではあったので、結局、父の生前の意思通り、母に全額を相続させることにして、相続税は 0 になった。ただしこの場合は遺産分割協議の結果によるものなので、申告はしておく必要があり、申告書を提出したわけである。 金額的にも、多少の修正が発生したとしても、税額は 0 に違いないはずなので、おそらく税務署から後で文句を付けられることはないとは思うが、相続税関係に区切りがついたということになる。 これで残るは、不動産の登記と、自動車の登記だけだと思う。

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 水色 エイリ