忘れないようにメモ。
眼球のコースティクスのリファレンス動画がX(旧Twitter)に上がっていました(5年前)。
Here's a reference of eye caustics that @JoverCyril and I shot. See the reply for high-res. pic.twitter.com/nGs8s92wgs
— Thomas (@Chman) June 6, 2019
高解像度バージョンの動画などはスレッドにリンクがあり，https://t.co/bc9HF4uWO5からダウンロードできるようです。
High resolution available here (1440p30 – don't stream it, download it to get the full-res and good quality version):https://t.co/bc9HF4uWO5
Feel free to use it (licence CC-BY).
— Thomas (@Chman) June 6, 2019
知識というのは更新しないダメですね。
法線データのOctahedral Encodingをよく用いています。
ここで，Octahedron を45度回転させて，符号をビットを別に持てば，表現する面積領域が増えるから精度が倍に上がるのと，OctWrap()の演算も無くなるので，デコードも高速できるそうです。
これが，John White 3Dというブログの，”Signed Octahedron Normal Encoding”という記事にのっていました。これをみて「ほぇぇ～」と感心しました。頭いい！
ただ、符号ビットを別に持つの何かやだなーと思っていたのですが，R10G10B10A2なら10bit分が残っているので，この32bitでNormal, Tangent, Bitangentを表現しちゃいたいところです。
以前に書いたかもしれませんが，SIGGRAPH 2020のDOOMで使っている，接線空間表現を使おうかなと思っていました。
しかし、今日もっといいやつを見つけました。
Jeremy Ongさんの”Tangent Spaces and Diamond Encoding”というブログ記事。この中でも上記のDOOMの方式が紹介されていますが，もっといいのがダイヤモンドエンコーディングというやつ。
ここでも，Octahedronの考えを利用しています。ちなみにサンプルコードは下記の様です。
ダイヤモンドエンコードで得られた接線を表すデータを残りの10bit部分に入れてしまえば，うまくR10G10B10A2に収めることができます。
ちなみに，Octahedron Encodingですが，Z+の半球が約束されているのであれば符号ビットもいらないので，下記のHemi-Octで実現できるそうです。
…ということで接線空間データの圧縮についてでした。
こんれな～。
Pocolです。
今日は…
[Vaisse 2024] Alexis Vaisse, Marios Michaelides, “Maximizing Graphics Performance with Flexible Virtualized Geometry”, GDC 2024.
を読んでみようと思います。
いつもながら誤字・誤訳があるかと思いますので，ご指摘頂ける場合は正しい翻訳と共に指摘していただけると有難いです。
こんるるー。
Pocolです。
今日は…
[McLaren 2022] James McLaren, “Adventures with Deferred Texturing Horizon Forbidden West”, GDC 2022.
を読んでみようと思います。
いつもながら誤字・誤訳があるかと思いますので，ご指摘頂ける場合は正しい翻訳と共に指摘していただけると有難いです。
断りが無い限り，図は[McLaren 2022]からの引用です。
今日は，エミュレーターの実装の進め方について紹介します。
基本的には…
MJHDというのブログ記事の「Rustでゲームボーイエミュレータを自作した話」に沿った手順で実装するのが良いと思います。
また，どのよう実装するかイメージがつかめない方は「脱・初級者のための自作GBエミュレーター開発」というスライドを参考にするものよいかもしれません。
Step.1 ROMをデコードする
Step.2 CPU処理を実装する
Step.3 PPU処理を実装する
Step.4 デバッガを実装する
Step.5 CPUテストROMを通す
Step.6 機能追加・改善を考え，実装する。
まずは，ゲームボーイのソフト。つまりカートリッジデータが読み込みできなければ話になりません。
…なので，まずはカードリッジデータを読み込めるようにしましょう。カードリッジデータが読み込めれば，ゲームで使用する命令列などが読み取れるようになるはずです。
カートリッジのデータフォーマットなどについては，Pan Docs にまとまっているようなので，どういうデータ構造になっているのか？についてはドキュメントを読みましょう。
どんなプログラマーもドキュメントが読み解けるようにならなければいけません。特に，コンソールプラットフォームなどは秘密事項の塊で，インターネットに情報が出ることはめったになく，公式ドキュメントを見なければ何も出来ないということが多々あります。
そのため，ドキュメントを見ながら実装力をつける訓練の最初の一歩としてやってみましょう。
続いて，絵を出す前にCPU処理をエミュレートした方が良いでしょう。
ロード命令やジャンプ命令・加算・減算・ビット演算など基本的な命令を実現できるようになりましょう。
また，基本的な命令の実装を通じて，低レベルで何が行われるのか？を知ることが研修の目的の一つでもあります。
グラフィックスプログラマーを目指すものであれば，絵が出せなければいけません。また，やっぱりゲームは絵が出てこそ！というところもあるので，絵を出しましょう。
また、PPU(Picture Processing Unit)で何が行われているかを知りましょう。これを知るためには，PPU処理を実装するのが一番です。
PPU処理の実装が出来れば，一番処理にGame Boyプログラムで作った「Hello World」の文字列表示プログラムが動かせるようになるはずです。
PPU処理まで実装出来たら，あとはひたすら精度・品質を上げていくだけです。
そのためには，デバッガの実装は必須でしょう。
また，デバッガを実装するためにどのようなことをしなければないのか，普段我々がVisual Studio何気なくつかっているブレークポイントなどの機能はどのようにしておこなわれているのか？などデバッガの仕組みを身をもって体験してください。
最後の仕上げです。
実機で動作保証がされているCPUテストと呼ばれるROMを実行し，自作のエミュレーターで正常動作すること確認してください。
テストのROMは以下にあります。
https://gbdev.gg8.se/files/roms/blargg-gb-tests/
正常動作しない場合は，エミュレーターの実装に問題があるということです。
特に会社等では，テスト駆動開発を実施している会社もあるのと思うので，ここでテストの重要さ，製品の品質保証など，クオリティーを上げる大事さを学んでください。
言われた仕様，あるいはお題に通りに作れば最低ラインは超えたことになります。少なくとも一般的な会社では言われたこと通りものを作ることが出来れば，きちんと給料は支払われるはずです。
ここから先は，「他とどう差別化するか？」という話です。同じ機能でも見た目をカッコよくできるのであれば，付加価値はあがるでしょう？また，他社や他人には出来ない機能追加をするのもよいかもしれません。あるいは，思い切って機能を削ることによる分かりやすさの改善・動作安定性なども差別化が図れるでしょう。
余力がある人は，自分なりのカラーを出せるように改造・改変してみてください。
特に昨今はKFCの事例のように何も考えない会社が作るとUX(User Experience：ユーザー体験またはユーザー体感)が激悪化しやすいです。また，どことはいいませんが解約手続きの面倒さなど，もう二度と使うもんか！と思うような酷いものあったりします。ユーザーにとって何か使いやすいのか？何が嬉しいのか？については我々は常に思考を巡らせる必要があります。特に日本の大手会社（例えば電機メーカーなど）などはこうした考えが非常に弱く，そのせいで海外メーカーにシェアを取られるというひどい状況に陥っています。携帯電話のUXの酷さなどはそのもっともたる例のひとつになるかもしれません。
我々はグローバルに戦っていく必要があります。そのためは，常にユーザーないし，使う側の立場にとって良いものを提供する必要があると思います。
そこで，余力がある人は作ったアプリに対して，ユーザーにとって有益であるような機能追加・機能改善を実行してみてください。
恐らく基本となる考え方は「自分だったら嬉しいか・喜ぶか」がベースになるのではないかと思います。そこから，平均と比べて自分がどのぐらいズレがあるのかを推測して補正していくと良いでしょう。
こんらみ。
Pocolです。
今日は，前回読んだ
[Li 2019] Bo Li, “A Scalable Real-Time Many-Shadowed-Light Rendering System”, SIGGRAPH 2019 Talks, https://sites.google.com/view/winningatgameproduction.
のプレゼン資料を見ていこうと思います。
いつもながら誤字・誤訳があるかと思いますので，ご指摘頂ける場合は正しい翻訳と共に指摘していただけると有難いです。
(さらに…)
こんこよー。
Pocolです。
今日は…
[Li 2019] Bo Li, “A Scalable Real-Time Many-Shadowed-Light Rendering System”, SIGGRAPH 2019 Talks, https://history.siggraph.org/learning/a-scalable-real-time-many-shadowed-light-rendering-system-by-li/.
を読んでみようと思います。
いつもながら誤字・誤訳があるかと思いますので，ご指摘頂ける場合は正しい翻訳例と共に指摘していただけると有難いです。
実装用メモです。
SSRを実装すると，エッジ部分どうすんのよ？っていう問題が付きまとうのですが，下記の資料で解決方法の1つが示されています。
[Genin 2017] Remi Genin, “Screen Space Planer Reflections in Ghost Recon Wildlands”, https://remi-genin.github.io/posts/screen-space-planar-reflections-in-ghost-recon-wildlands/
SSRの実装自体は下記記事が参考になります。
また，ナイーブな実装だと，下に伸びるようなアーティファクトが発生することがあります。この問題への対策の一つとして，深度の厚みを考慮することによってある程度回避する方法が述べられています(Notes On Screen Space HIZ Tracing)。
また、上記のブログでは，深度によるアーティファクトの問題が指摘されていますが，GDC 2016のTHE RENDERING OF INSIDEの中で紹介されている隣接セルの深度を補間するのが良いでアイデアではないかと触れられています。
最適化については，“Screen Space Reflections in The Surge”の中で触れられているInterleave化を試すのが良いかもしれません。SSAOなどでは実際に実装してみた経験があり，かなり処理負荷削減できました。ただ、この手法はHi-Zには相性が悪いかもしれません。
色々と試して思うのは，HYBRID SCREEN-SPACE REFLECTIONSにあるように，近い点をSSRで解決してしまって，遠い箇所についてはレイトレしてしまった方が，良いかもしれないと思っていますが，実際にHi-Z使うよりもいい結果とパフォーマンスが得られるかどうかまでは試していないので，どこかで試してみるのはありかもしれないです。
また深度の厚みに関しては，”Screen Space Reflection Techniques”という文献の中で，Min-Max Hi-Zという手法が紹介されており，これを使うとパフォーマンスやアーティファクトの問題が解決できるかもしれないです。こちらもまだ試せていないです。
こんちゃわ。
Pocolです。
今日は…
[Fatnassi 2023] Sammy Fatnassi, “Shadow Techniques from Final Fantasy XVI”, Technical Report, Square Enix, 2023, http://www.jp.square-enix.com/tech/publications.html.
を読んでみようと思います。
いつもながら誤字・誤訳があるかと思いますので，ご指摘頂ける場合は正しい翻訳例と共に指摘していただけると有難いです。
(さらに…)
こんにちわ。Pocolです。
今年は研修どうしようか悩んでいたんですが，今の若い人はあんまりハードのことを知らないのではないか？（当然、めっちゃ詳しい人もいますが…）
という考えが湧いてきたので，今年はGame Boyでプログラミングするというのを研修ネタとしてやってみようかなと思います。
ハードウェアについて理解し，実際にゲームを作成し，プログラミング能力および開発能力を高める。
また、ポーティング作業を行うことでマルチプレットフォーム展開を行う際に、やってはいけないことを体感させ，開発効率改善および向上のための意識づけを行うことを目的とする。
エミュレーター開発を通じて各種APIへの理解を深める。
● The Ultimage Game Boy Talk
● The Game Boy, a hardware astopsy – Part 1: the CPU
● The Game Boy, a hardware autopsy – Part 1.5: a few mistakes and register F
● The Game Boy, a hardware autopsy – Part2: Memory mapping
● GBDKの導入～ゲーム作成まで
https://qiita.com/BubbleBubble/items/9c28c57ed942c9b48843
● きるこ日記帳
https://www.dkrk-blog.net/category/GameBoy
● ゲームボーイのゲームを作ってみる
https://www.youtube.com/watch?v=xhUOhT7KKE4&list=PLbP78mBX9wpCH1SwnLix14rd1g47XJ5fO
● Game Boy Development community
https://gbdev.io/
● Open Game Boy Documentation Project
https://mgba-emu.github.io/gbdoc/
● 第1週目
お題：指定されたライブラリを利用した開発環境を整えてください。そして，第3者が開発環境を整えられるように手順書を作成してください。
アドバンスなお題：Visual Studio Codeで開発できるようにしてください。
● 第2～3週目
お題：サンプルアプリを作ってください。
・Hello, Worldの表示
・スプライト描画
・十字キー入力でキャラを動かす
・音を鳴らす (Option)
・説明書を作る (Option)
● 第4週～第5週目
お題：Game Boyエミュレータを自作して，サンプルアプリを動かしてください。ただし、描画APIを利用する場合はDirectX12を使用してください。
※6週目～7週目を見越してラッパーAPIを作っておくのは可とします。
アドバンスなお題：
・ゲームパッド対応を行ってください。
・どこでもセーブできる機能を作ってください。
・アップスケール対応を行ってください(Option) [ex]Hq3xなど…
・可能であれば次のSIGGRAPH論文を実装してしてください(Advanced）
Johannes Kopf, Dani Lischinski, “Depixeling Pixel Art”, SIGGRAPH 2011 Technical Papers, https://johanneskopf.de/publications/pixelart/
実装参考として，次のPythonコードを参照するのは可とします。https://github.com/vvanirudh/Pixel-Art
補足：動作確認には自作のアプリとhttps://gbdev.gg8.se/files/roms/blargg-gb-tests/のROMが動作することを確認してください。
● 第6週～第7週目
お題：指定プラットフォーム上で，自作Game Boyエミュレータを動作するように移植作業を行い，サンプルアプリを動かしてください。