会社で勉強会で発表担当になっているので、ヘネパタ(コンピュータアーキテクチャ 定量的アプローチ)の2章をスライドにしているんですけど……、な、長ぇーー!所詮36ページと思いきや、日本語版は1ページの文字数が尋常じゃなく多いです。全く進みません。
前回の担当分(補足B)のスライドを作ったときも同じことを思いましたけど、ヘネパタの説明って、日本語はわかるけど結局何が言いたいのかわからんときがあります。補足スライドを作るのに凄い時間が掛かりました。
話があちこち飛ぶというか、項目を列挙しているのに説明する性質が一致していなかったり、読んでてイライラします。もう3/4くらい進めた時点で疲れてしまい、最後は超手抜きです。それでも80枚くらいありました。
これでも2章は比較的短い章で、3章や4章なんて50ページありますからね!?スライド100枚でも説明できないのでは?
メモ: 技術系の話はFacebookから転記しておくことにした。
この記事にコメントする
Might and Magicの拡張RAM領域に書いてあるデータの意味のメモです。カートリッジはMMC3と呼ばれるタイプでiNESのマッパー番号でいうところのマッパー4 に相当します。
ファミコンのRAM領域は0x0000〜0x07ffですが、MMC3の場合0x6000〜0x7fffにも8KBのRAMがあります。詳細はNesdev wikiをご参照ください(MMC3 - Nesdev wiki)。
何に使っているか良くわからない領域も多いですが、わかっているところは以上のとおりです。
アドレス0x6200から並んでいて、マップ1マスにつき1バイト使っています。Xは昇順(0 → 15)で、Yは降順(15 → 0)に並んでいて、X, Y座標から配列インデックスを計算するときはi = (15 - Y) * 16 + Xです。オートマッピングのフラグと並び方が違うんですね……。
各ビットの意味は下記のとおりです。
壁とドアを両方セットした場合、マップによって挙動が変わります。下記のようになっているようです。全マップチェックしたわけではないので、これで完全かどうかわかりませんが……。
全くわからない状態から解析したので面倒に感じましたけど、わかってしまえば非常に素直というか、わかりやすい並びでした。
アドレス0x6300から並んでいて、マップ1マスにつき1バイト使っています。並び順は壁、ドアの領域と同じです。
各ビットの意味は下記のとおりです。
ビット3が良くわからないですけど、他は割と素直です。壁かどうかと、通れるか通れないかを分けているので、通れる壁やバリア(通れない空間)が作れるんですね。なるほどねえ。ちなみにイベントが起きるか起きないかは、ビット7とパーティーが向いている方角に依存します。方角はどこか別のところで管理されているようで、この領域を見てもわかりません。
方角に依存したイベントで一番わかりやすいものは、宿屋のドアの前のメッセージです。宿屋のドアの前のマスはビット7がセットされていますが、ドアの方向を向いていないとイベント(メッセージ表示)は発生しません。
以上の情報を見ると地図が書けます。ゲーム画面と重ねるとゲームが見えないので、右側に余白を確保してそちらに書くようにしました。
ゲームシステムの制約(アストラル世界など、オートマッピングができない)も無視できますし、オートマッピングでは描かれない(鍵が開いているか開いていないか)情報も取れます。
この機能、元々はTASのルート決めの補助として作りましたが、普通にゲームで遊ぶ時も非常に便利ですね。詳細な地図が見えない地上エリア、バリアだらけのアストラル世界なんかは難易度が格段に低くなって攻略しやすいです。
この記事にコメントする
| < | 2021 | > | ||||
| << | < | 11 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| - | 1 | 2 | 3 | 4 | 5 | 6 |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | - | - | - | - |
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: