おちゃめくらぶ掲示板 - 1659321896

1441：御茶目菜子：2013/01/03(木) 23:50:37: すごいプログラムも実はすごくない！？
3DSのダウンロードソフトとして販売された「3Dスペースハリアー」は多くの人が大絶賛を
しているけどそんな中でプチコンで「アフターバーナーII」を再現したTINY野郎さんが
また立ち上がったにょ。
今度は、「3Dスペースハリアー」に影響を受けてメガドラ版の「スペースハリアーII」を
プチコンで再現したということにょ。
ボス戦はまだ実装されてないもののオープニング、登場シーン、通常のゲーム画面などを
わずか3日で作り上げたということにょ。
http://www.nicovideo.jp/watch/sm19716569
http://www.youtube.com/watch?v=B4bIHokm910

相変わらず、彼の行動力とその作業スピードは驚嘆に値するにょ。
さて、閲覧者はこのプログラムの仕組みについて動画から検証をし始めたにょ。
私は単純に地面はパレット切り替えによるスクロールで影はスプライトで表示している
と考えたにょ。
パレット切り替えによるスクロールの基本的なことはプチコン講座第7回で書いているの
だけど複雑なパターンにしたり、スクロールをスムーズにさせる場合には必要な色数が
増えるためどんどん重くなるという問題があるにょ。
えぬおうさんが64色使って実際にパレット切り替えによるスクロールを行ってみたところ
地面の描画だけで60fpsギリギリになったとのことにょ。

半透明処理のできないプチコンにおいては影を半透明の描画は1フレームごと表示と非表示を
行うのが常套手段にょ。（スプライトならばSPANIM命令を使って影キャラと透明キャラの
2パターンをアニメーション表示するだけなのでプチコンで行うのは非常に簡単）
これは半透明処理ができないファミコンなどでも使用されていた技術であり、昔からある
ものだけど60fpsのゲームならば影は60iで表示されているためそれほど気にならないけど
これが30fpsのゲームならば30iとなってしまうにょ。
これだと人間の目でも点滅しているというのがはっきり視認できるようになるにょ。
30fpsでも起こさないためには影をためにはXORで重ねる必要があるにょ。

実際にどのようにこれは実現していたかというタネ明かし動画もTINY野郎さんによって
行われたにょ。
http://www.youtube.com/watch?v=mU2_P2OdY2k
地面のスクロールも影の描画もGDRAWMDを使い地面の横線のみGFILL、影の部分をGCOPYで
XOR描画することでこのスペハリIIは実現しているとのことにょ。
私もGDRAWMD命令の存在は知っていたけどGDRAWMD命令を使って描画を行うとビットが反転
してしまう（色相が変わる）ため使いどころがかなり限られていたにょ。（反転を行うため
同じ場所に再描画すれば元に戻る）
メイン画面の描画に使うならば反転した後の色を計算する必要があるためにょ。
これがモノクロ2階調ならXORは大活躍してくれたにょ。
シャープのポケコンにおいては、LINE命令、PSET命令にXORオプションが用意されていた
ためこれを使って描画をすることでドットのONとOFFの表示切り替えが簡単にできていた
からね。
TINY野郎さんのスペハリはGCOLOR 1（グレー）でXOR描画することで色相を変えることなく
市松模様になっているにょ。
このように実際に仕組みが分かればそれほど難しいものではないのだけどその方法で
実現可能だということを自らの手によって見つけてそれを実践に移すというのは簡単なこと
ではないにょ。

さて、「すごい人」の「すごいプログラム」を見せつけられるとそういう人は「技術力に
優れている」というように感じてしまうけどその「技術力」というのは主に下記の2つの要素
によって培われていくと思われるにょ。

　(1)　知識と経験
　(2)　発想力

(1)まず、プログラムというのは命令の使い方を覚えるということだけでは作ることはでき
ないためアルゴリズム（処理手順）を知ることが重要になるにょ。
これは、単なる知識なのでどのような処理にはどのようなアルゴリズムで行えば良いのかと
いうのを1つずつ覚えていけばいいにょ。
私が書いているプチコン講座もそのゲームを作るために必要な処理については1つずつ説明
しているのでそれらを覚えていけば私が作っているようなタイプのゲームを作ることは
容易に可能になるにょ。

ただし、ここで知識というのは活用できなければ無意味にょ。
蓄積された知識を活用するのに必要なものというのはやはり経験にょ。
そのためには実際に作るのが一番にょ。
そういう積み重ねをすることで作れるものがどんどん増えていくにょ。
したがって、入門書などを読んでそれで終わりではダメというわけにょ。
「入門書に書いてあることしか分からない」ということになってしまうからね。
未知のものに出会った場合の対処方法が重要となるにょ。
経験を積み重ねることで（最善策ではなくても）別の方法をとることで解決できることも
あるにょ。

まぁ、今の時代Web検索すればたいていのことは分かるし、いざとなればWeb上で質問を
行えばそれほど時間をかからずに回答を得ることも可能なので経験をそれで補うことも
できるけどその場合でも最低限自分の力で考えるという積み重ねをしていればそれは
将来の糧として非常に強力なものとなってくるにょ。（これはプログラミングだけではなく
学校の勉強も同じであり、自分で考える前に答えをヒント聞いてそれで問題を解いても
それで得られる経験値は小さなものになってしまう）

(2)すごいプログラムというのは多くの人が思いつかないような考えを元にして作られている
場合があるにょ。
確かに(1)で書いたように知識と経験を積んでいけば誰でも普通レベル以上になれるとはいえ
そういう特別なものはなかなか情報を得ることは難しいにょ。
上記のTINY野郎さんが作ったスペースハリアーにおいていえばパレット切り替えによる
スクロール表示という基本は（現状では）多くの人が知っているけどGDRAWMDを使って表示
するというのはそれを思いつかない限りはなかなかできないからね。

それを身につけるために重要なのはそれを思いつく必要性を持たせることにょ。
いかに速くするのか、いかにお手軽な処理にするのかなどの方向性を決めてそれによって
基本的なことを覚えた後に「別の方法でより良くできないだろうか」と考える習慣を身に
つけるということにょ。
速度面に関してはスペックが低かった昔のゲーム機では処理を工夫して普通に作ったら
そのハードではできないような処理を行っているものも見られたにょ。
パレット切り替えによるスクロール（パレットアニメーション）も今では当たり前だけど
それが登場した当時はすごい技術だったにょ。
大きなキャラを表示できないファミコンではBG画面を使ってキャラ表示を行ったりという
のも1つの技術だったにょ。

私はポケコン（PC-E500系）においては速度面を限界まで追求していたにょ。
プチコンと比べて100倍以上演算が遅く、グラフィック関係に関してはそれよりさらに
遅いというポケコンではよほどシンプルなゲームでない限りはBASICでは実用レベルの
速度を得られなかったにょ。
そこで「ポケコンBASICだから遅くても仕方がない」ということで終わっていたら技術の
進歩はないにょ。
したがって、私はまだ速くなる余地は残されていると他者が作ったベーマガなどの雑誌に
掲載のプログラムを1から作り直して高速化を行ってきたにょ。
その多くはポケコンコーナーの「E500BASICの高速化のすべて」でまとめているにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/basic1.htm
ファミコンの「スプライトでデカキャラが動かせないならBG画面を使えばいいじゃない」
という発想もポケコンには有効であり、それで私が思いついたのがOPASにょ。
OPASはE500の隠し機能であったフォント書き換え（プチコンでいうPCG機能に相当する
BGFキャラの書き換え）を使いそれで画面をスクロールさせたり、アニメーションを
行ったりしたにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/OPAS.HTM

速度面やメモリ面などのハードウェアの制約によって(2)の重要性は大きくなったけど
十分に高速で十分なメモリが使えるのならば「より速い処理を行う」「より省メモリの
処理を行う」ということに対する意味はあまり無くなってしまうにょ。
何をもって「すごいプログラム」と見なすかにもよるけどそのハードではできないような
処理を行うというのならば見た目はチープであってもすごいものという認識の人が多い
のではないかと思われるにょ。
しかし、すごいものであっても知識の蓄積が行われてそれが普通に使われるようになった
場合にはそれは普通のものになるにょ。
したがって、「すごい知識」を手に入れるだけではだめで常に高い目標を持って作る
必要があるにょ。
それが、高い発想力を鍛える元になるにょ。（固定観念にとらわれてこの場合はこうする
という一律的な考えにはならないようにしなくてはならない）
そのためには(1)が重要なので結局(1)が必要条件といえるにょ。

