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

947：御茶目菜子：2012/04/15(日) 15:10:32: プチコンのプログラムリスト短縮テクニックをまとめてみたにょ
私が使っているプチコンの「リスト短縮テクニック」をまとめてみたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/list.htm
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/mod.htm

ポケコンにおいてはその処理速度の遅さからまず第1に速度重視となっていてリスト短縮は
その次だったけどプチコンの場合は速度が速いため私はリスト短縮をして楽しんでいるにょ。
もっとも、プチコンもフリーエリアが1MBあるわけなのでこんな短縮をしてもほとんど無意味
となるにょ。
QRコード枚数が多いのは大抵の場合はグラフィックデータ（GRPだけではなくスプライトや
BGなどを含めた広義の「グラフィック」を意味する）を減らす方が遙かに効果的だからね。
それでも、1行、3行、1画面のように行数に制約を設けたプログラムを作っている人に
とっては有意義なものになると思うにょ。
特に1画面プログラムの場合は行数の制約に加えて1行当たり29文字以下に抑えなくては
ならないという大きな制約があるためこういったリスト短縮テクニックを知っているのと
知らないのとでは雲泥の差が出てくるにょ。

まぁ「プチコンが速い」といってもそれはあくまでポケコンやかつての8ビットパソコンと
比較しての話であり、スプライトを35個くらい（mkIIだと50個くらい）動かしただけで
処理落ち（1フレーム内に処理が終了しない）を起こしてしまうにょ。
これに当たり判定などが加わればさらに厳しくなるとはいえ、ポケコンと比べると遙かに
高速といえるにょ。（当たり判定においてはmkIIではSPHIT命令のお陰でかなり高速化されて
いるけど私はまだ使ったことがない）
演算速度は100倍近い差だし、標準のグラフィックキャラ表示機能は数100倍の差がある
わけだからね。
ポケコンのBASICでは1fpsさえ難しいようなゲームもプチコンでは数100fps出せる可能性が
あるということにょ。

もっともプチコンの方が画面解像度や色数が多いため処理速度に比例したフレームレートが
得られるという単純なものではないにょ。
しかし、ポケコン（PC-E650）では実際に作ってみると8x8ドットのグラフィックキャラを
標準となるGPRINT命令を使って1つ表示してそれを動かすだけで11fpsの速度しかでないため
10fps以上のゲームなんてBASICではほぼ不可能になるにょ。
私も10fps以上到達しているのは100m走系のケームがほとんどだしね。（OPASを使っても
8fps前後のものが多い）
ポケコンBASICだからそんなものといってしまえばそれまでだけど速度が遅いからこそ
ポケコンの場合は高速化の恩恵が非常に大きいものになっているにょ。
ポケコンゲーム制作講座で書いたように100m走系のゲームのように連射を要求するゲームは
5fpsでは成立しないけど15fpsではギリギリ連射をして遊べるくらいにはなるからね。
http://ww5.tiki.ne.jp/~ochame/E500/LECTURE/making_3.htm

連射を要求しないゲームでもアクションゲームならば3fpsはかなり厳しいけど10fps近くに
なればそれなりに快適に遊べるというのが私が長年ポケコンBASICでゲームを作ってきた
感想にょ。（これはポケコンの画面解像度が低い影響もあるためプチコンだと10fpsでは
やや厳しい感じになる）
つまり、アクションゲームならば10fpsにいかに近づけるかということが快適に遊べるか
ということになりアクションゲームにおいてはそれが面白さにかなり繋がっていたにょ。
しかし、上記のように8x8ドットのキャラを1つ動かすだけで11fpsまで低下するという
ことを考えると10fps以上のゲームがいかに難しいか分かると思うにょ。
とはいえ、工夫次第ではいくらでも高速化の余地が残されているにょ。
これは実際に私がPJやべーマガといった雑誌掲載のプログラムを高速化改良した結果平均で
3倍速くらいになっているために低スペックのポケコンとはいえ、潜在性能はそこそこ高い
というのが私のイメージにょ。

