したらばTOP ■掲示板に戻る■ 全部 1-100 最新50 | |
レス数が1スレッドの最大レス数(1000件)を超えています。残念ながら投稿することができません。

おちゃめくらぶ掲示板

1：御茶目菜子：2009/09/12(土) 15:33:12
現在大阪オフ中にょ
現在大阪オフにょ。
昼食を12時に済ませ現在3時のおやつ休憩にょ。
昼ご飯を食べてから現在までいろいろ買い物をしたけどもう3万円くらい使っているにょ。
めぼしいものは大体買えたけどそろそろ資金が尽きるにょ。


マリモーマさんへ
＞今日は　大阪オフだけど　関西は　雨が降ってたよ

さっきは結構降っていたにょ。
また詳しくは明日書くにょ。
908：?みっぴゅ?：2012/03/21(水) 19:33:59
プチコンmk?
初代のプチコン…結局あんまりやる気が起こらなかったんですけれど、お茶目さんのmk?を読んでたらなんだか欲しくなってきました。
近い内に購入してみようと思います。
でも、、、ちょっと触れて遊んでみる程度ですけれどね！

909：御茶目菜子：2012/03/22(木) 16:20:19
レスにょ
みっぴゅさんへ
＞初代のプチコン…結局あんまりやる気が起こらなかったんですけれど、お茶目さんのmk?を＞読んでたらなんだか欲しくなってきました。

やっぱり、QRコード＆SDカード対応は非常に大きいにょ。
自分で作ったプログラムをネットで簡単に公開できるようになったし、他人が作った
プログラムを簡単に利用可能になったからね。（ポケコンで例えるならばばオプション機器が
不要で標準機能のみでPCと繋がってプログラムのデータはやりとり可能になるレベルのもの）
著しく制限が大きかった初代プチコンとは比較にならない快適さにょ。
それにSDカードに書き出したプログラムリストはテキストエディタで読めるので機種依存
文字を使用していなければリストをネットで公開するのも簡単にょ。

＞でも、、、ちょっと触れて遊んでみる程度ですけれどね！

すでに私が確認しているだけでもmkII対応のプログラムは100本以上発表されているので
それを使ったり（遊んだり）改造してみるだけも元が取れると思うにょ。
そういうニーズを見込んでかBASICの知識が全くない人でも簡単に使える実行専用の
簡易ランチャーも標準装備になっているくらいにょ。

910：御茶目菜子：2012/03/22(木) 16:22:38
ニコンD800はただの高画素番長ではない！？
ニコンD800のレビューが行われているので見てみることにするにょ。
http://dc.watch.impress.co.jp/docs/review/newproduct/20120319_519454.html
ニコンD800は35mmフルサイズセンサーを搭載の機種を最も多い3630万画素という画素数の
デジカメにょ。
「高画素＝高画質」とは限らないばかりか、昨今においては特にコンデジにおいては
高画素化の弊害が目立ってきているため画素数にあまり意味はないという考えの人も多い
のではないかと思うにょ。
確かに一般的な1/2.3インチセンサーを搭載したコンデジにおいては1000万画素以上の
高画素は「ほぼ無意味」といっても過言ではないと私も思っているにょ。
それはレンズがその画素数で解像できるレベルに達してないこともあり、解像感がなく
単にファイルサイズが大きな画像になっているからにょ。
それに昨今は高画素の極小センサーでも低ノイズ化が可能になっているけどこれは
センサー性能だけではなく画像処理エンジンのノイズリダクションが上手く働いている
からにょ。
しかし、「低ノイズ＝ノイズがないキレイな写真」という認識を持っている人が多いためか
メーカー側もディティールを損ねてもノイズが少なくなるような絵作りをしているにょ。
したがって、最新の1600〜1800万画素のコンデジは最低感度の写真においてでさえ等倍では
見るに耐えないレベルになっているものばかりにょ。

コンデジではこのように高画素化が高画質に繋がってないのは明白であるためでD800で
3630万画素の高画素では画質に期待できないという人も多いにょ。
しかし、これはAPS-Cでは約1400万画素相当であり、1/2.3インチセンサーでは180万画素
相当であり、「高画素すぎる」と単純には言えないにょ。
何せ1/2.3インチ1600万画素の画素ピッチでフルサイズセンサーを作れば5億画素になって
しまうわけだから、それと比べると1桁低画素と言えなくはないにょ。
確かに画素ピッチが縮まる分だけよりレンズ性能に高いレベルのものが求められてくる
けれど4.88μmという画素ピッチはAPS-Cで1800万画素を実現しているEOS7Dなどよりは広い
ためにカメラを買うようなユーザー層であればハードルが高いものではないと思うにょ。

やはり、机上の空論ではなく実際の撮影されたものを見て判断する必要があるにょ。
http://dc.watch.impress.co.jp/img/dcw/docs/519/454/030.jpg
低感度（ISO100）での写真を見るとこのカメラのポテンシャルの高さが分かるにょ。
画素ピッチが狭いといくら低感度でもノイズリダクションによってディティール損失が多く
等倍ではかなり厳しい場合もあるけどこの画素数であっても等倍で十分に見れるレベルに
なっているわけだからね。
これは高性能な単焦点ではなくズームレンズでこのレベルの写真を撮ることが可能である
ためにそこまで無駄に画素数が多いというわけではないにょ。
先ほどのようにAPS-C換算で画素数を考えてみればこれは当然のことにょ。
古い設計のレンズや安物のズームだとAPS-C1000万画素でも解像しないことがあるけれど
一定以上の解像力のあるレンズであればAPS-Cで1400〜1600万画素ならば十分に解像が可能
だからね。
このローパスフィルタがあるD800でこのクオリティならばローパスフィルタの効果を無効化
したD800Eならばどれだけすごいのかということも感じてしまうにょ。
画素数がさらに1000万画素多くセンサーサイズも大きいPETAX645Dと比べるとやや劣るかも
しれないけどライバルはフルサイズではなく中判というのはすごいにょ。

NEX-7が（十分な解像力と組み合わせた場合）APS-Cで最も解像力が高いのだけどフルサイズ
であればD800ということで十分な画素ピッチを備えているならば画素数が高ければ高いほど
解像感において有利になるにょ。
ただ、十分な画素ピッチがどこにあるのかということにょ。
D800の画素ピッチは4.88μmということはF8を超えたあたりから徐々に回折の影響が出始めて
しまうにょ。
目立ってくるのはF11あたりからだろうけどそうなるとF8付近で十分な解像力のあるレンズが
求められてくるにょ。
回折の影響が目立ち始めると思われるF11が使えるか否かは個人の判断にゆだねられるけど
F11で撮影されたこの写真を見る限りでは「使えないレベル」ではないにょ。
http://dc.watch.impress.co.jp/img/dcw/docs/519/454/055.jpg
低画素では回折が起きないのではなく画素数が少ないため回折の影響が目に見えないという
だけであり、高画素だと単にそれが目で分かるから駄目と感じてしまうというだけの話にょ。
コンデジの場合は一部の機種を除き明るい広角側でさえ絞り開放から回折限界を超えており
暗い望遠側ではそれを2〜3段超えているためぼけ気味の写真しか撮れないにょ。（それでも
デジタルズームを使うことを考えれば光学ズームの方が解像感では勝るけど）

D800の低感度は「画素数が多いだけあってすごい」と言えたのだけど問題は高感度にょ。
D700と比べて3倍の画素数ということは単純に考えると1画素の面積は1/3になるわけであり
さらに単純に考えるとD700と比べて1.5段分高感度画質では不利になるにょ。
センサー性能や画像処理エンジン性能の向上といった技術革新によってISO6400が常用できる
レベルであったD700に迫れるものになっているかは作例から判断することにするにょ。

　◎ノイズリダクション強
　ISO1600　http://dc.watch.impress.co.jp/img/dcw/docs/519/454/041.jpg
　ISO3200　http://dc.watch.impress.co.jp/img/dcw/docs/519/454/042.jpg
　ISO6400　http://dc.watch.impress.co.jp/img/dcw/docs/519/454/043.jpg
　ISO12800 http://dc.watch.impress.co.jp/img/dcw/docs/519/454/044.jpg
　ISO25600 http://dc.watch.impress.co.jp/img/dcw/docs/519/454/045.jpg
　◎ノイズリダクション標準
　ISO1600　http://dc.watch.impress.co.jp/img/dcw/docs/519/454/051.jpg
　ISO3200　http://dc.watch.impress.co.jp/img/dcw/docs/519/454/052.jpg
　ISO6400　http://dc.watch.impress.co.jp/img/dcw/docs/519/454/053.jpg
　ISO12800 http://dc.watch.impress.co.jp/img/dcw/docs/519/454/054.jpg
　ISO25600 http://dc.watch.impress.co.jp/img/dcw/docs/519/454/055.jpg
　◎ノイズリダクション弱
　ISO1600　http://dc.watch.impress.co.jp/img/dcw/docs/519/454/061.jpg
　ISO3200　http://dc.watch.impress.co.jp/img/dcw/docs/519/454/062.jpg
　ISO6400　http://dc.watch.impress.co.jp/img/dcw/docs/519/454/063.jpg
　ISO12800 http://dc.watch.impress.co.jp/img/dcw/docs/519/454/064.jpg
　ISO25600 http://dc.watch.impress.co.jp/img/dcw/docs/519/454/065.jpg

ノイズリダクション標準を見るとややディティール損失があるとはいえISO1600は全く
問題ないレベルにょ。
ISO3200ではノイズが目立ち始めており、このあたりが実用レベルぎりぎりに感じるにょ。
ISO6400も縮小すれば十分使えるにょ。
ISO12800やISO25600はかなりノイズがあり、常用は難しいレベルにょ。
ノイズリダクション強にすればディティール損失が大きくなるもののISO6400も実用レベルに
なってくるにょ。
こうしてみると最新APS-Cセンサーと同レベルの高感度画質といえるにょ。
3年半の期間が経過しているとはいえD700と同レベルに到達しているとは思えないにょ。
ただし、これは等倍鑑賞をした場合の話にょ。
同じピクセル数に縮小して比較した場合は、縮小時にはノイズやディティール損失が目立ち
にくくなるため「D800は事実上高感度画質でD700を超えている」と言えるかもしれないにょ。

高感度においては高感度番長ともいえる低画素機を超えるレベルに達しており、低画質では
ライバルはフルサイズには存在せず中判センサーに迫るものになっているD800は機動性と
画質を求める人ならば最も良い選択肢になるのではないかと思われるにょ。
30万円という価格は安くはないけど性能を考えれば十分にお買い得感があるにょ。
そうなると問題はライバルであるキヤノンにょ。
製品の位置づけからすると5D MarkIIIはD800/D800Eと比較されることが多いけど実写比較
ではかなり不利な立場に立たされたと言えるかもしれないにょ。

911：orirakkusu：2012/03/23(金) 14:23:27
相互リンク
はじめましてにゃ。
元々はプチコンまとめwiki(http://wiki.hosiken.jp/petc/)から来た者にゃ。
そこでこのサイトへリンクを貼ろうと思ったのにゃ。
僕のサイトはhttp://www.geocoties.jp/orirakkusu/にゃ。
リンクを貼ってくれると嬉しいにゃ。

http://www.geocities.jp/orirakkusu/

912：御茶目菜子：2012/03/23(金) 15:32:57
レスにょ
orirakkusuさんへ
＞はじめましてにゃ。

はじめましたにょ。

＞そこでこのサイトへリンクを貼ろうと思ったのにゃ。
＞僕のサイトはhttp://www.geocoties.jp/orirakkusu/にゃ。
＞リンクを貼ってくれると嬉しいにゃ。

相互リンクは歓迎にょ。
ただし、相互リンク希望は何件もあるけどリンクページを全然更新してないからそろそろ
たまった分を更新しないといけないにょ。

913：orirakkusu：2012/03/23(金) 15:44:05
訂正
訂正にゃ。
本文内の
geocoties
　　↓
geocities
にゃ。
申し訳ございませんでしたにゃ。

http://www.geocities.jp/orirakkusu/

914：?みっぴゅ?：2012/03/23(金) 20:17:12
事後報告。。。
おちゃめさんが一生懸命に作成されました、｢は〜るがきぃた｣ですが、YouTube〔 http://www.youtube.com/watch?v=pYgJ7GjTK6w&sns=em 〕とﾆｺ動に載せました。
ＵＴＡＵとか某カロイド！？みたいな事が出来て羨ましかったんです！

動画サイトで何人かの作品を試聴していたのですが、あの声の特徴をうまく活かして使用されていたものもありましたよ。
でも、大抵の人はとりあえず唄わせただけでした...
それでも、BASICで歌わせることが出来るなんて凄いことですよね！

早く購入して試してみたいです。
でも、でも、どうしても待てなくて、おちゃめさんの作品を使って遊んじゃいました。
テンポや音程を変えたりしてみたんですが、あの歌声はかなりツワモノですね！
美しい歌声でってのはムリなんでしょうかねぇ。。。

http://www.youtube.com/watch?v=pYgJ7GjTK6w&sns=em

915：orirakkusu：2012/03/24(土) 11:33:40
相互リンクのこと
リンクしていただきありがとうございます！
これからもよろしくお願い致します。

http://www.geocities.jp/orirakkusu/

916：御茶目菜子：2012/03/24(土) 15:08:43
ここもいつかは無くなる時がくるだろうけど・・・
相互リンク希望がたまっていたのでリンクページの整理をしたにょ。（リンクの追加は
5年ぶりだけど整理をしたのは恐らくおちゃめくらぶ開設以来初めてかも）
ほとんど消えているサイトばかり・・・。
移転先が分かったものは移転先のURLも記載しているけどそうでないものはリンクから削除
したにょ。
それと相互リンク希望の人もまだリンクに登録する前にすでに消えているというのも数件
あったにょ。
確かに自サイトを「作ること」より「続けること」の方が何倍も大変だから分からなくもない
けれどね。

おちゃめくらぶは13年前と何も変わってないことを見ても続けることが成長に繋がっている
というわけではないにょ（笑）
今時JavaScriptもCSSも使ってないサイトだからね。
それに13年前と変わらないこのTeaCup掲示板が逆にレトロな雰囲気に・・・なるわけないか。
一時は移転も考えたけど移転する理由もない（あるとすれば容量制限が厳しいことだけど）
わけだし、移転してまたそこから再出発する手間を考えたらメリットよりもデメリットの
方が大きいにょ。（閲覧する側も検索エンジンで見つかって404だとショックだろうし）
続けるためにはある程度楽をしないと駄目にょ。
「楽＝手抜き」ではなく「自分が面倒」と感じることをしないということにょ。
まぁ趣味なんだから好きにやればいいけどね。



orirakkusuさんへ
＞リンクしていただきありがとうございます！
＞これからもよろしくお願い致します。

いえいえ、こちらこそよろしくにょ。
サイト名が書いてなかったので「orirakkusuさんのホームページ」としたのだけどサイト
名があるのならば修正するので知らせてにょ。


みっぴゅさんへ
＞おちゃめさんが一生懸命に作成されました、｢は〜るがきぃた｣ですが、YouTube〔 http://www.youtube.com/watch?v=pYgJ7GjTK6w&sns=em 〕とﾆｺ動に載せました。

適当に使ってもらって結構にょ。
ただ、リアルタイムに歌詞を読み取って歌っているから「おおっ」となるわけであって、
その音声ファイルだけを聞いても全然つまらないにょ（TALKを使わずにプチコンで音声を
再生しているのならばそれだけでもすごいけど）
下記のように手間暇書けてじっくり手動で補正をした方がキレイに歌ってくれるのに
対してOSPは「超お手軽にそこそこ歌える」というのがウリだしね。

＞でも、大抵の人はとりあえず唄わせただけでした...
＞それでも、BASICで歌わせることが出来るなんて凄いことですよね！

「BASICでしゃべらせる」というだけならば30年前からできていたことにょ。（音声合成
LSIの搭載の機種ならば）
とはいえ、しゃべるだけであって歌わせるとなるとソフトウェアの制御が必要になって
くるため30年前の性能では厳しくて30年前のパソコンのマシン語並の処理速度を持つ
プチコンだからこそBASICで実現可能になっているにょ。
TALK命令があるのでTALK "ドレミ"でドレミと発声させることは誰でも簡単にできるけど
歌わせるとなると音程と音長もちゃんと変えてやらないといけないので結構たいへんにょ。
例えばテンポ120で「ドーレーミー♪」と歌わせるためには下記のようにする必要がある
からね。

TALK "@E16@N1447@T159ドー@N1559@T211レー@N1686@T217ミー"

高さであるNの値は説明書に記されているからその値を指定すればいいだけなんだけど
速度に相当するTの値ははストップウオッチを使って実測で求めるしかないにょ。（発音
する言葉によって同じ指定値でも実際の発話時間が異なるため）
上記のTの値はストップウオッチを使って各音がちょうど0.5秒になるようにしたものにょ。
実際は音符1つ1つでここまでやるのは無理なのである程度しゃべらせてWAITやVSYNCで時間
補正というやり方を取っている人が多いにょ。
ただし、こうやって1つずつパラメータ指定するのは非常に大変だし、後から全体の速度を
変えたいという場合はすべてのパラメータを書き直す必要があるにょ。

そこで1つ1つパラメータのセットする必要がないOSPを考えたにょ。
MMLデータを読み取ることで自動的にその高さと長さの声が出るようにしたものという
わけにょ。（同日にsou51さんが「プチコロイド」を発表したので同じことを考えている
人はやっぱり少なくないということかも）
これによって誰でも簡単に歌わせることが可能になると思うにょ。

＞美しい歌声でってのはムリなんでしょうかねぇ。。。

声質は11通り選べるので自分の好みに変えるといいにょ。
11番の声は結構いい声（ニコ動の動画では「ナンジグライダー」に使われている声）だけど
滑舌があまりよくないので早い歌には対応できないため万能であるデフォの声を使って
いるにょ。（デフォの声を使えばリストを4文字分節約できるし）

それとOSPをさらに改良したOSP2も作ったにょ。
現在公開するための準備中なので楽しみにしておいてにょ。
よりスムーズにより正確に歌えるようになり、さらにOMP以外とも自由に組み合わせて
使えるようになっているにょ。（みっぴゅさんが作ったMMLを使って歌わせることも
可能）
それで（OSP2とOMPのリストを合わせて）たったの1画面という短さにょ。

あとずいぶん遅れたけどみっぴゅさんのサイトをリンクに登録したにょ。
相互リンクを待っているにょ（笑）

917：orirakkusu：2012/03/24(土) 18:11:50
サイトの事
javascriptは僕のサイトも今時トップのお遊びピンポンにしか使ってないですからねぇ。
cssなんかもうわからん！
んー、でも、シンプルなのもいいんですよねー。その方が多くの人に見てもらえるし。
あと、サイト名は、orirakkusuのなんとかかんとかです。
お願い致します。

http://www.geocities.jp/orirakkusu/

918：みっぴゅ：2012/03/24(土) 18:47:40
相互リンク
リンクをどうもありがとうございます。さっそく、こちらからもリンクをさせて頂きました。
ホントに驚きと感謝でいっぱいです！
過去にブログにも書きましたが、いつかは御茶目さんとリンクをすることが夢でしたから！

しかしながら、あのホムペ、内容が無いよう。。。
焦り焦り orz...



あ、｢はじめまして｣の方もいらっしゃるかもしれないので、軽く挨拶を…

わたくし、ﾐｯﾋﾟｭといいます。
PC-E500を買って貰ったと同時にＰＪも買ってくれまして、それからはバックナンバーを含めてＰＪ全巻購入してしまったという者です。
突然PJが休刊になっての淋しい毎日。
そんな時に出会ったのが、御茶目さんのこのサイト。
今でもＰＪを講読している気持ちで読ませていただいております。

ちょっと長くなってしまいましたね…

皆様、今後ともよろしくお願いいたします。2012

919：マリモーマ：2012/03/24(土) 23:00:19
リンク確認したよ
リンクが訂正されてたね　お疲れ様
最近は　忙しくて向こうの掲示板に何も書いてないけど
時間が出来たら　復活するかも

http://liv0.com

920：orirakkusu：2012/03/25(日) 15:47:48
プチコンのこと
ふと今思い出記録帳を見たら初代プチコン(12/25~3/14)とmkll(3/14~)を合わせたプレイ時間176:32！ちとびっくりしたにゃ(笑)そのくらいプチコンが好きってことにゃ(1位はインターネットブラウザー。200台)。好きじゃない物はこんなにやらないもんね！12/25は説明書とコンソールを行き来してたのが、今はさささのさっだもんにゃー。そのくらい上達したってことにゃ！

http://www.geocities.jp/orirakkusu/

921：御茶目菜子：2012/03/25(日) 16:15:58
レスにょ
orirakkusuさんへ
＞んー、でも、シンプルなのもいいんですよねー。その方が多くの人に見てもらえるし。

ものは考えようにょ。
シンプルだからケータイやDSのブラウザでもみれるしね（笑）

＞あと、サイト名は、orirakkusuのなんとかかんとかです。
＞お願い致します。

了解にょ。
早速サイト名を変更しておいたにょ。

＞ふと今思い出記録帳を見たら初代プチコン(12/25~3/14)とmkll(3/14~)を合わせたプレイ時間176:32！ちとびっくりしたにゃ(笑)

私は合わせて200時間くらいだったにょ。（初代は10月末に購入）
やっぱり、使わないと上達しないにょ。


みっぴゅさんへ
＞リンクをどうもありがとうございます。さっそく、こちらからもリンクをさせて頂きました。
＞ホントに驚きと感謝でいっぱいです！

こちらこそ、相互リンクどうもにょ。

＞過去にブログにも書きましたが、いつかは御茶目さんとリンクをすることが夢でしたから！

こんな些細なことを夢にしてもらえるとは光栄にょ。
次はもっと大きな夢に変えないといけないにょ。

＞しかしながら、あのホムペ、内容が無いよう。。。
＞焦り焦り orz...

マイペースでやればいいと思うにょ。
私の場合は「日本一のポケコンサイトにする」という野望と制作予定だった本である
「E500BASICのすべて」が個人的都合で発行が難しくなったのでWebで少しずつ公開
という形をとったためにょ。
年数はかかったものの本で書きたかったことの大半は書けたと思うにょ。


マリモーマさんへ
＞リンクが訂正されてたね　お疲れ様

移転してからリンク変更しないといけないと分かっていたけどずっと放置状態だったにょ。

922：御茶目菜子：2012/03/25(日) 16:17:06
プチコン用棒歌ロイド「OSP」が2にバージョンアップ！
1週間前に公開したプチコンで歌わせることができるプログラム（棒歌ロイド）「OSP」
だけど早くも「OSP2」にバージョンアップしたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#osp
http://youtu.be/amhVzkigxTM
というか、これがようやく完成品といった感じで前作は試作品といった感じにょ。
というのも、プチコンmkIIが配信された当初からプチコンで歌わせる動画を公開して
いる人が居たのだけどパラメータを手動セットしていくというのは非常に手間がかかる
ために、その手間を無くすという考えの人が必ずいると思ったからにょ。
ポケコンではBEEP 1,222,262でドの音を1秒間出すことができるけどそれを手動で並べて
曲を作るということはさすがにできないということで、自作MMLを作ったにょ。
それと同じく初代プチコンでもBEEPで曲を演奏する際に1つの音ごとにパラメータを
手動セットしていくのは非常に大変なのでMML演奏プログラムを作った人は多数現れた
からね。

私は、プチコンを入手したのは3DSを買ってからであり、その3DSを買ったのも私が欲しい
ピンクが発売されてからだったのでかなり出遅れたにょ。
しかし、mkIIでは比較的早い段階でプチコンを入手したので一番乗りに拘ったにょ。
その結果として、プチコンで自動的に歌わせるプログラムとしては何とか一番乗りはできた
もののOSPは開発速度を優先したためにやろうと思ったことが十分にできたとは言い難い
ものだったにょ。
プログラムを「ソースコードが見える形」で発表する以上は自分の中で想定する最低限の
クオリティに満たないものは発表は躊躇してしまうところだけど何とかそれにギリギリ
達したというレベルであり、「これ以上のものは作れない」というレベルには全く達して
無かったにょ。
特にテスト用に選んだ「春が来た」を何度も聞けば聞くほど不満点がどんどん見つかって
しまいそれを解消するものを作りたいと感じていたにょ。

ちなみになぜ「春が来た」なのかは「知名度が高い」「著作権切れである」「曲が短い」
「音符の種類が多い」「途中に休符を挟んでいる」などの理由があるにょ。
最初の2つは説明不要だと思うけどあとのものについて理由を書くと「曲が短い」という
のは何度も繰り返して聴けるためあら探しをしやすいということにょ。
「音符の種類」というのは八分音符、四分音符、付点四分音符、付点二分音符の4種類の
音符が短い曲の中に含まれているということにょ。
これによって各音符の長さがちゃんと出ているのかが分かるにょ。
「途中に休符を挟んでいる」というのも休符がちゃんと表現できているかの判断材料に
なるので有用にょ。
ということで、ここ1週間で少なくとも数100回は「春が来た」を聴いており、恐らくこの
期間内では「世界で最もたくさん『春が来た』を聴いた人」かもしれないにょ（笑）

ということで、このOSP2はどのようなものかというと改善点は下記の2つにょ。

　(1)自由度が高くなった
　(2)より正確に歌えるようになった

(1)具体的に言うと前作のOSPでは開発速度を優先したためにOMPでの使用が前提になって
いたけれど今回は好きなMML演奏プログラムと組み合わせて使用できるということにょ。
OMPは私にとっては使いやすいプログラムだけど多くの人にとっては使いやすいとは言い
難いものだろうからね。
OSPは「お手軽である」ということが最大のウリなんだけどOMP前提にしてしまうとその
ウリがどうしても弱くなってしまうにょ。
やはり、自分が使い慣れたものを使いたいということにょ。
確かにOSPもBASICの知識がそれなりにあれば他のプログラムでも活用できるけどそれだと
利用者のハードルを高めてしまう（OMPの仕組みを知っている人しか利用できない）ため
誰でも利用できるようなレベルではないにょ。
したがって、OSP2はサブルーチンとして機能を独立させてAPPEND命令で適当なMML演奏
プログラムと結合して、「GOSUB @OSP」とするだけで活用できるレベルにしてあるにょ。

といっても、現実的にはそれだけでは無理でOSP2で使用している変数に値を受け継ぐ
必要があるにょ。
そのため一般的なMML演奏プログラムで利用しているであろう値から変換せずにすむような
ものにしているにょ。
OMPはテンポ指定が特殊（OMPのテンポ8が一般的なMMLのテンポ120に相当する）なんだけど
これは曲のデータを少しでも減らしたいためよく使うであろうテンポ指定値を1桁にした
かったというのが理由にょ。（それだと微調整ができないためどうしても微調整をしたい
という人のために小数でもテンポ指定できるようにした）
そして、「テンポ指定1で音長1ならば1秒鳴る」というのは非常に明確で分かりやすいからね。
例えばテンポ72でで16分音符は何秒間鳴るのかというのは瞬時に答えられる人はまずいない
からね。（その点OMPは「音長/テンポ」であるため瞬時に答えられる）
それに音長指定もOMPは数字に比例した長さで鳴った方が分かりやすいというのと（データを
少なくするため1桁でしか指定できないということもあり）1桁だと指定値に比例する長さで
鳴らした方が分かりやすいというのとさらに単純に除算よりも乗算の方が演算が速いから
というのが理由にょ。

つまり、OMPはプログラム、データともに限界まで短くなっており、数字の計算が分かり
やすく、処理速度も限界まで速くなっているため音質の面で有利（処理速度の遅い
ポケコンだと時間がかかる処理を行えば音がブツ切れ状態になる）というわけで個人的に
非常に気に入っているもののやはりそのせいで一般的なMMLとは大きく異なっているにょ。
したがって、それを基準に作ったOSPでは一般的なMML演奏プログラムからは数値の変換が
必要不可欠となってしまうにょ。
しかし、OSP2ではプチコンのBEEP命令を使うMML演奏プログラムではほぼ数値の変換が
ほぼ不要になっているにょ。（多くの場合はMML演奏プログラムに使っている変数名に
変えてやるだけで他は何も変更しなくても動作する）
その代わりOMPで使用する場合には逆に変換が必要になるためOSP2ではプログラムのサイズや
処理速度面では不利になっているにょ。
それでも、OSP2はOMPと組み合わせた場合に1画面で収まっているにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/image/osp_omp.jpg

ちなみに上記のような自分が使っているMML変換プログラムへの組み込み方はこの「プチコン
MML with OSP2」を見れば誰でも簡単に分かると思うにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/osp_mml.htm
プチコンMMLはOMPと比べるとかなり一般的なMMLに近いものになっているためこちらならば
「OMPだと使いづらい」という一般MMLに慣れた人ならば有利になると思うにょ。（逆に
MMLなんて使ったことがなぃ「A→ラ」というのも瞬時に分からないレベルだとOMPの方が
分かりやすいと思う）
OSP2を組み込んだ「OMP with OSP」が使いづらいという人はこの「プチコンMML with OSP2」を
使えばいいし、普段使っているMML演奏プログラムが使いたいという人であればこの組み込み
方を参考にすれば簡単に自分が使っているMML演奏プログラムで使用できるようになるにょ。
ラベル@OSPの次の行にあるK=LEN(K$)というのは本来ならは最初に1回計算したら済むこと
なのでループ外に置くことが望ましいのだけど誰でも使えるようにするため1つでも手順を
減らすため涙をのんで@OSPのサブルーチン内に置くことにしたにょ。
これが無ければOSP2はOSPと同じ6行で済んだわけだしね。

上記のOMPやプチコンMMLもしくは自分が使っているMML演奏プログラムで曲を鳴らすのでは
なくBGMPLAYを使った曲に合わせて歌わせたいという人も当然出てくると思うにょ。
それもやり方は非常に簡単にょ。
それはこのMML演奏プログラム内にあるBEEPを消すかコメントアウトすればいいだけのこと
だからね。
要するに伴奏用ではなく単なるOSPの制御用としてMML演奏プログラムを用いるということにょ。
ただし、音ずれのないMML演奏プログラムを用いて音ずれのないMMLデータ（VSYNCによる
ウェイト指定が小数にならないようなデータ）ならば問題なく使用できるのだけどそうでない
場合はBGMPLAYとBEEPによるMML演奏プログラムは非同期であるため音ずれを起こしてしまう
可能性があるにょ。
音ずれのないMML演奏プログラムとデータを用いた場合でもTALK命令のタイムラグの関係上
完璧に合わせるというのは難しい（徐々にずれていくということが軽減されるというだけ）
ためにBGMPLAYによるMMLの最初に32分休符〜8分休符くらいの短い休符を入れてそのタイム
ラグを吸収しておく必要があるにょ。
そうすることで、BGMPLAYに合わせて問題なく歌わせることができるようになるにょ。
一見すると大変なようだけどMMLをちゃんと打ち込んでやれば後から全体の速度を変える
ということは簡単にできてしまうため1つ1つを手動セットしなければならないものと
比べると格段に楽になっているにょ。

(2)OSPでは誰でも簡単にそこそこ歌わせることができるのだけどキレイに歌わせるのは
逆に難しいにょ。
キレイに歌わせるならば1音1音ちゃんと微調整しながらパラメータセットするのが一番に
決まっているからね。
しかし、そんな原始的なことはとても私には耐えられないにょ。
そこで、お手軽にそこそこちゃんと歌ってくれるOSPを作ることにしたにょ。
なぜ1音ずつパラメータセットした方が良いのかというとそれは1音ずつ分けてTALK命令で
発声させるよりも1つのフレーズ単位でまとめて発声させる方がスムーズだからにょ。
それならば1音ずつ計算して発声は1つのフレーズ単位にすれば解決可能に思えるけどそう
いう単純なものではないにょ。
というのもTALK命令の速さとなるTの値が同じであっても発声する言葉で発声する時間が
異なるものになっているからにょ。

それならば各音がどれだけの時間発声するかを正確に測定して、それをデータとして用意
してそれを元にNの値を決定すれば良いだけに感じるかもしれないにょ。
発声する言葉によって発声する時間が異なるというのは「カ」と「バ」が異なるものに
なっているというだけではなく「バカ」と「カバ」さえも異なる時間になっているという
ことにょ。（厳密にいえば発声時間が異なるというよりも発声するまでのタイムラグが
異なるという感じだけどそのタイムラグを考慮してTALK命令を事前に実行しておくのは無理
であり、タイムラグを考慮した発声時間で計算しなくてはならない）
つまり、すべての言葉に対してあらかじめ発声する時間をデータとして持つ必要があるけど
そんなことは不可能にょ。
確かに「カバ」と「バカ」だとほんの数フレームの時間差であるためたいしたことはない
と思うかもしれないけど1フレーム単位の音ずれさえも気にっているという状況下において
たったの2音で数フレームのずれが出てしまうというのは非常に辛いにょ。（Tの値が
1000だと30フレームくらいの時間差になっている）
つまり、フレーズ単位で発声させることは可能だけど発声させる文字数が多くなれば多く
なるほど誤差が大きくなるにょ。（逆に誤差が相殺されるという可能性もあるけど）
そのため手動での調整は不可欠にょ。
したがって、自動的に歌わせるためにはフレーズ単位ではなく1音単位で発声させる
必要があるにょ。

1音単位であっても上記のように発声する言葉によって発生時間が異なるにょ。
1音が数フレームであってもテンポがゆっくりの場合にはそれが数倍〜10倍に拡大されて
しまう（←OSP1ではTの値のみで調整していたためこれが問題点となったけど1音ずつ
VSYNCで誤差を吸収していたから何とか聴けるレベルになっていた）わけだし、1音に複数の
言葉が入っている場合にも誤差が拡大していくにょ。
ただし、1音単位だと（ちゃんと正確なウエイトになっていれば）VSYNCによって1音ごとに
誤差を吸収できるため曲の後の方になればなるほどずれていくという心配はほとんど
無くなるにょ。（mkIIのVSYNCは仕様変更がなされたため従来ではMAINCTLを使わないと
できなかった正確なタイミングを取ることが可能になっているためTALK命令が追従できない
レベルの速いテンポで演奏しない限りは問題ない）

1音ずつ発声させれば（自動的に歌わせる場合に）フレーズ単位での発声と比べて音ずれが
無くなるというだけであってキレイになるというわけではないにょ。
それは原理上1音ずつ発声させた場合には音がどうしてもブツ切れ状態になってしまう
からにょ。
例えるならばポケコンのBASICでBEEP音による音階演奏をさせるようなものにょ。
そのブツ切れのような感じをいかに軽減させるかということがキレイに歌わせるか否かに
繋がってくるにょ。
ポケコンBASICの場合はやはりその処理速度がネックとなっていたにょ。
そのためBASICでは最も高速なMMLであるOMPはかなり有用だったにょ。
プチコンはその100倍以上速いため速度に関しては問題なさそうだけどそれでも可能な限り
処理そのものは軽い方がいいにょ。

それだけではなくいかに正確な長さの音符や休符が出せるかということがキレイに聞こえる
ためには必要不可欠になってくるにょ。
例えばテンポ120で2分音符を鳴らせば1秒になるのだけどこれが長かったり短かったり
すればキレイには聞こえなくなってしまうにょ。
これがどのようなものかはOSP2で実験してみれば一目瞭然にょ。
OSP2のリスト内にある185000という値を大きくすれば1音あたりの発声する時間が長くなり
小さくすれば短くなるのだけどはっきり分かるためには2倍、もしくは半分くらいにすると
いいにょ。
当然短くすればブツ切りが明確になってくる（テンポを遅くすればさらに分かりやすい）
のだけど長くした場合はそうならないため問題はないという人はいるかもしれないにょ。
「春が来た」の場合は最初の小節の中では「ル」や「ガ」は比較的発声までのタイムラグが
長目なので「ハールガキーター」が「ハー、ル、ガキーター」となってしまいスムーズさが
無くなっていることが分かると思うにょ。

それだけではなく音符より長目の時間だけ発声してしまうと休符が出せないという問題が
あるにょ。
「春が来た」では前半と後半の境目（「山にきた」の直前）に四分休符があるけどこれが
正確な長さ発声できないと休符が無くなってしまうにょ。
TALK命令はBEEPと異なり重ねて鳴らすことができないため休符を含まない場合は次の音が
鳴ると自動的に前の音が終了するにょ。
手作業でTALK命令を羅列して歌わせる場合にはすぐに次のTALK命令があるため実際に発声
されるのは最後のTALK命令だけになってしまうにょ。（したがって、WAITやVSYNCを用いて
適切なウエイトを入れておく必要がある）
1音ずつ自動的に発声するならば休符がない曲であれば多少のブツ切れ感を我慢すれば
問題ないけど休符がある場合にはそれが無くなるというだけではなく曲の最後の音が異様に
長い音になってしまうという問題もあるにょ。
TALK命令が重ねて発声できないというのを逆手にとってTALK " "をウエイトの後に入れれば
確かに発声しすぎは防ぐことができるにょ。
ただし、それはブツ切れ感をさらに増大させてしまうことになるにょ。

つまり、1音ずつ発声させるプログラムの場合は1音がどれだけ正確な長さ出せるかという
ことがキレイに歌えるかどうかの鍵になっていると思われるにょ。
この場合の「キレイ」というのは端的に言えば「いかにブツ切れ感を無くすか」という
ことにょ。
1音単位だとフレーズ単位と比べて誤差が小さくなる・・・と考えられるけどそれでも出す
音声によって2倍近く発声時間が異なるためこの誤差を軽減してやる必要があるにょ。
それに1つの音に1文字とは限らないためその文字数を考慮した補正が必要になってくるにょ。
その補正を行ったものがリスト中にある下記の式にょ。

　N=185000/T/Y/(LEN(N$)-4/Y)

これは各音が発声される時間をストップウオッチで測定してそれを元に最も誤差が少なく
なるような値にしたものにょ。
これによってほとんどの音において理論値との誤差は数％に収まっているにょ。
例えばテンポ15の二分音符で「ア」と発声した時は理論値が8秒だけどこのOSP2では8.2秒
となっており、誤差は2.5％に収まっているにょ。
曲の中でよく使われるであろう八分音符〜二分音符において最も誤差が少なくなるように
補正されているため16分音符ではそこまで補正しきれてないものの短い音符だと完璧な
補正をしてもTALK命令の発声タイムラグによるブツ切れ感の方が遙かに大きいため相対的
には問題は小さくなると思われるにょ。（音符が途中で切れるブツ切れ感は長い音符の方が
目立ってしまうため）
短い音符のブツ切れ感を無くすにはフレーズ単位での発声をするしかないのだけどそれが
上記のように自動化できない以上は処理を簡略化して速度を上げるしかないにょ。
その点、OSPは「これ以上ない」というシンプルな構成であるため1音単位で発声させる
自動歌唱プログラムではこれが限界ではないかと思われるにょ。
とはいえ、OSP2では他のMMLで利用しやすいように汎用性を高めているのでOSP1のように
OMPに特化すればそれが最も高速になるにょ。
OSP1にOSP2の発声アルゴリズムを入れただけのものとはいえ、OMPで問題ない人にとっては
これがベストな選択肢にょ。（テンポ240くらいでも結構追従できてるし）

OSPをさらに超えるためにはあらかじめすべての数値を計算しておいてTALK命令で出力
するデータを配列変数に格納するという方法もあるし、短い音符の正確さを求めるならば
各音の発音時間を記したデータを用意する（フレーズ単位ではないためそれほど難しくは
ない）
という方法もあるにょ。
いずれも実現するのはそれほど難しくはないとはいえ、苦労やプログラムサイズの増大の
割にはたいした効果を得られないのではないかと思われるにょ。
じっくり聞き比べてみればようやく分かる程度の違いでプログラムサイズが10倍以上とかに
なってしまうのは個人的には許容ができないにょ。
ただでさえ、OSP2も数バイトをいかに削るかでかなり考えたくらいだからね。
これより正確さを落とさずに処理を簡略化（リストを短く）したり、リストを長くせずに
補正を正確にするアルゴリズムが見つかれば話は別だけどここまで短いプログラムだと
これ以上の大幅改善はほぼ無理ではないかと思われるにょ。
リストが短くそれなりに使えるものになっていると思うのでぜひ皆さんのプログラムに
組み込んで使ってもらいたいにょ。

923：orirakkusu：2012/03/25(日) 18:08:43
Twitter
ツイッターの方もフォローしといたにゃ。よかったらフォローしてくれると嬉しいにゃ。

http://www.geocities.jp/orirakkusu/

924：orirakkusu：2012/03/26(月) 08:47:15
フォロー
フォローしてくれてありがとにゃ。

http://www.geocities.jp/orirakkusu/

925：御茶目菜子：2012/03/26(月) 15:20:25
レスにょ
orirakkusu
＞フォローしてくれてありがとにゃ。

どういたしましてにょ。
私はあまり呟かないけど夜間は大抵ログインしているので何かあればリプライをして
もらえたらいいにょ。

926：わぁぃ@：2012/03/26(月) 15:45:04
プチコンmkIIのスプライトサイズ変更の件
何で16×64が禁止なんだろう？
ついでに言うと16×128ができれば電車ゲームも楽に作れるのにな。

927：orirakkusu：2012/03/27(火) 10:24:36
荒しとかとか
ここって過去ログを見るからには
平和な掲示板みたいにゃ。
こんな穏やか〜にゃ掲示板が
僕は好きにゃ。
みんなはどうかにゃ？

http://www.geocities.jp/orirakkusu/

928：御茶目菜子：2012/03/27(火) 15:15:12
私のポケコンがお亡くなりに・・・
私の愛機であるポケコンPC-E650が液晶破損で亡くなったにょ。
このPC-E650はPC-E500の故障によって99年頃に購入したものだけどそれ以来結構ハードな
使い方をしても頑丈であり壊れなかったけど今回はたまたま打ち所が悪かったにょ。
10年前ならば普通に新品が買えていたポケコン（PC-E650）だけど今は生産終了しており
新品での入手は困難でヤフオクなどで中古を購入するしか入手の手段はないにょ。
確かに「ポケコンがないと困ること」はほとんどないし、最近はプチコンの方に
時間を費やしてばかりだったとはいえ、気が向いたらさっと作れる（モノクロの小さな
液晶であるため画面デザインをあまり考えずに作れる）のがポケコンの良さであり、
電卓代わりとしても優秀でバッテリ駆動時間も極めて長いということを考えるとプチコンで
ポケコンを完全に置き換えるのは無理にょ。
要するにポケコンにはポケコンの良さがあり、プチコンにはプチコンの良さがあるという
ことにょ。

さて、これからどうするか・・・。
ヤフオクで状態の良さそうな中古があればそれを入手するという方法もあるけど最近は
超金欠状態だし・・・。
それにしても、先月は録画用のノートPCのHDDクラッシュ、今月初めにはネット用のノート
PCの液晶破損と最近はトラブル続きにょ。
やはり、そろそろ部屋の中を片づけないと本当にやばいかも・・・（笑）
こんな状態では画面むき出しのスマホなんて買ったら1週間も経たずに壊れてしまいかねない
からね。（本来ならば昨年スマホに乗り換える予定だったけど予算面の問題とこの壊れる
危険性を考えて未だに6年前に買ったガラケーを使ってる）




わぁぃ@さんへ
＞何で16×64が禁止なんだろう？

言われて初めて気が付いたにょ。
私はmkIIを買ってからまともにスプライトを使ってなかったので8、16、32、64から
好きなサイズのスプライトが使えるものだとずっと思ってたにょ（笑）
まぁ1画面プログラムだったらデフォサイズ（16x16）以外のスプライトを使う機会は
ほとんどなさそうだけどね。

＞ついでに言うと16×128ができれば電車ゲームも楽に作れるのにな。

16x32のスプライトを4つ使うしかないにょ。
確かに1つで使えた方が楽だし、速度面でも有利なんだけどね。
ちなみに電車ゲームって「電車でGo！」みたいな運転シミュレーションゲームにょ？



orirakkusuさんへ
＞ここって過去ログを見るからには
＞平和な掲示板みたいにゃ。

ここも10年くらい前はBASIC論争で荒れたこともあったにょ。
あの頃は今とは別の意味で活気があったにょ。
ただし、ポケコン人気の低迷（90年代〜2000年代初頭は個人サイト立ち上げブームによって
どんどん新規ポケコンサイトができていったけど最近は閉鎖してしまったサイトが大半）に
よってこの掲示板への書き込み数は激減したにょ。
まぁ掲示板の閲覧数そのものは逆に昔より増えているはずなんだけどね（ポケコン以外の
話題によるものが大きいと思う）
最近はプチコンによって再びBASICに脚光が集まるようになったのが個人的には喜ばしい
限りにょ。

929：みっぴゅ：2012/03/27(火) 21:14:12
ま、、、まさかの…
ここまで来ての…ポケコン…卒業！？！？！？
最近はなにかと話題の卒業ブームですので、、、まさかまさかの！！！

いつかポケコン界に戻って来ることを心よりお待ちしております。。。2012

930：御茶目菜子：2012/03/28(水) 15:34:12
レスにょ
みっぴゅさんへ
＞ここまで来ての…ポケコン…卒業！？！？！？
＞最近はなにかと話題の卒業ブームですので、、、まさかまさかの！！！

卒業はせず、しばらく留年（？）するにょ。

ポケコンは無くても困らないとはいえ、あれば非常に便利なものなので予算面の都合が
付けば多少割高でもヤフオクなどを使って入手するにょ。
PC-E650はプログラム機能のある計算機として非常に優秀だからね。
繰り返し計算ならばExcelなどを使っても作れるけど複雑な条件設定の計算だと慣れた
ポケコンの方が圧倒的に早く作れてしまうし、E500シリーズはBTEXT$によってセーブや
ロードを使わずに複数のプログラムをワンタッチで使えるところが非常に使い勝手が
いいにょ。

931：御茶目菜子：2012/03/29(木) 15:21:33
棒歌ロイドキーボードを作ってみた
棒歌ロイドOSPが一段落して次に何を作ろうかを考えていたところニコ動でVOCALOID
キーボードが話題になっているのを見つけたにょ。
VOCALOIDは本来はPCを使って1音ずつデータ作成する必要があるためある程度のDTMの
知識が必要になってくるけど鍵盤を演奏できる人が必ずしもDTMの知識があるというわけ
ではないためそういう人が使えるようにということで試作品が開発されたみたいにょ。
右手でキーボード（鍵盤）を操作しつつ、左手でカナ入力という風変わりな光景だけど
VOCALOIDキーボードはあくまで試作品であり、今のところ製品化の予定はないという
ことにょ。

「無いものは作る」の原則で早速Windows版を作る人が現れたにょ。
http://www.nicovideo.jp/watch/sm17357529
まさにこれぞタブレットPCならではの使い方にょ。
カナ入力部分はスマホでおなじみのフリック入力を採用しているにょ。
本家の試作品が子音（ただし、ボタン数削減のため濁音は専用ボタンを用意）＋母音の
同時押しによって操作していたけどフリック入力はソフトウェアキーボードならでは
なのでそういう意味ではこれはハードボタンのないソフトウェアの強みといえるにょ。
短期間でここまでのレベルのものを作るとはかなりすごいにょ。
この動画を見て演奏は大変そうだけどなかなか楽しそうに感じたにょ。

恐らくiPad版やAndoroid版も今後誰かの手によって作られるのではないかと思うけど
プチコン版を作った人はまだ誰もいないので「無いものは作る」の原則によって一晩で
作ってみたにょ。（急いで作らないとダブってしまいかねないと思ったので）
全く前準備もせず行き当たりばったりで適当に作ってもそれなりに動くものが作れて
しまうというのはBASICの強みにょ（笑）
とりあえず、プログラムやQRコードはまだ見せられるレベルではない試作品ということで
使用している様子を動画で紹介しておくにょ。
http://www.youtube.com/watch?v=ZNqvttuZIv0

プチコンはタッチパネルが使えるためソフトウェアによるキーボード表示は簡単に行う
ことができるけど問題はカナ入力にょ。
画面サイズの問題でキーボード（鍵盤）表示が精一杯で無理にカナ入力用のソフトウェア
キーボードを表示してもかえって使いづらいだけだからね。
その代わりプチコン（DS）はゲーム機であるため（スマホやタブレット端末と比べた場合に）
ハードウェアボタンが多数用意されているにょ。
というか、マルチタッチに対応していないためハードウェアボタンを使わないとカナ入力を
しながら演奏なんて無理だしね。

プチコンで使えるボタンはESC（停止）機能を持つSELECTボタンを除く8個にょ。
十字ボタンは4方向の入力が可能であるため全部で2^7x4＝512通りの組み合わせがあるので
ボタンの同時押しだけでカナ入力（濁音、拗音を入れて100程度）には十分に使えそうにょ。
とはいえ、現実的には法則性がなくカナを特定ボタンの同時押しで入力するなんてとても
実用に耐えられないものになってしまうにょ。
どのボタンを同時に押したらどの文字が入力できるかあらかじめ覚えておかないと使えなく
なってしまうわけだからね。
そういう面においては少ないボタン数でより速い入力が可能なフリック入力はかなり有用
だと思われるにょ。
しかし、ハードウェアボタンでフリック入力が可能なのかというとそれは無理にょ。
「フリック」ができないからね（笑）

とはいえ、フリック入力っぽい入力（子音入力の後に上下左右で母音入力）ならば十分
可能だと思うにょ。
それはテンキーの1〜9を使って入力する場合に1から順にア、カ、サ・・・と対応していく
というのは分かるけどその次に一端ホームポジション（「5」の位置）に戻しそこから
左、上、右、下が母音であるI、U、E、Oに対応するというものにょ。（Aは最初の1段階目
で確定させたらいい）
ここで問題となるのはフリック入力は1アクションで文字入力が可能なのに対してこの
方式では2アクションになるということにょ。
それはいいとして一端ホームポジションに戻すとなるとそれは「別の文字を入力しようと
している」のか「1文字目の2アクション目」なのかが分からないにょ。
したがって、2アクション目であることを示すボタンが必要になってくるにょ。（ある程度
長押ししたら確定という方法もあるけどそれだとリアルタイム演奏には向かない）

このプチコン版はテンキーの1〜9の役割をABXYの4ボタンで実現しているにょ。
これもボタン同時押しを駆使して行わなければならないためやや難しいとはいえ、慣れれば
そこまで難しくはないにょ。（上記動画でミスしまくりの私が言うのも何だけど・・・）
ここで上記の「2アクション目を示すボタン」だけどここでは2アクション目はRボタンを
同時押しすることで実現しているにょ。
つまり、Rボタンを押していないときは1アクション目（子音選択）だけどRボタンを押して
いるときは2アクション目（母音選択）ということにょ。（2アクション目は上下左右の
4方向だけなのでABXYボタンを単独押しで行うため1アクション目とは異なりかなり楽に入力
できるけど間違えてRボタンを押したときはI、U、E、Oしか選択できないという問題点を
無くすために2アクション目でもXYの2ボタン同時押しで母音Aを選択可能にしている

一見複雑そうに見えるこの操作だけどこれでもプチコン（DS）のボタンでケータイ入力に
よるカナ入力を行うことに比べたら遙かに簡単にょ。
ケータイ入力によってABXYボタンをテンキー代わりにするならば「オ」を入力するために
XY同時押しを5回連続で行わないといけないからね。
その際は少し同時押しのタイミングがずれてXボタンが遅れてしまったらア行からタ行へと
変わってしまうため「オ」を入力することができないにょ。
その点、このフリック入力を元にした入力方法だとLボタンを押すまでは確定されないため
同時押しのタイミングが多少ずれても問題ないのでゆっくり確実に押していけば誰でも
カナ入力は可能になるにょ。

しかし、これだと濁音が入力できないにょ。
そこで濁音はLボタンを押すことで実現しているにょ。
あと残った十字ボタンを拗音に割り当てれば基本的にほぼすべてのカナを入力可能になる
と思われたけどここで重大な問題に気が付いたにょ。
それはすべての十字ボタンとABXYボタンとLRボタンを押している時は鍵盤での演奏が
できないということにょ。
ということで、行き当たりばったりでうまくいきかけていたけど十字ボタンへ拗音を
実装する計画は凍結してしまったにょ。

拗音は使う機会は少ないとはいえ「チューリップ」さえ必要になっているからね。
最低限ャ、ュ、ョの実装はしておきたいにょ。
しかし、十字ボタンを押さずにどうやって実現するのかが問題にょ。
残るは唯一使ってないSTARTボタンを使うという方法だけどABXYの同時押しを駆使している
右手親指ではSTARTボタンを押す余裕は全くないにょ。（それにSTART1つでは拗音を
まかなうことはできないわけだし）
というわけで何か革新的な入力方法が無い限りは何とかして左手でLボタンと十字ボタンと
タッチパネル上の鍵盤を同時に押すような持ち方を開拓するしかないにょ。（現時点の
仕様は拗音、濁音を含めたすべての音が2アクション以内で入力できるために気に入って
いるので個人的には入力方法を変えたくないけど演奏ができないのは困るし）
簡単に作れそう・・・と思ったけど意外なところが盲点になってしまったにょ（というか
最初から考えておけって・・・）
それでも試作品の動画を公開してみて予想以上に反響が大きかった（わずか数時間で
20件以上の反応があった）のがうれしいにょ。
上記のWindows版の作者であるミクミンP氏にもtwitterでフォローしてもらったしね。

932：通りすがりでごめんね：2012/03/29(木) 22:05:19
(無題)
（当然、検討→ボツ済みだろうけど・・・）
カナ入力をタッチパネル操作にして、音階・演奏をボタン操作にするのは？
タッチパネルならフリックぽい入力もできるだろうし。
一方、音階・演奏をボタンにすると、
多く採用されている(?)バンブラ方式だと音階演奏だけで両手を占有されるけど
同時押しを使えば片手でもある程度の音階をカバーできるのでは。
単音しか発音できないのは、タッチパネルで演奏するのと同じだし。

933：御茶目菜子：2012/03/30(金) 15:42:13
レスにょ
通りすがりでごめんねさんへ
＞カナ入力をタッチパネル操作にして、音階・演奏をボタン操作にするのは？
＞タッチパネルならフリックぽい入力もできるだろうし。

ご意見どうもありがとうございます。

当初は1画面プログラムで作ろうという無謀なことを考えていたのでボタンで音階入力
（独自入力式）、文字はタッチパネルのカナキーボード（プチコン標準のもの）で入力を
しようとしていたにょ。
しかし、それではとてもリアルタイム演奏ができないということで慣れた時の演奏速度や
慣れるまでの時間を天秤にかけて現在の方式を選択したにょ。
現在の方式だと最長でも2アクション、ア段と拗音は1アクションで入力可能であるため
ボタンを使っての文字入力としては最速になると思われるからね。

タッチパネルを使ったフリック入力もどきは作ってなかったので試しに作ってみたにょ。
http://www.youtube.com/watch?v=CrqIthUibVc
とりあえず、清音のみ実装した（濁音、拗音は未実装）けどフリックならばすべての音が
1アクションで入力可能なので私の考案した文字入力方法よりも高速な入力が可能（ただし
ミクミンP氏が作ったようにカーブフリックを採用して濁音も1度に入力可能にして、拗音の
ボタンを独立させた場合）とはいえ、結局十字ボタンは使えないにょ。

＞同時押しを使えば片手でもある程度の音階をカバーできるのでは。
＞単音しか発音できないのは、タッチパネルで演奏するのと同じだし。

確かに同時押しならばABXYで1オクターブ、LRでオクターブ切り替えとシャープが使える
ため十字ボタンを使わずとも半音ありの2オクターブ分確保できるにょ。
ただし、ここで厄介なのは演奏に同時ボタン入力は向かないことにょ。
100％完璧な同時押しというのはかなりの強者でないとできないからゆっくり演奏するだけ
でもかなり難しくなってしまうにょ。（カナ入力に同時押しを用いた場合には間違えても
音が鳴らないのでゆっくり確実に押していけばいい）

それを緩和する方法としてはキー入力から発音までの遅延時間を用意するしかないにょ。
30フレーム（0.5秒）くらい用意すれば素人でも何とかなりそうだけど押してから0.5秒後に
鳴るというのもあまりよろしくないにょ。
まぁこの辺は設定変更可能にすれば問題は軽減されるだろうけどね。
ちなみに上記の動画は同時押し問題によって実用には耐えられなかったため同時押し無しで
行っているにょ。
ABXYLRでドレミファソラしか演奏できないため「きらきら星」が限界にょ。

しかし、貴重な意見を戴いたので前向きに検討してみるにょ。

934：通りすがりでごめんね：2012/03/30(金) 21:21:42
(無題)
返信ありがとうございます。そして即効の製作すごいですね！
それにしても、まさか1画面プログラムで作ろうとしていたとは脱帽です。
ボタン操作・・・例えば、あくまで例えば、
2ボタン入力が前提の操作方法にしたらどうでしょう。
A->X=ド, X->Y=レ, Y->B=ミ, B->A=ファ
A->B=ソ, B->Y=ラ, Y->X=シ, R=半音
X->A=オクターブ上, R+X->A=オクターブ下, など
ボタン入力待ちの遅延時間も最小の考慮で済むのではないでしょうか。
文字入力で2ボタン入力をするなら、
2ボタン入力という点ではさほど変わらないかな、とか。

・・・なんとなく、音長の制御に不安を感じるような気がするので、
ABXYなしでRを押したら発音を止めるとか。
Rを半音として使うためには
1つ目のボタンと2つ目のボタンの間にRを押す順番を守るとか。
次の音を入力するまで発声が続けば、
途切れ途切れでない発声に近づけるかな。

935：通りすがりでごめんね：2012/03/30(金) 21:24:59
(無題)
「途切れ途切れでない発声に近づけるかな」
たとえば、A->Bでソを発声した後に、
A+Rを押しながら発声タイミングを待機し、
Xを押した瞬間にド＃を発声する、みたいなことを言いたかったんだが
日本語が不自由で泣ける

936：御茶目菜子：2012/03/31(土) 15:01:11
レスにょ
通りすがりでごめんねさんへ
＞A->X=ド, X->Y=レ, Y->B=ミ, B->A=ファ
＞A->B=ソ, B->Y=ラ, Y->X=シ, R=半音
＞X->A=オクターブ上, R+X->A=オクターブ下, など
＞ボタン入力待ちの遅延時間も最小の考慮で済むのではないでしょうか。

確かにその方法ならばわざわざ意図的に遅延をさせる必要はないけど今度は演奏するための
ハードルが高くなってしまうにょ。
私の方針としては最初に覚えることはなるべく少なくしより多くのことを覚えればより
上手く演奏が可能になるという感じにしたいにょ。
左右両方の手で複雑な作業をするのは難しいからね。（ある程度パターン化はされている
ものの文字入力に意識を集中させた状態でそれができるかどうかは微妙）
そして、ボタンが順番に押されているかということは慣れないと視覚で確認するしかない
けれど左手のフリック操作はブラインド操作が困難であるためそちらの方に視覚を集中
させる必要があるため初見殺しになりかねないにょ。
したがって、右手は簡単にブラインド操作ができるものが望ましいにょ。

それと同時押しがないためゆっくり押していけば誰でも演奏可能なのがその方法のメリット
だけど間違えたボタンを押した場合にリカバリする方法がないというのがネックにょ。
例えば、ラを出すつもりでBではなくYを押した場合にはボタン操作をリセットするような
ボタンが必要にょ。
技術不足による演奏ミスは仕方ないけど間違いに気づいて訂正できる余裕があるのに訂正が
できないというのは個人的には妥協ができないにょ。

あれから同時入力の遅延時間設定をいろいろ変えてためしてみたけど私がプレイする限り
では1フレームの遅延設定でも劇的に改善されたにょ。
遅延ゼロならば1〜2割は演奏ミスをしていたのに1フレームの遅延でほぼミスがなくなった
からね。
もっともこれは右手に意識を集中させた場合なので現実的にはもう少し遅延時間を確保して
おいた方がよさそうだけどね。
個人的には遅延が2フレームまでならばそれほど遅延は気にならなかったにょ。
むしろ、ボタン入力の遅延よりもTALK命令のタイムラグの方が遙かに大きいにょ。
遅延ゼロ設定でも一瞬の間ができてしまうからね。（OSPもそれでどれだけ頑張っても
ブツ切れ感を無くすことができなくて限界を感じた）
ということで、複数のボタンを順番に押していくよりもまだボタンの同時押しの方が
良さそうな感じにょ。

C3からではなくA2もしくはG2からの2オクターブを確保し、初見ですぐに分かるような
分かりやすいボタン操作で演奏可能なものにしたいので下記のようなものを考えてみたにょ。

ラ　　A
シ　　A+B
ド　　B
レ　　B+Y
ミ　　Y
ファ　Y+X
ソ　　X
オクターブ上げ　R
シャープ　　　　L

＞・・・なんとなく、音長の制御に不安を感じるような気がするので、
＞ABXYなしでRを押したら発音を止めるとか。

現状では演奏ボタンを押している時はずっと鳴らし続けて離せば瞬時に止まるのでその
心配は要らないにょ。
鳴り続けるといってもTALK文でずっと発声させるのは無理なので最長でも連続で26秒程度
だけどね。
ただし、これは発話速度Tの値が1000の時の時間であって、Tの値が大きくなればなるほど
発声タイムラグが大きくなるためリアルタイム演奏をしようと思えばTの値は200くらいが
許容限界といった感じにょ。（許容範囲に設定した場合は最長で連続5秒程度になるけど
後述のように発話文字数によるタイムラグもあるためそれを減らしたければさらに短くなる）

とはいえ別の音を鳴らすためには一端離してさらにもう一度押し直す必要があるため
どんなにすばやく指を動かしても5フレームくらいは無音時間ができてしまうにょ。
そういう点では演奏を途切れさせない手段を用意することは十分に意味があるにょ。（演奏を
途切れにくくしたいだけならばボタンを放してすぐに停止するのではなく数フレーム後に
停止するようにすればいいだけなんだけど）
ただし、特定ボタンによって停止させるよりも特定ボタンを押し続けることで演奏が続行
される方が自然で分かりやすいと思うにょ。
これが、タッチパネル上の鍵盤で演奏するならばスワイプやフリック操作で演奏も自由に
コントロール可能なので（ほぼ）途切れ無し（下記のようにTALK命令自体のタイムラグが
あるため完全に途切れなくするのは無理）での演奏もできるし、こちらの方がさらに
直感的で分かりやすくなるにょ。（現在の仕様では、スワイプ時には最初に押した鍵盤の
音が鳴り続けるためそのまま新しい鍵盤に移動してその鍵盤上でフリックすればほぼ
途切れることなく次の鍵盤の音が鳴るようになっている）

＞「途切れ途切れでない発声に近づけるかな」

TALK命令の音声の波形をおおざっぱに見ると下記のようになっているにょ。
（縦軸が音量、横軸が時間）
　　　＿＿＿＿
　＿／　　　　＼＿＿＿
　A B C?????? D E　　F

A　TALK命令実行開始（TALKCHKで1を返す）
B　発声開始
C-D発声中
E　発声終了
F　TALKCHKで0を返す

ここで別の音を鳴らすとこうなるにょ。

　　　＿＿＿＿＿　 　＿＿＿
　＿／　　　　　|＿／

TALKSTOPで強引に停止したり、発声中に別の音を鳴らした場合にはDE間が無くなってしまい
どうしてもブツ切れ感が目立ってしまうにょ。
これはOSP1で明らかになったためOSP2では可能な限り正確な音長で発声することでDE間を
残すようにしてブツ切れ感を軽減しているにょ。
これはあらかじめ鳴る時間が分かっているOSPだからこそ可能なことでありリアルタイム
演奏でDE間を残すようなことは無理にょ。

DE間と同じくらい問題となるBC間はTALK命令においてはTの値で変わってくるにょ。
したがって、無音時間を少しでも軽減したいというのであればTの値を小さくするしかない
けれどそうすると連続で鳴らせる時間がTの値にほぼ比例して短くなってしまうにょ。
Tの値を小さくしてBC間を短くしてもAB間は変わらないのでTを1000から200に変えた場合には
効果は大きくなるけど100から20に変えても効果はかなり小さくなるにょ。（BC間、CD間、
DE間の時間はTの値にほぼ比例する）

実は最も問題なのはAB間にょ。
CD間やDE間は完全無声状態ではないけどAB間は完全無声状態になるからね。
AB間を少しでも短くするためには発話文字数を減らすしかないにょ。
現状では「−」を限界まで連ねて長時間連続で鳴らせるようにしているためAB間を短く
しようとすれば連続発声時間を短くするしかないにょ。（それでもAB間が短くなるだけで
あってゼロにはならないため発話文字数を1桁にしてもわずかにブツ切れが起きてしまう）
これがTALK命令1つで複数の音を鳴らすならばかなりスムーズな発声が可能になる（前の
音のDE間と次の音のBC間をつなげてくれる）のだけどこれをリアルタイム演奏で行うのは
不可能にょ。
リアルタイム演奏だといくら頑張ってもOSP以下になるにょ。
937：orirakkusu：2012/04/10(火) 09:08:19
プチコンプチ
なんか今日の深夜0時ぐらいに
まさかの新作「プチコンプチ」
が発表されたようです。
なんかつい最近mkllが発売され
たような気がするんですが...。
URLはhttp://smileboom.com/special/ptcm2/です。

http://www.geocities.jp/orirakkusu/

938：御茶目菜子：2012/04/11(水) 05:51:06
今日は何の日？
さて、今日も例年通りたくさんのニュースが発表されているにょ。

この3Dゲームはなかなか楽しそうにょ。
http://www.forest.impress.co.jp/docs/yashiro2012/news/20120401_522446.html

Googleマップがド○○エ風に・・・
http://maps.google.co.jp/maps?t=8&utm_campaign=8bit&utm_source=se

たくさんの要望があったためコミPo!のPC-98版が発売されることになったにょ
http://www.comipo.com/pressrelease/pr20120401.html

しかし、日付が日付だけにだまされないようにしなければいけないにょ。
まぁ私は生まれてから一度もウソをついたことがないんだけどね！（笑）


ところで、先日から書いていた「棒歌ロイドキーボード」だけど何と1画面でできたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/qr/baka_kb.png
というか、私のリスト短縮テクニックを駆使したら1画面でさらに余裕であまって
しまったにょ。。
まだサイトの方は更新していないけどQRコードを公開するのでぜひやってみてにょ。
とりあえず、1回やってみればすぐに分かると思うにょ。
分からない場合はリストに簡易マニュアルを記載しているのでそれを見てにょ。



orirakkusuさんへ
＞なんか今日の深夜0時ぐらいに
＞まさかの新作「プチコンプチ」
＞が発表されたようです。

これはすばらしいハードにょ。
煮たらソフトにもなるにょ！？

939：orirakkusu：2012/04/02(月) 09:06:42
友達コード
友達コードの交換をしたいのですが...
私は、既におちゃめさんのメールに送っておきました。
よろしければ返信してください。

http://www.geocities.jp/orirakkusu/

940：御茶目菜子：2012/04/02(月) 13:55:11
プログラムリストを短縮させるのは面白い
昨日公開した1画面版の棒歌ロイドキーボードだけど一部バグがあったので修正したにょ。
まぁエイプリルフールに公開するために急いで作ったから仕方ないか・・・。
ということで、バグ修正のついでにリストをもう一度じっくり見直したら結構無駄な部分が
あったので作り直していたら何と19行だったプログラムリストが14行まで縮まったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/image/1bou_kb.jpg
確かに処理落ち回避で無駄な処理をしていたとはいえ5行も縮まるとは思わなかったにょ。
というわけでサイトの方でも正式公開となったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#bkb
リスト短縮はほとんどポケコンで身につけたものをそのまま使っているとはいえ、知らない
人もいるだろうからそのうちそれらをまとめたものを公開する予定にょ。
1画面とか1行プログラムを作りたい人でなかったらほとんど関係ないようなものばかりに
なるだろうけどね。
棒歌ロイドキーボードもプチコンのすべてのボタンを使うので普通にIF文とか使っていたら
その判定だけでかなりの行数になってしまうため1画面（29文字×24行）に収めることさえ
難しくなってくると思うにょ。
この1画面棒歌ロイドキーボードは実質1行ですべてのキー入力判定を行っているからね。



orirakkusuさんへ
＞友達コードの交換をしたいのですが...
＞私は、既におちゃめさんのメールに送っておきました。
＞よろしければ返信してください。

今、手元にDSがないので今晩メールをするにょ。

941：orirakkusu：2012/04/03(火) 08:07:20
友達コードのこと
友達コード、登録しておきました！

http://www.geocities.jp/orirakkusu/

942：御茶目菜子：2012/04/03(火) 15:45:31
レスにょ
orirakkusuさんへ
＞友達コード、登録しておきました！

私は普段3DSでネット接続してないからあまり意味がないかもしれないにょ。

943：御茶目菜子：2012/04/07(土) 15:29:42
私のゲーム作りの集大成
先日液晶破損をしてしまった私のポケコン（PC-E650）だけどまだ無事だった頃に撮影して
未発表の動画があったので公開してみるにょ。
http://www.youtube.com/watch?v=qGXir_CI6B0

このゲームは「ピーチバレー2」にょ。
15年前にべーマガに投稿した作品のバージョンアップ版にょ。
このゲームのウリはOPASを使い（ポケコンBASICのゲームとしては）それなりに高速と
いうのと2人対戦・コンピュータ対戦が選べるということにょ。
詳しいゲームの内容、このゲームに使っている技術解説、このゲームの攻略法などは
すでに途中まで作っていたのでそれを参照して欲しいにょ。
http://ww5.tiki.ne.jp/~ochame/test/peach.txt
ここまで作って1年以上放置していたのはプログラムリストを転記する必要があるからにょ。
ポケコンの周辺機器（？）になっていたPC-98を使えるように整備しなおせばそんな
必要はないけどHDD故障で放置状態になっている（交換用のHDDは部屋のどこかにあるはず）
ということでリストはPCで手打ちしないといけないので億劫になっていたためにょ。

OPASとは何かというとポケコンユーザーとしておちゃめくらぶに来ている人ならば
知っている人が大半だと思うけど最近は（ポケコンは使用経験がなく）プチコンユーザー
として来ている人の割合の方が多いと思われるので詳しくはこちらの解説を読んで
もらえたらいいと思うにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/opas_1.htm
これは私が考案したポケコン（PC-E500シリーズ）でグラフィックを高速に表示するための
システムにょ。（もちろんOPASそのものもBASICで動作している）
プチコンで言えばBG画面に相当するものといえば分かりやすいかもしれないにょ。（動作の
仕組みからいえばPCG機能をBG画面風に使えるといった方がいいのだけど）
機能面では横スクロールのみのサポートということでBG画面よりは劣るけどその代わり
非常に高い柔軟性を持っているにょ。

OPASはPRINTで制御可能なのでBG画面のように矩形領域に止まらず画面の好きな場所に
対して有効になるにょ。
ポケコンの仕様上の上限では4つの領域を表示できる（BG画面4面分に相当）ために
多重スクロールのゲームがBASICで簡単にできてしまうというメリットを持つにょ。
ただし1つの領域は64キャラ分となるため広い領域を表示する場合には複数の領域を使用
する必要があるにょ。
またプチコンのBG画面は1つあたり64x64キャラ分という制限があるけどOPASはポケコンの
メモリの範囲だと自由に選べるため（メモリさえ十分にあれば）広大なマップ表示も
可能になっているし、それらを順番に表示していけば全画面を使ったアニメーション
表示も可能になっているにょ。
ただし、プチコンのBGPUTのようにリアルタイムでデータそのものを書き換えるのは
速度面の問題で難しいため必要なデータをすべてメモリ上に展開しておかなくては
ならないため（プチコンに例えるならばGRPをBG風に使えるようにしているだけなので）
そんな広大なデータたとメモリをバカ食いするにょ。

OPASはスクロールやデカキャラを表示するといった用途にかなり有効活用できるにょ。
http://www.youtube.com/watch?v=TNTkpnJbVn0
そのためこのピーチバレーのように小さいキャラを多数動かすという用途にはあまり向いて
いるものではないにょ。（背景としてコートを常時表示することでボールが通過した後も
コートやネットが消えることがないというメリットがあるのでそれを防ぐためには
再描画が必要になるGPRINTと比べると圧倒的に有利にはなるけど）
とはいえ、PC-E500シリーズ標準のグラフィック命令であるGPRINTはお世辞にも速いとは
言い難い（何せ8x8ドットの1キャラを4方向に動かすだけで10fps程度の速度しか出ない）
ということで明らかにOPASが実力を発揮できないこのゲームにおいてもGPRINT比で
5倍の表示速度を得ることができているにょ。
表示だけ速くなっても後の処理がボトルネックになっていては意味がないためそれらも
高速化することで普通に作れば2fpsしか出ないようなこのゲームは最大8fpsもの高速（？）
動作が可能になっているにょ。
まぁこれはコンピュータの思考ルーチンのない2人対戦時のものなので上記の動画の
ようにコンピュータ対戦時は6fps程度まで落ちてしまうため少々重いけどそれでも
GPRINTで作ったら2fps程度になり、実用レベルには全く達しないためそれと比べたら
格段に快適にょ。

冒頭にも書いているようにこのゲームは15年前にべーマガに掲載された同名のゲームの
バージョンアップ版となっているにょ。
Dr.Dにも絶賛されたこのゲームだけどべーマガに投稿した初期バージョンはプレイ
するためのハードルがかなり高かったにょ。
というのもこのゲームはブロック崩しのパドルのようにボールをレシーブする場所で
ボールのレシーブ角度が決まるためかなり難易度が高いにょ。（とはいえ、それでは
ゲームとして成立させるのが難しいためボールの飛距離を「近く」「遠く」「中くらい」
というのをレシーブやスパイクをするときに方向ボタンとの同時押しで選べるように
なっている）
ブロック崩しの場合はパドルとのあたり判定は常に有効だけどこのゲームの場合は
レシーブボタンを押した瞬間のみ有効になっているにょ。
こうすることであたり判定を大幅に減らせるため高速化には非常に有用だけど難易度を
跳ね上げている原因にもなっていたにょ。
何せ標準では落下の予測地点が一瞬表示されているだけであってプレイヤーはそれ
だけを頼りにレシーブしたりスパイクしたりしなくてはならなかったにょ。

したがって、「2」では「1」からあったコンピュータの強さ（5段階）以外にもプレイ
補助機能を選択できるようにしてプレイのためのハードルを下げたにょ。
プレイヤーとボールの当たり判定を常時行うことでレシーブ難易度を下げたりといった
ありがちなものなのだけどそれによる難易度の変化などがあるためプレイモードを
ビギナーモード、アマチュアモード、プロモードに分けたにょ。
「1」ではゲームクリア後に選べた「プロモード」だけど落下予測地点も無いため目算で
プレイしなくてはならず縦方向に画面が小さいポケコンでは高いボールは完全に見失う
ために難易度が劇的に高くなってしまったにょ。
しかし、「2」では一般的な球技ゲームにあるような現在座標を示したもの（要するに
ボールの陰）を表示しているためプロモードでもそれなりにプレイできるようになって
いるにょ。（表示オブジェクトが増えれば速度低下を招いてしまうけど上記動画では
ビギナーモードということでフルオプション時の動きや実行速度はこれで分かると思う）
プレイのハードルが下げられたためクイックプレイ（上記動画の3分30秒くらい）の
ようなものもそれなりに簡単に出せるようになったにょ。

あと「2」ではコンピュータの思考ルーチンにも手が加えられてより強くより人間らしく
なっていると思われるにょ。
べーマガでおなじみの「砦の攻防」のようなゲームの場合はコンピュータに厳密な計算を
やらせてしまえばミスをしなくなるため人間は絶対に勝てなくなってしまうにょ。
そのためにコンピュータはいかにして手を抜くかが必要になってくるにょ。
乱数の影響を大きくしてしまえばわざとミスをしているように見えてしまうため
「頑張っているけどミスをしている感」を出すためにピーチバレーでは厳密な計算は
一切しておらず、プレイヤーも得られるような情報を元に思考しているにょ。
これはピーチバレーの場合はフレームごとの動きが大きいため厳密な計算を行うためには
かなりの補正が必要になるため処理が重くなってしまうというのが本当の要因では
あるけどね。
それとOMPによる音階演奏なども加わっているにょ。

ポケコンだとOPASを駆使しても最高8fpsの速度だけどプチコンだったら容易に60fpsの
速度が出せそうにょ。
表示オブジェクトはプレイヤー2人×2、ボールとその陰の6つだし、それにプレイヤーの
陰を表示してもキャラ数は10だからね。
プチコンmkではのスプライトは1フレームで50個くらい動かせていたけどmkIIでは70個
くらい動かせるようになったからね。（1キャラでさえ10fpsで動かすのがやっとである
ポケコンと比べると標準グラフィックキャラ表示速度は400倍くらいの差があるため
ポケコンで8fpsを出すというのはプチコンで3200fpsを出すくらいの難しさといえる）
ただ、ポケコンの画面サイズだからこの程度でも問題ないけどプチコンだと画面が
スカスカになるため画面レイアウトや演出も変える必要があるかもしれないけどね。
1画面ゲームならばその妥協が許されると思うけどこのゲームを1画面で作ることは
無理にょ。
まぁ「シュプール」を「プチコンスキー」として、「3D DRIVING」を「PETIT RUN」
として基本的な考え方のみ使って別物のゲームとして作れば十分可能だけどこの
「ピーチバレー」を簡素化するとただの2人対戦のテニスゲーム（地面についたら負けに
なるので羽根突きのようなゲーム）になってしまうにょ（笑）

というわけで、私が最後に発表したポケコンゲームが3月14日の「ホワイトデーゲーム」
ではあまりに嫌すぎるためこの「ピーチバレー2」を最後に発表したポケコンゲームと
しておいて欲しいにょ（誰に向けて言ってるのやら・・・）
まぁポケコンが壊れてしまったから即終了というわけではなくポケコンを再入手したら
また復活できる可能性もあるけど生憎PC-E500シリーズの最終モデルとなったPC-E650も
すでに生産終了して時間が経つだけにどんどん入手が難しくなっているためいつ復帰
できるか分からないからね。
それに唯一新品でも入手可能なPC-G850VSはPC-E650よりは高速とはいえそれをPC-E500
シリーズで蓄積された知識のほとんどが生かせないのが厄介にょ。
G800シリーズで使える知識もあるけど私の場合はE500シリーズに特化したものばかりを
使用しているからね。

特定機種のみに通用する専用テクニックは100％の性能を使い切るには当然のことにょ。
BASICレベルであっても100％の性能を使い切るというのはかなり大変であることは私が
長年1機種（PC-E500シリーズ）を使い続けることで身をもって体験したからね。
たからこそ、雑誌掲載のレベルのゲームでも3倍とか5倍の高速化というものが可能に
なっているにょ。
私がプチコンにおいてはどの程度使いこなしているかはまだ不明（未だに使ったことの
ない命令さえある）だけど1つだけ言えるのは潜在能力の上限までは全く使ってない
ということだけは確かにょ。
上限にかなり近いくらい使いこなしている人ならば何人もいるにょ。
ただし、それらの人も100％使いこなすというのは無理だと思うにょ。（ここで言う
100％というのはプログラムリストを見ただけでこの実行には何フレームかかるというのを
把握しているようなレベル）

私はプチコンはマイペースでプログラムを作っていこうと思うにょ。
もはや、若い頃のように上限まで使いこなしてやろうという気力はないからね。
1画面プログラムを作って「1バイト縮まった」とかいう些細な喜びで十分にょ。
昔はポケコンでも大作主義でメモリがあればあるだけ使っていた（PC-E500にドラクエ
移植をしていたけどメモリ不足で途中で断念したこともあった）けど雑誌投稿を
始めた90年代からはいかにリストパフォーマンスを向上させるかに焦点を絞って
いったからね。
ポケコンBASICで作られたアクション系のゲームの場合は実行速度がおもしろさを左右
することも多いため速度重視でなおかつリスト短縮にも拘ってきたにょ。
その点、プチコンはよほど凝った処理をしない限りは速度面が問題になることはポケコン
と比べると非常に少ないためリスト短縮のみに焦点を絞ったプログラミングができるにょ。
そういう意味ではやはり私にとっては1画面ゲームが最適っぽいにょ（笑）

944：御茶目菜子：2012/04/08(日) 15:41:12
棒歌ロイドキーボードが完成！
先月末から作っていた棒歌ロイドキーボードがついにできたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/bo_kb.htm
http://www.youtube.com/watch?v=Rmks-sKVXaY
すでに1画面版（といっても14行）のものを発表しているとはいえ、やはりプチコン標準の
カナ入力ボードではいくら慣れても速度面でかなり無理があるし、指では入力が難しい
ためタッチペンでの操作になってしまうけどそうなると事実上右手でペンを持って左手で
支えるしかなくなるにょ。
そうなると音階演奏部分は必然的に十字ボタンとなってしまうのだけどそのせいで斜め
ボタンの入力を多用することになり実用レベルに達しているとは言い難いにょ。
まぁこれはいかに短いリストで作るかに焦点を置いており使いやすさは二の次という感じ
だったけど今回のは使いやすさに重点を置いたものにょ。

プチコンで文字入力をしながら音階演奏をする場合には文字入力と音階演奏のどちらを
タッチパネルで行いどちらをボタン操作で行うかによって操作性はまるで別物になって
しまうにょ。
当初は1画面版と同じ方式で考えていたけど「リアルタイム演奏は絶対に無理」という
ことで1画面はあきらめて他の方法を行うことにしたにょ。（結局途中まで作った1画面版も
あとからリスト短縮に最大の主点を置いて作り直したものを発表したけど）

操作する場合にはタッチパネルはブラインド操作は無理であるためそちらの方に視点を
集める関係上でボタン操作は慣れたらブラインド操作が容易であることが望ましいにょ。
そして、できるだけ速く、確実に入力できるものが望ましいにょ。
そういった条件のものに2つのものを試作したにょ。
1つが今回発表したようにボタン操作でカナ入力をしてタッチパネルの鍵盤で音階演奏を
行うというものでもう1つが3月30日に書いたようなタッチパネルで文字入力を行い
ボタン操作で音階演奏を行うというものにょ。

　試作品1
　http://www.youtube.com/watch?v=ZNqvttuZIv0
　試作品2
　http://www.youtube.com/watch?v=CrqIthUibVc

後者（試作品2）の方は、まだ清音のみの実装とはいえ一般的なフリック入力にほぼ準拠
したものであるためにスマホのフリック入力に慣れている人であればすぐに使えると
いうのが大きなアドバンテージになっているにょ。
前者（試作品1＝今回完成させたものの原型）はABXYボタンをテンキーに模して
フリック入力をモチーフとした入力方法となっており、こちらも清音においては簡単に
入力できると思われるにょ。
どちらを完成させるか迷ったけど今回は前者を完成させることにしたにょ。（後者に
関しては後述）
やはり、少しでも早く完成させたかったのと前者と後者では使い勝手が別物であるため
それを両方搭載すると中途半端なものになりかねない（ベストな状態がわかりにくい）と
いうのがあるからにょ。
プログラム面を見ても2つを1つにまとめれば別々に発表したものを合算するよりは小さく
なるとはいえ大部分が異なっているためあまりリスト短縮効果は望めないにょ。（無理に
共用できる部分を増やそうとするならばリストの最適化を施すのが難しくなるため逆に
サイズ面では不利になる）

基本システムは一晩でできたもののネックとなったのはボタン操作による文字入力において
致命的な問題が見つかったからにょ。
清音においては「ボタン操作でこれ以上のものは考えられない」という配列であるため
それをさらに使い勝手を良くするために濁音と拗音ボタンを独立させて素早く入力が
可能になったにょ。
子音＋十字ボタンで一発で拗音が出せるため拗音においてはフリック入力を超えると
思われていたくらいにょ。（例えば「ニョ」ならば同時押しさえ要らず十字ボタンの
右だけで出せるためどの入力方法よりも速い）
その結果、十字ボタンに割り当てている拗音を入力するときはタッチパネル上の鍵盤で
演奏ができないという問題が発覚したにょ。
結局拗音の1ステップ入力は諦めて2ステップ入力にすることでこれを解決したにょ。（とは
いえ、一応十字ボタンでの入力も残しているけどこちらも拗音を出す時のみ右手で演奏
すれば使えなくはない）

というわけで、ボタン操作による文字入力はこれ以上のものを望むのが難しいため次に
タッチパネルの鍵盤演奏について考えることにしたにょ。
重視したのは操作性とTALK命令により音のブツ切れ対策にょ。
プチコンでもすでにタッチパネルを使った鍵盤演奏プログラムは多数発表されているけど
やはりそれらのほとんどがタッチペンを使っての演奏を想定していると思われるにょ。
指で入力するためには最低ボーダーラインが鍵盤の横幅は16ドットくらい欲しいにょ。
これだと2オクターブ実装できるにょ。
楽器演奏ならば2オクターブでは足らないことが多いため2オクターブの鍵盤を2つ分用意
して4オクターブ出るようにしたり、中には3段分で6オクターブ出せるものもあるにょ。
横幅が16ドットが最低ラインといってもそこまで増やすと縦幅が狭くなり操作しづらい
ためにボーカル演奏ならば2オクターブあれば十分といえるにょ。

むしろ問題なのはどの音からどの音まで出せるかということにょ。
下限がド（C3）からだと演奏できない歌唱曲も結構あるためラ（A2）かソ（G2）までは
対応させておきたいところにょ。
そうなるとソ（G2）〜ファ（F4）もしくはラ（A2）〜ソ（G4）となるにょ。
これだと白鍵の数は14個になり横幅は16ドットを超えるものになるにょ。（計算上では
横幅が約18.3ドットになる）
しかし、白鍵の鍵盤数14個でも文字入力に十分に慣れておらず意識が右手の文字入力に
行ってしまうと結構ミスが目立ってしまうためさらなる横幅の増加が欲しいと感じるように
なってしまったにょ。（DSi LLならばまた変わってくるんだろうけどあいにく持ってない）

鍵盤の横幅を増やすのは簡単だけどそうなると鍵盤数が足らなくなる可能性もあり、
演奏できる曲にかなりの制約ができてしまうにょ。
そこで思いついたのが鍵盤サイズの可変機能とスライド機能にょ。
これがプログラムを書き換えたりせずに誰でも簡単かつ自由にできることによって
自分が最も使いやすい鍵盤にすることができるにょ。（GFILLとGBOXを使って描いている
ためにBG画面を使うものと比べてサイズを変更するのは非常に簡単にできるし、色で簡単に
判別可能であるため鍵盤の入力判定のコードも短くなる）
やはり、どの程度の音域をカバーしているのか、どの程度の横幅まであれば十分なのかは
曲によっても違うし個人差も大きいからね。
私自身も曲によって手軽に設定変更ができるというのは非常に恩恵が大きいにょ。
私の知る限りでは鍵盤サイズの自由可変ができるプチコンプログラムは私が今回作った
「棒歌ロイドキーボード」以外には存在しないにょ。（鍵盤スライド機能を持ったもの
ならば他者が作ったものの中に1つだけあったけど）

そして、重要となるのが音切れ対策にょ。
TALK命令で長時間（数10秒間）連続で発声させることは簡単なのだけど問題はあらかじめ
発生時間を決めておく必要があるということにょ。
したがって、一般的な方法としては長時間発声させるようにしておいてタッチパネルや
ボタンを離したときにTALKSTOPで停止するという方法によって時間調整をしているにょ。
この方法で音切れの原因となるのはTALK命令自体のタイムラグとボタンやタッチパネル
から指を離すことで発声する無音時間にょ。

TALK命令は発話速度Tを調整することで発声時間を調整できるし、発音したい音の語尾に
「ー」を付けることで調整もできるにょ。
先日も書いたようにTALK命令の音声の波形をおおざっぱに見ると下記のようになってい
ためまずはこれを見てみるにょ。（縦軸が音量、横軸が時間）
　　　＿＿＿＿
　＿／　　　　＼＿＿＿
　A B C?????? D E　　F

A　TALK命令実行開始（TALKCHKで1を返す）
B　発声開始
C-D発声中
E　発声終了
F　TALKCHKで0を返す

しかし、発話速度を遅くするとTALK命令を実行してから実際に発音されるまでの時間で
あるBC間の時間が増加してしまうため素早い操作に対応できなくなってしまうにょ。
「ー」をたくさん連ねるとAB間の時間が増加してしまうためこちらも同様の状況になって
しまうにょ。
TALK命令は発音する文字によってそのAB間やBC間の時間は異なるため一概には言えない
ものの上限付近ではかなり顕著になってくるにょ。
それならば、発話速度を速くして、「ー」の数も減らせばいいけどそうなると今度は
連続して発声できる時間も短くなってしまうにょ。
許容範囲がどこにあるのは演奏者や演奏曲によって大きく変わってくると思うのでそれは
「バッファサイズ」という項目でいつでも容易に設定変更できるようにしたにょ。
レスポンス重視か発声速度重視かが簡単に調整できるということにょ。

ただし、これでTALK命令自体のタイムラグは妥協できるレベルになるとしても厄介なのは
演奏者が原因となる無音時間にょ。
これは「すばやくボタンを押せば問題ないのでは？」という考えもあるけどすばやく操作
するにも限界があるにょ。
ひたすら連射を行うだけならば秒間16連射も可能だけど普通だったらせいぜい秒間6連射
程度ではないかと思われるにょ。
これはテンポ120の曲の三連符の速度であるため無茶な速度ではないにょ。
実際にこの速度で連射をして、タッチパネルに触れている時間がどの程度あるのかを
プチコン上で実験してみたところ数回のテストの平均で接地時間は約3分の1程度である
ことが分かったにょ。
これは言い換えると1回押すのにかかっている時間（10フレームの時間）のうち接地時間は
3〜4フレームということにょ。
これば指を素早く動かしても1回あたり6〜7フレームの無音時間ができてしまうことを
意味するにょ。
当然ながらこれは「速く動かす」ということを考えてこのレベルであり、慣れないうちは
その数倍の無音時間になると思われるにょ。（だから音がブツ切れになって当たり前）

無音時間を減らすのにもっとも簡単な対策方法はボタンやタッチパネルから指を離しても
すぐに発声が止まらないようにすることにょ。
最低でも6〜7フレーム、設定によってはその10倍くらいの時間まで可能にすればかなり
音切れは軽減できると思われるけど止めたいときにすぐに止まらないというのはあまり
良いものではないにょ。
ピアノのダンパーペダルのように特定のボタンを押している間のみ鳴り続けさせる
というのも1つの方法だけどそのためにボタンを1つ占有されてしまうというのはあまり
良いものではないにょ。（専用ボタンを設けないと使い勝手が著しく低下してしまう）

しかし、タッチパネルでの演奏の場合は「押す」「離す」以外の操作が可能であるため
わざわざ専用ボタンを使う必要はないにょ。
今回私が行ったのは鍵盤を押さえた時は基本的に発声し続ける（ただしTALK命令の発声
可能時間内に限る）のだけどその発声中にタッチパネルに触れたままで次に押す鍵盤の
場所まで指を移動させてその鍵盤の上で軽く下方向にスライドさせて演奏させるという
ものにょ。
これを行えば上記検証で分かった「最低6〜7フレームの無音時間」をゼロにすることが
できるにょ。
私はこの演奏方法を「レガート奏法」と名付けたにょ。
もちろんこれはピアノ演奏では初歩のテクニック（バイエルを初めてすぐの頃に習う）と
なるレガート奏法を元にしたネーミングだけどこれができるのもタッチパネルの恩恵で
あると思われるにょ。（プログラムの処理的にはたいしたことはやってないんだけど）

このレガート奏法の効果は実際に試してみると非常に大きいことが分かるにょ。
例えば、デフォで発声される「ナ」の音だけどこの音は比較的発声タイムラグが大きめ
となっているにょ。
そのためバッファサイズゼロに設定しても秒間6連射ところか秒間4連射で同じ鍵盤を
押しても全く発声してくれないにょ。（発話速度10、「ー」を1つにすれば辛うじて
発音されるけどその代わり押し続けても一瞬しか鳴らないため実用にならないし、
ブツ切れ感は非常に大きい）
これはテンポ120の八分音符の速度であり、決して速いものではないにょ。（ピアノを
ONにしているとピアノ音だけ鳴るのを見てもプログラムそのものの処理が重いのではなく
TALK命令のタイムラグが大きいのが分かる）
しかし、そういう状況下であってもレガート奏法を行えば秒間4回同じ鍵盤を上下に
こするようにスライドさせてもそこそこ反応してくれるため効果の大きさは一目瞭然
だと思うにょ。
というわけで、とりあえずプチコン（DSi／3DS）で動作させるということを考えると
今回私が行った文字入力、演奏方法がベストな方法ではないかと思われるにょ。

あとの細かいことはプログラムの紹介ページに書いたけどその中から2点ほどさらに詳しく
書いていくにょ。
レガート奏法に直前の2フレーム分の移動量を使用したのかは1フレーム分だと誤差が極めて
大きくなるからにょ。
2フレームで8ドット分の移動量ならば1フレームで4ドット分の移動量でも同じようだけど
実際はある程度力が入っていたら指を置いたときのちょっとしたずれで数フレーム分移動
してしまうためにょ。
1フレーム分の移動量だと誤差が大きいし、たくさんのフレーム数だとその分だけたくさん
だけ変数を用意しなくてはならない（リングバッファを使えば処理は簡単とはいえできる
だけ短いコードで意味のある動作をさせたかったため）というわけでベターに感じたのが
2フレームで8ドット分にょ。（これが15とか20ドットくらいになると今度は演奏のミスが
増えてしまったし、あまり参照フレーム数を増やすとレスポンスも下がってしまう）

それとデフォ設定でド（C3）ではなくラ（A2)を鍵盤の下限の音にしているかということ
だけどこれも理由があり、デフォ設定でどんな曲も無難に弾けるようにするためにょ。
確かにスライド機能があるから必要な人だけ変えればいいんだけどね。
それは私も思ったけど鍵盤数を23個まで増やせる関係上ドを下限にしてしまうとその上限
設定ができないということも理由にもなっているにょ。
鍵盤位置がデフォの状態だと鍵盤数を23個の上限に設定したときに音域の上限になるように
なっているにょ。
設定を変えないと選択できない機能があるというのは個人的にはあまり好ましくないし
かといって鍵盤数の設定を14段階にするというのもあまり好きではないためにそうなって
しまったにょ。（一見するとキリが良い10段階にするという方法もあるけど0H〜FHまでの
16段階や00H〜FFHまでの256段階が最もキリが良いと感じているという主観的な理由による）
それならば逆に鍵盤数の下限を6まで選べるようにすれば16段階の設定でデフォの鍵盤位置
においてドをデフォの下限の音にすることができるという考えもあるかもしれないけど
その場合は6音だとあまりに弾ける曲に制限がある（「きらきら星」くらいか）だけでは
なくてキーボードスライドルーチンが長くなってしまうためにょ。
このスライドルーチンは1オクターブ上の黒鍵の有無（GSPOITで黒鍵の色から判断）を
調べているという単純なものだけどその手段が使えなくなってしまうからね。
いくらでも他の方法はあるのだけどわざわざ長いコードにしてまでそこまでする価値を
見いだすことはできなかったにょ。
それでも変えたいという人はどんどん自分好みに変えて欲しいにょ。

最後にさここで先ほども書いたタッチパネルを用いてフリック入力で文字入力を行い
ボタンで演奏するというもう1つの案（試作品2）についてだけどここまでタッチパネルでの
演奏が快適になるとボタンでの演奏はかなり見劣りしてしまうにょ。（確かにバンブラの
ようにすべてのボタンを割り当てればそれなりに快適に演奏できるとはいえ、それは私の
文字入力で拗音が入力できないというのと同じであり、すべてのボタンを使うことは
できないわけだし、音切れ対策を行うならばさらに使えるボタンが減ってしまうために
快適に演奏できるものにするのは極めて困難）
確かに文字入力だけを見ればタッチパネルでフリック入力を入力した方が快適とはいえ
肝心の演奏部分にここまでの差ができてしまうとそれを埋めるにはかなりの工夫が必要に
なってくにょ。
せめて、ボタンがすべて使えたらバンブラ式で結構快適に演奏できるのだけど文字入力を
しながらだとABXYボタンか十字ボタンのどちらかは事実上使えなくなってしまうからね。
それでボタンを使った快適な演奏は難しいにょ。

演奏部分には大きな問題があるけど文字入力は完璧かというとそうでもないにょ。
フリック入力はカーブフリックによる文字入力について研究して（手元にカーブフリック
対応の機種がないためその使用感を得るためには店頭で確かめるしかない）それに
見劣らないレベルで文字入力を可能にしたいところにょ。
そして、ボタン操作で上記のような快適に演奏できる方法が見つかり、さらに音切れを
緩和させる方法が良い方法（1つの方法として挙げた上記のダンパーペダル式だと演奏に
使えるボタンが1個減ってしまう）が思いつけば開発を再開するにょ。
ただし、その前に作るのに飽きたら開発はそこで一端終了となるにょ。
とりあえず、当初に作ろうと思ったものはできたので代案の方は安心してゆっくり
進めることができると思うにょ（笑）
そのうち、こっそり完成させてプチコンコーナーの方に公開しておくかもしれないにょ。
よほど「ここを見て欲しい」という工夫した点がないとここでわざわざそれについて
こんなに書くことは無いだろうからね。

945：orirakkusu：2012/04/09(月) 18:41:59
IF短縮
プチコンで8方向に動かすルーチンを作ってみた。
X=X+(SGN(BUTTON() AND 8)-SGN(BUTTON() AND 4)):Y=Y+(SGN(BUTTON() AND 2)-SGN(BUTTON() AND 1))

http://www.geocities.jp/orirakkusu/

946：御茶目菜子：2012/04/10(火) 15:38:08
プチコン講座がmkIIに対応にょ
私が書いたプチコン講座がようやくプチコンmkIIに対応したにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/lecture.htm

基本的にmkIIは初代プチコンの上位互換であるためプチコンの知識はmkIIでもほとんど
使えるのだけど一部は命令の仕様が異なったり、mkIIで導入された命令を使えばさらに
簡単に記述可能だったりするためそういうのを内容に盛り込んだにょ。
それだけでは物足りないのでゲーム作りの基本となる第1回、第2回に関しては初心者の
理解をさらに深めるためにより基礎的な部分とより実践的な部分を書き加えたにょ。
加筆部分だけでテキストサイズは10数KBに達しているにょ。
この講座を書いてから4ヶ月余りの間にtwitterなどで良く聞かれている疑問点に対応する
ようなものになっていると思うにょ。
一応初心者向けの講座なのであくまで基礎知識がメインであるため効果的なリスト短縮の
方法などは別の形で公開するにょ。



orirakkusuさんへ
＞プチコンで8方向に動かすルーチンを作ってみた。

私も作ってみたにょ。
B=BUTTON()X=X-(B%16-B%4+1)%3+1Y=Y-(B%4+1)%3+1
こんな感じのリスト短縮法は今度Tipsコーナーにまとめる予定にょ。

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画面プログラムに興味を持つ人が増えたら個人的にはうれしいにょ。

948：orirakkusu：2012/04/15(日) 15:40:07
ついにきたーー
ついに、来たようだ！
おちゃめさんのリスト短縮技が！
やったあああああああああああああ
(この人はtwitterからすっとんで来ました。)

http://www.geocities.jp/orirakkusu/

949：御茶目菜子：2012/04/16(月) 15:23:31
レスにょ
orirakkusuさんへ
＞ついに、来たようだ！
＞おちゃめさんのリスト短縮技が！
＞やったあああああああああああああ

良かったら自作プログラムの中でどんどん活用してみてにょ。
まぁ1行とか1画面とかいう行数制約のあるプログラムでないとあまり意味がないけどね。

950：御茶目菜子：2012/04/17(火) 15:19:25
10インチ液晶にはWQXGAがベスト！？
キヤノンとシャープが4K対応モニタを年内に量産開始すると発表したにょ。
http://av.watch.impress.co.jp/docs/news/20120413_526212.html
http://av.watch.impress.co.jp/docs/news/20120413_526327.html

すでに4Kモニタ（3840x2160のQuad HDが主流）は市場に出回っているもののそれらは50〜60
インチクラスの大型のものばかりで一部の需要に応えるハイエンドな製品でしかなかった
からね。
しかし、この度は32インチという一般家庭における普及サイズで4Kを実現していることに
価値があるにょ。
液晶モニタはQuad XGA液晶を搭載した新型iPadが4万円台からの普及価格で発売されている
のを見て分かるように解像度アップによるコストアップはそれほどたいしたことはなくて
パネルサイズと生産数が価格に大きな影響を与えているにょ。
したがって、32インチという比較的小さなサイズであるのと同時にそれを大量生産する
ことで量産効果によるコストダウンが実現できるにょ。
新型iPadが高解像度でも安価なのは9.7インチというパネルサイズに加えて1000万台単位の
出荷が行われるため量産効果によるコストダウンが容易であるためにょ。
実際はコストダウンができても4K対応という付加価値によってやや高めの価格付けが
行われると思われるにょ。
現在の液晶TVは低価格競争によって国内メーカーはどこも採算がとれる状況にはならない
レベルにまで達してしまったからね。

問題はTVが4Kになったところで現時点でどれほどの恩恵があるのかということにょ。
次世代となるスーパーハイビジョンはまだ試験放送さえ始まってないという状況下であり
その高解像度を生かせる映像ソースがないからね。
そんな中でやはり期待されるのは4K対応のビデオカメラにょ。
キヤノンはEFマウント対応のデジタルシネマカメラ「EOS C500」とEOS 1DXをベースとした
4K動画が撮影可能な「EOS 1DC」を発表したにょ。
http://av.watch.impress.co.jp/docs/news/20120413_526222.html
http://av.watch.impress.co.jp/docs/news/20120413_526218.html
いずれも非常に高価なものとはいえ、これはハイエンド市場を見込んだ大型センサー搭載の
レンズ交換式であるためやむを得ないにょ。
4K動画が普及してくれば現在のフルHD対応ビデオカメラ並の価格で4K対応のビデオカメラが
登場することが予想されるにょ。

現時点では再生環境がほとんどないため普及にはしばらく時間がかかりそうにょ。
4K対応のビデオカメラをそれなりに安価に抑えてもフルHD液晶TVではその違いが分からない
からね。
エンコーダチップは近い将来安価に作れるようになるとしても記録するメディアが問題と
なるにょ。
現在はフルHD対応のAVCHDでは規格上28Mbpsが最大になっているにょ。
4K動画の主流ビットレートはどれくらいになるのかは分からないけどコーデックが進化
しない限りはフルHDの4倍となる100Mbpsクラスのビットレートが必要になるにょ。
1秒当たり約12MBのデータ量になるのだけどこれだと64GBのSDXCカードであっても1時間半
しか記録できない計算になるにょ。
半導体の製造プロセスの微細化によって記録時間はどんどん増えていくのだけど問題は
容量ではなく速度にょ。
12MB/sというのはあくまで最低レベルの速度であり、より高画質を求めるため高ビット
レートで保存するならばより速い記録メディアが求められるにょ。

十分な映像コンテンツがないと表示機器は普及しないというのは現在の3D対応テレビを
見れば良く分かると思うにょ。（それ以前にメガネを掛けないと視聴できないという
現在の主流のスタイルでは普及は難しいと思われるので3DTVを本格普及させるのであれば
裸眼でまともに視聴できるレベルの3DTVを安価に発売する必要があると思う）
したがって、4K対応TVを普及させるためには価格も重要だけどその価格を下落させるため
にも量産効果によるコストダウンが必要であり、そのためにも多くの人に多少割高でも
4K対応のTVを選んでもらう必要があるにょ。
「卵が先か鶏が先か」というのと議論になってしまいそうだけど結局はコンテンツが
ないと話にならないにょ。
HDTVに関しては地デジへの完全移行が極めて大きい（つまり強制的なアナログからの
乗り換え）けれどBSデジタルやHD対応ビデオカメラがすでに普及しつつあったという
状況を考えると地デジ放送が開始される前からHDTVの需要増はある程度見込まれていた
と思われるにょ。（ここ数年で一気に普及したのは価格面の問題による影響が大きい）

TVの4K化も気になるところだけどそれよりもPCの高解像度化も気になるにょ。
シャープは上記の32インチ4Kパネルと同時に10インチWQXGA（2560x1600）や7インチの
WXGA（1280x800）の液晶パネルの量産化も発表したにょ。
http://pc.watch.impress.co.jp/docs/news/20120413_526257.html
個人的に気になるのは10インチWQXGAモニタの方にょ。
これを搭載した小型ノートPCの発売を期待したいにょ。（Let'snote Jあたりに搭載される
とうれしい）

ノートPCの液晶モニタの解像度は90年代後半にXGAが主流になってからはそれがずっと
据え置きの状態が続きXP世代後半（2000年代半ば）にはWXGAが主流になって現在に
至っているにょ。
確かにモデルによってはWXGAよりも高解像度なものは選べるとはいえそれはあくまで
ごく一部の機種に限られ国内で流通している多くの製品はWXGAになっているにょ。
昨年10月4日に書いたようにこのWXGA主流の状況は個人的にはあまりうれしくないもの
となっているにょ。
確かに解像度が上がっても文字が小さくなって読みづらくなるから結局大きな文字
サイズにしてしまうから意味がないとか、そもそもそういう設定方法さえ良くわからない
層も多いから無難に見やすいサイズの文字になるような粗いドットピッチのモニタを
採用しているにすぎないにょ。
そもそもWindowsは基本的には96DPIとなっているため15インチクラスでWXGAというのは
決して間違いではないけどそれは遙か昔のものであり現在の環境に合っているとは
思えないにょ。

Windowsが抱えている問題は互換性を重視しているためスケーリングで解決している
からにょ。
http://pc.watch.impress.co.jp/docs/column/config/20120406_524158.html
Vista以降はDPI変更に対して柔軟になりアイコンサイズなどもドットピッチに合わせて
変更できるようになったとはいえ、問題はアプリの対応にょ。
依然として特定のDPIに縛られているため自由な解像度で表示できるというわけではなく
文字が小さくなったりレイアウトが崩れたりするものも少なくはないにょ。
この辺はAndroidやiOSといったスマホやタブレット端末対応のOSの方が進んでいると
言えるかもしれないにょ。
Windowsでも高解像度液晶モニタを低解像度で使用することは可能だけどその際には
単純に表示画素数を減らしているため高解像度のメリットは全く無くなってしまうにょ。
もっとも、Windowsも次世代となるWindows 8に採用されているMetro Styleでは仮想的な
スケーリングにある程度対応可能になっている模様にょ。

あと問題は高解像度化してしまうとGPU性能がボトルネックになってしまうという可能性が
あるにょ。
確かに新型iPadはそれを懸念してA5XチップではGPU性能を大幅に高めたにょ。
そのせいで消費電力が増加してしまうので駆動時間減少を招いてしまうのを防ぐため
大容量バッテリを搭載して何とか従来機種（iPad2）と同レベルの駆動時間を維持して
いるにょ。
では、現在のPCはどうなのか・・・？
すでに独立GPUではフルHDを大きく越える解像度に対応しているのだけど内蔵GPUでは
次世代（今月正式発表予定）となるIvyBridgeで対応予定となっているにょ。
つまり、IvyBridgeを搭載したモデルが普及することでフルHDを越える解像度に対応可能
となり、独立GPUの搭載が難しい10インチクラスのノートPCでも上記のようなWQXGA液晶を
搭載することが可能になってくるにょ。

10インチでWQXGAになるのであればそれより大きな液晶パネルを搭載のPCや外付けの大型
モニタを使用可能なデスクトップPCではさらなる高解像度を期待したいにょ。
しかし、それに立ちふさがるのがインターフェイスの問題にょ。
現在主流のHDMIはフルHDまでしか対応していない（3D表示においてはフルHDにさえ対応
できなくなる）ためにDisplayPortが必須となるにょ。
しかし、そのDisplayPortであっても対応はWQXGAまでにょ。
複数のポートを同時に使用することでさらなる高解像度に対応させることは可能だけど
それでは一般へ普及させるのは難しいので転送速度を2倍に高めたDisplayPort2がすでに
規格化されているにょ。
このDisplayPort2を使えば4K液晶にも1ポートで対応が可能になるにょ。

長い間ノートPCはWXGAが主流であり、デスクトップPC（外付けモニタ）の主流はSXGA主流
だったのが近年になってフルHDが主流になっている（20〜22インチフルHD液晶モニタが
1万円台前半で購入可能となっている今では設置スペースの問題が無ければそれ以下の
ものをわざわざ購入する意味がない）とはいえ、それ以上はなかなか進まなかったという
ことがネックになっていたにょ。
あとは需要とOSやアプリ面の対応だけが問題にょ。
OSやアプリ面は上記に書いた通りだけど需要においては何とも言い難いにょ。
個人的には作業領域が増えるというだけでもかなり大きなメリットになっているのだけど
それでは一般に訴求するのは難しそうにょ。

しかし、スマホにおいてはWVGA主流からQHD（960x540）やHD液晶（1280x720）へとシフト
しつつあるし、タブレット端末においては新型iPadがQuad XGAになったのを皮切りにして
他社もフルHDもしくはそれ以上の高解像度の端末の投入を予定しているにょ。
そうなると単純に文字だけを比べても表示品質はタブレット端末よりもPCの方が劣るものに
なってしまうにょ。
iPhone4が同じ液晶サイズのiPhone3GSと比べて縦横2倍の解像度になったけどそれは上記の
ように作業領域の拡大ではなく表示の綺麗さに使われているにょ。
そして、それは多くの人に受け入れられているということを考えるとPCにおいても高解像度
へと進むべきだと私は思うにょ。（本当に価格重視の廉価モデルのためにWXGAを残して
おいてもいいけど）
人間の目の分解能は300dpi程度（これは私も自分自身で実験してみた結果、30cmの距離で
300dpi程度というのはほぼ正しいということが間違いでないことが分かった）だけど
10インチWQXGA液晶ならばほぼ300ppiであるためその理想にほぼ合致するにょ。
つまり、10インチWQXGA液晶は（私にとっては）ベストな選択肢といえるためぜひこの
クラスのノートPCが普及して欲しいにょ。（冒頭に書いたように高解像度になれば高価に
なるというものではないため普及してしまえば量産効果でほとんど価格差は無くなる）

ただし、高解像度の方がいいといってもスマホやタブレット端末は自由な距離で閲覧可能で
あるためその限界まで高めても十分にメリットがあるのに対してPCの場合はモニタと
は固定距離で使うことが多いため単純に言えばそこまで高解像度にしても大きなメリットが
あるとは言い難くなってしまうにょ。
30cmの距離で300dpiならば60cmであれば150dpiと同じになってしまうからね。
それを考えると現状のLet'snote Jや一部の高解像度パネルを使用したネットブックの
ような10.1インチWXGAは一般的なPCの使用方法においてはベストな選択肢になると言える
かもしれないにょ。
とはいえ、10インチWQXGAの液晶パネルが量産化されるとなればやはりそれを欲してしまう
からね（笑）
数年後にはノートPCの主流がWQXGA、デスクトップPC（外付けモニタ）の主流が4Kになって
いることに期待したいにょ。
そのための下準備は整っているためにあとは需要次第にょ。

951：御茶目菜子：2012/04/18(水) 15:16:04
Windows8は成功するのか？
コードネーム「Windows8」の正式名称が「Windows8」に正式決定したにょ。
http://pc.watch.impress.co.jp/docs/news/20120417_526937.html
まぁ7の次で8ということで分かりやすいし、すでに「Windows8」の名称で認知度を高めて
いるから妥当な選択だと思うにょ。
やはり、Windowsでやっかいなのはエディションの多さにょ。
特に8からはARM版も加わるために複雑きわまりない形になりかねないにょ。
そこで8では大幅な統廃合が行われたにょ。

　Windows7においては「Starter」「Home Basic」「Home Premium」「Professional」
「Ultimate」の5つあったエディションをWindows8では「Windows8（無印）」と
「Windows8 Pro」の2つに集約したにょ。（7 Home Basicは新興国向けであり日本国内では
流通していなかったためあまりなじみはないけど）
それにARM版となる「Windows RT」が新規に加わる形にょ。
1月12日に問題指摘していたけどARM版は別の付加名称となることで区別が付いたのは
良いことにょ。

Windows RTはWindows搭載のタブレット端末向けにOEM供給されるのみに止まるため個人が
OS単体で入手はできないので選択肢は実質2つにょ。
Windowsは毎回エディションごとの機能差が問題となっていて特にVistaにおいては上位
となるエディション（ただし、金額面において）が必ずしも下位の機能をすべて持っている
というわけではなくエディションごとの差が特に顕著だったにょ。
7ではそれはランク（金額）ごとに差別化されているとはいえ多すぎてその差を把握する
のは一般人には難しかっただけにエディション数を減らすことは良いことにょ。

ただし、64bit版だけではなく依然として32bit版も残り続けるというのはやや保守的に
思えるにょ。
7も多くの機種に64bit版がプリインストールされているという現状を考えると8で64bit
一本に集約するというのは決して時期尚早とは思えないけどそうしないのは動作環境を
下げたことによって32bit版でもメモリに余裕が出てきたということと新興国向けでは
まだ32bit版の需要が大きいということが考えられるにょ。
まぁ動作環境だけを見ればXP末期のNapa世代（CoreSolo/CoreDuo＋945GM）でも動作は
可能だし、画面解像度の制約さえ許せば初期のネットブック（Atom N270＋945GSE）でも
動作は可能だからね。
それらのCPUが64bit非対応ということを考えると32bit版を廃止するのはまだ早いという
考えも分からなくはないにょ。
Windows8は実質WindowsNT6.2であるためVista/7のアプリは基本的に動作するものの
それにARM版であるRTが加わるため互換性の面で32bitを残したとも考えられるにょ。
RTは32bitであるためx86版が64bitに全面移行するのは難しいという保守的な考えも
含まれていると思われるにょ。

Windowsにおいては過去はバージョンアップの度に高スペックを求められてきたにょ。
これはCPU、GPUもだけどメモリにおいてもそれは顕著にょ。
MSが提示している推奨スペックも95が8MB、98が16MB、Meが48MB、2000が64MB、XPが
128MB、Vistaが512MB、7が1GBといった感じでどんどん増加していったからね。
もっともMSの推奨スペックは（7を除き）その4倍くらいが快適に使うための最低ラインと
私は考えているにょ。（XPは無印とSP2以降ではかなり異なるのでXP SP2/SP3においては
4倍ではなく6〜8倍くらい欲しいところ）
それを考えるとVista/7が2GBが実質最低ラインとなると8が4GBが実質最低ラインに
なっても特に高いスペックとは言えないにょ。（7の動作環境がVistaからほぼ据え置きに
なったため昔と比べるとかなり低い感じでありVistaで2GB必要なら7で4GB、8で8GB必要に
なってもまったくおかしくはない）
もしも、そこまでのスペックを要求していたら間違いなく64bit一本に集約されていた
ことだと思うけど実際は動作環境は1GB以上となっており、数字上は7から据え置きに
なっているにょ。（デフォ環境でのOSの消費メモリは2世代前となるVistaよりも少ない
みたいだし）

このことが64bit一本にならなかったというだけではなく将来的にはメモリ（DRAM）の需要
減少を招いていると思われるにょ。
国内で唯一だったDRAMメーカーのエルピーダの倒産は記憶に新しいけどDRAMのみの生産
ではビジネスが成り立たなくなっているためだと言えるにょ。
DRAMのコストダウンをするためにより微細化した製造プロセスを使用し量産効果による
値下げを見込むというのが従来の考え方だったにょ。
1世代微細化すれば単純計算で2倍のビット量になるわけであって簡単に言えば需要が
倍増しなければ「量産効果によるコストダウン」というのは難しいにょ。
確かに90年代から2000年代前半までは上記のようにOSが要求しているメモリがどんどん
増えていたために微細化によるコストダウンはできていたけど近年はVistaでメモリ需要が
増加したものの7はそれほど増えず8でも据え置きとなるとDRAM需要の増加は望めないにょ。
http://pc.watch.impress.co.jp/docs/column/kaigai/20120301_515496.html

それに、Windowsが業界を牽引していくのがどんどん難しい状況になっているにょ。
スマートフォンやタブレット端末といった非PC（x86CPUを搭載していない端末）が徐々に
PCを脅かしているからね。
現時点では依然として新興国を中心にPCの需要は伸びているけどスマホやタブレット端末の
需要増はそれを遙かに凌いでいるにょ。
元々マウスとキーボードで操作するように作られたWindowsはタッチパネルでの操作に
適しているとは言えないためWindows8では従来型のDesktop Styleとは別に新UIとなる
Metro Styleを導入したにょ。
将来Metro Styleの方が主流になってしまえばARMとx86はの垣根もほぼ無くなるためPCと
非PCという上記の定義自体が意味をなさなくなってくるにょ。（もしも区別するならば
x86 CPU搭載PCとARM系CPU搭載PCという感じになる）

そうなるとWindows8において32bit版を残すことが保守的と思われたのがそうではないと
いう考え方もできるようになるにょ。
Metro Styleは32bitでの動作を前提に作られているためか64bit版のWindows8ではMetro
StyleにおいてFlashPlayerが正常動作しないというユーザーの報告もあるくらいにょ。
タブレット端末でもPCでも同じアプリが動作するというのがMetro Styleの最大の強みで
あるため高い互換性を持つ32bit版Windows8を残す必要があるというわけにょ。
他のOSを搭載したタブレット端末に対抗するためにMetro Slyleを普及させたいものの
32bitを前提にした現在のMetro Styleを普及させなくてはならないわけだからね。
そうなると次世代Windowsも64bitの一本化は難しく思えてくるにょ。
Macも近い将来はOS X上でiOS用アプリが動作するようになると思われるにょ。（8の
Desktop StyleとMetro Styleと同じような関係か）
将来（今後5年くらい先まで）はOS XとiOSは完全に統合すると予測しているアナリストも
いるくらいにょ。
それを考えると今回のWindows8はMacOS/iOS端末に対して先手を打ったとも言えるにょ。
ただし、すでに成功を収めているiOSに対してMetlo Styleは実質ゼロからのスタートである
ために厳しい立場だと思われるにょ。
したがって、成功か失敗かというのが判断するためには少なくとも3年くらいはかかるかも
しれないにょ。

952：orirakkusu：2012/04/19(木) 16:13:33
プチコンに日々が吸い込まれて(ry
なんかプチコンに日々というか生活が吸い込まれている...
なんだかんだ言って習い事やめたし。
ところで、XPはメモリなしで使ってました(メモリ入れると起動しなくなった)けど、我慢に耐えるレベルでした。

http://www.geocities.jp/orirakkusu/

953：御茶目菜子：2012/04/20(金) 15:10:01
レスにょ
orirakkusuさんへ
＞なんかプチコンに日々というか生活が吸い込まれている...

確かにプチコンでプログラムを作っていたら時間がどんどん過ぎていくからね。
お陰でプチコンを買ってから他のゲームはほとんどやってないにょ（笑）

＞ところで、XPはメモリなしで使ってました(メモリ入れると起動しなくなった)けど、我慢に＞耐えるレベルでした。

メモリがないとPCが使えるわけがないのでこれはオンボードメモリのみで動作して
拡張スロットにメモリを挿したら起動しなくなると解釈させてもらうとするにょ。
オンボードメモリはXP初期（2001〜2002年）の頃は128MBの機種が多く、中期（2003〜
2005年）の頃は256MBの機種が多く、末期（2006年〜）は512MBの機種が多かったにょ。
初期の128MBは論外として中期以降の256MBならば我慢すれば使えなくはないレベルにょ。

拡張スロットにメモリを刺したら起動しないとなるとメモリを買い換えるしかないにょ。
メモリの世代によって異なるもののDDR2に対応していればパソコン工房などのPCパーツ
ショップで買えば2GBを2000円前後で買えるにょ。（BaffaloやI/O DATAなどのパッケージ
モデルならば1万円前後ということで高価だけど）
ただし、XP世代ならば多くの機種が上限2GBということで2GBのメモリを挿したら上限を
越えてしまい使えなくなるにょ。（最近拡張メモリを買ったのならば「メモリを挿して
使えない」というのはこれが原因かも？）
したがって、無難に1GBのものを買うといいかもしれないにょ。
とはいえ、これがDDR1（DDR266やDDR333）ならば価格が跳ね上がってしまうにょ。

メモリがどれだけ必要かは用途によって全然異なるけど多ければその分だけ快適になる
ことが多いため私はPCのメモリはとりあえず上限まで搭載しているにょ。
昔（90年代）と違って最近はメモリが安いからね。

954：orirakkusu：2012/04/21(土) 09:58:20
パソコンがああああ
おちゃめさんに言われたことをやろうとして、
まずメモリ無しでPC立ち上げたら...
ピーピー
...？どうした？
あああああ....
俺のPCがついにNECロゴとビープ音を出すだけになってしまったorz
しょうがないので、
QRはPetitEditorでQRを作ることにしても、
アイデア.txtが消えた...
どーしよどーしよ

http://www.geocities.jp/orirakkusu/

955：御茶目菜子：2012/04/21(土) 15:56:51
ついに100語突破
「おちゃめくらぶ用語の基礎知識」の登録語数が100語を越えたにょ。
http://ww5.tiki.ne.jp/~ochame/ochamewords.htm

しばらく新用語を追加していなかったのでpixivやお絵かき関係、プチコン関係の用語を
約40語追加したにょ。
まぁこれを見ている（活用している）人がどれだけ居るのか分からないけどここで書いている
雑記の補足用として活用してもらうのを目的として書いているため特に質問や疑問のレスが
無いならば活用してもらっているという解釈をさせてもらうことにするにょ。



orirakkusuさんへ
＞まずメモリ無しでPC立ち上げたら...
＞俺のPCがついにNECロゴとビープ音を出すだけになってしまったorz

先日は「メモリ無しで使っていた」といっていたのでオンボードメモリが搭載されている機種
だと思ったけどそうなるということはそうではなかったということにょ？
まぁメモリ無しで使えるわけがないから当然なんだけどね。
今までちゃんと動作していたのならばメモリをちゃんと挿せば復活すると思うにょ。

＞アイデア.txtが消えた...

消えたというよりも、PCが起動しないためHDD内のデータを見れないというのが正しいかも
しれないにょ。
メモリの故障ならば新しいメモリを挿せばいいけどPS3を持っているならば本体からHDDを
抜き出してUSB接続可能な外付けケースに入れて読み取るという方法もあるにょ。
ただし、XP搭載ならばNTFSでフォーマットされているだろうから無理かも・・・。
したがって、どうしてもそのデータが早急に必要ならばケースに入れたHDDを抱えて友人に
PCを借りるかネットカフェに行ってデータだけを取り出してUSBメモリなどに保存するという
方法があるにょ。
ただし、この方法はPCの分解を伴うためあくまで自己責任で行ってにょ。

956：＠パー：2012/04/22(日) 03:49:01
打ちひしがれています・・・
　メイク・ラヴの数だけ重ねるたびに、利用され見捨てられて行く様な気持ちで途方にくれていました、落ち着いたところで、元の性別に戻ろうか今の性別のままにするのか、思案に暮れています。
　お茶目様はどんな方か思い出したので、ここはひとつやさしく助言をいただければ幸いです。
以上
957：＠パー：2012/04/22(日) 05:21:39
助言、感謝します・・・
確かな助言助かります、自分の年に居直って今の性別ままで良いと覚悟してきました。
大変ご迷惑をかけ大変申し訳ない。
以上

958：orirakkusu：2012/04/22(日) 06:50:12
PCは分解しなくて済むかも...
なぜなら、今までに2回HDがいかれてるから。
むぐう、今回も新しい物を買うか...
メモリは蒸気でやられたのでちーんになってます。

http://www.geocities.jp/orirakkusu/

959：御茶目菜子：2012/04/22(日) 15:05:27
レスにょ
＠パー??さんへ
＞確かな助言助かります、自分の年に居直って今の性別ままで良いと覚悟してきました。

よく分からないけど自己解決したみたいで良かったにょ。


orirakkusuさんへ
＞なぜなら、今までに2回HDがいかれてるから。
＞むぐう、今回も新しい物を買うか...

ということは、今回もHDDがクラッシュしたにょ？
まぁHDDは消耗品ということを考えてこまめにバックアップをとらないと駄目にょ。
私も今までに10回くらいクラッシュしてるからね。

話は変わるけど例のプチコン電子雑誌化計画はDATA文をプチコンの手打ちで作ってると
いうのは本当にょ？
もっともPCがそんな感じではPCで入力してプチコン用に変換は無理だろうけど漢字を
DATA文に16進数で入力するのはかなり大変にょ。
これがGRPならばJISコード入力エディタを作ればDSの画面で見ながら文字入力もできるので
DATA文を手打ちよりは楽になりそうにょ。（あとデータのサイズも半分になるし）
といっても、それでも大変な作業だけどね。（JISコード入力エディタならば25年くらい前に
ポケコンで作ったけど自分で使ったことが一度もないくらいだし）
まぁ26日に間に合わせるならば今からシステム変更はできないだろうけど・・・。
完成を楽しみにしているので頑張ってにょ。

960：わぁぃ@：2012/04/22(日) 17:16:15
(無題)
さすがに学校にDSiは持ってけないので、「99BASIC」というのをSDに入れて持って行くことにしたにゅ。
ここに「99BASIC」を知っている方はいるにゅ？

961：＠パー：2012/04/22(日) 20:50:56
家族に見捨てられた、つらいです。
もう誰からも拒絶されるようになったようです、涙も出ません。
何とか気晴らしでもあればよいと思い書き込みます。

カラオケで歌えなくいのは悲しい交通事故の過去のおかげです。
政治のことは私にはわかりませんしかし両親が選挙に行かしてくれないのです。
お金は、銀行にうんこにたかる金蝿、金蝿えがうるさいと電話で答えてくれたのです。
音楽は聴くことが一番の楽しみです。
ペットは、アメリカンショートヘアのシマが居ます。
絵を描く、各学校に通った妹がいます。
寒いのでストーブつけています。
父は鎌倉に働きにいっているようです、しかし中茶監視員です。
誰だって楽しい人生を送りたいのに私は失恋ばかり、誰でも寂しいものですし無理してることは知っていても、やはりつらいものです。
音楽でも聴いてます。
以上

962：＠パー：2012/04/23(月) 01:54:14
混乱していたようです
　なんと１０年もしくは３０年もたまっていた「おなら」が出たばかり、数日間食べて眠ってやっと落ち着きました、騒がせて大変申し訳ない。
時々は書き込みます。
確かに、CDの方が音が良いですね。
寝起きで眠い・・・
以上

963：orirakkusu：2012/04/23(月) 06:51:35
やろうと思えばPS3でPetitEditorでぶつぶつ
まあ、手打ちです。そんな中、悲劇が
！
帰宅して、さーて今日もやるぞーって
いってタッチペンを取りだそうとした
ら、タッチペンが無い！？！？って悲
劇が...でもあいからわず手打ち(オイ)

@わぁぃさん
あーそれ知ってます！プチコンスレに
荒しが来てそれを一生懸命アピールし
てました！
でも一回GBAなら持ってった。

では、学校に行ってきます！

ただいま帰りました。
なんかPCはNECロゴ→オペれティー
ングうんたらかんたらエラー→自動シ
ャットダウン
って感じです。
ところで、なんとなんと、ビューワー
の仕様を今更変更します！
んで、26日にはどう頭をひねっても
無理なので、5/10の5月号までお待ち
ください(汗)

http://www.geocities.jp/orirakkusu/

964：御茶目菜子：2012/04/23(月) 15:03:01
レスにょ
わぁぃ@さんへ
＞さすがに学校にDSiは持ってけないので、「99BASIC」というのをSDに入れて持って行くことにしたにゅ。
＞ここに「99BASIC」を知っている方はいるにゅ？

昔、少し使ったことがあるにょ。
（センター試験対策などで）旧世代のBASICを使う必要があるとか、旧世代のBASIC（というか
N88BASIC）に慣れていて現在のプログラムミング言語にはあまりなじめないという人には
いいかもしれないにょ。

せっかくなので久々に使ってみたにょ。
上記のCAVEを99BASIC用に移植したにょ。（コピペしてcave.99bで保存すればLOADできる）
速攻で作ったのであまりいいプログラムではないけど・・・。

　◎「CAVE」 for 99BASIC

?? 10 CLS 3:CONSOLE ,,0:WIDTH 64,24
?? 20 P=0:S=0:X=0:Y=60:V=RND (244)
?? 30 P=P+1:W=140-P/10
?? 40 COPY @3,(4,0)-(511,383) TO @3,(0,0),PSET
?? 50 LINE (508,0)-(511,383),40,BF
?? 60 LINE (508,V)-(511,V+W),0,BF
?? 70 A=POINT (67,Y+4)-(Y<-4)-(Y>379)
?? 80 LINE (60,Y)-(67,Y+7),2,BF
?? 90 U=RND (2)*8-4
??100 V=V+U*(U+V>0)*(U+V+W<383)
??110 X=X+(STRIG (0,1))*2+1:Y=Y+X
??120 S=S+INT (ABS (X/2))+1
??130 LOCATE 0,0:PRINT S
??140 WAIT 66
??150 IF A=0 THEN 30
??160 LOCATE 25,10:PRINT "GAME OVER"
??170 LOCATE 25,12:PRINT "SCORE";S
??180 IF STRIG (0,2) THEN 10 ELSE 180

爆発演出や音楽もないチープさは上記のPC版と全く同じにょ（笑）
ちなみに[SPACE]で上移動、[ENTER]でリトライにょ。


＠パーさんへ
＞騒がせて大変申し訳ない。

いえいえ。
また落ち着いたら遠慮無く書き込んでにょ。


orirakkusuさんへ
＞やろうと思えばPS3でPetitEditorでぶつぶつ

PetitEditorが動作するならばPS3で作ってそれをQR経由でプチコンに転送するということが
できてしまうにょ。
まぁプチコンの基本はスタンドアローンでの開発にあるからそういうツールに頼らないという
ことをポリシーにするのは良いことにょ。
便利ツールの存在は知っているけど私も使ったことはないわけだしね（笑）

＞タッチペンを取りだそうとした
＞ら、タッチペンが無い！？！？

よくありがちにょ（笑）
私はタイピングを両手の親指でやっているのでタッチペンを使うことは滅多にないけどね。
ただ、親指タイピングはそこそこ速く入力できるけどミスタイプが非常に多いのが玉に瑕にょ。

＞プチコンスレに荒しが来てそれを一生懸命アピールしてました！

プチコンスレで関係ないものをアピールする必要はないのにね。
99BASICは旧世代のBASICになじみがあれば悪くない言語だけど10年前にサポート終了していて
バグが放置状態だったり、Vista以降のOSには正式には対応していなかったりするので個人的
には他人にはお勧めし辛いように感じるにょ。
まぁバグといってもそれほど致命的なものはないし、自分が趣味で作る程度ならばほとんど
問題はないけどフリーウェアとして公開するならば実行形式（exe）を作成できないのが
ネックとなるにょ。

＞なんかPCはNECロゴ→オペれティーングうんたらかんたらエラー→自動シャットダウン
＞って感じです。

「Operating System not found」のことにょ？
それならばOSの起動情報が読み取れないかHDDの物理的な故障のどちらかだけどHDDに問題が
あるのは明らかなのでHDDを交換した方がいいにょ。

965：御茶目菜子：2012/04/23(月) 15:06:58
GCOPYで横スクロールゲームを作ってみたにょ
プチコン用の新作プログラムの案はいろいろあるけどまずはmkIIで加わったけど使ったことが
ない命令を試してみることにしたにょ。
TALK命令は十分使ったので次に試したのはGCOPYにょ。
これはBASICではそこそこポピュラーな命令で他所に描いたグラフィックを別の所にコピー
することができるためポケコンでいうGPRINT的な使い方もできるにょ。
ただし、気になるのは速度にょ。

というわけで全画面GCOPYを行ってみたところ1.6フレームもかかったにょ。
ただの描画だけでこれだけの時間がかかってしまえば高速なアクションゲームを作るのは
かなり厳しそうにょ。
mkIIではグラフィック面が4面に増えたのでいろいろなことができそうなのにね。
とはいえ、全画面GPAINTは2.3フレームだからそれよりは高速に動作するにょ。
描画だけで1.6フレームかかるといってもどの程度使いものになるかは実際にゲームで使って
みないと判断はできないため簡単なゲームを作ってみたにょ。

というわけでできたのがこの「CAVE」にょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/image/cave.jpg　（プログラムリスト）
http://ww5.tiki.ne.jp/~ochame/petitcom/qr/cave.png　（QRコード PRG:OCHACAVE）

どんどん狭くなってくる横スクロールする洞窟の中をAボタンのみを使用して上下に動かし
当たらないように進むという酔っぱらい系のゲームであり、単純なものにょ。
単純であるからこそ速度の影響が分かりやすいというメリットがあるにょ。
GCOPYでスクロールさせるのは非常に簡単なので1画面では余裕がありすぎるということで
1/2画面という制約で作ってみたけどそれも難なくできてしまったからね。
このゲームはVSYNC2（30fps）となっているわけだけどVSYNC1にしてみればGCOPYの遅さによる
処理落ちが非常に目立ってしまう（上記のように描画に1.6フレームかかっているわけだし）
ということで仕方がないにょ。

しかし、この速度に似合うゲームバランスにしてやれば問題ないというわけでスクロールは
1ドット単位ではなく2ドット単位にして上下の加速度もやや大きめにしたにょ。
それでも、慣れたらほぼ平行移動が簡単にできてしまうためスコアアタック的な要素を強め
上下の移動量が大きい方が高スコアになるようにしたにょ。
このゲームでは当たり判定は中央部分の1ドットしかないためかなり狭い洞窟でもくぐり抜ける
ことができるとはいえそれではスコアがほとんど伸びないというわけにょ。
そのため序盤の簡単なところでいかにスコアを稼ぐかが重要になってくるにょ。（ちなみに
私の自己最高は2540点）

実際のところどの程度遅くてどの程度簡単にくぐり抜けられるのかは実際にプレイしてみる
のが一番分かりやすいということで今回は簡単なゲームということもありPC版も速攻で作って
みたにょ。
http://ww5.tiki.ne.jp/~ochame/cave.zip

私が基本的にPCでゲームを作らないのはどうしてもグラフィックや音楽に費やす手間が増えて
しまうからにょ。
それとリスト短縮（コード短縮）や高速化を行う意味が全くないからにょ。
ソースコードが見えないので短縮する意味がないし、速度は速いマシンを使えば解決できる
だけの問題だからね。そういう意味では環境が固定化されているポケコンやプチコンの方が
いろいろと楽しめるにょ。（プチコンはポケコンと比べるとグラフィックや音楽に対する
手間が増えてしまうけどその点はプリセットデータがあるためそれを使えばポケコン以上に
お手軽に作ることが可能になる）
私にとってゲーム作りそのものがゲームであるため作っている過程が楽しめないとつまらない
ということにょ。

今回はプチコン版の完全移植にするため画面サイズは256x192でいきたかったけどさすがに
それは小さすぎるため2倍の512x384ドットにしたにょ。
画面サイズを2倍にしたためプチコン版の2ドット単位から4ドット単位のスクロールへと
変更しているにょ。
あとはプチコン版と全く同じにょ。（速度も同じになっているはず）
ただし、衝突時の爆発演出がないのも同じということですごいチープ感が漂うにょ（笑）
その上、音楽も無し（プチコンはプリセット音があるためBGM、効果音付きのゲームが非常に
簡単にできる）ということでそういう面でいえば完全移植ではなく劣化移植かもしれないにょ。

GCOPY命令がもう少し速ければそれを使いまくった多重スクロールゲームとかも考えたけど
この速度では使うとしてもかなり限定的にするか、速度が気にならないゲームデザインに
しないと難しそうにょ。
スクロールだけならばBGを使った方が数10倍は速いからね。（スムーズにスクロールしてる
「Petit Scroll（honoP氏制作）」を見た後だとこのCAVEのスクロールはかなりぎこちない）
もっともBGは8x8ドットのキャラ単位で構成する必要があるために今回のCAVEのようにドット
単位で構成された背景データを用意するのはかなり大変にょ。
これがランダムに鏤められた星であればBGを使って多重スクロールというのも簡単にできて
しまうけどどんどん狭くなってくる洞窟を表現するためには計算して配置する必要があるし、
ちゃんとキャラ定義しないといけなくなってしまうためどうしてもプログラムリストが長く
なってしまうからね。
BG＋スプライトが高速なゲームを作る場合にはベターな選択になり、重いグラフィック面を
使ってゲームを作るメリットは手軽さしかないにょ。
お手軽スクロールとお手軽グラフィックキャラ表示がGCOPYのメリットだと思うのでそれが
生かせるゲームにすれば問題ないにょ。

966：orirakkusu：2012/04/23(月) 17:45:12
でもね、でもね
どうせJISに変換するのはPetitEditor
だからねっ！

http://www.geocities.jp/orirakkusu/

967：御茶目菜子：2012/04/24(火) 15:37:58
レスにょ
orirakkusuさんへ
＞どうせJISに変換するのはPetitEditor
＞だからねっ！

その程度ならばプチコンで手打ちならば「ツールに頼ってない」と言っても問題はないにょ。
PCで描いたドット絵を見ながらプチコン上で手打ちするのと同じようなものだからプチコンで
作ったのと変わりはないにょ。

968：orirakkusu：2012/04/25(水) 06:22:00
3DSの更新
今日の午後、3DSの更新が来るそうにゃ。なんかフォルダ機能とパッチ機能
が追加される予定にゃ。さてインターネットブラウザーでたまにフリーズす
るバグは直されているのかにゃ...まあ、そんなこんなで行ってきますにゃ。

ただいま帰りました。
さっそく更新！
便利ですよ、使ってみて下さい！
特にフォルダ機能！

http://www.geocities.jp/orirakkusu/

969：御茶目菜子：2012/04/25(水) 16:54:07
レスにょ
orirakkusuさんへ
＞今日の午後、3DSの更新が来るそうにゃ。

これは楽しみにょ。

＞便利ですよ、使ってみて下さい！
＞特にフォルダ機能！

後から試してみるにょ。
というか無かったのが不思議なくらいにょ。
プチコンもフォルダ管理ができたらかなり楽になるんだけどね。
ファイル数が増えれば増えるほど探すのが面倒になってくるからね（笑）

970：御茶目菜子：2012/04/25(水) 16:55:15
EOS 5D MarkIIIは失敗なのか？
EOS 5D MarkIIIのレビューが公開されているので見てみることにするにょ。
http://dc.watch.impress.co.jp/docs/review/newproduct/20120423_528094.html
EOS 5D MarkIIIについては3月4日に書いたようにライバルと想定されるニコンD800がD700
と比べて別物に進化したのと比べるとEOS 5D MarkIIからの進化は小さいものになっている
けど時代の流れによって着実に進化しているであろうということを想定しバランス重視と
いう結論に至ったにょ。

とはいえ、実際にD800のレビューがあちこちでされるようになってからはD800の人気は
急上昇してしまったにょ。
それはやはり3630万画素という高画素を十分に引き出しているというのが1つの理由だけど
もう1つが犠牲になっていると思われた高感度時の画質も思ったほど悪くはないからにょ。
確かにD700と比べてピクセル等倍で鑑賞すればノイズは目立っているのだけど画素数が
3倍になっているということもあり、D700と同サイズにリサイズしてしまえばそのノイズは
かなり目立たなくなってしまうからね。
現実問題からいって比較する場合はピクセル等倍同士ではなく同一サイズ同士でないと
フェアではないにょ。
これは10年前の200万画素のコンデジの方が今の1600万画素のコンデジよりも等倍で見たら
解像しているからといってもそれを持って10年前の方が高画質（この場合は高解像）かと
言われたらそうではないのと同じにょ。
今のコンデジが等倍ではまともに見れるレベルではないといっても200万画素にリサイズ
すれば10年前のコンデジの等倍と比べても劣るどころか遙かに優れていることが分かると
思うにょ。

前モデルのEOS 5D MarkIIはD700と比べて画素数が多く解像感は非常に優れていたにょ。
その反面高感度画質はD700に劣っていたもののD700と同じ1200万画素にリサイズすれば
高感度画質の差はそれほど大きなものではなくなったにょ。
これは実際に作例比較をしてようやく分かったことなのでカタログスペックから5DMarkIIの
順当進化となる5D MarkIIIがD800に劣っているとは一概には言えないにょ。
したがって、まずはレビューから見てみるにょ。
日中屋外での撮影の場合は5D MarkIIから画素数もそれほど増えてないこともありそれほど
大きな進化があるようには見えないにょ。
センサーよりも測光システムや画像処理エンジンの影響の方が大きいと思われるけどすでに
5D MarkIIで十分なレベルに達していたためそれを上回るレベルであってもそれは見た目で
簡単に分かるレベルの差にはならないにょ。
それにレンズの差も大きいため同一被写体、同一レンズでないと有意的な差は見られない
のではないかと思われるにょ。

やはり、進化の様子が簡単に分かるのは高感度時の画質にょ。
基本感度での撮影の場合は今となってはユーザーの「好み」やメーカーごとの「味付け」の
違いの方が大きいけれど高感度になればなるほどいかにノイズを減らすかディティールを
残すかでメーカー間、機種間の違いがかなり大きくなっているからね。
画素数があまり変わってない場合はセンサー性能の進化を見るときには高感度画質で比較
するのが一番分かりやすいにょ。

　◎NR弱め
　ISO　1600　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/042.jpg
　ISO　3200　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/043.jpg
　ISO　6400　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/044.jpg
　ISO 12800　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/045.jpg
　ISO 25600　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/046.jpg
　ISO 51200　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/047.jpg
　ISO102400　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/048.jpg

　◎NR標準
　ISO　1600　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/054.jpg
　ISO　3200　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/055.jpg
　ISO　6400　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/056.jpg
　ISO 12800　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/057.jpg
　ISO 25600　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/058.jpg
　ISO 51200　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/059.jpg
　ISO102400　http://dc.watch.impress.co.jp/img/dcw/docs/528/094/060.jpg

これを見るとISO3200までならば全く問題ないにょ。
ISO6400もわずかにノイズが目立ち始めるけどまだ十分に実用レベルにょ。
ISO12800からはさすがにNR弱では厳しくなってしまうためNR標準で見てみるとディティールは
やや失われているもののほぼ実用レベルにょ。
ISO25600はディティール損失が大きくなるため縮小での使用が前提となりISO51200以上は
非常用レベルの画質に感じるにょ。
総じて見るならばピクセル等倍で見た場合にはD800よりは確実に高感度性能で勝っているにょ。
ただし、これがピクセル等倍ではなく同一サイズでの比較ならばその差はかなり縮まって
しまうにょ。
それだけD800が予想外に高感度画質で優れていると考えることもできるし、EOS 5D MarkIIIが
3年半の歳月の割にはあまり進化していないと考えることもできるにょ。

高感度重視であればEOS 5D MarkIIからの買い換えも十分にメリットはあるものの現在の
価格を考えるとコストパフォーマンスが良いとは言い難いにょ。
高感度だけではなく連射速度の向上などのプラス要素はあるものの上位となるプロ機で
あるEOS 1DXと比べてバッファサイズが削減されている影響で連射の上限枚数も十分か
どうかは微妙なものとなっているにょ。
やはり、D800の発売開始価格が30万円ならばこのスペックを考えると20万円台半ばでの
発売開始価格が妥当に思えるにょ。（35万円ではさすがに割高感が大きい）
これと同じようなことはEOS 60Dが発売されたときにも言ったけどバランス面は優れて
いてもすでに発売されていた7DとKiss x4と比べて価格面を考慮すると割高に感じて
しまった60Dだけどすぐに価格が下落してそのスペック相応の価格になってからは
お買い得感も高まりおすすめできる機種になったからね。
それと同じことは5D Mrk IIIにもおきる可能性はあるものの上下の価格差（上となる
1DXと下となる7Dとの価格差）が非常に大きいためその間の価格帯に収まっている5D
Mark IIIは金額面は抜きにしてポジション面からすると妥当であり60Dと同じような
立場であるとは言い難いにょ。
そうなるとウワサとなっている5Dの上位となる高画素モデル（EOS 3D？）が30〜40万円の
価格帯で登場する頃にならないと5D MarkIIIの大幅な値下げは期待できないのではないか
と思われるにょ。

さて、5D MarkIIIといえばユーザーの間で問題となっているのが露出計の表示に問題にょ。
http://dc.watch.impress.co.jp/docs/news/20120416_526757.html
これは上部の表示パネルから測光センサーへとわずかに光が漏れている影響でこのような
状態になっていると思われるにょ。
普通に考えるとありえないことだけどやはり先行するD800に遅れを取ることができず急いで
発売した結果が招いてしまったのかもしれないにょ。
ただし、これだけを見ると致命的に見えてしまいそうだけど実際のところ表示パネルから
漏れている光というのはごく微量であるため日中での撮影の場合はほぼ無視できるレベルと
いえそうにょ。
むしろファインダーから逆行する光の方が遙かに大きいと思われるにょ。
上級機では当たり前となっているアイピースシャッターを三脚使用時やライブビューでの
撮影時には必ず使用しているという人ならば気になっても仕方がないけどそうでない人
ならばそこまで気にするレベルではないにょ。（ちなみに私が昔使っていた銀塩一眼レフの
キヤノンA-1にはアイピースシャッターはあるものの現在使っているニコンD50とペンタックス
K200Dにはアイピースシャッターは付いてない）
確かに暗所で使う場合にほぼ真っ暗な状態で表示パネルの照明を付ければ露出は変わって
くるけどそういう場所ではAEの測光範囲外であるためメーカーとしては不具合とは認め
にくいにょ。

とはいうものの「露出が狂うから困る」というのではなく普通では起きないことがこの
価格帯（30万円クラスのカメラ）で起きているということそのものを問題視している人が
大半ではないかと思うにょ。
それに関しては私も同感だけどこの度ようやくキヤノンも対応を開始すると発表したにょ。
http://dc.watch.impress.co.jp/docs/news/20120425_529085.html
どのような内容かは分からないけど「不具合と認めて回収する」というのではなく「気に
している人にたいしてより快適に使えるために改善をする」という感じで希望者のみを
対象に修理（？）を行うものだと思われるにょ。
かなり大きな問題となっていただけにこのままスルーするわけにはいかずトップシェアの
キヤノンだからこそ真摯な対応が迫られていたからね。
これで何とか一安心にょ。
予想外に発注が入り出荷の遅れが起きているD800に対していきなり躓いてしまった感じの
ある5D MarkIIIだけどこれからの情勢に期待したいにょ。

971：orirakkusu：2012/04/26(木) 16:01:41
酷い荒しがプチコンまとめwikiにきたそうです
詳しくは http://wiki.hosiken.jp/petc/?OverFlow をご覧下さい

http://www.geocities.jp/orirakkusu/

972：＠パー：2012/04/27(金) 13:33:44
すごい書き込みですね・・・
こんなに書き込みがあって、頭パンクしませんか？
読める場所がないくらいです・・・それでよいなばよいのだけれど。
今寝起きで寝ぼけているので、コーヒーやかんに目いっぱい作って今から飲みます。
以上

973：＠パー：2012/04/27(金) 14:37:23
ATOKのアカウントを第三者が利用しています。
くたくた・へにょへにょになって来ました・・・
いきなりここでかなり長い間「コーヒー・ブレイク」
以上

974：御茶目菜子：2012/04/27(金) 15:13:11
レスにょ
orirakkusuさんへ
＞酷い荒しがプチコンまとめwikiにきたそうです

wikiは誰でも簡単に編集ができるということがメリットになっているけどそれが今回の
ような荒らしのえさになってしまったにょ。
このような荒らしがもしも今後も頻繁に出るようならばパスワード設定をして編集は
管理人のみとかになりそうにょ。
それだと気軽に公開できるwikiの魅力が大幅にダウンしてしまうし、管理人の負担も
大きくなってしまうにょ。



＠パーさんへ
＞こんなに書き込みがあって、頭パンクしませんか？

大丈夫にょ

975：御茶目菜子：2012/04/27(金) 15:14:27
プチコンで疑似乱数を作る
プチコンには標準でRND関数が備わっておりこれによってA=RND (10)で0〜9の乱数を発生
させることが可能にょ。
普通に使う場合には全く問題ないけどゲームで使用する場合には同じ乱数列の乱数を発生
させることができないという問題があるにょ。
つまり、そのゲームと同じものを再現してプレイができないということにょ。
多くのBASICではRNDOMIZEの引数によって同じ乱数列の乱数を発生可能だし、ポケコンでは
シャープの機種においてはRND（負の数）で同じ乱数列の乱数を発生させることが可能になって
いるにょ。
プチコンの乱数でそういうものがないならば作ればいいだけの話にょ。

一般的なコンピュータによって生成される乱数は計算式によって導かれる疑似乱数になって
いるにょ。
その中で最もポピュラーなのが線形合同法によるものにょ。

　X(N+1)=(A*X(N)+B) mod M

このA、B、Mの組み合わせによって乱数の発生の仕方が最大値や周期が変わってくるにょ。
ここでMが乱数列の最大周期と最大値になるにょ。（実際は剰余であるため最大値はM-1）
例えば X=(X*3+2)%64 という式で考えてみるにょ。
まず使うためにはこの乱数の初期値を決めないといけないにょ。
この初期値によって乱数の発生の仕方が変わってくるけど逆にいえばこの初期値が同じならば
同じ値となるためゲームなどにおいて再現性を持たせることが可能になるにょ。

《　リスト1　》
　ACLS
　X=0
　FOR I=1 TO 64
　　GOSUB @RND
　　? X;
　NEXT
　END
@RND
　X=(X*3+2)%64
　RETURN

上記公式におけるMの値が64ということで64通りの乱数の発生を期待してみたけどよく見ると
同じものが4回タブっているにょ。
つまり、この式は周期16の乱数ということにょ。

次にこの乱数を使って画面上にドットを表示してみるにょ。

《　リスト2　》
　ACLS
　X=0
　FOR I=1 TO 64
　　GOSUB @RND:A=X
　　GOSUB @RND:B=X
　　GPSET A,B,15
　NEXT
　END
@RND
　X=(X*3+2)%64
　RETURN

1周期16の乱数であるため16個のドットが表示されることを期待してみるけど画面上には8個しか
点が打たれていないにょ。

実は線形合同法には以下の2つの問題点があるにょ。
(1) 上位の桁はランダム性が高く下位の桁はランダム性が低い
(2) いくつか組にして使えばランダムではなくなる

(1)リスト1において発生した乱数をよく見ると全部偶数になっているにょ。
線形合同法における乱数は下位の桁は全部奇数、全部偶数、奇数と偶数を交互のいずれかに
なっているにょ。
2進数で表した時には下位Kビットの最大周期は2^Kになるにょ。
下位1ビットだと最大周期が2であるため良くて偶数と奇数が交互になり、悪ければ偶数のみ
しか出なくなってしまうにょ。
下位3ビットを使用した場合は最大周期が8になってしまうため実用性はほとんどない乱数に
なってしまうにょ。
したがって、基本的に線形合同法の乱数は上位から使うのが望ましいにょ。

この線形合同法の問題は分かっていれば回避が可能（発生した乱数を生の状態で下位の
ビットから使うことを避ければ良い）なのだけど市販のゲームでも回避されなかったもの
さえあるからね。
Xbox360用ソフトのカルドセプトサーガはダイスの目が偶数と奇数が交互に出るという
この線形合同法の問題をそのまま抱えた状態で発売されているにょ。（2人でプレイする
場合は片方のプレイヤーはダイスの目が必ず偶数、もう片方のプレイヤーは必ず奇数になって
しまっていた模様）
これは実際にダイスの目という表面上ですぐに分かるものであるため十分なテストプレイが
行われていたら簡単に発覚可能だったけど内部計算に乱数を用いる場合はこのように奇数と
偶数が交互に出ても気づかないにょ。
乱数による自動マップ生成などならばそれほど問題にはならないけれど周期が短いことで
パターンが固定化されてしまうため下位ビットから使うというのはあまり望ましくはないにょ。

(2)これはリスト2の実行結果を見ればよく分かるにょ。
周期16の乱数でも2つ組み合わせれば実際の周期は半減してしまうからね。（三次元座標に
用いた場合にはさらに周期が短くなってしまう）
そのため必要な周期の数倍の周期の乱数が求められてくるにょ。
では、どの程度必要かというと具体的にはジャンルによって変わるので難しいにょ。
ゲームではなく科学技術シミュレーションならば億単位、兆単位の周期でないと使い物には
ならないけどプチコンではそのような用途には用いることはほぼないにょ。
というのも扱える数字の上限が524287だからね。
これは32ビット固定小数点を採用しており、符号1ビット、小数部12ビットで残りの19ビットが
整数部であるためにょ。

メインルーチンがVSYNC1（60fps）で実行するゲームだと30分のプレイで最低でも108000回の
乱数発生が行われるにょ。（敵キャラ8体に乱数を使えばその8倍になる）
そうすると少なくとも周期は10万単位くらいは欲しいところにょ。
また、プチコンにおいては標準のRND関数によってランダムに表示したドットで画面を埋め
尽くすことが可能になっているにょ。

《　リスト3　》
　ACLS
　FOR I=1 TO 524287
　　GPSET RND(256),RND(192),15
　NEXT

プチコン（というかDS）の液晶画面解像度は256x192の49152ドットで構成されているため
すべてのドットを埋め尽くす期待値を計算すると559345回のループが必要にょ。
X座標、Y座標は独立しているため期待値から考えると最低でも100万回程度の周期が必要と
いえそうにょ。
つまり、「RNDの変わりに使えるレベル」となると周期は100万回以上が合格ラインといえる
けど現実問題からすれば線形合同法を使用する限りはそれは不可能にょ。
それは上記のようにプチコンで扱える上限が524287だからにょ。
これが32ビット符号無し整数が扱えるならば下記のものが最大数になるにょ。

　X=(1664525*X+1013904223) MOD 2^32

桁あふれの場合のことを考えなくてもいいために実際はMOD以下は不要にょ。
しかし、上限を考えるとプチコンだと下記のものが最大になりそうにょ。

　X=(X*5+3)%65536

この式だと周期は65536になり、上記の十分とされる100万には及ばないけどかなり使える
レベルにはなりそうにょ。
これを用いて上位8ビットのみを使って画面上にドットを表示してみるにょ。
8ビットの最大数は256であるため座標は0から255になるにょ。
プチコンの画面解像度においてX座標は問題ないけどY座標は収まりきらないため下画面も
使って表示をすることにしたにょ。
524287回のループで埋め尽くせる可能性は低いため2重ループにして最大1億回実行できる
ようにしたにょ。（もっともこの疑似乱数は周期が65536だから無意味だけど）

《　リスト4　》
　ACLS
　X=0:Y=0
　　FOR I=0 TO 9999
　　　FOR J=0 TO 9999
　　　　GOSUB @RND:A=X/256
　　　　GOSUB @RND:B=X/256
　　　　GPAGE 0:GPSET A,B,15
　　　　GPAGE 1:GPSET A,B-192,15
　　　NEXT
　　NEXT
　END
@RND
　X=(X*5+3)%65536
　RETURN

これを実行すると画面には5本の直線が引かれるだけにょ。
線形合同法による乱数はパターン化されておりそのパターンが可視化されてしまったと
いうわけにょ。
この乱数列の周期は65536で上位8ビットだけを見た場合に0〜255の値が一様に発生している
ため画面の多くの部分にドットが表示されるべきなのだけどそれなのに256x5＝1280個のドット
しか描かれないというのはあまりに少なすぎるにょ。
このような状態になっているのは0〜255の数字がほぼ均等に出ているといってもその数字の
組み合わせそのものが少ないと言えそうにょ。（線形合同法のにおける問題の(2)が明確に
現れた形になったということ）
そういった規則性は乱数を一次元的に見ても分からないので2次元もしくは多次元において
検証する必要があるにょ。
その検証は今回やったように2つの数字を組み合わせて使い2次元的な描画を行うことで
視覚的に可能になっているにょ。
このプログラムではドットが表示されているか否かということだけに注目いしているため
ドットの色は白で固定なのだけど色を随時変えることで同じ場所にどの程度の頻度で
ドットを表示しているかというのが視覚的に分かるようになるので下記のように変更して
みるのもいいかもしれないにょ。

　GPAGE 0:GPSET A,B,GSPOIT (A,B)+1
　GPAGE 1:GPSET A,B-192,GSPOIT (A,B-192)+1

このことから疑似乱数を使い下位ビットを捨てて使用するという使用方法をとる場合で
あっても頻度やばらつきは十分にあっても線形合同法の場合は2つの数字を組み合わせて
使用する場合において明確な規則性が出てしまい実用性の面において問題が発生する場合が
あるにょ。
しかし、プチコン標準のRNDでできていることができないというのはさすがに気になるため
これを何とかして改善したいところにょ。

これは線形合同法をやめて非線形合同にする（1次式ではなく2次式にする）とかM系列乱数を
使用するとかいう方法によって解決は可能にょ。
しかし、2次式を使えば扱える上限数値が低いプチコンの場合はOverflowの可能性がさらに
高まるためそれによって公式のMの値（つまり、乱数の周期）を小さくするしかないにょ。
最大に見積もっても周期256回が限界だからね。（X、Y完全に独立した乱数が発生可能で
あっても理論上最大で画面上の128カ所にしかドットを表示することができない）
その点ではM系列乱数ならば非常に優秀にょ。
どんな乱数かを掻い摘んで説明すると予めP個の乱数を配列変数などに確保しておいてその
中で最も古い乱数（新しいものから数えてP番目の乱数）と最新のものから数えてQ番目の
乱数のXORを取りそれを新しい乱数として生成するというものにょ。
リングバッファで確保しておけば処理そのものは単純になるにょ。
この場合はPとQの値で周期は変わるものの最大周期は2＾Pｰ1になるにょ。
さらに線形合同法とは異なり下位ビットも周期の小さい乱数にならないというメリットは
あるもののこれはいくら単純とはいえプログラムに組み込んで使うならばできるだけ短くて
処理の速いものが望ましいからね。
単純で高速な線形合同法で十分な周期やばらつきが得られるならばそれがベターにょ。

では、線形合同法ではこれ以上は無理なのかというとそうではないにょ。
さまざまな方法によって改善は可能だからね。
その1つの方法として私が考えたのはカウンタを併用することにょ。
1回ごとにインクリメントするカウンタを用意すれば座標が1つずつずれていくので理論上
画面をドットで埋め尽くすことが可能になるにょ。（単純なアイデアだけど組み合わせて使用
した場合にランダム性がほぼ無くなってしまう線形合同法においてはかなり効果的だと思う）
カウンタの周期を65536にしてしまえば乱数の周期と重なってしまうため周期は65536になって
しまうけどこれをずらすことで理論上の周期をほぼ2乗にすることが可能になるにょ。（この
カウンタの上限をもっと大きな値にした場合は周期そのものは伸びると考える人もいるかも
しれないけど同じ乱数列をダブって発生させるだけであり実質的な周期は変わらないので
MとM-1が互いに素ならばM-1となる値にするのがベストだと思われる）

《　リスト5　》
　ACLS
　X=0:Y=0
　　FOR I=0 TO 9999
　　　FOR J=0 TO 9999
　　　　GOSUB @RND:A=X/256
　　　　GOSUB @RND:B=X/256
　　　　GPAGE 0:GPSET A,B,15
　　　　GPAGE 1:GPSET A,B-192,15
　　　NEXT
　　NEXT
　END
@RND
　Y=(Y+1)%65535
　X=(X*5+Y)%65536
　RETURN

これを実行すると確かにどんどん埋め尽くされていくもののランダムという感じが全く
せずに明らかにパターン性を感じてしまうにょ。
これは上記の線形合同法の公式におけるAに相当する5が65536に対して小さすぎるためにょ。
これを大きくすれば解決する（たとえば12345とかに変えればかなり自然にドットが描画
されていく）問題だけどそれはプチコンで扱える数字に上限があるため無理にょ。（最大値を
計算すると809095109になってしまい余裕でOverflowになる）
したがって、公式のMの値を小さくするしかないにょ。
そこでMの値は4096にしたにょ。（この4096の理由は後述）
それによって最大100少々までAの値を上げることが可能になり、かなり見た目のばらつきを
持たせることが可能になったにょ。
周期が4096になるAの値はたくさんあるけど実際にドットを表示してみて発生した乱数に
見た目の規則性が最も見られなかった「117」を採用したにょ。

《　リスト6　》
　ACLS
　X=0:Y=0
　　FOR I=0 TO 9999
　　　FOR J=0 TO 9999
　　　　GOSUB @RND:A=X/16
　　　　GOSUB @RND:B=X/16
　　　　GPAGE 0:GPSET A,B,15
　　　　GPAGE 1:GPSET A,B-192,15
　　　NEXT
　　NEXT
　END
@RND
　Y=(Y+1)%4095
　X=(X*117+Y)%4096
　RETURN？

規則性はほぼ無くなり上位8ビットを使う限りは全く問題はないように見えるにょ。
ちなみに771582回のループ（1543164回の乱数発生）で256x256の範囲をドットで埋め尽くす
ことができたにょ。（期待値は764646回なのでほぼ期待値通り）
これならばRNDの置き換えは十分にできそうにょ。
線形合同法による乱数が苦手としている二次元分布にも十分使えると思うのでプチコンで
普通に使う分には特に困ることはないと思うにょ。（再現性が要求されるシミュレーション
とかにも活用できると思う）

これで終わってもいいけどやはり0〜4095の乱数というのは気に入らないため4096で割った
数字を発生させることにしたにょ。
つまり、0以上1未満の乱数ということにょ。

《　リスト7　》
　ACLS
　X=0:Y=0
　　FOR I=0 TO 9999
　　　FOR J=0 TO 9999
　　　　GOSUB @RND:A=X*256
　　　　GOSUB @RND:B=X*256
　　　　GPAGE 0:GPSET A,B,15
　　　　GPAGE 1:GPSET A,B-192,15
　　　NEXT
　　NEXT
　END

@RND
　Y=(Y+1)%4095
　X=(X*479232+Y)%4096/4096
　RETURN

これによって下記の2つのメリットが生まれてくるにょ。

　(1)使いやすい
　(2)上位ビットのみが使用される

(1)は言うまでもないことだけど0〜1の乱数というのは一般的なBASIC言語では非常に
ポピュラーであるため使用に慣れている人も多いということにょ。
これが0〜4095の乱数だとダイスで1〜6の目を表示したいというだけでも4096で一端割ってから
6をかけて1を足して整数化するという手間が加わるにょ。
つまり、4096の約数の乱数を発生させない限りは必ず4096で割るという手間が入ってしまう
ためにそれならば事前に4096で割ったものを発生した方がいいということにょ。

これが4096ではなく8192だったらそういうわけにはいかないにょ。
それはプチコンの小数部は12ビットであるため1/4096単位の数に丸められてしまうためにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/p005.htm#column
丸められたら4096の場合よりも周期が短くなってしまうにょ。
つまり、0〜1の乱数を発生させるという時点で0〜4095の乱数である必要が出てくるわけにょ。

(2)出てくる数字が小数であれば0〜3の乱数が欲しい場合はAに乱数の返り値が入っている
場合はFLOOR (A*4)もしく0 OR A*4 いう方法をとるのが普通だけどこれが0〜4095であれば
A%4という方法をとるのが普通だろうからね。
つまり、下位ビットを優先して使う人が出てくるということにょ。
カウンタを併用することで乱数のパターン性はかなり減ったとはいえ下位ビットにおいては
上記のような小さい間隔の周期性が残されているために下位ビットのみを使うというのは
推奨できないにょ。
わざわざ推奨できない方法をコメントで書くのも何なので普通にかつお手軽に使えるものに
するならばこれがベストだと思うにょ。
C言語の場合<stdlib.h>に含まれるrand関数は線形合同法によるものだけど下位ビットを
捨てて0〜32767の値で返しているので上記のような偶数と奇数が交互出るという問題は発生
しないもののそれでもRAND_MAXの値で割って「事実上0〜1の乱数の状態」にして使用する
ことが推奨されているくらいだからね。

あとプチコンで扱える数字が1/4096単位ならば上限2048や1024の乱数でもいいという考えの
人もいるかもしれないにょ。
確かにそれはそうだけど少しでも周期が長い方がいい（1024にしてしまうと周期は1/16に
なってしまう）わけだし、それだけではなくプチコンで扱える数字が1/4096単位という
ことはそれ以下の数字は無視されるということにょ。
その結果が上記リンク先のコラムに書いている演算誤差に繋がっているわけだけど4096で
事前に割っておくことで普通に使うだけで下位ビットの周期性の短さは演算誤差で打ち
消されてしまう可能性が高くなるということにょ。
つまり、線形合同法の問題点が自然消滅するというわけにょ。
もちろん、わざわざ4096倍して使えば下位ビットの周期性の短さは健在になるけどこれが
100倍とか1000倍とかの「4096の倍数でない」ならば演算誤差で消えて無くなる可能性が
高いくなるにょ。
ちなみにこの乱数の周期は16773120であるため普通にゲームとかで使用していても問題
ないと思われるにょ。（1フレームで8回乱数を発生させても10時間の周期になる）

では、数値的な偏りがどの程度あるのかをモンテカルロ法によって検証してみたにょ。

《　リスト8　》
　X=0:Y=0
　FOR I=1 TO 100000
　　GOSUB @RND
　　A=X
　　GOSUB @RND
　　B=X
　　IF A*A+B*B<1 THEN C=C+1
　NEXT
　? C*4/100000
　END
@RND
　Y=(Y+1)%4095
　X=(X*479232+Y)%4096/4096
　RETURN

これを実行すると「3.14」となりこれは円周率にかなり近い値になっていることから
普通に使用して問題ないレベルだと推測されるにょ。

あと気になるのは速度かもしれないにょ。
10万回ループによって実行してみたところRNDは198フレーム、この疑似乱数は590フレーム
だったにょ。
遅いようなイメージがあるけど1フレームあたりだと169回発生できているためメインルーチン
1回につき8個の乱数を発生させても1フレームの1/20以下の時間で済むにょ。
またこの乱数で使用しているカウンタだけどメインルーチンで他にカウンタを使用している
ならばそのカウンタを使えばY=(Y+1)%4095が不要になるにょ。
その場合はそのカウンタの変数がPの場合は X=(X*479232+P%4095)%4096/4096 とする必要が
あるにょ。
リストが短くなっただけではなく速度も10万回で463フレーム（1フレームあたり216回）と
いうことで1.5倍も高速化可能になるにょ。
プチコンでできるだけ短くで実用になる疑似乱数を求めているならばこれはかなりおすすめ
だと思うにょ。
初期値を与えるのが面倒ならばY=MAINCNTL%4096を入れておけばいいにょ。
X=MAINCNTL%4096/4096を入れてもいいけど「/4096」の分だけリストが長くなるにょ。
まぁ再現性があるのがRNDよりもこの疑似乱数を使う意味があるわけだから初期値を
お任せにしたら全く意味が無くなってしまうにょ。

あとそこまで長期の周期性が求められてない場合でなおかつプレイヤーにとって気分の良い
ばらつきの疑似乱数を発生させる場合には乱数テーブルを用意してそれを読み取るという方法もあるにょ。
1/2の成功確率のイベントに10回連続で失敗とかいうのは線形合同法等の演算による疑似乱数
なら起きてしまう可能性は十分にあるけど予めテーブル化しておけばそれは防げるからね。（もっとも演算による疑似乱数でも完全に一定確率ではなく失敗が続けば確率が上がるように
して期待値が2回になるような設定にすれば良いだけのことだけど）
しかし、そのテーブル化の手間を考えると速度面さえ気にならなければ今回書いた疑似乱数の
方が短いリストで済むと思われるにょ。

今回いろいろと疑似乱数を作ってみて思ったのだけど画面上にドットを表示したときの
様子を見るとプチコンのRNDによる動作によく似ているにょ。
もしかするとプチコンのRNDは線形合同法＋乱数を呼び出すたびにインクリメントという
私が考えた方法と同じような方法によって乱数を発生させているのかもしれないにょ。
上記のように乱数のシードにMAINCNTLのカウンタ用いているために同じ乱数列の乱数を
発生できないと考えているにょ。

再現性のある疑似乱数ということで初期値さえ同じならば環境が違っても同じものを再現が
可能になるにょ。（例えば先日作った横スクロールゲーム「CAVE」でもプチコン版とPC版で
全く同じステージでのプレイが可能になる）
ということで、PCを使って自由な縦横サイズにドットを表示するプログラム（要は上記
リスト7に解像度可変とドットが埋められたかどうかの判定を付けたもの）を作ったにょ。
http://ww5.tiki.ne.jp/~ochame/rand.zip
これを見ればどの程度のバラツキがあるのかはプチコンを持って無くても分かると思うにょ。
また、プチコンを持っている場合は事前にPCでシミュレーションをしておくことで乱数の
初期値をいくらに設定するのが良いのかというのも分かるにょ。（上記プログラムでは
初期値変更の機能まではサポートけど）
ちなみに1024x1024を埋めるのに7099847回のループ（14199694回の乱数発生）が必要で
2048x2048ドットだとこの疑似乱数の最大周期の最後でちょうど埋められるにょ。
さすがに4096x4096だと線形合同法特有のラインが発生してしまう（2048本の線が描かれる）
もののプチコンで使うならば十分だと思うにょ。


《追記》
上記のPC版の疑似乱数プログラムをバージョンアップしたにょ。
オプション機能を付けてX、Yの初期値が設定できるようになったのに加えて疑似乱数の
計算式も3種類が選べるようになったにょ。
今回私が考案した線形合同法におけるカウンタの効果の確認やMAX4096ではなくMAX8192に
変更した場合の違いの確認もできるようになったにょ。
8192と4096の違いは表示ウェイトを10くらいに設定したら4096の方がいかにランダムに
描画されているかということが分かると思うにょ。

976：わぁぃ＠：2012/04/27(金) 20:44:09
(無題)
http://putikonclub.g.hatena.ne.jp/
HTMLて楽しいにゅ。
もし良かったら相互リンクしていただけませんか。

977：orirakkusu：2012/04/28(土) 07:17:13
やりたいこと
やりたいことはたくさんあるけれどまずは電子雑誌を進行しないと...

http://www.geocities.jp/orirakkusu/

978：わぁぃ@：2012/04/28(土) 16:40:00
DS調子悪い
今日、電池切れでもないのに突然消えることが頻発してる。
誕生日(11月)にでも買い換えようと思っていたけど間に合いそうもない。
しかし、DSライトまでのものに比べ引っ越しが手間がかかる。
「3DSへの引っ越し」を使うとデータが消えるという。
どうしよう×2

979：御茶目菜子：2012/04/28(土) 17:16:14
レスにょ
わぁぃ＠さんへ
＞HTMLて楽しいにゅ。

私もHTMLを覚えた頃は新しいタグをどんどん使っていたにょ。
もっともそれはごく最初だけだったので未だに初歩的なタグしか使ってないにょ（笑）

＞もし良かったら相互リンクしていただけませんか。

相互リンクはOKにょ。
リンク先はわぁぃ＠さんの日記ではなく「プチコン大好きクラブ」のトップページで
いいにょ？

＞「3DSへの引っ越し」を使うとデータが消えるという。
＞どうしよう×2

プチコンならば（かなり面倒だけど）すべてQRコードにすればセーブデータが消えても
復活可能にょ。
それ以外はセーブデータに関しては全滅だけどね。



orirakkusuさんへ
＞やりたいことはたくさんあるけれどまずは電子雑誌を進行しないと...

楽しみにしているのでぜひ完成させてにょ。
しかし、（早くて）6月か・・・。
かなり伸びたので期待感は余計に高まるにょ。（とプレッシャーを与えてみたり）

まぁいきなりすごいものを作ろうとせず徐々に完成度を高めていくのが一番だと思うにょ。
これはゲームにおいても言えることだけどまずは完成させないとね。

980：御茶目菜子：2012/04/28(土) 17:17:34
3DSのダウンロード販売は成功するのか？
任天堂が2012年3月期の決算報告を発表したにょ。
http://game.watch.impress.co.jp/docs/news/20120427_529952.html
その中で最も注目されるのがパッケージ版としてリリースされるソフトのダウンロード販売
だと思われるにょ。
すでに3DSは「3DSアプリ」としてダウンロード販売のソフトはあるもののこれはパッケージ
とは異なるダウンロード専用の小規模のゲームとなっているにょ。
WiiウェアやDSiウェアと本質的には変わらないものにょ。
すでにパッケージソフトと同一内容のダウンロード販売はSCEではPSPで実施しており決して
目新しいものではないにょ。
ダウンロード販売うぃデジタルデータ販売という広義の考えでいけば任天堂はディスク
システムの時代で実現しているということを考えると任天堂においてもそれほど新しいもの
というわけではないにょ。（ディスクライターと同じようなシステムはPCソフト販売に
おいても同時期に「ソフトベンダーTAKERU」が登場しており、任天堂のみの先進的なもの
というわけでもないけど）
しかし、8月から任天堂が行おうとしているのは今までに無かった新しいダウンロード販売と
いえるにょ。
それはダウンロード販売では初めて小売り（販売店）を意識したものになっているからにょ。

さて、ダウンロード販売というのは上記のようにすでにPSPでは一定の地位を獲得している
けれど3年前の6月5日に書いたように現状のSCEが行っているダウンロード販売がもしも今後
主流になった場合には下記のようなメリットやデメリットがあるにょ。

◎SCE（ハードメーカー）
メリット・・・コピー対策、中古対策
デメリット・・サーバコスト

◎ソフトメーカー
メリット・・・コピー対策、中古対策、開発の敷居が下がる
デメリット・・販促問題、開発費回収問題

◎販売店
メリット・・・なし
デメリット・・中古というかソフト自体の取り扱いがなくなる

◎ユーザー
メリット・・・新作が安く買える、売り切れの心配がない
デメリット・・購入の敷居が高い、中古で売れない、貸し借りができない、所有感がない
　　　　　　　将来的サポートの不安

ダウンロード販売が主流になった場合は「コピーが氾濫しそう」というのを気にしている
人もいるかもしれないけど現状では物理的にそのゲーム機以外ではプレイできないという
アクセスコントロールがされている程度であり、吸い出しを行った場合はノーガードである
ものが大半にょ。
それを考えるとアカウントに紐つけされておりそれ以外ではプレイできないダウンロード
販売はパッケージソフトと比べて遙かにコピー対策に優れているにょ。
それと同時にメーカーにとってはデメリットも多い中古販売（中古があることで新品ソフトも
売れるという側面があるし、ゲーム市場の裾野を広げているため中古ソフトが単純に新品
ソフトの販売機会を奪っているという単純なものではないけどメーカー側としてはそこまで
考えることはできずデメリットの方が多いと考えている人も多い）の対策としても非常に
有用といえるにょ。

ユーザーにとっては「安く買える」というのがダウンロード販売の最大のメリットに掲げて
いる人も多いかと思うにょ。
確かに中間マージンをカットすることで低価格になっている（問屋や小売りを通さないこと
で安い価格に設定が可能）とはいえ、PSPの場合はせいぜい定価から2割弱の値引きであり
新品発売当初の大手量販店より若干安い程度の金額に止まっているにょ。
ゲームソフトは機種や流通経路によっても変わるけど販売店への卸値は定価の75〜80％に
なっているにょ。（一般的なゲームチェーン店ならばPSPソフトの卸値は定価の78％）
それを考えると定価の2割引以上にすることは容易にできるはずだけどそれはさすがに販売店
からの反発が大きいからやらないだけだと思われるにょ。
店頭販売だと発売日から日数が経ち売れ行きが悪くなったソフトや在庫が大量にあるソフトは
卸値より下げて売ることも少なくないにょ。
そのため定価の2割引程度のダウンロード販売の価格ではすぐに店頭販売の方が安くなって
しまうため価格面のアドバンテージがあるとは言い難いにょ。
それに中古で買えば（基本的に）新品よりも安く買えるわけだし、中古への売却を考慮すれば
人気ソフトは新品ソフトを購入しても実質1000円程度になるためダウンロード販売よりも
通常のパッケージ販売の方が安いという感覚の人も多いのではないかと思われるにょ。

したがって、ダウンロード販売は（現在のSCEのような価格設定では）売り切れがないという
方が価格面よりも遙かにユーザーにとってメリットが大きいと思われるにょ。（従来ならば
1アカウント5台まで使用できるため家族共用アカウントであれば1つソフトをダウンロード
するだけで家族共用ができるというメリットはあったけどそれが昨年11月18日から2台に
減ってしまったためそのメリットはほぼ失われてしまった）
人気ソフトの場合、（これは任天堂ソフトの場合に多いのだけど）分納によって少量ずつ
分散して納品されたり、発注上限数が定められたりしているため予約をしていないと買えない
という場合も少なくないにょ。
マイナーソフトの場合は店頭に並ばない（というか小規模のショップだと1本も発注しない
ソフトも結構ある）ということもあり、こちらも予約しないと買えないことが少なくないにょ。
したがって、それらが無くなり、（サーバダウンしない限り）確実に買えるというのは非常に
大きなアドバンテージといえるにょ。


では、改めて今回の任天堂のダウンロード販売を見ていくことにするにょ。
本格的なダウンロード販売への参入は後発ということでやはり上記のようなデメリットがある
ということは分かっている上での導入となっているにょ。

　(1)決済問題の解決
　(2)販売店にもメリットがある
　(3)ダウンロード販売の認知拡大


(1)ダウンロード販売の最大の問題はこの決済問題にょ。
日本においてケータイ向けのコンテンツ市場がi-mode登場以降急速に拡大したのはキャリアを
通じての決済システムが確立したためにょ。
確かにクレジットカードで決済すれば問題ないかもしれないけどクレジットカードによる購入
にはリスクが付きまとうし、「クレジットカードによる購入そのものが嫌い」とか学生など
自分のクレジットカードを持つことができないというという人も多いと思うにょ。
ゲーム人口の多くが学生ということを考えるとクレジットカードのみの決済では市場を狭めて
しまうのは確かにょ。
ということで、ダウンロード販売のゲームの決済が店頭でできるというのは非常に大きな
アドバンテージになるにょ。

(2)店頭決済ができるだけではコンビニ決済と何ら変わりはないにょ。
コンビニ決済との根本的な違いはその決済によって販売店側に利益があるということにょ。
コンビニ決済はただの「決済代行サービス」であって来店のついでに店頭にある商品を
買ってくれることを期待して行われているにょ。
しかし、ゲーム販売店においてゲームソフトは主力商品でありそれで利益が得られない
ならば経営が成り立たなくなってしまうにょ。
したがって、ダウンロード販売は小売りからの反発が非常に大きなものになってしまって
いるにょ。

では、今回任天堂が行おうとしていることはそれと何が違うのかというと具体的には
店頭で受け渡すものは16桁のダウンロード用のコードのみにょ。
それを元にユーザー自身でダウンロードをすることになるにょ。
ニンテンドーポイントのプリペイドカードと同じく売れた時点で在庫となるPOSA技術が
使われているため予め大量のダウンロード用コードをメーカーから買い取る必要性はなく
在庫がダブつく心配もないにょ。
それだとただの決済手数料を受け取るのと同じだけど違うのは販売店側が自由に価格設定を
することができるということにょ。
店頭販売のパッケージソフトの場合は卸値からどのような価格を付けるのかは販売店に委ね
られているわけだけどそれと同じことがダウンロード販売のソフトでも可能になるという
ことにょ。
もっとも、卸値がある以上はそれ以上の値下げはできないし、在庫がダブつくことがないため
卸値より安く売る必要性はないけどね。

ただ、ここでパッケージ版とダウンロード版で価格を統一することを強制された場合はまた
話が変わってくるにょ。
一時期SCEは販売店側に定価販売を義務づけていたけどこれは再販制度のある書籍やCDなどに
のみ許されていることであり、その義務はすぐになくなったにょ。
それとは異なり定価販売を義務づけているわけではないけどそれでも在庫がダブついている
パッケージソフトを販売したり、広告用に安く仕入れたソフト（問屋に在庫がダブついて
いるソフト）を安く販売することが事実上できなくなってしまうためにパッケージ版と
ダウンロード版では価格を統一することをあくまで推奨に止める程度であり、義務付けては
ならないにょ。

(3)任天堂が現在のダウンロード販売の問題として考えているのがこれにょ。
あとは、ダウンロード販売の方法がよく分からない（もしくはそれ自体を知らない）という
人も結構な割合で存在するだろうからね。
すでにネットを利用してダウンロード購入することに慣れている人ならば何ら問題はないけど
それでは市場が小さくなってしまうにょ。
老若男女幅広い層からの需要がある任天堂ソフトにおいてはやはりそれでは駄目でやはり
店頭での告知が必要にょ。

ただし、ダウンロード販売の認知が高まって決済の問題が克服されたとしてもそれでも
ダウンロード購入そのものに抵抗がある（もしくは良く分からない）という人はそれなりに
いるのではないかと思われるにょ。
そういう人向けに店頭でもダウンロードサービスを行えるようにするのがベターだけど比較的
容量が少ない3DS用のソフトでもすでに容量の小さなものでさえ1Gbit〜2Gbit（128MB〜256MB）
であり、「バイオハザード リベレーションズ」や「NEWラブプラス」などは32Gbit（4GB）に
達しているにょ。
これは4GBのファイルをダウンロードする場合には仮に実効帯域が30MbpsのFTTHでさえ18分
かかり、実効帯域2MbpsのADSLだと4時間半かかってしまう計算になるにょ。
4GBというのはあくまで現在の最高クラスの容量であり、多くが1GBにも達していないのだけど
それでも容量が今後もさらに上がっていくのは確実であり、数年後には4GBは普通レベルと
いう時代になるかもしれないにょ。
それを考えるとダウンロードを店頭ですませるというのは数100Mbpsクラスの超高速回線を
用意しないと難しそうにょ。

任天堂は8月に発売予定のNEWスーパーマリオ以降は自社ソフトのすべてにおいてダウン
ロード版を用意することを発表しているものの今回発表された新しいダウンロード販売の
スタイルもダウンロード販売の問題点のいくつかは克服しているといってもパッケージ
販売の方がより幅広い層に受け入れられることは確実であるためパッケージ販売も併売して
行われるにょ。
やはり、物理的に残したい（パッケージという形として残したい）とか紙の説明書が欲しい
とかいう人もいるだろうしね。


さて、ダウンロード販売における価格面に関してのメリットだけど今回の任天堂のダウン
ロード販売は基本的にパッケージ販売と同一（上記のようにそれを強制させるわけには
いかないけど）となっているにょ。
そのためダウンロード販売の方が安いからダウンロード購入するという人にとってはあえて
ダウンロード版を購入するメリットはないにょ。
しかし、ダウンロード版は安さよりも利便性を求めるユーザーもいるにょ。
カートリッジを差し替えることなく他のゲームがプレイできるわけだしね。
そのためにはSDカードも大容量の物が求められてくるにょ。
1本平均1GBと考えても標準の2GBのものならば1本しか入らないにょ。（システムその他で
2GBすべてが使えるわけではにため）
将来的なことを考えておくとできるだけ容量の大きなSDHCカードが欲しいところだけど
SDHCカードの規格最大容量は32GBであるためそれが限界にょ。
月に1本ずつ購入しても5年で60本になるため32GBでは十分とは言えないにょ。
いっぱいになって消しても任天堂の場合は再ダウンロードできるから問題ないとはいえ
その際には時間がかかってしまうし、その時にはソフトメーカーが消滅したり権利上の
問題でダウンロードできなくなってしまうという可能性を考えるとあまり気軽に消すと
いうことはできないにょ。
複数のSDHCカードを差し替えれば良いだけのことだけどファームアップでSDXCカードに
対応させるのが一番にょ。（ファームアップで対応できないならば2、3年後にはSDXCに
対応したニューバージョンの3DSが登場するかもしれない）

あと任天堂の場合にはダウンロード販売の一番の問題はアカウントではなく本体に紐付け
されていることにょ。
アカウントに紐付けされている場合には本体を故障や紛失してしまった場合にも何度でも
別の本体でダウンロードできるけど本体に紐付けされているためにそれは最初にダウン
ロードした本体以外ではできないにょ。
これが買い換えならば引っ越し機能によって引っ越し元の本体では使えなくして購入した
アプリをすべて移行できるもののその引っ越し元の本体が無いという状況ではどうしようも
ないからね。
つまり、100本のソフトをダウンロードした3DS本体を紛失した場合には3DS本体を紛失
したというのではなく本体と100本のソフトを一緒に紛失したのと同じことになるわけにょ。
今まではあくまでおまけレベルのアプリしかダウンロード販売してこなかった（まぁ
その「おまけレベル」といっている「プチコン」のせいで他のソフトを全くプレイして
いない私のような人もいるため「おまけ」レベルというのは内容のことではなくあくまで
価格面の問題だけど）
1本4000円としても100本ならば40万円を紛失したのと同じになるため今後ダウンロード
販売に力を入れていくつもりならばこの本体との紐付けは見直すべきではないかと私は
思うにょ。


それと今回の発表会ではダウンロード販売への参入だけではなく少しだけWii Uについても
語られたにょ。
スペック等の詳細は6月のE3で明かされるとこのことだけど発売は年末商戦に決まったみたい
だからね。
Wii Uの注目点の1つとなっているスペックだけど28nmの立ち上がりの遅れがある上に3DS
本体の大幅値下げによって大きな赤字を出しているためその利益構造を変える必要があり
コストを重視した設計にする必要があると思われるにょ。
そのためPS3やXbox360を大きく越える性能にするのは難しそうな感じにょ。
PS3と同レベルどころかそれよりも低いと言っているアナリストもいるくらいにょ。
当初よりスペックがダウンするのは残念だけどPS3並の性能があれば少なくとも次世代の
PS（PS4？）や次世代Xboxが登場するまではマルチ対象へと格上げされるため十分に価値は
あるにょ。
それに液晶モニタが付いた新しいコントローラでどのような新しいゲームが登場するのか
という楽しみもあるからね。
DSのような絶対的な勝利は無くても勝機（シェアトップの可能性）は十分にあるのでは
ないかと思われるにょ。

981：＠パー：2012/04/29(日) 00:25:02
お爺ちゃんに、しかられたようなものです。
お爺ちゃんの怒りで風邪をひいたのです、風邪薬飲んでつらいの抑えています、水晶はほかの人に貰ってもらちゃいました、私とっては呪いの石と思いますが、手元にないので昔の自分に戻ってきていています。
いろいろ苦労させてしまったことは、深くお詫びします。
私が持つアカウントは全て第三者に使われるのでアカウント持てません。
寂しくなったらまた書き込みます。
以上

982：orirakkusu：2012/04/29(日) 06:11:06
プチコンmkllの新作は？
気がはやい僕ですので、もう気になっております。
このままいけばmkll SRですかね...

983：orirakkusu：2012/04/29(日) 11:04:04
(無題)
ゲーム探求のドラクエのところ、
本当に3Dがうんたらかんたらっていうような(最初の方)文章の途中に
改行タグの<をわすれたと思われる
BR>がありました。

984：御茶目菜子：2012/04/29(日) 15:51:57
レスにょ
orirakkusuさんへ
＞このままいけばmkll SRですかね...

その次は廉価版のFRとメモリを増やしたMR、通信機能を強化したTRが出るにょ？
まぁ60や80だったらSRで打ち止めになってしまうけど・・・。
さすがに次は3DS用だと思うので大幅な向上が期待できそうにょ。

＞改行タグの<をわすれたと思われる
＞BR>がありました。

よく発見できたにょ。
というか、更新停止しているコンテンツだから私自身も全く見てなかったくらいにょ（笑）

985：orirakkusu：2012/04/29(日) 16:03:30
(無題)
FR=200円
MR=
?FREEMEM
2048
OK
__
TR=
な、な、なんと！
俺の作ったゲーム(近日公開予定
、2人用)が2台の本体でええええ！？
という勝手なよそくでした。

986：わぁぃ@：2012/04/29(日) 20:47:48
電車ゲーム
何かへんだと思ったら背景をスクロールするということに気づいた。
いい感じになってきたけど、今度は停止位置直前で突然ホームが現れるという恐ろしいことに。
ループは%を使ってます。

987：わぁぃ@：2012/04/29(日) 21:40:58
リンクの件
そうです。
トップページであってます。

988：orirakkusu：2012/04/30(月) 09:11:10
俺が知っているマイコン
MZ-80K
PC-8001
ぴゅう太
PC-8001mkll
PC-8001mkllSR
MZ-700
MZ-800
MZ-1200
X1
X1Turbo
X68000
X68030
くらいかな。
ちなみに7/12が誕生日です。

989：orirakkusu：2012/04/30(月) 12:01:37
JavaScript
なんかうまく動かないんですが、見てくれませんか？URLはツイッターのダイレクトメッセージで送ってあります。

990：御茶目菜子：2012/04/30(月) 15:42:16
レスにょ
orirakkusuさんへ
＞俺の作ったゲーム(近日公開予定

楽しみにしているにょ。
私も先日作った疑似乱数を使ったゲームを作る予定にょ。

＞俺が知っているマイコン

私はマイコン世代だったから80年代前半のマシンは大抵電器店の店頭などで触ってるにょ。
当時は店頭に置いているマシンがほとんどBASICが動く状態になっていたため店頭で自由に
プログラミングができたので休日は店頭でプログラミングしまくったにょ（笑）
店頭以外ではは友人が持っていた（当時最新機種の）8801mkIISRとかマイコン部で使って
いた8001mkIでプログラミングしてたにょ。
お金が無くてポケコンを買うのが精一杯だったけどそのお陰でリスト短縮とか高速化の
テクニックは身に付いたにょ（笑）
ポケコンを「電卓」として学校に持ち込んでいろいろなプログラムを入れて休み時間に
みんなで遊んでたりしてたにょ。（あと授業中にプログラミングしたりとか）

＞なんかうまく動かないんですが、見てくれませんか？

Google ChromeとIE8で見たけどちゃんとQRコードが表示されているにょ。
ただし「前のQRへ」「次のQRへ」のボタンを押しても動かないにょ。



わぁぃ@さんへ
＞トップページであってます。

リンクをはっておいたにょ。

＞電車ゲーム

横スクロールゲームにょ？

＞いい感じになってきたけど、今度は停止位置直前で突然ホームが現れるという恐ろしいことに。
＞ループは%を使ってます。

複数パターンの背景を交互に表示してそれで電車が動いているように見せているという
ことにょ？
それならばあとはホームの部分は他の背景と分けて処理をした方が簡単かもしれないにょ。

991：orirakkusu：2012/05/01(火) 15:41:18
ゲームの件
QRをカメラでとったのを公開すると思います。
なにせ下に書いたように
PCがこわれたまんまなので(いい加減HDD買え！)
ね(汗)

992：御茶目菜子：2012/05/01(火) 20:44:37
レスにょ
orirakkusuさんへ
＞QRをカメラでとったのを公開すると思います。

ということは、PS3でQRコードの表示はできるけど生成されるzipファイルの保存や解凍は
できないということにょ？

＞PCがこわれたまんまなので(いい加減HDD買え！)

容量の小さなPATAのHDDで良ければウチに来たらタダであげるにょ。
ゴミみたいなHDDを電車賃を払ってまでもらうような奇特な人はいないだろうけどね（笑）

993：御茶目菜子：2012/05/01(火) 20:47:06
疑似乱数を生かしたゲームは難しいにょ
先日書いた疑似乱数ルーチンを使った1画面ゲームを試しに作ってみたにょ。
といっても、まだ1画面化ができてないので「1画面ゲーム候補」と言った表現が正しいかも
しれないけどね。

タイトル名無し（開発コードA35）←mkIIを買ってから35番目のプログラムという意味
http://ww5.tiki.ne.jp/~ochame/petitcom/qr/a35.png

十字ボタンで左右移動、[A]ボタンでジャンプというオーソドックスなジャンプアクション
ゲームとなっているにょ。
穴に落ちたり障害物に当たらないようにしてひたすら先に進むというゲームだけどジャンプ中
でも左右移動できるためかなりトリッキーなジャンプができるし、当たり判定は中央部分
のみなのでかなり強引に障害物を避けることが可能にょ。

1/2画面に収めるために限界までシンプル化した「CAVE」ほどではないけど極力シンプルに
してみたにょ。
私は1画面ゲームを作る際にはとりあえず普通に遊べる状態のものを作ってから1画面化に
とりかかるのだけどそれは特に制限なく普通に作るだけの方が圧倒的に簡単だからにょ。
この「A35」はゲーム自体は1画面（にする予定）としてはそれなりに遊べるレベルだけど
プレイすればするほど問題点が出てきたにょ。
それは疑似乱数を使う意味があまりないということにょ。

プチコンのRND関数はシードを与えることができず再現性がないため疑似乱数ルーチンは
非常に有用になってくるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/rnd.htm
疑似乱数を使うのは再現性があるということは何度も同じことができるということにょ。
今回はステージデータ生成に疑似乱数を使っているため何度プレイしても同じステージが
できるにょ。
これはステージデータを事前に用意しておけば良いだけのことだけど30fpsで動作している
このゲームの場合には（データ圧縮を行った状態でも）1分当たり1800バイトのデータ量に
なってしまうにょ。
それが、疑似乱数を使えば乱数からステージデータを生成する部分さえあればいいので
大幅なリスト短縮が可能にょ。

しかし、このゲームのようなエンドレス（といってもループ回数を設定している以上は
エンドレスではないのだけど）の場合は再現性のある疑似乱数がネックとなるにょ。
確かにちゃんと計算式が分かっている疑似乱数を使えば他の機種（言語）に移植する際にも
まったく同様の動作が可能になるというメリットはあるものの毎回同じステージデータでは
プレイにすぐに飽きが出てしまうにょ。
したがって、ステージクリア制にしないとそのメリットはあまりないにょ。

あと再現性があるということは攻略法が生まれるということに繋がるにょ。
そのためにはステージを覚えてもらう必要があるためこのゲームでは障害物以外にも背景
（山らしきもの）を描いて覚えやすくしているにょ。
しかし、乱数による自動生成の場合はどうしても攻略性の薄いステージになりがちにょ。
実際このゲームもステージを覚えて攻略ではなくいかに障害物を穴を見てそれを元にプレイ
することが多くなってしまっているにょ。
初見ではクリア不能にみえても攻略方法が分かればクリアできるという難易度のステージを
自動生成するのは至難の業にょ。（乱数の初期値を変えながら何度も試していけばいいけど
エンドレスのゲームではそれも難しい）
このゲームの場合はジャンプはただの放物運動ではなく不規則な軌道を得ることが可能で
あるためあらゆるパターンを検証していたらとてもプチコンではリアルタイム処理は
不可能になってしまうからね。

それと自動生成のゲームの場合はクリア不能なステージができてしまう場合があるという
ことにょ。
このゲームもエンドレスにしているため徐々に穴の間隔が広くなっておりそのうちクリア
不能の状態になってしまうにょ。
ジャンプ可能な幅よりも狭い間隔であってもそのジャンプの軌道上に障害物があったらどう
しようもないにょ。
それを自動的に起きないようにするのは自動生成よりも遙かに難しいし、このプログラム
サイズでは実現が不可能にょ。

というわけで、ゲームとしてはそれなりに遊べるものの疑似乱数をあえて使う意味がない
ために一端没にして次のゲームを作ることにしたにょ。
ぶっちゃけ、新しいネタを思いついたのでこのゲームの1画面化を行う時間があったら
そっちの方の時間に費やしたいというだけのことなんだけどね。
今度はステージクリア制の縦スクロールゲームにょ。
作るのはすぐにできそうだけど果たして1画面化はできるのか・・・？
うまく完成すれば次の講座のネタはこれにするにょ。


さて、明日いよいよプチコンmkIIが最初のバージョンアップを行うみたいにょ。
http://smileboom.com/special/ptcm2/html_bug.php
バグ修正がメインだけどQRコード読み取り時にハードウェアボタンに対応したのはうれしい
限りにょ。
これで片手でマウス、片手でボタンを押すことができ1枚ごとに手を持ち替えて読み取らせる
必要がなくなったにょ。

994：orirakkusu：2012/05/02(水) 16:40:03
おちゃめさんへ
公式くん→Adobe Frash Playerが起動できませんでした。
だってPS3はFlashPlayer9なんだもーん！だからニコニコ動画も見れないのー！しかも.zipを落とそうとするとメディアつなげ言われてUSBのリーダーでWiiのSDに保存してもPCころわれたから解凍できない...
.zipで公開する方法はただ一つ。
「お父さん、PC貸ーして♪」
しかし何回も失敗している。

995：御茶目菜子：2012/05/03(木) 16:13:45
レスにょ
orirakkusuさんへ
＞公式くん→Adobe Frash Playerが起動できませんでした。

ということは、どうやってPTCからQRを表示させているにょ？
「PTC→TXT変換」を使って一端テキストに変換してからしているにょ？（といってもこれは
ブラウザに依存しているのでPS3ではできるのやら）

＞.zipで公開する方法はただ一つ。
＞「お父さん、PC貸ーして♪」

Win98や2000搭載のゴミPCで良ければあげるけど電車賃を払ってまでもらいにくる人は居ないと
思われるにょ。

996：orirakkusu：2012/05/03(木) 17:14:57
PTCじゃなく
ぽちぽち手打ちです！

997：御茶目菜子：2012/05/04(金) 21:00:29
レスにょ
orirakkusuさんへ
＞ぽちぽち手打ちです！

それだと打ち間違いがないように慎重にやらないといけないし、長いリストだと大変にょ。
私もポケコンプログラムは手打ちで公開しているにょ。（ポケコン接続用のPC-98のHDDが
壊れたままであるため）

998：orirakkusu：2012/05/05(土) 10:12:31
大変なのを少しでも少なくするために
今JavaScriptで動くキーボード作ってます！もちろん配列はプチコンキーボードと同じw

999：御茶目菜子：2012/05/05(土) 15:53:03
レスにょ
orirakkusuさんへ
＞今JavaScriptで動くキーボード作ってます！もちろん配列はプチコンキーボードと同じw

プチコンの独自記号も入力できるならば記号入力とかはかなり楽になりそうにょ。
実際にどれくらい記号入力をするかはプログラムによってかなり異なるけど・・・。

私の方は今月に入ってからずっと作っているプチコン用の新作ゲームがようやくほぼ
完成になったにょ。
あとは説明用のページ作成とプレイ動画の撮影のみにょ。

1000：わぁぃ@：2012/05/05(土) 22:48:56
DSi延命工事
とりあえず買い換える前に延命工事しようと思うにゅ。
・LR故障と意図しない電源落ちを修理
・バッテリー交換

1001：orirakkusu：2012/05/06(日) 05:43:13
わぁぃ@さんへ
LR故障にゃら指でボタンを持ち上げ中に向かってヨダレなどが入らないようにして強くふーーってやればいいのにゃ。
普通は原因は埃にゃからね。

1002：御茶目菜子：2012/05/06(日) 16:18:35
レスにょ
わぁぃ@さんへ
＞とりあえず買い換える前に延命工事しようと思うにゅ。

DSiウェアは本体に紐付けされているため本体を買い換えたらアプリもまた買い直す必要が
でてきてしまうからね。

＞・LR故障と意図しない電源落ちを修理
＞・バッテリー交換

DSのLRは壊れやすいみたいだけど私の3DSは買ってからまだ半年ということで今のところ
問題はないにょ。


orirakkusuさんへ
＞LR故障にゃら指でボタンを持ち上げ中に向かってヨダレなどが入らないようにして強くふーーってやればいいのにゃ。
＞普通は原因は埃にゃからね。

それで直ったという人はよく聞くからね。

1003：御茶目菜子：2012/05/06(日) 16:24:01
新作プチコンゲームができたにょ
ここ最近書GCOPYを使ったスクロールゲーム、自作疑似乱数ルーチンなどを書いてきたけど
それらを使った「JUMPING ISLAND」ができたにょ。
http://www.youtube.com/watch?v=QlpOX2vrg1Y
http://ww5.tiki.ne.jp/~ochame/petitcom/jumping.htm
このゲームは、残念ながら1画面ではないものの私のリスト短縮テクニックを駆使している
ために2KB以内（1.9KB、56行）に収まっているにょ。
リストの長さの割には時間がかかったけどこれは実際は逆でリストを短くした分だけ制作に
時間がかかっているにょ。（実際リスト短縮前の基本部分のプログラムは数時間でできた
わけだし）

このゲームを作るまでに至った経緯をまとめると下記のような感じにょ。

　GCOPYでスクロールゲームを作ってみよう
　　↓
　酔っぱらい系ゲーム「CAVE」ができた
　　↓
　CAVEは1/2画面に収まったのでもう少し見た目やゲーム性に優れたものを
　1画面で作ってみよう
　　↓
　ゲーム性を考えると再現性のないRND関数は厳しい
　かといって、ステージデータを別途用意する余裕はない
　　↓
　それならば疑似乱数を作ればいい
　　↓
　コンパクトサイズで周期が長い疑似乱数ルーチンができた
　　↓
　これを使ったスクロールゲームを作ってみよう
　　↓
　疑似乱数を使った横スクロールジャンプアクションゲーム（コードネームA35）ができた
　　↓
　ステージクリア制にしないと疑似乱数の意味はあまり感じられないし
　現状のゲーム内容だと戦略性が乏しい
　　↓
　横スクロールではなく縦スクロールならばZ座標を新たに用意することでキャラの動きの
　自由度が高まり戦略性も高くなる
　　↓
　今回の「JUMPING ISLAND」が完成！

ただし、このゲームは当初は1画面で作る予定だったけど基本部分だけで1KBを越えてしまい
1画面化はかなり厳しくなってしまったにょ。
リスト短縮をどれだけ頑張っても（元のプログラムによほど無駄がない限りは）リストを
半減するというのは無理だからね。
確かに部分的に見れば半分くらいになることはあるけど全体で見ればせいぜい2〜3割削減が
やっとにょ。
つまり29x24行（696バイト）に収めるためには7〜900バイト程度に元のプログラムが収まって
ないと無理ということにょ。（1画面で作る場合には1行29文字制限によって元の部分よりも
長く書かざるを得ない部分があるため1KBのプログラムを1画面にするのは単純に何か機能を
削らない限りはほぼ不可能）

というわけで途中から1画面化はあきらめて「1画面レベルのリスト短縮」を行ったものに
路線変更をしたにょ。
1画面でないならばmkIIのホームメニューから遊べるようにするのは不可欠だし、せっかく
スコア争いが熱いゲームなのだからハイスコアのセーブ機能も欲しいところにょ。
それとせっかくなので少しだけグラフィックもマシにしようという欲も出てしまうにょ。
しかし、あまり長くなってしまってはせっかく事実上ステージデータが不要というこの
アイデアそのものがスポイルされてしまうため2KB未満になるように死守したにょ。
その範囲内では最高のものができたと思うにょ。

このゲームは2KB以内ではなく20KB以内で同じものを作れと言われたらそんなに難しくは
ないにょ。
ステージデータがキャラ単位ではなくドット単位で構成されているというのがこのゲームの
ウリであり、BG画面では簡単にはマネができないもののそれでもドット単位でずらした
キャラをたくさん定義しておけばいくらでも実現可能であるためリストが長くてもいいの
ならば作るのは簡単にょ。
このゲームのステージグラフィックはGFILL2つとGPSET3つで描かれているし、キャラの影も
グリーンスライム（スプライト番号200）のパレット1の灰色版を使って高速に切り替える
ことで影っぽくしているため実際は1つもキャラやスプライト定義をしておらずそれも
プログラムリスト短縮に繋がっているにょ。
もしも、ステージデータも1ステージあたり960バイト分（9ステージなので実際はその9倍）
用意すれば疑似乱数を使わなくても同じものを作れるし、自由に変更が可能になるけど
疑似乱数によってそれが不要になっているというのは大きなリスト短縮に繋がっているにょ。

もっとも、このゲームのステージデータは疑似乱数によるものといっても決して馬鹿には
ならないにょ。
というのもこの乱数の周期は1677万あるため1677万パターンの中から最適なものを選べば
それなりに良いものは見つかるだろうからね。
仮になくてもステージデータ生成の計算式を少し変更すればさらにパターン数は増える
ためにパターン数は事実上無制限にょ。

ただし、その中から最適なものを選び出す作業が問題となるにょ。
そのためには例えば「ステージ1に求めるものは何か？」ということを把握しておく必要が
あるにょ。
ステージ1ならば「簡単」であると同時にチュートリアル的な意味も込められている必要が
あるにょ。
簡単とは何かというと足場が多いことと島と島の距離があまり離れておらず大ジャンプを
行わなくてもクリアできることが重要にょ。（実際このゲームのステージ1は上方向移動を
限界まで使った大ジャンプを使用せずにすむどころか左右移動だけでクリアできるほど
うまい具合に構成されている）
あとは、狭い隙間はジャンプ無しに移動できるということもこの1面でユーザーに知って
もらうためにわずかに離れた島が連続するということも必要となってくるにょ。
私はステージ1だけで100種類くらい試してみたけどその中でもトップレベルに良いでき
だったのがこのゲームに採用しているX=K/11という式にょ。
ステージ1が優れていても他のステージに事実上クリアできないステージがあったらそれで
終わりであるため実際私がクリアしたステージ数は数100ステージにのぼるにょ。
これは基本プログラムを作ることと比べると遙かに大変でだけど大幅なリスト短縮効果に
よってこの大変さの甲斐は十分にあったと思われるにょ。
まぁGWをほぼすべて費やしてしまったけどね（笑）

1004：　：2012/05/07(月) 14:52:23
JUMPING ISLAND
慣れるまでが大変だけど慣れたら楽しい。

1005：御茶目菜子：2012/05/07(月) 15:54:18
レスにょ
名無しさんへ
＞JUMPING ISLAND
＞慣れるまでが大変だけど慣れたら楽しい。

プレイしていただきどうもありがとうにょ。
このゲームは最初の操作面のハードルが高いものの慣れたらクリアは簡単にできるように
なるので全面クリアが余裕でできるようになったらハイスコア争いにも挑戦してみたら
良いのではないと思うにょ。
ちなみに私のハイスコアはステージ1が10876点、ステージ9が7735点にょ。

1006：orirakkusu：2012/05/07(月) 18:45:01
JUMPING ISLAND
かたた...たたた...じゃぼーん　ちっくー！
あ、ちなみにVSYNC 2をVSYNC 1にするとタイニーゼビウスmkllの実機番風になり昔風になります。
ちなみに影がしいたけに見えるのは僕だけですか？

1007：御茶目菜子：2012/05/08(火) 15:59:06
レスにょ
orirakkusuさんへ
＞あ、ちなみにVSYNC 2をVSYNC 1にするとタイニーゼビウスmkllの実機番風になり昔風になります。

GCOPYの速度が遅いのでVSYNC1にしたら処理落ちしまくるためそう見えてしまうのかも
しれないにょ。

＞ちなみに影がしいたけに見えるのは僕だけですか？

スプライト番号200のグリーンスライムのパレット1の色が影には最適と思ったけど白い
ラインが目立っているのでそういう風に見えてしまうのは仕方ないにょ。
これが気になるのならば自分でグレーの楕円をキャラ定義するしかないにょ。

CHRSET "SPU3",32,"0"*64
CHRSET "SPU3",33,"0"*64
CHRSET "SPU3",34,"000DDDDD00DDDDDD0DDDDDDDDDDDDDDDDDDDDDDD0DDDDDDD00DDDDDD000DDDDD"
CHRSET "SPU3",35,"DDDDD000DDDDDD00DDDDDDD0DDDDDDDDDDDDDDDDDDDDDDD0DDDDDD00DDDDD000"

というのをどこかの行に入れれば影っぽく見えるかも・・・。
あまりにリストパフォーマンスが悪く感じたのであえてキャラ定義はせず、既存キャラを流用
したにょ。


某所で見かけた「プチコンコンテスト」（略して「プチコンコン」？）だけど私も昔ポケコン
コンテストを主催したことがあるにょ。
http://ww5.tiki.ne.jp/~ochame/E500/CONTEST2.HTM
プチコンユーザーはこれよりは多いだろうからもっと盛り上がりそうな感じにょ。
参加するならば個人的には1画面部門になるだろうけど大作ばかりでは参加し辛いという人も
いるだろうからHSPのコンテストみたいにデフォのデータのみ使用可でソースコードサイズに
制限を加えた部門が欲しいところにょ。（ちょこっとゲーム部門がこれに相当するのかな？）

掲示板管理者へ連絡 無料レンタル掲示板