私はプチコンではそんなにすごいプログラムは作ってないのだけどリストサイズに制限を
持たせることでリスト短縮技術だけはかなり身に付いたと思うにょ。
1画面プログラムを作る場合に「単に短いから1画面に収まっただけ」というものではリスト
短縮に必要性がないため上記(2)のような発想力は鍛えることができないにょ。
1画面であっても手を抜かずより良いものにしていこうという考えがないと1画面プログラムを
いくつ作っても得られる経験値は微々たるものになるにょ。
1画面プログラムなどでは、リスト短縮のスキルが非常に重要となってくるのだけどこれも
知識や経験でカバーできる類のものなのでそれほど難しくはないにょ。
それらの多くはTipsコーナーでまとめているけど「どの命令で置き換えるか」とか「どんな
使い方をすればいいのか」という様々な試行錯誤があったからこそできたものにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/list.htm

そのような知識や経験を積むことでさらなる高みを目指すことができるにょ。
実際同じプチコンで同じ1画面という制約であっても単純にそれらによって大きな向上が
あるわけだからね。
最近は1画面プログラムだけではなく1行プログラムも多く作っているのだけど初期の頃に
作った1画面プログラムなら1行で作り直すことが可能か・・・ということでチャレンジする
ことにしたにょ。
チャレンジする元になったのは初代プチコンで1画面プログラムとして作っていたものの
ボツにした楽器演奏プログラム「SOUND PAD」にょ。

楽器演奏をするならば鍵盤を表示した方が分かりやすいため「使いやすい鍵盤」を目標に
した「PETIT KEYBOARD mkII」が生まれたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#pkb2
1画面ながら鍵盤演奏プログラムとしてはプチコン用では最も使いやすいと思うのだけど
せっかくなので鍵盤に縛られない楽器もいいかなと思って作ったものが「SOUND PAD」にょ。
すでにKORGのKaossilator（カオシレーター）のように実際の製品でもそのようなものは
作られているため目新しい部類のものではないけどプチコンで作るならば鍵盤よりも
簡単であるためリストが短くて済むというのがメリットになるにょ。
もう1つは鍵盤だとタッチパネルで強さを感知できないためどうしても強弱をつけた演奏が
できないけどこのタイプのプログラムならば音程と音量を二次元的に処理可能になるため
直感的な演奏もしやすくなるというメリットがあるにょ。

1画面プログラム「SOUND PAD」はもともと400バイト程度と大きなプログラムではなかった
とはいえ、1行（改行コード抜きで99文字）に収めるためには大胆な短縮が必要になるにょ。
まず1つ問題となったのは画面上でどうやって音程を分かりやすく表示するかということにょ。
元のプログラムではGLINEで半音ずつ線を引いていたのだけど1行にするためにはGLINEを使う
ことは不可能だからね。（GLINE命令だけではなくGPAGE 1という処理だけで7文字分も余分に
必要になるし、グラフィックを使うならばGCLSも入れた方がいいため12文字分余分に必要）
それで思いついたのがPNLSTRを使いコンソール表示をする方法にょ。
コンソールの場合はCPAGE 1のような下画面設定は不要だし、文字で埋めればCLS命令を
別途使う必要もなくなるにょ。
ただし、上画面では?"A"*256,"A"*256,"A"*256で「A」という文字を画面一杯に表示可能
なのだけど下画面は文字の折り返し機能がないためPNLSTR命令をループなどで24回実行
する必要があるにょ。
ここで思いついたのがすでに私の1画面プログラムではポピュラーなテクニックとなっている
別の必要不可欠なループ内で初期化を行う処理にょ。（例えば30回ループが必要な処理Aと
20回ループな処理Bがある場合にわざわざ別のループにしなくてもAの中でBを実行することが
可能）
これによってFOR～NEXTが1組分省略可能になるにょ。

