ゲームボーイエミュレータを作っている。
https://bit.ly/3MQZaUS
オーディオ以外はだいたい出来た。
音まわりはなー、デバッグめんどいことが見えてるから手つけづらいんだよな。
そして作り始めたはいいけど、思ったよりゲームボーイのゲームやってないことに気づいて
若干この先を作るモチベが下がっている... 本当にやりこんだのは初代ポケモンくらいだな...
あまり苦労した感じは今のところない。
NESに比べるとCPUが8bit(6502)から16bit(LR35902)になって実装めんどくなるかと思ったが
結局0xFF個しかオペコードないから、実装するだけならさほど時間はかからなかったし。
(厳密には0xFF*2だが)
ゲームボーイは仕様面がわかる資料がNESに比べてはるかに整備されてると感じた。
まず、洗練されたドキュメントがここにあるし。
https://bit.ly/43pMqKi
このへん読めばどう動いてるのかなんとなくわかるし。
https://bit.ly/3WxuUS7
でもやっぱり細かいところわからなかったりするから
githubで誰かのコードを漁って読むんだけどね...
-----
今回はRustを使ってみたんだが、この言語はいろんな意味ですごいと思った。
まず、所有権という概念のせいで恐ろしく書きづらい。しかしその制約のおかげで、
いかに今まで自分が適当にオブジェクトを設計していたのかを思い知らされる。
この循環参照を完膚なきまでに許さない言語仕様は、
書きづらいのに心地いいみたいな不思議な感覚に陥る。
これは初めての感覚だ。人気が出る理由がなんとなくわかる。
とはいっても、RcとかRefCellとか使えば似たようなことができるわけだが...
しかし、そういう設計は最小限にしようという思考が働くだけでも十分だと思う。
欠点があるとすれば、他のプログラミング言語に比べると
ちょっと難しい気がするなぁというのが正直な感想ではある。
でも多分慣れだな。
javascript は気に入らないところが結構あるなぁと思ったので書きとめておく。
■気に入らないところ
(1) 浮動小数点
浮動小数点の演算をすると、割と頻繁に変な値が下位の桁に現れる。
こんな感じ。
これがデバッグするときにマジで邪魔。
調べた限りでは倍精度浮動小数点の仕様なので、javascriptが悪いって感じじゃないんだが
他の言語はなんとかできてるし、なんとかしてほしい。
(2) クラス変数がない
javascriptにおいてはクラスという概念自体が割と最近できたもののようだ。(ES6から)
クラス変数がないからクラスごとの定数の表現が微妙...
毎回、this.HOGE みたいな書き方しなきゃいけなくて気持ち悪い。
(3) sleepの実装がめんどくさい
javascriptは非同期処理が基本だから、sleepという概念がそもそもないみたいなんだが
わざわざ async/await, Promise使って、同期処理を書かないといけないのがめんどい。
■気に入ったところ
(1) UIまわり
Canvasは使い勝手がいいし、WebAudioAPIも悪くない。
ゲームUIを選ぶときに特に迷う要素がないところが良い。
他のコンパイラだと、SDL? Qt? OpenGL? みたいな感じで悩みそうなところ。
(2) Chromeのパフォーマンスモニタが優秀
視覚的にわかりやすい。ボトルネックが割とすぐわかる。
NESエミュレータを作っていた。(JavaScript)
https://bit.ly/3a5R9Lq
作り始めたのはだいぶ前だったと思うが、APUデバッグがめんどくさすぎて頓挫していた。
そういえばと思って再開したら思いの外ささっとバグが取れたので割とまともに動くようになった。
作る上で参考にしたのは下記。
- Nesdev Wiki https://bit.ly/3yshCfh
- githubにある無数のNESエミュソースコード
Nesdev Wikiに書いてある内容は充実してるけど、それだけで作るのは絶対に無理だ。
githubにある先人たちの知恵を参考にする必要がある。
だから、まぁ作ったというよりは答えを見ながらポーティングしてた感覚に近い。
はっきり言ってエミュレータを作るのに一番必要な能力はプログラミング能力ではない。
そのアーキテクチャの仕様を理解する能力だ。
-----
NESを作る上でめんどくさいのは下記だと思う。
(1) CPUデバッグ
命令自体は100も無いから時間はそこまでかからないと思うが、問題は実装がある程度終わった後だ。
コードを目視してもどこが間違ってるのか絶対にわからんw
最終的には完成済の6502エミュレータを持ってきて出力を全部比べるしかないw
(2) APUデバッグ
これがまた分かりづらいんだよなぁ。
実装してみて、なんとなくそれっぽい音が出ても何が間違っているのやら...
Audacityでキャプチャして波形を見るも、細かい違いまではわからない。
最終的に波形サンプル全出力して、gnuplotで短形波や三角波を全て絵にすることになる。
あとはパフォーマンスのボトルネックも絶対にぶち当たる壁ではあると思うが
これはモニタリングするツールがあるなら何とかなるだろう。
Chromeのパフォーマンスモニタがこんな感じ↓でかなり優秀。
これを細かく見ていけば、何の関数が遅いとか割とすぐわかる。
CPU/APUに比べると、PPUは視覚的に分かりやすいからデバッグしやすいのよね。
こんなんなったらスプライトまわりなんかおかしくね？と思うし。
これだと、ミラーリングおかしくね？みたいな感じ。
-----
あとはマッパーを増やして遊べるゲームを増やしていくだけなので、いったんここで終わりだな。
次はゲームボーイを作ろうかね。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
Dustin BoswellTrevor Foucher
話題になってたから読んだ。良本。でも、
Martin Fowlerのリファクタリングとか、リファクタリングRubyエディションとかを
読んだことがあるならこの本を読む必要は無いと思う。
15章構成で、1〜6章は読みやすいコードを書くための心得というかコーディング規約、
7章からやってることはぶっちゃけリファクタリングだ。
まー、恐ろしく読みやすい本というところが良いところだと思うのだが
ボリュームが少なくて物足りなかったかなー。
あと11章、12章あたりのリファクタリング前のコードの読みづらさが
わざとらしすぎてイライラしたｗ
情熱プログラマー ソフトウェア開発者の幸せな生き方
Chad Fowler
ずっと読もう読もうと思って読んでなかった本。
プログラマーにとっての創作意欲を上げる内容が書いてあるのかと思いきや全然違った。
ソフトウェア開発者として理想的な道を歩むためにどうすればいいのかが書いてあった。
それができりゃ苦労しねーよみたいな話も多かったんだが、基本的に面白かったと思う。
今読んでみて全部の項目が面白かったわけじゃないけど共感できるところも多かったし
多分この本はは数年後にもう一回見返すんじゃないかな。
↓は割と心に残った内容メモ。
3. コーディングはもう武器にならない
君が「ただのプログラマ」だったとしても、顧客に彼らのビジネスの言葉で
語りかけることが出来れば、それはもう立派なスキルだ。
5. 自分の知性に投資しよう
数十人を面接したけど採用したくなる人材に出会えず、採用条件に
smalltalkを追加してみたら…という話が面白かった。
6. 親の言うことを聞くな
「僕だったら、ただ一つのやり方しか知らない人よりも、いろいろな環境で
多彩な成功と失敗を経験してきた人を採用したいね」
10. 愛せよ、さもなくば捨てよ
自分の仕事で秀でた存在になりたければ、自分の仕事に情熱を注がないとだめだ。
どうでもいいと思っていると、その気持が結果にも現れる。
13. 師匠を探す
手本となる人物の特徴を10個あげて、ランク付けする。
これは君の努力が必要な分野トップ10だ。
上位の2、3項目からはじめて、今すぐ出来る具体的なことのリストを作ろう。
21. 読心術
仕事を頼まれる前に、事前に予測し行動に移せ。
頼まれてもいない仕事をやることになるのだから、
実装が実現可能か調査し、最小限のコストでできるかどうかを判断しろ。
読心術のトリックがうまくいけば相手の信頼を勝ち取れる。
Raoかっけぇeeeeee。
23. 今の職務を全力で
別にこれは本を読む前から分かっていたことだし組織で働いてりゃ
すぐ身にしみて分かる話なんだが、仕事を選り好みし、次の段階を常に念頭に
置いてるような奴には永遠にやりたい仕事はまわってこないという話。
そういう奴は月並みの仕事しかしないし態度も良くないから、企業からすると
重要な仕事をまわそうという対象にならない。
(外的な特殊要因が無いならば)、今の職務を全力でやることがやりたい仕事への近道なのだ。
26. バケツいっぱいの水の中の小石ひとつ
あなたがどんなに重要な人物であっても、あなたが会社を辞めた時に企業にとって
大きな打撃となることは少ない。あなたは代替可能な存在なのだ。
「誰も自分の代わりになれない」と感じるのは悪い兆候であり、その逆に
取り替えがきく存在を目指すことは次の大きな仕事へのステップアップになる(かもしれない)。
コードを保守しろ。ドキュメントを作成しろ。チームのメンバーがいつでも容易に
参照できるようにしておけ。
28. 8時間燃焼
どう頑張っても8時間異常働き続けるのは無理なくらい容赦なく働くべき。
毎日仕事に使える時間はわずか8時間！やってやってやるしかない！
というフレーズが気に入った。
33. 視点が違えば認識も異なる
この本では例えば各担当者が何を認識できるのかを↓と書いてるけど
チームメイト … 技術的技能、社会技能、チームワーク
マネージャ … 指導力、顧客重視、コミュ力、遂行力、チームワーク
顧客 … 顧客重視、コミュ力、遂行力
プロマネ … コミュ力、遂行力、生産力、技術的技能
全体を通してみると技術的技能ってのは重要な要素であることは間違いないんだけど
あくまで数ある要素の中の一要素に過ぎないという感じが凄くした。
49. 鏡の中の太った男
自分の成長具合というのは自分からはわかりづらい。
だからチームメイトやプロジェクトリーダなどの第三者を使え。
プロフェッショナルとして必要な要素を10個ほどリストアップし
アンケートにしてフィードバックをもらえ。
別に会社にはこの手の評価制度みたいなのはあるんだけど、
自分で考えてやったほうが効果的なんじゃないかなーと思った。
UNIXという考え方―その設計思想と哲学
Mike Gancarz
基本的にスモール・イズ・ビューティフルな話ばっかりしてる本。
原著がいつ出たのか調べてみたら1994年だった。20年前かよ。
すげー古い本だけど3章と7章だけでも良いから読む価値はあると思う。
プログラミング作法と同じでこういう昔から引き継がれている考え方が書かれた本は
コンピュータに関する昔の話とかと一緒に書かれてて結構面白い。
- ソフトウェア開発に終わりはない。あるのはリリースだけだ。
気に入った一言。
- できるだけ早く試作を作成する
こんな時代からこの考え方が根付いていたという驚き。
- 人間には三つのシステムしか作れない
これが一番おもしろい話だったな。
第一のシステムは本当にやりたいことに特化したシステム、
第二のシステムは第一のシステムが多機能になって性能が劣化したシステム、
第三のシステムは第一と第二の良いとこ取りをしたシステム、
っていうただそれだけの話なんだけど、
「追いつめられた人間が第一のシステムを創る」という一言が凄い良かった。
- 全てのプログラムはフィルタだ
入力と出力があるんだから別に当たり前のことなんだが
あまりそう考えたことがなかった。
- 言うべきことだけを言うことが重要である
ファイルがなかった時に、lsが"NO FILES FOUND"を表示した場合の弊害はなんでしょう？
-> パイプ使うと悲しいことになる。
- 一人の女性は九ヶ月で子供一人産める。女性九人でかかれば一ヶ月で子供が一人産めるのか？
並列処理のボトルネックを現すジョーク。
- UNIXとは90％の解を目指すシステムである
100%を目指すより90%にとどめたほうが成功するという例のあれ。
いつまでも『ソフト』ウェアにとどまり、ハードウェアになれない以上
100％の解を実装するソフトウェアはありえない。
ここ2日間はこれを読んでいた。
エキスパートCプログラミング―知られざるCの深層 (Ascii books)
ピーター ヴァン・デ・リンデン
4章くらいまでは歴史とか、バグはどこでしょうみたいな話とか
ややこしい宣言の話とか、K&RとANSIの比較とかあって知らないことが
結構あったから面白かったんだけど、それ以降はOS(っていうかプロセス)と
ポインタの話になったので、そこまで目新しい話はなかったなー。
なんで今頃こんな古い本読んだのかと言われるとJavaの本もRubyの本も
コンパイラの本もOSの本もそれっぽいのを持ってるのに、Cの本はK&Rしか
持ってないっていうか、まともにC言語と向きあおうとしたことがないと思うんだよな。
いや、普段の仕事でOSのデバッグはしてるからCのソースはずっと読んでるんだが
何か基本的な素養が足りない気がして…
まー、↓の本を今読んでてそう痛感したというか…。
ハッカーのたのしみ―本物のプログラマはいかにして問題を解くか
ジュニア,ヘンリー・S. ウォーレン
大学院生のときに読もうとして途中で飽きた(諦めた？)記憶があるんだが
今読むとかなり面白い。この本に書いてあることは凄いと思う。
第3の変数(レジスタ)を使わないで値を交換する方法とか
ハードの力を借りずにオーバーフロー検出する方法とか
凄いんだけど現代では明らかに役に立たないtipsばかりだｗ