話をプチコンに戻すと限界まで処理を高速化して10fpsが困難なゲームというのはよほど
無茶なことをしていない限りはあり得ないにょ。
私が作っているような単純なゲームならば高速化を特に意識せずに余裕で60fps出るもの
ばかりだからね。
仮に100fpsのゲームが高速化を駆使して300fpsの速度になってもVSYNC1でウエイト調整を
している以上は60fps以上の速度は無意味となるにょ。
したがって、少なくとも私がプチコンで高速化をしなくてはならないと感じたことは
ないにょ。（唯一60fpsが微妙になったのはPETIT RUNだけであり60fpsを何とか確保する
ために画面を若干荒くしてループ回数を減らして解決した程度だけどそれでも1フレーム
あたり40回以上GFILLが実行できているわけだから非常に高速であり、mkIIでは60回以上
GFILLを実行しても処理落ちが無くなった）

もっとも私は1画面プログラムをメインに作っているために置かれている環境そのものが
他の人とは大幅に異なるのでプチコンの速度は十分速いからリスト短縮の方が価値がある
ということを理解できる人はほぼ居ないと思われるにょ（笑）
とはいうもののプチコンでプログラムを作っている人はそれなりに多いため私と同じ
ような考えを持っている人がゼロであるとはいえないにょ。
実際にプチコンの1画面プログラムで私よりも先輩となる人もいるわけだからね。
やはり、実際に作ってみなければその難しさや楽しさは実感できないにょ。

やはり上記のプチコンのリスト短縮テクニックの中で私が好きなのは！（論理否定）と
％（剰余）にょ。
それは1文字で済むということに加えていろいろと応用性が高いからにょ。
剰余はポケコンには無くてこれがあれば便利という場面に出くわしたことは多々あるにょ。
とはいえ、剰余は実際は無くても何とかなるし使いまくれば処理が重くなるため速度を
もてあましているプチコンだからこそ気兼ねなく使うことができると思うにょ。
論理否定はmkIIから登場したものだけどこれを知っているのと知らないのとでは大きな
差になると思われるにょ。
IF文でもかなり有効活用できるからね。
とはいえ、BASICではあまり見慣れないので　X=X+!(4AND B)-!(8AND B)　で左右移動が
できるなんて分かる人は果たしてどれだけ居ることやら・・・。
もっとも、剰余を使えばこれが　X=X-(B%16-B%4+1)%3+1　になりさらにわかりにくくなって
いるけど剰余は多くのBASICに搭載されているため分かる人もそれなりに多そうにょ。

上記のプチコンのリスト短縮テクニックの中でやたらたくさん書いているような気がする
8方向移動や左右移動だけど左右移動に関するものだけを抜き出したらこれだけあったにょ。
（リストの長い順に記載）

《　IF文を使った基本形　》
IF (B AND 4)==4 THEN X=X-1
IF (B AND 8)==8 THEN X=X+1

X=X-((B AND 4)==4)+((B AND 8)==8)
X=X+((B AND 4)==0)-((B AND 8)==0)
X=X-SGN(4AND B)+SGN(8AND B)
X=X+!(256AND B)-!(512AND B)　（※LRボタン用）
X=X+SGN((8AND B)-(4AND B))
X=X-(4AND B)/4+(8AND B)/8
X=X-!!(4AND B)+!!(8AND B)
X=X+B%16/8-B%8/8*3+B%4/4
X=X-(B%1024-B%256+1)%3+1　　（※LRボタン用）
X=X+!(4AND B)-!(8AND B)
X=X-((B AND 12)+1)%3+1
X=X+112%(B%16-B%4+3)-1
X=X-(0OR B/256+1)%3+1　（※LRボタン専用）
X=X-(B%16-B%4+1)%3+1
X=X-(B==4)+(B==8)　（※左右移動以外不可）
X=X-!(B-4)+!(B-8)　（※左右移動以外不可）
X=X-(B+1)%3+1　（※左右移動以外不可）

　《　参考　》　同時入力におけるプチコンのボタン入力判定方法
　http://ww5.tiki.ne.jp/~ochame/petitcom/p002.htm#button

これをすべて覚える必要なんて無いけど「左右移動」という単純なものでさえ工夫できる
余地がいくらでもあるということが分かってもらえたらいいにょ。
それを考えると1画面プログラムといってもバカにならないことが分かると思うにょ。
1画面プログラムを作る場合にはこういったリスト短縮方法をいかにたくさん知っていて
それを使い分けられるかが重要になってくるけど今回私がよく使っているようなものを
分かりやすく書いていったのでこれでかなり1画面プログラムは作りやすくなるのではないか
と思うにょ。
これによって1画面プログラムに興味を持つ人が増えたら個人的にはうれしいにょ。