また、ボタンに対する音色の切り替えについても「PETIT KEYBOARD mkII」と同様にボタン
操作で音色No.を1つずつ変えていくという処理を行っていたにょ。
しかし、1行に収めるためにはそれでは無理にょ。
そこで思いついたのが、ボタンと1対1に対応させるというものにょ。
これならばBUTTON()関数の値によって変えられるためリストの長さは一気に縮まったにょ。
問題はその鳴らせる範囲外を指定した場合だけどそれは剰余で行えば問題ないのだけど
いくつに設定するのベターかが問題となったにょ。
とりあえず、サイズの限界から2桁しか入らないので99から順に試していってどのような
音色になるのかを確かめていったところ最初の99がベターだと感じたにょ。

あと1行に収めるとはいえやむを得ないのがBEEPの処理にょ。
BEEPの同時発音数が8というのがネックになってくるからね。
どういうことかというとメインルーチンにWAIT 1を入れた場合には8フレームで自動的に
音が切られてしまいブツ切れ状態となるにょ。（タッチしてない場合は無音演奏となる
ため自動的にスタッカートの状態になるので長い音（例えばBボタンに設定されている
OK2など）は鳴らすことができないにょ。
また、ピアノなどの音も完全に濁ってしまうにょ。
これはWAITの引数を変えることで有る程度改善可能にょ。
ただし、引数を大きくすればタッチの反応が悪くなるという問題が発生するにょ。
そのためWAIT 1から順番に引数を大きくしていき鳴る音とタッチの反応状況から判断して
WAIT 4がベターであるという結論に至ったにょ。
これだと反応においては許容ギリギリの速度であり、素早く動作したら上手く反応して
くれないことがあるにょ。
しかし、ドラム系の音を鳴らす場合にはこれは都合がいいにょ。
WAIT 1だと確実に音が連続して鳴ってしまうためドラムっぽくならないからね。（つまり
WAIT 4だと操作の仕方によって音の出方をコントロールできるということ）
というわけで、どの音を重視してどの音を妥協するのかという話になるためあくまでこれは
私が考えた最善な値にょ。
1行プログラムなんだから「1行に収めました」だけで終わってはダメで1行でできる範囲内の
ベストを尽くしてこそ意義があると私は思うにょ。

というわけでできたのがこの「SOUND PAD」にょ。
PNLTYPE"OFF"FOR I=0TO 24PNLSTR 0,I,"|"*32BEEP BUTTON()%99,(TCHX-123)*43,TCHST*TCHY:WAIT 4I=I%24NEXT
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#16
http://www.youtube.com/watch?v=MY1gQ4NxvEs　（使用動画）
http://twitpic.com/bs2j08　（操作説明図）
1行でこれを上回る楽器演奏プログラムを作るのは不可能だと思うにょ（笑）

というわけで、ボツになった1画面プログラムとはいえ（多少のアレンジが加わったものの）
ほとんど機能を落とさず1行で収まったのは感無量にょ。
まぁたまたまこのプログラムに短縮化の余地があったというだけであって、私が発表している
1画面プログラムは相当のアレンジを加えて全くの別物にしない限りは1行に収めるなんて
ことはできないと思うにょ。
普通だとプチコン用に移植されたピラミッドのフルバージョン、1画面バージョン、140
文字バージョンを比較してみたら分かるようにリストの長さが大きく変われば内容は全く
別物になってしまうにょ。
http://togetter.com/li/265867

タネを聞いてしまえば「こんなの簡単にできる」と思うけどどんなすごいものであろうと
よほど高度な技術（アルゴリズム）を用いているものでない限りはそんなものだと私は
思うにょ。
まぁ今回の「SOUND PAD」は同じ1行プログラムである「ヘビゲーム」や「スノーボード」
と比べてアクロバティックなことはあまりしてないため本当に簡単なのだけどプログラム
リストを見ずに上記リンクの「SOUND PAD」の動画や操作説明のみを見てこれを1行で
どうやって再現できるのかを考えて実際に1行で作るというのは非常に困難だと思うにょ。
もっとも、作っている本人はタネが分かってるから簡単なんだけどね。
そして、「タネを知らなければすごいと思えるようなもの」を比較的簡単に作れてしまうのが
1画面とか1行といったリストサイズに制限があるプログラムの醍醐味と言えるにょ。