サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ドラクエ3
wentwayup.tamaliver.jp
ファミコンの解像度は横256px×縦240pxだが、縦を224pxとする説が根強い。 中には「内部的には240px」の但し書きをつけたり、「約」224pxとするものもあるが、224という値を書いている時点で五十歩百歩だ。 「内部的」の解釈も曖昧だが、たぶん次のような認識なのだろう。 「メモリ上には240px分の領域が用意されているが、出力されるのはそのうちの224px分のみ」 そのようなことがないのは、Google画像検索で適当なファミコンソフト名を「640×480」や「720×480」の解像度指定で検索すれば分かるだろう。 ただ似たような現象はあって、240px分が出力されても、普通のアナログTVでは実際に画面に表示されるのはその内の85%や90%程度である。 (詳しくは「タイトルセーフ・アクションセーフ」「オーバースキャン」あたりで検索するとよい) ではそのことを言っているのかというと
ファミコンのドラゴンクエストシリーズにおいてカタカナが一部しか使えなかったことは有名だ。 この理由としてROMの容量が少ないためと言われることが多い。 試しにGoogleで「ドラゴンクエスト カタカナ」と検索し、上位50ページの中から初代ドラゴンクエスト(以下ドラクエ1)のカタカナが少ない理由を述べていると考えられる文章を(重複を除き)抜粋してみる。 ・「当時はゲームソフトのメモリ（記憶容量）が少なかったため」「ROMの容量を増やしたこともあり、使用可能なカタカナは徐々に増加していった。」 ・「64キロバイトしかありませんでした。」 ・「容量の問題で」 ・「容量の関係で」 ・「わずか64KB！」「データ量削減」 ・「使える容量はわずか64KB」 ・「64kB」「容量を節約するため」 ・「64KB」「データ量の削減のため」 ・「512KB」「容量の節約のため」 ・「ゲームソフトのメモリ（記憶
この記事はGame Boy Advent Calendar 2017の16日目です。 15日目はtakeshi0406さんのPythonプログラマーがGBでチップチューンを始めて変わったこと・驚いたことです。 17日目はch3coohさんのゲームボーイアドバンスのカセット収納ケースの決定版です。 一般的な2次元ゲーム機の画面は背景面とスプライトからできている。 ファミコンでは背景面が1枚だけだったのに対し後年のゲーム機は複数枚の背景面を持つのが当たり前になり、多重スクロールなどの技法で差を見せつけたものだ。 さてゲームボーイだが、これが背景面は1枚だけなのだが、特徴的な「ウィンドウ」という機能を持っていて、背景面1枚ではできないような表現が少しだけ実現できる。いわば背景面1.5枚とでもいえる面白い仕組みだ。 背景面が2枚あると、2枚の絵を用意してそれらを重ねて動かすことができる。上の絵の透
アタリショックで有名なAtari2600。 フェアチャイルドチャンネルFに続くカートリッジ交換式ゲーム機であり、ファミコンの前世代機としてアメリカで流行していたらしい。 日本では流行らなかったため日本語での情報が少ないのが残念だ。とりあえず日本語で一番詳しくなるくらいに仕様をまとめてみる。 性能が分かりやすいよう、日本人に馴染みの深いファミコンとの比較を各所に入れた。 スペック・CPU 6507、1.19MHz この6507というCPUは6502の機能削減版で、割り込みが存在しないことと、メモリ領域が6502の64KBに対し8KBしかない点が違いである。 ファミコンのCPUもBCD演算が無い他は機能は6502と同一なので単純に比較すると、ファミコンは1.79MHzなので、演算性能はファミコンの2/3と言えそうだ。 が、Atari2600はファミコンと違い画面の描画にCPUを使うため、実質的
最近ファミコンプログラミングにはまっているので、ちょっとファミコンのCPUである6502の命令セットについてまとめてみる。 いろんなところに命令表はあるけど結構大事な情報が載ってなかったりするので、探すのに苦労した情報を重点的に。あと自分なりに解説も付けておく。 ▶レジスタA アキュムレータ 基本的に演算結果はここに入る。 X インデックスレジスタX Y インデックスレジスタY 汎用レジスタ。メモリの連続アクセスのために使いやすい設計。 S スタックポインタ これが1バイトなのでスタックの場所が$0100～$01FFの256バイトに制限されている。 TXS/TSX命令を介して読み書きできる。 P プロセッサステータスレジスタ いわゆるフラグレジスタ。素直にFって名前にしといたほうが分かりやすいと思うんだが。 重要なビットはSE*/CL*系命令で1つづつ制御できる。PHP/PLPでスタックを
ふと思い立ってやってみた。 まずは文字数をカウントするプログラムを作る。 適当に作ってたら「入力はUnicodeのリトルエンディアンのみ」「出力はUTF-8」というけったいなプログラムになったが別に問題はない。 ※理由: ・入力がバイト数可変なコードだと扱いにくい。 ・じゃあUnicodeだ。 ・出力は文字コードと出現数だけにすればASCIIで十分。 ・と思ったけどやっぱり文字の実体も欲しい。 ・じゃあUnicodeだ。 ・と思ったけどワイド文字の使い方が分からない。 ・一文字置きに'\0'を書けばいいか。 ・と思ったけど文字出力にfprintf("%d",～)使ってるから一文字置きとか無理だ。 ・仕方ない、自力でUTF-8変換プログラム書くか。 こういうことやってると自分で書いた変換プログラムのところにバグが出るんだけどね。 さて次は文書データだ。これに何を使うかで分析の質が変わるから一
5×5ドットフォントを以前作っていたが、最初のはひらがなだけの1バイトフォントで、次のは画像として描いただけでフォントファイルにする方法は分からなかった。 それが今回やっと、きちんとWindowsで使えるフォントファイルとして完成した。 そもそもがひらがなを5×5ドットで描けるかというのが製作動機であったので、フォント名はKanaFive(カナファイブ)とした。 ただし、折角なのでカナ・かなだけでなく、めぼしい文字をいろいろ詰め込んである。 とりあえずJIS2004の非漢字は5×5ドットで描ける限り入れ、他にもUnicodeの記号で描けそうなものは積極的に入れた。 例えば、 ▸数学記号 ∃∇∏∓∖∫≤⊣ℵ ▸星座や占星術の記号 ☼☽☾☿♀♁♂♃♄♅♆♇♈♉♊♋♌♍♎♏♐♑♒♓ ▸八卦 ☰☱☲☳☴☵☶☷ ▸大文字エスツェット ẞ といったところである。 なお、前回からいくつか修正した文字があ
以前、アイヌ語用など特殊カタカナのローマ字変換方法について考えたことがある。→ローマ字入力考 が、考えてはみたものの作る技術がなかったのでそのまま放ったらかしになっていた。 そんな中Google日本語入力にローマ字変換テーブルをいじれる機能がついたというので色々試してみたのが、これが凄い。自由度が凄まじく高いのだ。 どういう事かというと、MS-IMEでは入力はA-Z、出力はひらがな限定である。 それがGoogle日本語入力では、入力も出力も任意のUnicode文字を使える。 出力が任意Unicode文字というのはつまりその気になれば「a→東京特許許可局」であるとか、「b→안녕하세요」であるとかの変換も出来るということだ。 勘違いしないでいただきたいが、かな漢字変換ではない。ローマ字かな変換の時点でこの出力が出るのだ。 「A」のキーを押すと「東京特許許可局」という未確定文字列が出て、さらにス
最近たまにネットで見かけるようになった変な文字があります。 「ズベズダ」 こんな感じの。 環境によって見え方が異なるのですが、よくて「ス゛ヘ゛ス゛タ゛」のように濁点が1マス使って表示、悪ければ「ス・ヘ・ス・タ・」や「ス?ヘ?ス?タ?」のようになってしまうと思います。 でなんでだろうなーとずっと思っていたのがやっと理由が判明しました。 偶然見つけたこのページによると、 OS Xのファイル名はUnicodeで記録されますが、Normalization (正規化) として、かなの濁点半濁点つきの文字等を合成文字として、基底文字と結合文字 (濁点半濁点) に分離して保持する方式です。Windows NT、2000、XPもファイル名はUnicodeですが分離したりしません。結合文字未対応のソフトで扱うと、Windows 95、98、MeのShift_JISのファイル名との変換時に問題が出ます
このページを最初にブックマークしてみませんか？
『WentWayUp: WebLog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
