NOKOGI RiderのWindows版はそれでも（スマホがメインということで）QVGA縦でゴリ押ししたが。（NOKOGI Riderは）縦置きディスプレイでのフルスクリーンにも対応していたというのもある。しかし、今回はMacにも対応する。Macで縦置きディスプレイというのはあまり聞かない。デスクトップ版のMacの事情はよく分からないが、少なくともMacBookで外付けディスプレイを使わずに縦置きというのは無い。
という訳で、横置きディスプレイでのフルスクリーンをプライマリに想定する必要がある。その場合、解像度をどうしたものかが悩ましい。とりあえず「正方形でいいや」と考え 256x256 で作り始めてみたものの、ひとつ重大な問題を思い出す。
WindowsのDirectX9のDirectGraphicでオフスクリーンサーフェイス描画をする場合、ビュー領域の拡大を自前処理でやらなければならない。DirectGraphicだと、サーフェースロックをしてメモリ領域にダイレクトに点を打つ（※この場合GPUを使わない）ローレベルなインタフェースがある（OpenGLには無い）。
ピクセル単位で描画する描画方式（VGSやエミュレータ全般で一般的な描画方式）の場合、GPU経由で描画すると、GPUはシステム・メモリ間のデータのやりとりが絶望的に遅いため、リアルタイムに描画内容が変わるラスタ形式グラフィックのようなものはGPUで描画できない。
GPUは使っていないので、回転、拡大縮小、半透明といった加工ロジックを全て自前実装する必要がある。ゲームを作ったことがない人だと「こんなオーパーツ的な技術は今でも必要なのか？」と疑問に思うかもしれないが、例えばメニューやメニューの上に載せる描画（文字など）、体力ゲージ的なものの表示などで（フル3Dのゲームだったとしても）割とよく使う。
レトロチックな純2Dのゲームの描画であれば、GPUを一切使わずこの方式だけで描画するのが最も高速になる。だから、VGSはそれで描画する前提のレンダリング機能しか実装しないようにしている。（スマホゲームの場合、GPUを使うゲームと比べて消費電力量や本体の温度上昇を大幅に抑えられるメリットがあったのでかなりうま味だったと思う）
そして、Windowsの場合、フルスクリーンの解像度は640x480などの固定サイズにする必要がある（昔は320x240でフルスクリーンにするmode-xというものがあったが、今は無いので最低解像度は640x480）。
少し前置きが長かったが、解像度を256x256にした場合の問題とは、縦のピクセル（256）を綺麗に480に拡大できないということ。等倍じゃないと pixel by pixel で拡大ができないので画面が汚くなるし、せめて間引き方式で拡大できる1.5xとかでないと拡大縮小時に浮動小数点数演算が必要になる関係で（自前拡大に要する）処理コストも増えてしまうので不味い。
という訳で縦のピクセル数は 240 （480÷2なので綺麗 & 低コストで拡大できる）にして、横は256ピクセルにしてみた。これをMacでフルスクリーン表示した場合のキャプチャが下図。
 |
| Mac + 解像度256x240 で フルスクリーン にした キャプチャ |
妙に既視感のある解像度だな...
と思ったら、256x240 ってファミコンの（表示上の）解像度と同じか。
ファミコンの解像度は正確には256x256の正方形で、縦は上下8ピクセルが切れている。その切れている間がBLANK割り込み期間で、その間にスプライトの情報などを更新するとチラつき無くスプライトが動かせたりする感じだったような気がする。（ファミコンのコードを最後に書いたのが結構昔の話なので、若干記憶が曖昧だが、ファミコンだと非描画系処理を非BLANK時、描画系処理をBLANK時という具合に実装する必要があって苦労したような記憶がある）
スーファミの場合も確か同じ解像度があったような。ただし、SFCには解像度に幾つかの種類があって、どちらかといえば 512x240 の方がよく使われていたかな（だからスーファミには縦より横の方が木目が細かいグラフィックのものが多い: 例）。
Windows（基本的にVGSベース）と比べて横長のMac（640x400というPC-9801相当の解像度がベース）でも左右の帯が概ね気にならないので、コレで良い感じか。
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。