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

おちゃめくらぶ掲示板

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


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

さっきは結構降っていたにょ。
また詳しくは明日書くにょ。
1390：天郷思音（わぁぃ＠)：2012/11/20(火) 17:17:59
「ラジコン飛行機プログラム」の1画面化
昨日投稿した、ラジコン飛行機プログラムの1画面化に成功した！
具体的なテクニックを書くと
・ラベルをFORに
・長く、複数の箇所で使う式を変数に代入
・コロンの省略
・BGPUTのパッケージパラメータ文字列

今回1番びっくりしたのはパッケージパラメータだった。
BGPUTは引数が多く、気をつけないとすぐに画面からはみ出てしまう。
このプログラムでは、BGPUTの引数に演算が含まれていたため、それ単独でも画面内に収まらなかった。
そこで効果を発揮したのがパッケージパラメータである。
このプログラムでは、すべてのBGPUTがパレット0、反転なしだったため、そのままパラメータを3つ省略することができた。
それにより、画面内の収められたわけである。
1画面化に限らず、パッケージパラメータはDATAにBGの情報を記述するなどの際には、とても有望であると思う。

1391：御茶目菜子：2012/11/21(水) 00:07:17
レスにょ
天郷思音（わぁぃ＠)さんへ
＞昨日投稿した、ラジコン飛行機プログラムの1画面化に成功した！

1画面化成功おめでとうにょ。
内容的にはシンプルだったので1画面プログラムには最適にょ。

＞1画面化に限らず、パッケージパラメータはDATAにBGの情報を記述するなどの際には、とても有望であると思う。

引数が多い命令の場合は1画面プログラムの1行29文字制限が非常に大きな壁となってしまう
からね。
省略可能なものは省略しないと1画面化が不可能になる場合もあるにょ。

ということで、私もそのプログラムの1画面化にチャレンジしてみたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/image/fli.jpg
キー操作や各種計算も元のゲームと全く同じものになっているはずだけどもしも異なる
部分があったら言ってにょ。
もう少し縮まりそうな部分があるので時間を掛ければもっと短縮できそうにょ。

1392：御茶目菜子：2012/11/22(木) 23:59:49
デスクトップPCが終わりを迎えるとき・・・
Intelの第3世代Core iプロセッサであるivyBridgeが今年の春に発売され今ではほとんどの
機種に搭載されているのだけどすでにPCベンダー向けにその次の世代となるHaswellも出荷
されているにょ。
Intelの場合はチックタックによって製造プロセスの微細化と新しいアーキテクチャの導入を
交互に行うことで毎年刷新を行いかつリスクを減らしているにょ。
HaswellはivyBridgeと同じ22nmプロセスで製造されているものの新しいアーキテクチャの
導入が行われる予定となっているにょ。
そしてHaswellのさらに次の世代であるBroadwellもすでに話題が出ているにょ。
http://pc.watch.impress.co.jp/docs/column/ubiq/20121122_574440.html

Haswellを搭載した製品が登場するのは来年の第2四半期であると予想され、Broadwellはさらに
その1年後であるため2014年の製品に搭載予定のプロセッサ（CPU/GPU）にょ。
Broadwellの最大の特色は電力効率の改善にょ。
Core iプロセッサは登場以降電力効率（ワットパフォーマンス）の向上がかなり行われて
きたけどBroadwellではそれがメインになるということらしいにょ。
そこで大きく変わるのがノートPCでは現在スタンダードとなっているTDP35W枠が廃止されて
Ultrabook向けの10Wもしくは15WというSKUに加えてさらに10W以下のものまで用意される見込み
となっているにょ。
これはUltrabookが登場前から告げられていたTDP10W台のものが主流になるということに
加えてタブレット市場を視野に入れたものと言えそうにょ。

Ultrabookは現時点ではまだ成功しているとは言い難いもののこれは従来とは異なる使い方を
提案したもの（ノートPCユーザーの大半は省スペース型のデスクトップPCとして使っている
ため可搬性が高く起動が速いPCというもののメリットが伝わりにくい）となるわけだし
一般的なノートPCが（新製品でも）3万円台から購入可能なのに対してUltrabookは（安く
ても）5万円前後、中心価格が10万円前後となっているためその価格に似合うものであるか
どうかということが十分にユーザーに伝わってないせいだといえるにょ。
それにようやくUltrabookも各メーカーごとに上下複数の製品を出すようになりユーザーの
選択肢が増えたことが今後はUltrabookの販売数増加に繋がっていくと思われるにょ。
タブレット端末向けとしては10W以下のSKUがあり、これは次世代Atomとバッティングする
感じにょ。（Atomも次世代のBayTrailからは現在のインオーダからアウトオブオーダへと
変更され大幅な性能向上が期待されている）
しかし、タブレット市場は現在より大きくなるのは確実であるためこれは現時点では特に
問題となることはないにょ。

低TDPのCPUはかつて超低電圧CPU（ULV CPU）と呼ばれていたレンジのものだけどそれは低
クロックであっても低TDPということが強いウリとなり高価格なものだったにょ。
実際1V弱で動作する超低電圧CPUは選別品が使われており高価格になっていたのにもそれ
なりの理由があるにょ。
しかし、製造の微細化によって低電圧駆動のCPUは量産化ができるようになったにょ。
45nmの時代（Penrynコア）では低クロックのSKUのものはいわゆるCULVノート用に使われた
くらいであり決して高価なものではなかったにょ。
そして、Broadwellでは14nmにまで微細化され1V弱で動作するものは普通に作れるようになった
ため従来ならば「超低電圧」が「普通のCPU」になったと言えるのかもしれないにょ。
そう考えると低クロック＝低コストとなるため低価格化が進んでいるノートPCにおいて
十分な性能がありながら安価になるというのならばメーカーも採用するのではないかと
思われるにょ。（低TDPだからといって高価格で販売するならばUltrabookのように
プレミアム性のあるノートPC以外には採用しにくい）

ただし、UltrabookがノートPCに占める割合が増加するといっても一般のノートPCがそんなに
簡単に絶滅するとは思えないにょ。
確かに私の感覚から言ってもCore2Duo 2GHzくらいあれば一般的な処理においてCPU性能不足に
なることはほとんどないためIPCが高まっているBroadwellならばTDP10WのSKUでもこのクラスの
性能はありそうにょ。（ゲームやエンコなどの特殊なものを除けばCPU性能よりもストレージ
性能の方がボトルネックになりそう）
もっともそれは「そんなに困ることはない」といってもそれで十分かと言われたら微妙にょ。
恐らく14nm世代のBroadwellではTDP17Wでクアッドコアになり現行のTDP35Wのミドルクラスの
性能には達しそうだけどそれではゲーム用途などでは不満が出てくる可能性も高いにょ。
それはIntelも分かっているのかゲーミングノートPC向けでは47/57WのSKUはBroadwellに
おいても残るとされているにょ。（ただし、それで中間層となる35WのSKUが無くなるという
のはやや疑問ではあるけど）

さて、ここで問題なのはデスクトップPC向けにょ。
どうやらBroadwellは現在デスクトップPCで使用されているLGAでは提供されずBGAのみになる
ということだからね。
これはどういうことかというと現在は例えば自作PCを作る場合にはマザーボードを買って
それに合うCPUを買って自分で組み立てるというのが最初からマザーボードにCPUが乗った
状態で販売されるようになるということにょ。
確かに昔マザーボードと安いCPUを買ってあとから登場するCPUに組み直すということがよく
行われていたにょ。
しかし、最近は新しいCPUを買ってもそれを生かすには新しいマザーボードが必要になることも
少なくないため結局CPUとマザーボードはセットで交換するという場合も多いにょ。
ただし、これは多いというだけであって自作PCならではのパーツ流用がしにくくなるという
のは難点にょ。

ただし、これもすぐに自作PC市場が無くなるというわけではないためBroadwellの世代にも
HaswellリフレッシュとしてHaswellの新製品が継続販売されると予想されているにょ。
それは自作ユーザーにとってはありがたいことだけどその次があるかどうかは微妙にょ。
つまり、「マザーボードを買って別に予算に応じたCPUを買う」という買い方が出来るのは
それほど長くはないということにょ。
これは自作PCだけではなくデスクトップPCの需要減もあるし、デスクトップPCの多くが
一体型であり、ノートPCのパーツを流用したものになっているためこの変更をしても大きな
影響がないというのもありそうにょ。

しかし、x86CPUを作っているのはIntelだけではないにょ。
ということでAMDに期待したいところだけどAMDのロードマップも現在は不安が多いにょ。
http://pc.watch.impress.co.jp/docs/column/kaigai/20121121_574241.html
AMDも昨今はIntelに押されっぱなしの状態でまともに利益が出せてないにょ。
かつて、Athlon64x2がPen4やPenDに圧倒的な優位性を示していた頃はハイエンドモデルは
10万円オーバーの価格付けだったのに今やAMDのハイエンドはIntelのミドル〜ローエンド
クラスと対等となっているからね。
それは製造委託をしているGLOBALFOUNDRIESが製造の微細化が上手くいかずいまだに32nm
より先が見えてない状態であるためにょ。
すでに製造プロセスでIntelに1世代以上の差（2年以上の差）を付けられた状態となっている
AMDだけどかつては1年差だったにょ。
それを何とか挽回するために通常は2年かかる製造プロセスの微細化を1年ごとに行おうと
しているためそれが余計に製造の立ち上がりを困難にしていると思われているにょ。
これがARM系CPUならば他のファウンドリを使うという選択肢もある（AMDもすでに将来を
見据えてARM系CPUの製造を開始しようとしている）けれどPC向けとなる高性能なx86CPU
ではそれも難しいにょ。

さて、通常のノートPCのTDP35Wの枠が無くなってもほとんどの人はその影響を受けることは
ないし、自作PC向けにマザーボードにCPUが載った状態で販売されてもその影響を受ける人は
ほとんど居ないと思われるにょ。（困るのはエンドユーザーではなく販売店側でありセットに
なることで在庫管理が難しくなる）
「かつては、マザーボードとCPUは別々に買って自分でPCを組み立てていた」と昔を懐かしむ
人がそのうち出てきそうなくらいで後は（自作ユーザー以外は）まったく気にならないと
思われるにょ。
個人向け市場では80年代から90年代にかけてはデスクトップPCが主流だったのが2000年代
からはノートPCが主流になり2010年代の今はノートPCからタブレットやスマホへと主導権が
移りそうな時期になっているにょ。
もう、デスクトップPCには主導権を握る力はないということにょ。
やはり、時代の流れには逆らえないにょ。

1393：天郷思音：2012/11/23(金) 20:29:10
レスと報告
挙動そのままとはすごいですね。
PS
「5行パッケージパラメータ計算機」ができた。

1394：御茶目菜子：2012/11/23(金) 23:27:22
レスにょ
天郷思音さんへ
＞挙動そのままとはすごいですね。

自分が作ったプログラムでは自分が許せる範囲内でリスト短縮のために異なった挙動にする
こともある（ただし譲れない部分は妥協はしない）けど他の人が作ったプログラムを
短縮する場合には基本的に挙動そのまんまで短縮しているにょ。
これはポケコンで雑誌に掲載されていたプログラムを高速化していた頃も同じことが言え
掲載プログラムと全く同じ挙動で速度だけを3倍くらい速くしていたにょ。

＞「5行パッケージパラメータ計算機」ができた。

私はパッケージを使う機会がなかったので作る気はなかったけど5行で作るとはなかなかにょ。
29文字x5行ならば最大でも145文字しか使えないからね。
といっても1画面に収めるというルールはないから（改行抜きで）最大99文字x5行の495文字
使えるのか・・・。
せっかく作ったのならまとめwikiには投稿に投稿すればいいけどすでにパッケージパラメータ
生成プログラムはあるのでそれと競合してしまうのがネックにょ。（まぁ用途はダブっても
短いことに価値を求める人もいるだろうし）

1395：御茶目菜子：2012/11/23(金) 23:28:42
テキストエディタを作ってみた
プチコンの1画面プログラムでテキストエディタ「PETIT EDITOR」を作ったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/2page.htm#edit
http://www.youtube.com/watch?v=cLzTmpmXwAI
プチコンですでに発表済みのテキストエディタというと私が知る限りではえいださんの
「簡易テキストエディタ」しかないにょ。
この簡易テキストエディタは「簡易」の名前の通り最大256文字までのテキストが編集できる
のだけどこれはプチコンで標準で用意されているMEMリソース（読み書きができるシステム
変数MEM$）の最大文字数が256文字となっているためにょ。
この簡易テキストエディタは汎用性重視のプログラムであるため4.5KBもあるというのは
問題ないのだけど個人的に気になった部分といえばカーソルと削除の挙動にょ。
カーソルの移動はWAIT 5で固定となっているためやや遅く逆にゆっくりボタン操作をした
場合にはWAIT 5では速すぎる（一度に2文字削除される場合がある）というのに加えて
削除がカーソルの右の文字が消されてしまうからにょ。（一般的には文字間ではなく
文字上にカーソルがある場合にはカーソルのある場所の文字を削除するはず）
改造して使ってもいいのだけどせっかくならば1画面で作ってみようと思ってできたのが
今回のプログラムにょ。

このPETIT EDITORを作るにあたって注意した点は下記の3つにょ。

　(1)ストレスない動作を可能にする
　(2)ファイルサイズを分かりやすくする
　(3)データの活用を可能にする

(1)これが今回最も重視した点にょ。（どんなに高機能、多機能なもツールであっても
動作にストレスを感じさせるようなものでは使いたくなくなるため）
一般的にはカーソルの移動は初回とキーリピートがかかってからでは異なるにょ。
だからこそ素早いカーソル移動も可能だし、1文字単位で正確に移動も可能になるにょ。
これは押してからのフレーム数をカウントすれば簡単に実現ができるにょ。
しかし、それではリストを1画面に収めるのは難しくなるにょ。
そこで考えたのが WAIT 3+!A*!!B*9 という式にょ。
これによって基本的には3フレーム単位で動作しているけど前のフレームでボタンを押して
おらずこのフレームでボタンを押した場合には3+9＝12フレームのウェイト（WAIT 12）と
なるためゆっくりボタンを押した際に誤って2文字削除するということはほとんどなくなる
と思われるにょ。
そして、連続してボタンを押した（もしくはボタンを押していない）時にはWAIT 3になる
ため素早い動作が可能になるにょ。（WAIT 2だと速すぎで思った場所で止まらないことも
あったためWAIT 3にした）

カーソルの動き（点滅）においてはさすがにWAITのみで管理するのは無理があるため別途
カウンタを用いて管理しているにょ。
この点滅だけど点滅サイクルは1秒では遅いので48フレーム分（＝0.8秒）にしたにょ。
それとカーソルの移動中は点滅をしないようにしたにょ。
問題となるのは削除中のカーソルにょ。
反転表示や重ね合わせ表示で下の文字が見える状態ならば常時表示でも問題ないのだけど
それは1画面で実現するのは極めて困難である（BGFではなくSPUやGRPでカーソル表示を行う
必要がある）ため1文字ずつゆっくり削除しているときは点滅を速くして、連続削除している
ときは点滅そのものを無くしたにょ。（カーソルは非表示）
別にこれらはわざわざ書いているようなすごいことではなく普段PCで使っているテキス
トエディタの挙動に（できるだけ短いリストサイズで）近づけるようにしただけのものにょ。
要するに1画面プログラムで無ければできているのが当たり前のことだけどこれを1画面で
実現しているからこそ高い価値があるというだけの話にょ。

あと問題となるのはPCでは[DEL]と[BS]の2つの削除ボタンがあり「文字削除」という観点
だけを見てもそれぞれにメリットがあるため両方の搭載が望ましいのだけど1つ実装する
だけで（1行あたり29文字制限のため）2〜3行必要になるということで両方を搭載はできない
ためにどちらか一方のみの選択を迫られたにょ。（SUBST$によって大幅なリスト短縮が
可能になるかと思われたけど削除では思ったような動作が得られず通常の文字入力にのみ
使用可能だったため[DEL]と[BS]の両方を1画面で実装するのは無理だった）
両方を実際に実装して試したのだけど結局選択したのは[DEL]の方にょ。
これは通常の文字入力や[INS]の仕様上の問題と照らし合わせた結果にょ。

このPETIT EDITORでは基本的に文字は上書きで入力していくけどPCのテキストエディタ
ではデフォで挿入モードになっており、文字入力をした場合には自動的に挿入が行われる
というものが大半にょ。
まぁこれはテキストエディタの仕様ではなく日本語入力システム（要するにIME）の仕様と
なっているにょ。
これは文章を書くのにはデフォで挿入モードがベターだからにょ。
その際に間違えた場合には[BS]を使えば1文字戻りつつ削除可能であるため普通に文字入力を
する場合には[BS]の使用頻度は[DEL]と比べて極めて高いのではないかと思われるにょ。

PETIT EDITORが基本的に上書きで文字入力をしているのはMEM$の編集にはその方が都合が
良いからにょ。
何文字目に何のデータがあるかということが重要であるため挿入によってその場所が移動
してしまうようなことがあると逆に問題となるにょ。
あと文字の挿入は挿入モードへの切り替えではなく1文字スペースを挿入するという仕様に
なっているにょ。
これは上記の簡易テキストエディタでも採用されている方法だけど昔ながらの方法であり
シンプルで分かりやすいにょ。
その挿入の仕様とベストマッチなのが[BS]ではなく[DEL]ということにょ。（余分に挿入
した場合にカーソルを動かさなくても削除できる）

(3)このPETIT EDITORはMEM$の編集や小さなプログラムを書いたりするのを想定しているの
だけどその際に欲しくなるのがファイルサイズ（テキストサイズ）の表示にょ。
これは単純に文字数をカウントするだけなので別に特筆するようなことではないのだけど
これがあるのと無いのとでは文字数に制限があるものを入力する場合の使い勝手が大きく
変わってくるにょ。（上記の簡易テキストエディタではそれが無かった）

このPETIT EDITORではエディタの性質上1行256文字のテキストの編集となっているにょ。
改行を書いてもテキストエディタでは反映されないにょ。（別途活用する場合には改行は
有効になる）
そのため文字入力はカーソルのある場所に自由に行えるような形になっているにょ。
この際に問題となるのはそれによって発生するスペースにょ。
これが文字と文字の間のスペースならばいいのだけど文字の後にあるスペースにおいては
どうするかということが重要なポイントになるにょ。
簡易テキストエディタではデータの末のスペースはセーブ時に自動的に削除となっているけど
MEM$がセーブデータとして活用されるとなるとスペースがデータに含まれる可能性は十分に
あるにょ。
そうなると本来は必要だったデータの末のスペースが削除されるのは好ましくないにょ。

ところがスペースがあるかないかというのは見た目では分からないにょ。（スペースを
示すキャラコード32のキャラをCHRSETで別のものに書き換えるしかない）
しかし、一般的なテキストエディタには[EOF]マークがあるのでそれを付ければいいにょ。
これはリスト短縮によって何とか付けられ他の文字と異なっているのを明確にするため
何とか色を変えることもできたにょ。
これが1画面プログラムでなかったら単に画面にCOLOR 5:PRINT"[EOF]"とするだけで
いい（色を元に戻すためにCOLOR命令はメインルーチン内に2つ必要になる）のだけど
数文字削るのにプログラムの大幅な書き直しが必要になる1画面プログラムでここまで
できたのはリスト短縮の賜だと思われるにょ。

(3)さて、MEM$の編集だけならば簡単だけど最低でもセーブとロードの機能を付けないと
ツールとしては事実上使いものにはならないにょ。（MEM$の内容はCLEARでは消えない
とはいえホームメニューから実行時にはMEM$は初期化されるため）
これは行数制限が無ければサブルーチンで簡単に作れてしまうのだけど1画面ではそんなに
簡単にサブルーチン化はできないにょ。（ラベルを使えばそれだけで1行分が無駄になる）
そこで考えたのがポケコンの2LINE（2行）プログラムでは良く使っていたセーブとロードの
一体化にょ。
メニューからではなく一方通行的にセーブとロード機能を実装するということにょ。
ここでメイン→セーブ→ロードとしても良かったのだけどやはり編集作業がメインになると
ロードを最初に行う可能性が極めて高いためロード→メイン→セーブと実装したにょ。

そこで問題になるのはボタン入力の煩雑化にょ。
セーブをするだびに再びロード画面となるわけだからね。
そこで有効活用できるのがmkIIでは[A]ボタンに[ENTER]キーが割り当てられているという
ことにょ。
これを使えば[A]ボタンを押すだけでロード画面をスキップできる・・・と思いきや
INPUTでは空入力ができないのでLINPUTにしたにょ。
これによって、セーブをして再び編集画面に戻るためには[A]ボタンを2回押すだけで
済むにょ。
これがメニューシステムだと少なくともセーブを選択・確定の操作があるためボタン操作が
2回以上必要となるためメニューシステムと比べて煩雑になってないにょ。（これも機能が
セーブとロードしかないため）

編集したものはセーブ画面を通過することでMEM$として確定されるにょ。
これはうっかり間違えて編集してしまっても確定されないようにするためにょ。（もしも
間違えて編集してもBREAKしてからRUNし直せば編集前のMEM$がそのまま残っている）
それとこのPETIT EDITORでプログラムを作ってもMEM$はあくまで変数でありプログラムに
実際に活用するためにはリテラル型（定数）にする必要があるにょ。
プチコンにおいてそれを唯一実現可能にできるのはファンクションキー経由にょ。
これはKEY 1,MEM$とすれば[F1]にMEM$の内容が入っているからそれをプチコンの編集モード
において[F1]を押すだけでそのリストが入力できるにょ。（実行動画を見てのように改行
マークが含まれるデータならば自動的に改行も行われる）
つまり、256文字以内のプログラムであればこのエディタで書いたプログラムは実際の
プログラムで簡単に活用が可能になるということにょ。
短いけどよく使うルーチンを記述しておけば利便性は極めて高くなるにょ。


さて、このようにこのPETIT EDITORをどのような意図で作ったのかが分かってもらえたと
思うけど私は1画面だからといっても使えないツールでは意味がないと考えているため
自分で十分に実用になるものを作ったつもりにょ。
実行動画の中に出ている1行プログラム「100m走」もこのPETIT EDITORの途中バージョンで
作られたものにょ。

◎1行ゲーム「100m走」
ACLS:T=0WAIT 99BGMPLAY 3FOR X=6TO 174T=T+1X=X-!BTRIG()LOCATE X/6,9?"　人":?T/50,:WAIT 1NEXT:BGMPLAY 5
　　（※「人」は人型のキャラを示す）

様々な実証テストを重ねて作ったので1画面で出来る範囲内としてはこれ以上ないくらいの
できになっていると思うにょ。（今回はMEM$の編集をメインと考えて作ってきたたため
上書き入力＋[DEL]による削除となったのだけど機会があれば挿入モードでの入力＋[BS]の
派生バージョンでも作ってみようかと思う）
ツールの場合は行数（リストサイズ）さえ増やせばいくらでも多機能にできるため1画面
プログラムでは10月28日にも書いたようにどれだけの機能を詰め込めるかということを重視
しているにょ。
もちろん、それらの機能を含有した高性能なツールがあればいくら1画面で作ったといっても
実際に出番はないだろうけどPETIT EDITORで求めていた機能を実装しているプログラムは
プチコンでは無いためその存在価値は十分にあると思うにょ。

ちなみに1画面プログラムコーナーの量が増えすぎて重くなったのでプチコンを購入して
2年目を区切りに今回から別ページにしたにょ。（1画面プログラム2ページ目となる）
このレベルのクオリティの作品を頻発するのは難しい（普通に作れば1〜2時間で出来るような
ものでも限界に挑戦した1画面プログラムならば10時間や20時間は平気でかかってしまう）
けど1ヶ月に1本くらいは作っていきたいと思うにょ。
今のところ9月にPETIT RUN mkII、10月にPETIT KEYBOARD mkII、11月にPETIT EDITORを
発表しているので何とか1ヶ月に1本ペースは維持できているけど一体どこまで続くこと
やら・・・。

1396：御茶目菜子：2012/11/25(日) 23:32:27
ちっちゃいってことは便利だね
一昨日に作ったPETIT EDITORだけどMEM$の編集に主眼を置いて作ったため文字入力は上書き
モードで入力となっており、削除はカーソル上の1文字を消す[DEL]のみと挿入（[INS]）
ボタンによって1文字ずつ挿入していく形となっているにょ。
これはMEM$が主にセーブデータとして活用されているということを考慮したためであり
PETIT EDITORをプログラムの入力用として考えるならばこれがベターとは言い難いにょ。
ということで、挿入モードで入力し、[BS]で削除するPETIT EDITOR type Bを作ったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/2page.htm#edit_b

文字入力のモードが異なるのと削除方法が異なるという以外は通常版と同一にょ。
常時挿入モードで入力するため[INS]ボタンが不要になるということを考えれば大幅にリスト
短縮できそうだけど実際は1行で済んでいた（他の文字列操作の関数を使わずSUBST$のみで
賄えた）文字入力が挿入作業の必要性によって長くなっているため相殺されて実際は1行も
短縮ができなかったにょ。
それでもかなり行末の空白ができたので新たな機能を付けようかとも思ったけどこの量では
それも難しいので通常版と同一仕様としたにょ。

もしも高性能なテキストエディタがあればこのような低機能のテキストエディタは不要かも
しれないけど現時点でそのような高性能なテキストエディタは発表されてないため有用だと
思われるにょ。
それにPETIT EDITORの特徴の1つとしてファンクションキー経由でのやりとりが可能（これは
PETIT EDITORでなくても可能だけどそれを全面に押し出して活用できる形にしているのは
現時点では他にない）になっているからね。

プチコンはポケコン（PC-E500シリーズ）と比べてBTEXT$がないという点が開発において
やや不満に感じているにょ。
BTEXT$はセーブ無しで複数のプログラムを同時編集可能にしてくれる非常に便利な命令なの
だけどこれによってゲームを制作中にグラフィックエディタのプログラムを使用するという
ことも可能になっているにょ。
プチコンでそれと同じようにEXEC "CHRED"なんてやってしまうとセーブしていてないと
パーになってしまうからね。
何度もそういうツールを立ち上げるごとに無駄にセーブをするというのはあまりに好ましく
ないため開発中のプログラムにツールをAPPENDしておくというのがベターだと思うにょ。
制作中のプログラムをセーブせずにPETIT EDITORを使うにはAPPEND "OCHAEDIT"（今回
作ったtype BならばAPPEND "OCHAEDTB"）とした後にPETIT EDITORの先頭行の前にラベル
@PETIT_EDITORなどを付けて制作中のプログラムの先頭行にGOTO@PETIT_EDITORを付けると
いいにょ。（立ち上げない場合はGOTO命令をコメントアウトする）
わざわざGOTOで飛ばなくても一般的なBASICのようにRUN@PETIT_EDITORのように任意の行から
プチコンで実行できるといいんだけどね。

そうやって、制作中のプログラムに一時的とはいえAPPENDするとなるとやはりサイズは
小さい方がいいし、発表する段階で削除するため行数が少ない方が楽にょ。
というわけで、必要最小限の機能を備えた小さいツールというのは多機能でサイズの大きい
ツールと比べて役立つ機会が多いと思われるにょ。

さて、当初は主にMEM$の編集用に作ったPETIT EDITORだけど短いプログラムにも有効活用
できるということで1行プログラムを作ってみたにょ。

「アナログテレビ」　ただのジョークプログラム
FOR I=0TO 1I=0BEEP 1ACLS:?"　"*58"アナログ":FOR J=0TO 999GPSET RND(256),RND(192),13NEXT:NEXT
「簡易お絵かき」　タッチペンで線を描くだけ
ACLS:PNLTYPE"OFF"GPAGE 1FOR T=0TO 1GLINE X,Y,TCHX,TCHY,T*15X=TCHX:Y=TCHY:T=TCHST-1WAIT 1NEXT

1行プログラムはプチコンのエディタではかなり作りづらいのだけどこのPETIT EDITORがある
ことで作りやすさは飛躍的に高くなっているにょ。
この程度ならばPC用のエディタで書けばいいのだけど動作検証をするためにプチコンに入力
する手間を考えるとやっぱり単体で完結する方が有利だからね。
やはり、良く使うツールは単機能で使いやすいものを自分で作るのが一番にょ。

1397：otya：2012/11/26(月) 00:51:44
(無題)
RUNの後はアルファベット以外は使える(RUN<などがエラーにならない)のでCHKCHR使ってサブルーチンでRUN@再現可能かも

1398：御茶目菜子：2012/11/26(月) 23:20:15
レスにょ
otyaさんへ
＞RUNの後はアルファベット以外は使える(RUN<などがエラーにならない)のでCHKCHR使ってサブルーチンでRUN@再現可能かも

そうか・・・その手があったにょ。

(1)画面上から「R」「U」「N」が連続して出現する場所を調べる
(2)「RUN」に続く文字列を読み取りCHR$(0)が出るまでを文字変数に入れる
(3)その文字変数に入っている値が「@」から始まっているならばラベルジャンプ

というアルゴリズムで早速プログラムを作ったけど3行もかかってしまったにょ。
やはり何とか1行にまとめたいところにょ。
というわけでアルゴリズムを考え直したにょ。
別にRUNで始める必要はないので@のみに注目してやることで大幅にリストが削減されて
ようやく1行に収まったにょ。
@から始まってCHR$(0)で終わるまでがラベルとして認識しているわけにょ。

A$=""FOR I=767TO 0STEP-1A=CHKCHR(I%32,I/32)A$=(CHR$(A)*!!A+A$)*!!A:IF A-64THEN NEXT ELSE GOTO A$

RUNの有無は関係なく@しか見てないため[START]ボタンでの起動にも対応することができて
RUN@ラベル、@ラベル[START]のどちらでも任意の場所からスタート可能になったにょ。
これはかなり使えそうにょ。

ということで、最近公開した1行プログラムと合わせて1行プログラムコーナーを作ったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm

1399：御茶目菜子：2012/11/27(火) 23:44:29
WX100はTX1を大幅に越えた！
普段使っているデジカメ（Cybershot TX1）の充電器が無くなってしまったにょ。
部屋の中を探しまくったけど見つからないので近所のキタムラに買いに行くことにした
けど充電器はすべて取り寄せになるとのことにょ。
充電器だけ買っても取り寄せならば5000円以上するだろうし日数もかかりそうなので
すでに電池の裏蓋も壊れてボロボロになっているTX1から買い換えるというのも1つの手
と考えたにょ。
というわけで、充電器を買いに行くつもりが新しいデジカメCybershot WX100を買って
しまったにょ。（Cybershotはこれで4台目、デジカメ全体だと20数台目）
http://ww5.tiki.ne.jp/~ochame/test/wx100.jpg

このWX100は今年の春に発売のモデルとはいえ12800円というのは価格com最安値より安価で
あるためお買い得度は非常に高いにょ。

さて、私が新しいコンデジを買う場合に考慮したのが次の4つの項目にょ。

　(1)屈曲光学系、もしくは厚さ20mm以下の機種
　(2)広角側が28mm以上に対応（望遠側は100mmくらいあれば十分）
　(3)高感度画質に優れる
　(4)USB充電が可能

(1)私はここ最近メインコンデジ（普段の持ち歩き用コンデジ）はずっと屈曲光学系ばかり
だったにょ。
2003年に買ったDiMAGE X20、2005年に買ったNikon COOLPIX S1、2009年に買った
Cybershot TX1のどれもが屈曲光学系だからね。
といっても、実際はその間にも格安新品や中古品で良さそうなのがあったら買っているので
トータル20台以上のデジカメを買っているにょ。
さて、なぜ屈曲光学系に拘っていたかというとやはり一般的な沈胴式のレンズを搭載した
デジカメはそのレンズの部分が真っ先に壊れているからにょ。
持ち歩き用でバッグやポケットの中に無造作に入れておいて知らない打ちに電源が入り
無理な負荷が加わって壊れる場合、部屋の中にケース無しで放置しておいてレンズの
隙間に埃が入って壊れる場合などあるけどそれが屈曲光学系にしてから無くなったからね。

それと昔は沈胴式のデジカメというのはどうしても厚みがあったからにょ。
屈曲光学系は内部でミラーやプリズムによって曲げられているためズームレンズ搭載で
あっても薄く設計できるというメリットがあるにょ。
といってもセンサーの大きさやイメージサークルの大きさの関係上厚さ数mmのスマホで
屈曲光学系というのは難しく薄くてもせいぜい10mm余りとなるため単焦点レンズならば
必ずしも屈曲光学系の方が薄型化できるというわけではないにょ。
昨今は光学設計の進歩によって3〜5倍ズーム程度ならば沈胴式であっても厚さが20mmを
切る機種が増えてきているため「厚さ」という観点では屈曲光学系が沈胴式よりも優れて
いるとは言い難くなっているにょ。
そのため防水カメラのように気密性を高める必要がある機種を除いて屈曲光学系は年々
選択肢が減っていったにょ。（実際は屈曲光学系が姿を消しつつあるというのではなくて
3月13日にも書いたように屈曲光学系と合わせることで高倍率で薄型の沈胴式のデジカメが
登場しているため屈曲光学系が前面に出なくなっただけ）
TX1を買い換えるときにはTX300Vにしようかと思ったけど近所に売っている店は全然無くて
TXシリーズで一番新しいTX20ならば売っていたけど価格は3万円台ということで非常に
高価で買う気は全く起きなかったにょ。

WX100は屈曲光学系ではなく沈胴式なのは選択肢がほとんどないから仕方ないとはいえ
厚みに関しては公称値で21.6mmということで許容限界である20mmをわずかに越えているにょ。
これは光学10倍ズームを搭載しているということを考えると驚異的な薄さだけどずっと
厚さ20mm以下（TX1は16.5mm）の屈曲光学系ばかり持ち歩いていた私にとってはやや厚めと
なるにょ。

(2)TX1で私が最も使用頻度が高いのは広角端（換算35mm）にょ。
とはいえ、実際は35mmでは不満を感じる機会は少なくなくて28mmくらいは欲しいと感じる
ことは多々あるにょ。
逆にTX1は光学4倍ズームで望遠端は140mmなのだけど140mmなんて画角はほとんど使わない
ので100mmくらいあれば8〜9割程度はカバーできる感じにょ。
とはいえ、TX1の世代（2009年）以降はほとんどの機種が28mmまで対応になったにょ。
WX100を見てみると25〜250mmの光学10倍ズームとなっているにょ。
やはり、広角側が25mmというのは非常に大きいにょ。
最近は24mmまでカバーしている機種もそれなりにあるため25mmといってもそれほど広角
という感じはしないものの私のデジタル一眼でも18-55mm（換算27-81mm）であるため
それよりも広角なわけだからね。

(3)高感度画質は普段使い用のコンデジにおいて私が最も重視している項目にょ。
画質が悪い（特に日中屋外の画質は最低レベル）というのが分かっていてTX1を購入した
のは裏面照射CMOSセンサーを搭載によって高感度時の画質の方を優先したためにょ。
私はコンデジで作品を撮るなんてことはなく普段のお出かけ用のスナップや買ってきた
小物撮影、食事撮影などそういう日常的なものであり300万画素でそれなりに撮れれば
問題ないというスタンスだからにょ。
実際TX1はそれに応えてくれたにょ。
日中屋外の撮影は1000万画素で撮影時には等倍では基本感度（ISO125）でも見るに値
しないレベルなのだけど300万画素モードでは苦手な日中屋外でも及第点レベルの画質を
得ることが出来たからね。

TX1が発売された2009年当時は1/2.3インチクラスの極小のCCDセンサーを搭載した機種は
ISO400ですでに破綻がしかかっておりISO100〜200が許せる範囲内だったにょ。
それを考えるとISO400でも十分に使え「手持ち夜景モード」ようなノイズ軽減を行う
連写合成を行えばISO1600でもそれなりに使えるTX1は極めて大きなアドバンテージが
あると感じたにょ。
特に私の手持ちのデジタル一眼であるNikon D50とK200Dは高感度に強いとは言い難いので
ISO1600ではかなり厳しいレベルでしかなくISO1600で300万画素にリサイズ時の画質を比べた
場合はTX1はそれらとそれほど変わらないレベルだったにょ。（1000万画素同士での比較
だとレンズ性能がボトルネックになって同じISO1600でもTX1はK200Dに完敗だけどね）

では、WX100の高感度画質がどれくらいかを実際に撮影してみたにょ。
http://www1.axfc.net/uploader/so/2693366.zip
被写体は上記の写真と同じく本体が入っていた箱にょ。
1800万画素ではISO100であっても等倍では見るに堪えられないレベルなので500万画素
モードで撮影したにょ。（ISO800とISO12800の2枚を無加工で収録）
ISO800で撮影した方は500万画素ということもあって等倍で見てもそれほど大きな破綻は
ないにょ。
細部のディティールはともかくノイズの少なさだけを比較すれば私の手持ちのデジタル
一眼（上記2機種）を完全に凌駕している感じにょ。
ISO12800はさすがに等倍でみると明らかな塗りつぶしであるため実用レベルとは言い難い
けどXGAサイズくらいに縮小するならば十分使えそうなレベルにょ。
APS-Cセンサーと比べて約1/13という極小センサーでここまで表現できれば立派ではないか
と思われるにょ。（単純計算ではAPS-CでISO102400より無理があるわけだし）
それ以前に私の手持ちのデジタル一眼はいずれも最高感度設定がISO1600までとなっている
ため高感度での撮影はできないにょ。
マニュアル撮影してRAW現像の際に増感するという方法もあるけど単にノイズが増すだけで
ISO12800相当を実現させようとしたらWX100に完敗は間違いないにょ。（WX100が極小
センサーなのにISO12800でそこそこ撮れているのは公式サイトで記されているように
4画素混合をして感度を高めた後に超解像で全画素に引き延ばしているためみたい）

(4)USB充電に関してはここ1年くらいの機種においては多くの機種が対応しているにょ。
とはいえ、USB充電と一口でいっても専用端子に専用ケーブルで充電するという機種も多い
ため厄介にょ。
ちなみにWX100は通常のマイクロUSBであるため100円ショップに売っているようなケーブルを
使って充電も可能となっているにょ。
これがTXシリーズだと最新のTX20でもAV出力兼用であるため専用ケーブルが必要になって
いるにょ。（TXシリーズだとTX300VのみマイクロUSBによるUSB充電が可能）

さて、USB充電に拘るのはバッテリ切れ対策のためにょ。
昔だったら乾電池駆動ができる機種を買うという選択肢もあったのだけど昨今は乾電池
駆動が可能な機種というのは安価な入門機くらいしかなくなっているにょ。
小さくもない光学手ぶれ補正もないようなデジカメなんて今更買う気は起きないため
乾電池駆動というのは今となっては選択肢として存在しないといっても過言ではないと
いえるにょ。（私がK200Dを買ったのはそこそこハイスペックで乾電池駆動が可能であった
ことが大きいけど今はデジタル一眼において乾電池駆動が可能な機種は絶滅している）
そうなると、モバイル環境下でも充電が可能となるとやはりUSB充電が可能というのが
重要となってくるにょ。
これは昨今のスマホはAC電源＋クレードルを使わないと充電できないようなものだったら
どれだけ不便かを考えると想像が付くと思うにょ。
スマホの普及によってUSB給電が可能なモバイルバッテリも選択肢が非常に増えてしかも
安価になっているためこれに対応しているのとしていないのとでは雲泥の差があるにょ。

私は普段持ち歩いているモバイル機器はすべてUSB充電が可能になっているにょ。
その中でコンデジであるTX1だけがUSB充電ができなかったにょ。
8月に上京した際にはTX1が真っ先にバッテリ切れ状態になり充電器も持ってきてなかった
ためにほとんど撮影ができなかったからね。（デジタル一眼も持ってきていたからメイン
撮影はそちらで行ったけど）
他の機器においてはUSB充電が出来たのでバッテリ切れを起こすことなく2日間過ごすことが
できたにょ。


ということで、WX1は高感度画質、USB充電、レンズの画角においては満足だけど厚さにおいて
やや不満という感じにょ。（この厚さにおいては厚さを重視している私だからこうなった
というだけであって、少なくとも光学10倍ズームを搭載している中ではトップレベルの薄さと
なっている）
あと上記には記してないものの(5)としてSDHC/SDXCに対応も挙げようと思ったけど今売られて
いるコンデジで対応していないようなものを探すのが大変なレベルなのでこれはあえて除外
したにょ。
しかし、TX1はSDHCにさえ対応しておらず、MS Duo専用となっているにょ。
TX1がソニーのデジカメとしてはSDHCに非対応の最後発となっているためそれ以降の機種は
SDHCに対応しているのがやはり悔しかったにょ。
そういう意味ではSDXCにも対応しているWX100は不満はないにょ。
これで12800円ならば十分お買い得と言えそうにょ。（色がシルバーしかなかったという点が
不満なくらい）
WXシリーズの最新モデルであるWX170が17800円だったけどタッチパネル搭載と液晶が異なる
という程度の差であり価格差ほどの価値は見いだせなかった（というか財布の中にそれだけの
お金が入ってなかった）ためWX100にしたにょ。
まぁタッチパネルの使いやすさはTX1でよく分かったからWX170も良かったけどTXと差別化を
していたダイヤルやボタンも無くしてしまったのが残念にょ。

1400：たぼ：2012/11/28(水) 19:39:36
もしかして・・
屈曲光学系では？屈折光学と対になる言葉は、僕の中では反射光学なので・・・

1401：御茶目菜子：2012/11/28(水) 21:57:20
レスにょ
たぼさんへ
＞屈曲光学系では？屈折光学と対になる言葉は、僕の中では反射光学なので・・・

指摘どうもにょ。
確かに日本語の意味合いからするとそれが正しいにょ。
どうやら最初に「屈折光学系」という言葉を見て間違えて覚えてしまった模様にょ。
しかし、10年以上間違えたまま気づかなかったとは・・・（笑）

それと私が書いた雑記を見て間違えて覚える人が居ないように昨日書いたものにおいては
修正をしておいたにょ。（それ以前のものはCookieがないため無理）

1402：御茶目菜子：2012/11/30(金) 23:57:07
デジタル一眼を買うならばやっぱりフルサイズか・・・？
今日はEOS 6Dが発売されたにょ。
これによってD600で先行するニコンとキヤノンのフルサイズ合戦がいよいよ激戦化して
きたにょ。
現時点の価格comの最安値はD600ボディが163110円、EOS 6Dボディが170157円となって
いるにょ。
EOS 6Dの方が若干高価ではあるもののすでに発売から2ヶ月経ちある程度価格が下落
したD600と比べて本日発売されてまだ高値の6Dの価格を見て単純に比較することはでき
ないにょ。（今すぐ買うという人ならば現状の価格が重要だけどしばらく経って買うと
いう人ならば価格が逆転の可能性は極めて高い）

EOS 6Dレビュー
http://dc.watch.impress.co.jp/docs/review/impression/20121128_575460.html
D600レビュー
http://dc.watch.impress.co.jp/docs/review/newproduct/20120928_562710.html
両者のスペック比較については9月18日にすでに書いているのでそれを参考にしてにょ。

銀塩時代は「フルサイズ」という呼び方はほとんどされることが無かったにょ。
これはすでに普及していた35mmフィルム（ライカ版）を基準としたものであり一眼レフは
ほぼすべてが35mmフィルムを採用していたからにょ。
一眼レフでも古くはPENTAX オート110のような110フィルム搭載機とかオリンパスPENの
ようなハーフサイズ（1枚につき35mmフィルムの半分を使用し1本で2倍の枚数撮影を
可能にしたもの）を搭載したものもあったものの35mmフィルムを採用したものが圧倒的
多数でありそれが業界のデファクトスタンダードになっていたにょ。

コンパクトカメラにおいてはどうかというとこちらも110フィルムやハーフサイズの
ものがあったもののやはりメインは35mmフィルムだったにょ。
つまり、コンパクトカメラも銀塩時代はフルサイズが当たり前だったといえるにょ。
しかし、1996年に登場したアドバンスフォトシステム（APS）によってそれは変わって
きたにょ。
装填が簡単なカートリッジ式になり、サイズも小さくなり、撮影情報をフィルム面に
磁気記録可能になるなど銀塩写真において大きな変革となったにょ。
コンパクトカメラはこのAPSフィルムの登場によって35mmフィルムから一気に変わる
ことになったにょ。
筐体もコンパクトになったというのが最も大きいにょ。（私も初代の銀塩IXYを使って
いたけど当時は感動的に小さかった）
コンパクトカメラはレンズと一体型であり、レンズの小型化の恩恵が十分にあったけど
一眼レフの場合はそのマウントによるレンズ資産があるためそう簡単には方向転換が
できないにょ。
APSフィルムを採用された一眼レフも一応は発売されたもののAPSのメリットを生かす
ことができずすぐに消えてしまったにょ。

では、なぜデジタル一眼はAPS-C（APS規格のCタイプ）サイズが主流になったかというと
やはり一番の問題はコストにょ。
大型のセンサーは歩留まりが非常に悪く1999年に登場したNikon D1はAPS-Cという当時と
しては非常に大型のセンサーを搭載したものの定価65万円という価格であっても破格の安さ
と感じた人が多かったくらいにょ。
このD1以降はAPS-Cがデジタル一眼の標準フォーマットとして定着していくことになった
もののデジタル一眼のレンズは35mmフィルム基準で作られたものが多いということが
問題となってくるにょ。
それはカバーしているイメージサークルの問題もあるけど焦点距離が約1.5倍になって
しまう（キャノンの場合は一回りセンサーが小さいので1.6倍となる）ことがAPS-Cサイズ
センサー搭載のネックだったにょ。（望遠撮影主体の人にはいいけど広角側がほぼ絶望的）
これはデジタル一眼が普及するにつれてAPS-C専用のレンズが登場することで解決して
いくことになるにょ。
キヤノンだと2004年にEOS 20Dが発売以降はAPS-C専用となるEF-Sマウントのレンズが登場
していったにょ。（キヤノンの場合はAPS-C専用のEF-Sマウントのレンズは従来のEF
マウントを搭載したカメラでは使用することができず、ニコンはAPS-C専用となるDX
フォーマットのレンズはフルサイズであるFXフォーマットの本体ではクロップ状態で使用
可となっているけどこれはEF-SとEFではバックフォーカスに違いがあるため誤使用を
考慮すると今後もニコンのようにクロップで使えるようにする改善は難しそう）

では、デジタル一眼はAPS-Cが主流になるのかというとそうではないにょ。
それはやはり2002年に登場したEOS 1Dsの影響が大きいにょ。
EOS 1Dsは35mmフルサイズセンサーを搭載したからね。
あくまでデジタル一眼でAPS-Cを採用しているのはフルサイズセンサーがコスト面で実用
レベルの価格にならないため妥協策として考案されたものにすぎないにょ。（とはいえ
APS-Cセンサー搭載はデジタル一眼の低価格に貢献したのは非常に大きい）
だからこそ、今になって各メーカーがフルサイズに力を入れているのだけどフルサイズが
APS-Cに対するメリットとデメリットは下記のようになっていると思われるにょ。（一部は
9月18日に書いたものと重複している）

　◎フルサイズのメリット
　(1)画質
　(2)ボケ

　◎フルサイズのデメリット
　(a)価格
　(b)サイズ、重量

まずは、フルサイズのメリットから書いていくにょ。

(1)画質のアドバンテージといえばセンサーサイズが約2.3倍あるということが起因となって
いるにょ。
デジカメの画質を決める主な要因はセンサー、レンズ、画像処理エンジンだけどそのうちの
センサーの性能がAPS-Cとフルサイズではセンサー面積の分だけ異なっているからね。
まぁ「画質」と一言で言っても多くの尺度があるためセンサーサイズだけでは優劣を決める
ということはできず画素数などの影響も確かにあるにょ。
ただし、画素数が数100万画素という少なかった時代ならば画素数の増加が解像感の向上へと
繋がっていたのだけどAPS-Cでさえ2400万画素になっており近年は画素数の増加が画質に
与える影響はほとんど無くなっていると思われるにょ。
確かにAPS-Cならば2400万画素のデジカメが1600万画素のものより必ずしも優れているとは
言えない（使用レンズや使用環境で容易にひっくり変える程度の差であり、これが極小
センサーを搭載のコンデジならば今となっては画素数は飾りでしかない）けれどフルサイズ
であれば画素ピッチに余裕があるためレンズ性能さえ高ければ3000万画素、4000万画素の
恩恵は十分にあるにょ。（ただし、画素数が多くなれば回折の影響も出てくるし手ぶれの
影響も大きくなるためそれを生かすのは容易ではなくなる）

センサーサイズが画質に与える影響で大きいのは高感度時の画質だと思われるにょ。
低感度時であればフルサイズの1/3程度しかないフォーサーズでさえデジタル補正と組み合わす
ことで非常に解像感のある写真を撮ることが可能になっているからね。（それに基本的に
フォーサーズ、マイクロフォーサーズは高解像力のレンズが多い）
しかし、高感度時には同一世代、同一メーカー製のセンサーかつ同一の画像処理エンジンで
比較するならばセンサーサイズにほぼ比例した画質になると思われるにょ。
実際は画素ピッチの影響も考えないと行けないのだけど同一サイズで鑑賞するために
リサイズして比較した場合には画素数よりもセンサーサイズの影響が大きいにょ。
これはD800で画素数が多く等倍では高感度画質はそれほど高くはないものの画素数が多いため
他機種に合わせてリサイズした場合にはそれほど高感度画質は落ちているようには見えない
ことからも明らかにょ。（これは画素ピッチが狭くなるに従って開口率の影響が大きくなる
のでコンデジで広く普及しているような裏面照射センサーでないと画素数が増えれば増える
ほどリサイズを考慮しても高感度画質は落ちていく）

人によってどこまでが実用レベルかというのは変わってくると思うけどEOS 6DやD600の
レビューを見る限りではISO1600までは躊躇無く使うことができ個人的には（高感度が必要な
状況ならば）ISO6400程度までならば十分に実用に耐えると感じているにょ。
縮小しての鑑賞ならばISO12800〜25600も使えそうにょ。
これがAPS-CならばISO1600〜3200も十分実用レベルに達していると思うけどISO6400は
厳しい場合が多いにょ。
やはり、同一世代のセンサーならば少なく見積もってもセンサーサイズ通りの1段分以上の
差はありそうな感じにょ。

(2)ボケについてはやはりセンサーサイズの大きさからくるボケ量が主な違いにょ。
センサーサイズが大きくなればなるほど同じ画角のレンズで撮影してもボケ量は大きく
なるからね。
ボケ量のおおざっぱな比較は単純計算で可能であり、フルサイズ換算で1.5倍の焦点距離と
なるAPS-Cの場合はF値が1/1.5のレンズを用いてようやく互角になるにょ。
フルサイズで300mm F2.8のレンズとAPS-Cで200mm F1.86でほぼ同じ画角とボケ量を得る
ことが可能になるにょ。
それならば単に明るいレンズを使えばAPS-Cセンサー搭載デジタル一眼はフルサイズ
センサー搭載デジタル一眼と互角になる（明るいレンズを使えば高感度画質で負けている
分もカバーできる）と考えられそうだけどAPS-C専用に作られたレンズはどれもコストや
サイズを重視したものになっており、同画角のフルサイズ対応のレンズと比べて明るい
ものというのは存在しないにょ。
それにハイエンドなレンズはAPS-C専用レンズには存在せず、フルサイズ対応のレンズを
使うしか選択肢がないにょ。
そうなるとセンサーサイズが小さい分だけ必然的にボケ量の面では不利になるにょ。

またボケ量が多いというのは被写界深度のコントロール量が多いということも言えるにょ。
これがどういうことかは昨今の画素数の増えたコンデジを見れば明らかにょ。
（実際のセンサーの画素ピッチによって変わってくるけど）1/2.3インチセンサーならば
1400万画素の時点でF2.7前後が回折限界となっているにょ。
つまり、それ以上絞れば絞るほど解像感が徐々に失われていくということにょ。
レンズには多かれ少なかれ収差があるのだけどこれは絞ることによって徐々に少なくなって
行くので開放から絞れば絞るほど解像感が高まっていくのだけど回折限界付近からは徐々に
低くなっていくため昨今のコンデジでは機械的な絞りを入れておらずほとんどの機種がND
フィルターによって露出をコントロールしていると思われるにょ。（これはコスト面の
問題もあると思われる）
上記のようにAPS-C用センサーのレンズにはフルサイズ対応のレンズより明るいものがない
ためにコンデジほどではないけど実質的に絞りがコントロールできる幅はフルサイズよりも
狭くなっていると言えるにょ。（回折においては等倍で鑑賞した場合にはセンサーサイズ
ではなく画素ピッチの影響が大きいのだけど同一サイズ同士で比較した場合にはセンサー
サイズの影響が大きくなる）

9月18日にはもう1つファインダーのメリットも書いたけど今回はそれは省略したにょ。

次にフルサイズのデメリットを書いていくにょ。

(a)やはり、問題となるのは価格にょ。
しかし、当初は60〜100万円のプロ機のみの採用だったけどそれがD700やEOS 5Dのような
30万円クラスのハイアマ向けのものが登場したにょ。
それは大きな第一歩だったけど今回はそれからさらに一歩前進して20万円クラスの
D600とEOS 6Dが登場したにょ。
これでフルサイズが高価で手が出なかったという人も手にする機会が増えるのは確実だけど
今のご時世で20万円程度（激安店の実勢価格でも17万円前後）というのは決して安価では
ないにょ。

またデジカメの画質はセンサー性能だけではなくレンズ性能の影響も大きいのだけどフル
サイズ対応でAPS-C以上の解像力を持つレンズとなると必然的にAPS-C用よりも高価になって
しまうにょ。
これは単純に大きくなる分だけ部材コストが大きくなるだけではなくセンサーサイズが大きく
なるほど（というかイメージサイズが大きくなるほど）高解像力のレンズを作るのに
かかるコストが大きいというのが理由にょ。
例えばフルサイズのサンニッパ（300mmF2.8）とほぼ同じ画角と明るさとなるのはAPS-Cだと
200mmF2.8だけど当然のことながら200mmF2.8の方が格段に安価にょ。（上記のように両者の
ボケ量は異なる）

(b)サイズについて見ていくと1kg弱あったフルサイズ機本体は760gのD600や680gのEOS 6Dに
よってそのイメージは大きく変わったにょ。（重量でいえばAPS-Cの中級機クラス）
センサーサイズが大きくなっても小型軽量化を行えばそのセンサーサイズ分ほどのサイズ差
にはならないことはNEXシリーズなどでも明らかになっているけど問題はレンズの方にょ。
いくら本体が小型軽量化してもフルサイズの性能を生かせるレンズとなるとそれなりの
重量になってしまうからね。
それに同じ画角、同じ明るさのレンズだとセンサーサイズが大きい方が確実に不利になって
しまうにょ。
つまり、本体だけではなくレンズとの合算重量ではフルサイズはAPS-Cよりも不利になると
いうことにょ。


このようにメリット、デメリットがあるのだけどメリットの方を見るとまとめて言うとフル
サイズの方はAPS-Cと比べて撮影できる幅が広がっているということが言えそうにょ。
あとは、それに似合うコストや重量かということにょ。
さて、ここで重量面が気になる人だとミラーレスという選択肢が出てくるにょ。
ミラーレスにしたからといってセンサーサイズが小さくなければレンズはそれほど小型
軽量化はできないもののAPS-Cセンサーを搭載したデジタル一眼とAPS-Cセンサーを搭載した
ミラーレスならばミラーレスの方が小型軽量化が期待できるにょ。
それにコスト面でもミラーレスの方が有利になるにょ。
現時点においてはミラーレスはAF性能が（動体に関しては）まだ不十分な機種が多かったり
とか、レンズのラインナップが十分とは言い難いなどの問題があるもののそれらの問題が
克服されたらすでに十分なレンズ資産がある人ではなければミラーレスではなくAPS-C
センサー搭載のデジタル一眼を選択する理由が無くなるにょ。（レンズ資産が全くない新規
ユーザーならば確実にそうなっていく）
現状ではまだAPS-Cセンサー搭載のデジタル一眼レフはミラーレスより優れている部分も
多いためすぐにAPS-Cセンサーを搭載のデジタル一眼レフが廃れていくということはない
ものの徐々にシェアを落としていくと思われているにょ。

それはモデル数を考えても明らかにょ。
フルサイズセンサー搭載のデジタル一眼に新しいラインナップが加わり、従来は無かった
ミラーレスが増えた影響を受けるのはAPS-Cセンサー搭載のデジタル一眼だからね。
つまり、APS-Cセンサー搭載のデジタル一眼は徐々にそのモデル数が減少していくという
ことが言えるわけにょ。（パイの大きさそのものが大きくなるということも考えられる
もののフルサイズの低価格化とミラーレスの性能向上を考えると一番影響を受けるのは
APS-Cセンサー搭載のデジタル一眼であることは容易に想像がつく）

その1つの大きなターニングポイントとなるのがAPS-Cの中〜上位モデルとなるニコンでいう
D7000とD300s、キヤノンでいうEOS 60DとEOS 7Dの後継機種は両メーカーともに2機種から
1機種に統合にょ。
この噂は以前から出ており、現在のラインナップを考えればかなり信憑性は高そうにょ。
これはフルサイズセンサー搭載機の低価格化を見れば10万円以下の入門機の上に10万円を
越える価格のAPS-Cセンサー搭載機は2つも不要ということが理由にょ。
将来的（10年後くらい）には10万円以下はミラーレスで対応となり、10万円台からは
フルサイズとなるとなりAPS-Cセンサー搭載のデジタル一眼が入り込む場所は無くなる
と思われるにょ。（レンズもフルサイズ一眼、APS-C一眼、ミラーレスといういうライン
よりもフルサイズ一眼とミラーレスに絞った方がコストが節約できるし充実できる）
まぁまだ先のことなので現時点で買うならばコストが許せる人のみフルサイズを選択すれば
良いのではないかと思われるにょ。
個人的にはフルサイズは確かに魅力だけどAPS-Cセンサーも性能が向上しているため最新の
中級機に変えれば満足できそうにょ（笑）

1403：御茶目菜子：2012/12/01(土) 23:41:20
コンデジは500万画素でキレイに撮れれば十分だけど
私は過去にコンデジに必要な画素数を様々な面から考えていったにょ。
その1つの基準が200万画素にょ。
200万画素ならば（当時はまだデスクトップPCの主流がSXGA〜WXGA+であったため）PCの
画面で見るならばそれで十分だしはがきサイズまでならばほぼ300dpiでプリント可能という
のが理由にょ。
それからしばらくしてその基準は300万画素に引き上げたにょ。
それはPCにおいてフルHDモニタが普及したため長辺が1920ピクセル以上は必須と考えた
からにょ。（それに2Lまでなら300dpiでプリント可能）
そして、フルHDを越えるモニタを搭載したPCやタブレット端末が今後は増えるということを
考えると新しい基準は500万画素くらい変えようと思うにょ。

ならば最初からフル画素で撮影（1800万画素なら1800万画素のJPEGで保存）すれば問題
ないと思うかもしれないにょ。
しかし、実際はコンデジにおいてフル画素で記録しても容量ばかり無駄に増えるだけで
あってメリットはほとんどないにょ。
一昨年の4月5日に書いたように画素数のアップが画質（解像感）の向上には繋がってない
というのが現状だからね。
画素数の向上が画質アップに繋がるためには十分な画素ピッチが必要不可欠となるにょ。
プリントをする場合でも500万画素あればA4サイズでさえ220dpiでプリント可能にょ。

A4サイズまでプリントできれば一般家庭ならばまずは困らないけどここで220dpiで十分か
という問題が発生するにょ。
私がブラインドテストしてみた結果では350dpi≧300dpi＞250dpi＞200dpi＞＞＞150dpiと
いう感じで300dpiを越えた場合にはその違いはほぼ分からないにょ。（これは人間の目の
限界もあるけどインクジェットプリンタの限界もあるため）
ただし、300dpiを下回っていくと徐々に差がつき始めるにょ。
200dpiと150dpiには大きな差があるけど200dpiを越えると近くでじっくり見ない限りは
区別できないレベルの差であり、A4サイズにプリントしてそこまで近くでじっくり比較
するということはほぼないため220dpiでプリントできればほぼ問題ないと思われるにょ。
むしろ問題となるのは元のデータの方にょ。
500万画素で十分に解像できているか否かという方が遙かに重要であり、それで解像できて
いなければフル画素で撮影してもプリントの際に有利になるなんてこともないし、画素数が
多いからトリミングで有利になるということも無くなるにょ。（したがって、上記のように
ファイルサイズが大きくなるというデメリットしかない）

というわけで、一昨年4月5日の300万画素モードの比較に続いて今回は手持ちのコンデジの
500万画素モードの比較を行ってみたにょ。
ちなみに今回撮影に使ったコンデジは下記の6機種にょ。

・LUMIX FZ5 　　　　　2005年発売　500万画素
・Nikon COOLPIX S1　　2005年発売　500万画素
・Xacti HD2 　　　　　2007年発売　700万画素
・Cybershot TX1 　　　2009年発売　1000万画素
・Optio I-10　　　　　2010年発売　1200万画素
・Cybershot WX100 　　2012年発売　1800万画素

撮影条件について書いておくと画角は35mmカメラ換算で35mm付近を使用したにょ。
そして、各カメラで500万画素モードを設定してフルオートで2枚撮影して良く撮れたと思う
1枚を採用して比較したにょ。
ただし、HD2のみ500万画素モードは16:9しか選択できなかったけどそれ以外は4:3で撮影して
いるにょ。

発色傾向は各メーカーの味付け具合ということで今回はあえて比較対象とはせず解像感のみに
絞って比較することにしたにょ。（このテストは晴天時の遠景の撮影のみ有用なものであり
他の条件では変わることがある）

　◎私の個人的判断
　中央付近　I-10＞FZ5＞＞TX1＞HD2＞＞S1＞＞＞＞WX100
　周辺部分　FZ5＞＞TX1＞HD2＞＞＞＞I-10＞＞WX100＞S1
　総合評価　FZ5＞＞＞TX1＞HD2＞I-10＞＞＞S1＞＞WX100

ということで、解像感だけを見ると総合的には画素数が最も少ないFZ5がトップで画素数が
最も多いWX100が最下位となったにょ。
とはいっても、このテストは今回たまたまこうなったというだけであって次に別の条件下で
試した場合には異なる場合も十分考えられるにょ。
TX1は晴天時の屋外撮影は苦手としており、普段であればI-10と同じくらいの位置にいると
予想されるからね。（500万画素でも厳しいから普段は300万画素モードしか使用していない
くらいだし）
逆にS1は今回のテストはやや力を出し切れてない感じにょ。

とはいえ、そんなことを言い出したらWX100はどうなのかということになるにょ。
WX100はタダでさえ解像感においては厳しい（これは恐らくノイズ除去のため）裏面照射CMOS
センサーを採用しているのに1800万画素という尋常ではない画素数だからね。
そのため等倍だととても見れたものではないにょ。
これは昨今の1000万画素超の普及型コンデジすべてにおいて言えるけど裏面照射センサーの
1800万画素搭載モデルは特にそれが顕著になっていると言えそうにょ。
ただし、WX100の場合はプレミアムおまかせオートだと自動でさまざまなデジタル処理が
行われてしまうという点が今回のテストではマイナスに働いた（普段でも塗り絵なのに
それが余計に強調された）ということは十分に考えられるにょ。
実際、遠景でなければ500万画素モードで撮影する限りはそこまで問題となることはあまり
ないからね。

というわけで、WX100の撮影テストも別途行ってみたにょ。
撮影した被写体はもう撮影時期のピークを過ぎている紅葉にょ。
普段であれば1枚1枚構図や露出を考えてデジタル一眼で撮影するところだけど今回は時間的な
問題もあってWX100のみで撮影したにょ。
フルオートで撮影したものの（500万画素ならば）等倍で見てもそれほど悪くはないレベルの
写真は撮れているにょ。
むしろ、上記の遠景のテスト結果とは全く別物といっていいレベルの非常に良好なものだと
いえそうにょ。（さすがに同じ画素数でもデジタル一眼と比較すれば大きく劣るためあるため
あくまでコンデジとして考えた場合だけど）

前回の室内での高感度テストと合わせてみるとWX100は高感度時の画質は過去最高レベルの
素晴らしいものだけど低感度で晴天の風景を撮影した場合には旧世代（7年前）のコンデジに
大きく負けてしまう場合もあることが分かったにょ。（遠景でも紅葉の写真くらいまともに
撮れていたら個人的には普及型コンデジとしては画質は十分に満足できたのだけど）
私は撮影の多くが室内であるため特に問題はないけど風景とかを良く撮影する人で屋内で
撮影する機会がほとんどない（高感度で撮影する機会がない）という人はWX100をはじめとする
1800万画素の裏面照射センサー搭載機種は向いてないと言えそうにょ。（一般的に考えると
風景写真は解像感を高めるために高画素機の方が有利だけどセンサーサイズが小さいコンデジ
ではそのような一般論は今回のテストを見てのように通用しない）

また、今回のデジカメの500万画素の比較写真とWX100の撮影テスト（紅葉）の原寸大無加工の
写真はこちらにアップロードしたので良かったら見てみてにょ。
http://www1.axfc.net/uploader/so/2698408.zip
（合計約30MBのZIPファイル）

1404：御茶目菜子：2012/12/22(土) 01:43:16
YouTubeで動画を公開する意味
私はYouTubeにて自作プログラムの実行動画を多く投稿しているにょ。
http://www.youtube.com/user/ochamenako
現在の投稿数はプチコン関係が28本、ポケコン関係が6本、その他が3本となっているにょ。
ゲームの場合は単なるプレイ動画とはいえその動画を見ていれば概ねどんなゲームか分かる
（上手くプレイするよりもどんなものかが伝わるようなプレイをしている）と思うしツール
などの場合は動画があることでどんなツールかとか具体的な使い方もそれによって分かる
からね。
それに該当機種を持ってない人でも分かるというのが便利でそれを元に移植する場合などに
YouTubeの動画を活用している人も多いのではないかと思うにょ。

プチコン関係が圧倒的に多いのは当然ながらYouTubeアカウントを取得した方が先だった
（2010年にアカウント取得）ため公開済みの作品の多くを実行動画として公開している
ためにょ。
それに対してポケコンの動画が少ないのは全盛時が80年代〜90年代だったためにょ。
もしも20年前にすでにインターネットとブロードバンドが普及していてYouTubeのような
サイトと動画を撮影可能なデジカメを所持していたならばポケコンの動画本数はプチコンを
遙かに上回る数になったと思われるにょ。（私がプチコンで作った作品数はネットで公開
しているだけでも約60作品になるためこの動画もすべての作品ではないけどポケコンで
作った作品はそれと比べて桁違いに多い）
まぁプログラムそのものは過去作品のを公開すればいいのだけど2001年のRAMカードの故障で
未公開のを含め90年代後半以降の自作プログラムをすべて失ったのが痛いにょ。

YouTubeではタグ検索やによって投稿日（アップロード日）順、再生回数順、評価順に並べ
変えることが可能であり、人気の動画はどんどん伸びていくにょ。
その反面人気のない動画はそれなりということで、私が投稿した動画がどのようなものかを
検証してみることにしたにょ。
さて、YouTubeにおいて再生回数は日数が経てば経つほど伸びていくため単純に再生回数
だけで優劣を比較するのは難しいにょ。（それと同時に評価順だけでも難しい）
1日当たりで計算してもいいけど日数が経てば徐々に再生数の増え方が鈍化していくため
それも難しいにょ。
そこで、下記の計算式で人気度を算出することにしたにょ。

　人気度＝再生回数×（高評価数＋1）÷投稿してからの日数

この式はこうやまさんが考えたものだけど上記の日数だけ、評価数だけ、1日当たりの
閲覧数だけで見るのではなくそれを総合的に示しているので新しい動画が必ずしも有利や
不利にはならないものになっている気がするにょ。（下記の順位を見てみると若干、新しい
方が有利な気もしなくはないけど）
というわけで、私が投稿している動画をプチコン関係、ポケコン関係でまとめて人気度順に
並べ替えたのが下記のものにょ。

　YouTubeのochamenakoチャンネルの人気度ランキング

　　　　《　プチコン関係　》　　　現在の再生数　高評価数　日数　　人気度
　　1位　プチコンアーチェリー　　　　　　515　　　　8　　　127　　 36.49
　　2位　PETIT EDITOR　　　　　　　　　　104　　　　1　　　　9　　 23.11
　　3位　レースゲーム用表示サンプル　　 1310　　　　4　　　369　　 17.75
　　4位　プチコン用マルチタスクOSもどき　686　　　　3　　　160　　 17.15
　　5位　PETIT KEYBOARD mkII　　　　　　 150　　　　3　　　 35　　 17.14
　　6位　PETIT RUN　　　　　　　　　　　1559　　　　3　　　364　　 17.13
　　7位　JUMPING ISLAND　　　　　　　　　656　　　　4　　　210　　 15.61
　　8位　ダミーちゃん危機一髪　　　　　　998　　　　1　　　148　　 13.48
　　9位　プチコンクレー射撃　　　　　　　620　　　　2　　　168　　 11.07
　 10位　PETIT RUN D　　　　　　　　　　1256　　　　2　　　364　　 10.35
　 11位　BEEPでBGM演奏をしてみる　　　　 935　　　　3　　　385　　　9.71
　 12位　棒歌ロイドOSP2　　　　　　　　　575　　　　3　　　252　　　9.12
　 13位　棒歌ロイドキーボードを作ってみた742　　　　2　　　249　　　8.93
　 14位　自動歌唱ソフトOSP　　　　　　　 444　　　　3　　　258　　　6.88
　 15位　PETIT RUN mkII　　　　　　　　　259　　　　1　　　 77　　　6.72
　 16位　プチコンベンチ　　　　　　　　　806　　　　1　　　259　　　6.22
　 17位　JUMPING ISLAND MANIAX　　　　　 127　　　　2　　　 62　　　4.94
　 18位　棒歌ロイドキーボード（完成版）　388　　　　2　　　238　　　4.89
　 19位　プチコン100m走　　　　　　　　　934　　　　1　　　392　　　4.76
　 20位　プチコンスキー　　　　　　　　　855　　　　1　　　371　　　4.60
　 21位　レイヤー機能付きお絵かきソフト　281　　　　2　　　204　　　4.13
　 22位　何かそれっぽいプログラム　　　　213　　　　2　　　199　　　3.21
　 23位　プチコン100m走mkII　　　　　　　546　　　　0　　　189　　　2.88
　 24位　ピョン子　　　　　　　　　　　　814　　　　0　　　378　　　2.15
　 25位　JUMPING ISLAND（1画面版）　　　 369　　　　0　　　196　　　1.88
　 26位　プチコンハンマー投げ　　　　　　315　　　　0　　　183　　　1.72
　 27位　スプライト動作テスト　　　　　　395　　　　0　　　392　　　1.00
　 28位　棒歌ロイドキーボード別バージョン133　　　　0　　　247　　　0.53

　　　　《　ポケコン関係　》　　　現在の再生数　高評価数　日数　　人気度
　　1位　2LINE UFO GAME　　　　　　　　 1282　　　　6　　　917　　　9.78
　　2位　ピーチバレー2　　　　　　　　　 331　　　　2　　　239　　　4.15
　　3位　UFO GAME 2　　　　　　　　　　 1050　　　　2　　　911　　　3.45
　　4位　SENGOKU GAME　　　　　　　　　 1139　　　　0　　　750　　　1.51
　　5位　SENGOKU GAME Another　　　　　　286　　　　1　　　750　　　0.76
　　6位　2LINE PYONKO　　　　　　　　　　423　　　　0　　　742　　　0.57

まずは、プチコンの方から見ていくと1位はプチコンアーチェリーとなっているにょ。
これは高評価が8というのが非常に大きいにょ。
ここまで評価されたのはプチコンを縦に持ってタッチパネルを用いて弓を引いて的を射る
ような感じが表現されている（気がする）のが良かったのかもしれないにょ。
2位のPETIT EDITORは投稿してからの日数が少なすぎるため最初に伸びた分が大きく影響
していると思われるにょ。（私の投稿動画は初日の再生数は50〜80程度いくため評価ゼロ
でも1日目の時点で人気度を求めたら50〜80くらいになってしまう）
初日の伸びが極めて大きいため上記の計算式もやはり1ヶ月以上経たないとかなり新作が
有利になっているような気がするにょ。

では、プチコン大喜利にて技術賞を戴いたPETIT RUN mkIIを見てみると28作品中15位に
止まっているにょ。
これは、すでに投稿しているPETIT RUNと見た目が大きく変わってないことが影響して
いると思われるにょ。
実際にプレイしてみると画面表示（高精細化や視点移動）の違いもあるし、前作では
入れられなかったトップタイム表示やリトライ機能があるため大きく変わっているの
だけど動画で見るだけではそれらは伝わりにくいからね。
したがって、前作を見た人、評価した人は新鮮さに欠けてしまっていることが15位という
順位になっていると思われるにょ。
それと同じことがJUMPING ISLAND MANIAXにも言えるし、試作品の動画を先に公開した
棒歌ロイドキーボードにおいては完成品より試作品の方が再生数も評価数も多くなっている
というのを見ても明らかにょ。
単純に合算はできないものの仮にPETIT RUN、PETIT RUN D、PETIT RUN mkIIを合算した
場合には、再生数3074、評価数7となり作品別ではトップになるにょ。（さらにPETIT RUNに
使用した道路表示のサンプルも加えれば再生数4384、評価11のダントツトップになる）

次にポケコンの方を見てみると1位はダントツで2LINE UFO GAMEとなっているにょ。
これは「OPASを使えば2行でもドット単位の横スクロールゲームが作れる」というのを
知ってもらうために作ったものにょ。
すでにポケコンを持ってない人もいるだろうからオールBASICでどの程度の速度が出せる
のかは動画で見てもらうのが一番ということでこの動画のためにYouTubeのアカウントを
取得したにょ。
2位のピーチバレーは作品公開前にポケコンが壊れてしまい作品の公開が無期延期になって
しまった不遇の作品にょ。（この動画は普通にプレイできるバージョンが完成した時点で
撮影したものであり事前に撮影していなければこの動画は公開できなかった）
完成してすぐに公開ができなかったのはポケコンとのデータのやりとりが可能なPC-98を
整備しなおさない限りはリストを書き出す手段が画面を見ながらPCで手入力となってしまう
ためにょ。（プチコンも初代はそうだったけどmkIIではQRコード経由での公開ができるように
なったのが非常に大きい）


さて、こうしてみると私はオリジナル作品が多そうなイメージを持っている人がいると思う
けどかつてはポケコンも移植作品や改造作品が多かったにょ。
プチコンにおいては、棒歌ロイドキーボードはミクミンPさんがWindows用に作った作品（と
いうかそれ自体がヤマハが開発した製品をソフトウェア化したものだけど）の移植で「何か
それっぽいもの」は某シューティングゲームを元にしたものであり、それ以外はオリジナル
みたいな気もするかもしれないけど実はほとんどがポケコンで作った自作作品の移植ばかり
となっているにょ。
そのため自作作品の移植を「移植作品」とした場合には私が公開している作品はほとんどが
移植作品となってしまうにょ。

もっとも、プチコンスキーは元となったポケコンゲーム「シュプール」とは別物といって
いいくらい変わっているしPETIT RUNも元となったポケコンゲーム「3D DRIVING」とは別物
といってもいいレベルにょ。
とはいえ100％オリジナルというのは不可能でありポケコンによる四半世紀に渡る経験がある
からこそ今の私があるわけであって、その過去の経験を生かしたものにするのが当たり前
ともいえるにょ。
四半世紀の間にはポケコン以外の様々な機種やゲームに触れているわけなので全く作った
こともないものや自分で見たこともないものを作る方が無理があるにょ。
したがって、誰もが様々なものに影響を受けて作っていると思われるにょ。
私が公開している動画も誰かに影響を与えるようなものになればうれしいと思うにょ。

1405：hatena：2012/12/03(月) 20:58:45
サイト移転のお知らせ
サイトの移転をしました。
トップページは　http://www1.atwiki.jp/hatena71869/　で、
リンク集ページは　http://www1.atwiki.jp/hatena71869/pages/20.html　です。

@WikiというレンタルWikiを使用しています。
ブラウザ上でページを書き換えれるのは私にとって大きかったので。

お手数ですが、おちゃめくらぶさんのリンク集の変更を宜しくお願い致します。

1406：御茶目菜子：2012/12/03(月) 23:51:12
レスにょ
hatenaさんへ
＞サイトの移転をしました。

了解したにょ。
早速リンクを張り替えておいたにょ。

私はテキストエディタで書いてFTPで転送する方が好きなので現状のままで問題ないけど
唯一の問題は容量にょ。（このサーバの上限は今時20MBしかない）
何度か移転を考えたけど相互リンク先の人に知らせるのも大変だし、何より13年間この場所を
使い続けてきたため身動きがなかなか取れないにょ。
そのためできるだけ軽くしているにょ。
それでも限界になったらここは残して適当なサーバをレンタルして別館を作るつもりにょ。

1407：御茶目菜子：2012/12/03(月) 23:52:29
PETIT RUNで分かったプチコンの1年間の動向
昨日は私がYouTubeに投稿した動画について書いていったにょ。
その中からPETIT RUNの再生数についてもう少し詳しく見ていくにょ。
実はこのPETIT RUNをYouTubeに投稿して今日でちょうど1年経つにょ。
そういうわけで、過去1年間の再生数をグラフで振り返ってみたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/image/petit_run_1d.jpg

このグラフを見てみると4つの突起部分に気が付くと思うにょ。

　(1)投稿日
　(2)プチコンmkII発売
　(3)北米版プチコン発売
　(4)PETIT RUN mkII投稿

(1)まず、投稿日を見てみると18回で投稿日の翌日が52回で大幅に増えているにょ。
これはアップロードした時間は日本時間に変換されて表示されているけれど再生回数の
集計は現地時間（北米時間）を基準にしているからだと思われるにょ。
そうしないと24通り保存しなくてはならなくなるからね。
実際に投稿したのは日本時間で昨年の12月4日であり、再生画面でもそう記されているけど
この集計画面では12月3日に投稿したことになっているからね。
恐らく（現地時間の）12月3日の日付が変わる直前に投稿したことになっているため投稿
した当日の再生が翌日の再生数を大きく下回っていると考えられるにょ。
そうなると事実上、投稿日の再生数は18回＋52回＝70回を少し下回る程度の再生数（投稿
3日目が16回なので投稿して24時間の再生数は65〜70回程度）になると思われるにょ。
実際、だいたい投稿して24時間後の再生数は昨日も書いたように概ね50〜80回程度になる
ことが多いからね。（この50〜80というのは今年に入ってからの数字なので昨年の時点で
PETIT RUNが65〜70回程度だったならば当時としてはかなり多い方だと言える）

(2)やはり、プチコンmkIIの発売の影響が大きいにょ。
とはいえ、mkIIが発売されたのは3月14日であり、この再生数のピークとなったのは3月17日
となっているため誤差が大きいにょ。（3月17日の再生数は32回）
これから発売当初は初代プチコンのユーザーの買い増しがメインだったけど3日経ってから
新規ユーザーが増えたと予想できるにょ。
これはPETIT RUNだけではなく他の作品においても似たような傾向が見られる（3月14日が
ピークではなく数日遅れでピークとなっている）という点を考えるとたまたまこういう結果
ではなくユーザー数の拡大が起きた結果と言えそうにょ。

(3)3つ目のピークは7月20日であり、これは北米版プチコンが発売された日でもあるにょ。
ちなみに7月20日の再生数は45回あったにょ。
(2)ではmkIIの発売から数日遅れでピークがやってきたのに対して(3)は発売日にピークと
なっているのは北米ユーザーが全員新規ユーザーであるためにょ。
しかも、発売日にピークを迎えているということはかなり注目度が高い製品だったという
ことが言えるにょ。
この北米版の発売以来（作品によって伸び方に差はあるものの）再生数がほぼ止まっていた
作品が再び伸び始めるなどの大きな差が見られたにょ。
私は基本的にすべて日本語の説明文しか書いておらず「言語の壁」があるのだけどそれでも
ここまで伸びたというのは相当に注目されている証拠だと思うにょ。（社長のツイートから
北米版発売2ヶ月で日本でトータルの発売数を上回ったらしいし）

(4)これは上記の3つより劣るものの明らかな伸びが出ているので採り上げたにょ。
これから分かるのは続編や関連作品を投稿してその影響がどの程度あるのかということにょ。
ピークとなっている9月16日のPETIT RUNの再生数は25回にょ。
同日にPETIT RUN mkIIは25回なので極めて高い効果があると考えられるにょ。
PETIT RUNの再生がすべてPETIT RUN mkII経由とは限らないのだけどPETIT RUN mkIIを投稿
する前5日間の再生数を見てみると前日（9月15日）が5回、2日前が3回、3日前が2回、4日前が
1回、5日前が2回であるため続編であるPETIT RUN mkIIの影響で一気に23回まで再生が伸びた
と考えるのが妥当にょ。
仮にPETIT RUN mkIIの投稿がない場合に前日の5回と同じだけ再生されたとすると差し引き
18回がPETIT RUN mkIIを経由しての再生となり、その経由割合は72％と極めて大きな数字に
なっているにょ。


PETIT RUNをサンプルに選んだのは「投稿からちょうど1年」「私が投稿した動画の中で最も
再生数が多い」というのもあるけどそれに加えて上記の傾向が最もはっきり読み取れた
からにょ。
実際は1日単位では分かりにくい部分もあるけど1週間単位で集計したグラフならば投稿日を
除き普通は考えられない大きな山が2つあることに気が付くと思うにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/image/petit_run_1w.jpg

この山は(2)、(3)であり、これによって再生数がいかに大きく増えているかが分かると
思うにょ。
それと比べると(4)による伸びは一瞬（ほぼPETIT RUN mkIIの投稿日のみ）だったので1週間
単位のグラフで見ると誤差程度の小さな山になっているにょ。
他の小さな山は関連動画からの再生である可能性が高いにょ。（同日に人気のあるプチコン
動画が投稿されてそれの影響で伸びたと考えるのが妥当）
こうして1年間を振り返ってみるとmkIIの発売や海外版プチコンの発売がいかに大きなもので
あったのかが分かると思うにょ。（1週間単位のグラフを見てのように新作として投稿した時
よりも大きな伸びを見せているので）

1408：hatena：2012/12/04(火) 19:09:22
リンクについて
私のサイトのサイト名は「hatena @Wiki」でよろしくお願いします。

それともう一つ…
色々事情があり(？)プチコンプログラム規格HPCPSを廃止しました。

1409：御茶目菜子：2012/12/04(火) 23:15:40
レスにょ
hatenaさんへ
＞私のサイトのサイト名は「hatena @Wiki」でよろしくお願いします。

変更しておいたにょ。

＞色々事情があり(？)プチコンプログラム規格HPCPSを廃止しました。

それは残念にょ。
ちょっとガチガチにしすぎていると私も思ってたので私が別の規格を作ろうか・・・と
考えたけど1画面以外ほとんど作る機会がないので不要ということで考えただけにょ（笑）
もっとも、他者が作ったプログラムを使ってみて不便だと思ったことを盛り込むだけ
だから自分で使う必要はないのだけど当の本人さえもそれに対応させたプログラムを作って
ないとなると説得力に欠けるからね。（ポケコンのPSSは賛同者によって私以外数人が
対応プログラムを作ってくれた）
もしもプチコン用のPSSを作るならばリソース関係を盛り込む予定にょ。

1410：御茶目菜子：2012/12/05(水) 22:59:47
プチコン大喜利の記念品がついに到着！
先月最終結果が発表されたプチコン大喜利の記念品がついに届いたにょ。
http://twitpic.com/bj8hwx

届いたのは下記のものにょ。
まずは、参加記念品となるシールにょ。
http://twitpic.com/bj8ihq

そして、ノミネート20作品に残った記念となるオリジナルサントラCDにょ。
http://twitpic.com/bj8iuo

さらに入賞記念となるオリジナル法被と表彰状にょ。
http://twitpic.com/bj8jhe
http://twitpic.com/bj8jtw

発表から1ヶ月経ちもう次第に発表当時の喜びも薄れ過去の出来事のように思っていたけど
こうやって記念品が届くと再びそのときの喜びが溢れてくるにょ。
どれも、この大喜利用に用意された他では手に入らないものなので非常にうれしいにょ。

今回は初の開催ということで知らなかった人や他の人のレベルが分からず参加を躊躇していた
人もいるだろうし、入賞以外でも記念品がもらえるから次回はぜひ参加したいという人も多い
ため次回はかなり競争率が高くなりそうにょ。
今回は何とか技術賞に入賞できたものの次回はこんなに甘くないかもしれないにょ。
それでも、（恐らく開催されるであろう）第2回のプチコン大喜利にも1画面プログラムで参加
予定なので今回以上のものを作ってまた入賞目指して頑張るにょ。

1411：御茶目菜子：2012/12/07(金) 23:53:45
プチコンがお手軽な理由
今回の第8回プチコン虎の穴だけど冒頭でプチコン大喜利について触れられており私の
「PETIT RUN mkII」もスクリーンショットで紹介されているにょ。
http://monoist.atmarkit.co.jp/mn/articles/1212/07/news003.html
もう1枚紹介されているスクリーンショットはOBONOさんの「HOPPER」にょ。
この2つに共通する点といえばメインの描画がグラフィックであるということにょ。
プチコンには描画画面としてコンソール（普通のキャラクタ）、グラフィック、BG、
スプライトが独立して用意されているのだけど旧世代のパソコンの多くはコンソールと
グラフィックしか用意されてなかったにょ。
ポケコンに至ってはVRAMこそキャクタ用のVRAMとグラフィック用に分かれている機種
こそあったけど描画においては同一画面上の機種しかなかったにょ。

そんな旧世代のパソコンを使っていた人だとグラフィック関係の命令というのはすごく
遅いというのが頭の中にあると思うにょ。
ポケコンにおいては描画専用のLSIが搭載されている機種はなくCPUによって描画されて
いたのだけどこのためグラフィック関係の命令は極めて遅かったにょ。
ポケコンでは高速な部類に位置するPC-E650は演算速度はプチコンmkIIと比べて100倍くらい
遅いけど塗りつぶし四角形（一般的なBASICだとLINE命令のBFオプション）においては
プチコンよりも1万倍くらい遅いにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/what.htm
これはプチコンでは塗りつぶし四角形専用命令であるGFILLが搭載されているというのが
大きいにょ。
これでもプチコンはグラフィック（GRP）においてはスプライトやBGと比べて面積当たりの
描画速度は遅いのだけど実際に表示してみるとそれでも十分な速度を出せる場合は多いにょ。

例えば私のPETIT RUN mkIIにおいては1フレーム（1/60秒）当たり52回のGFILL命令を実行
してそれによって疑似3Dを実現しているのだけどそれだけ表示しても処理落ちは起きない
わけだからね。（これが54回ならば処理落ちしてしまうのでゲームに使うならばこれがほぼ
限界といえる）
単純に計算すると1フレームあたり50回とすれば1秒間に3000回表示可能といえるにょ。
こんなことは旧世代のパソコンではあり得ない速度であり、グラフィック命令は遅いから
スプライトやBGのみでゲームを作るというのは非常にもったいないにょ。

動作環境のハイスペック化はそれだけユーザーに出来ることを増やすという恩恵があるものの
逆に言えばできることが多すぎて使いこなせるのはごく一部の人のみになるということにょ。
つまり、スペックが上がれば上がるほど上下格差は広がることを意味するにょ。
では、ハイスペック化は必ずしもデメリットばかりかというとそうでもないにょ。
例えばポケコンでゲームを作る場合には上記のように演算速度だけを見てもプチコンより
100倍以上遅く、グラフィック命令は話にならないくらい遅いため高速化の方法を駆使しても
せいぜい8〜10fpsが限界だったにょ。（100m走系のゲームは処理が楽なので数10fps出ていた
けれど）
そうなると、マシン語を使うかBASICを極めない限りは快適に動作するアクション系のゲームを
作ることは困難になってしまっていたにょ。
これは、ポケコンに限らず旧世代の8ビットパソコンの多くが抱えていた問題にょ。

プチコンではマシン語が使えない代わりに8ビットパソコンのマシン語に匹敵する演算速度が
得られているにょ。
そして、画面表示においては上記のように非常に高速にょ。
グラフィック命令の最も良い点はお手軽であるということにょ。
幸いにしてプチコンの場合はスプライトやBGのキャラにはプリセットデータが大量にあるため
それを使えば「キャラを作るのが大変」というデメリットはないものの分かりやすさに
おいてはグラフィック命令の方が格段に上にょ。
1ドット単位で自由な場所に自由な形で描けるわけだからね。（それにスプライトのように
管理番号の制限もない）
プチコン講座第7回ではそのグラフィックのメリットが書かれているにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/p007.htm

では、これが仮に10倍高速になった場合にはさらにハードルが下がるのかというと単純にそう
とはいえないにょ。
それは、高速化によってより緻密な描画が可能になるためにょ。
それは、誤魔化しが効かないことを意味するにょ。
PETIT RUNの描画アルゴリズムは単純かつ高速なものだけどプチコンの速度や解像度だからこそ
これで問題はないにょ。
これがPC向けに造り高解像度でプレイ可能になった場合にはそれに応じたものにしなくては
ならなくなるにょ。
アルゴリズムは普遍的な物ではなく速度によって選択肢が変わってくるにょ。
上記のPETIT RUN mkIIやHOPPERは旧世代のパソコンではなく高速なプチコンだからこそ出来た
ものであり、アフターバーナーIIの回転処理にGPAINTを使うというのも高速なプチコンだから
こそできたものにょ。
つまり、グラフィック命令が簡単でお手軽というのはプチコンの解像度や処理速度との
バランスが非常に良いからと言えるわけにょ。
だからこそ、プチコンはゲーム作りにおいてハードルが低くなっていると思われるにょ。


上記とは関係ないけど、プチコンのユーザー識別コードをまとめたページを作ったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/usercode.htm
プチコンでやはりネックな部分はファイル関係が弱いということとmkIIで他のユーザーの
プログラムがQRコード経由で簡単に取り込むことができるようになったのにその保存領域が
小さいことにょ。
後者はどうにもならない（みんながリスト圧縮を行うようにするのは無理がある）けれど
前者のファイル関係のうちフォルダ管理ができないからファイル重複が起きてしまうという
問題はこの識別コードによって克服が可能になるにょ。（ザウルスOSも基本的にフォルダが
扱えなかったためこのようなシステムになっていた）

1412：hatena：2012/12/08(土) 19:56:54
識別コードの統一のお知らせ
私の識別コードを統一致しました。
この通りです。「HN_ 、HTN」→「HN_」

識別コードをどちらかに統合しておいた方が良いと思いまして。
その時、「HN_」の末尾にはアンダースコアがあり
どこまでが識別コードか分かりやすいので「HN_」の方にしました。

1413：御茶目菜子：2012/12/08(土) 23:11:59
レスにょ
hatenaさんへ
＞私の識別コードを統一致しました。
＞この通りです。「HN_ 、HTN」→「HN_」

報告どうもにょ。
リストから「HTN」を削除しておいたにょ。

1414：りょーん：2012/12/09(日) 21:56:34
(無題)
識別コードが載ってなかったけど最終公開が4月だから何の問題もなっかたでござる

1415：御茶目菜子：2012/12/09(日) 23:54:49
レスにょ
りょーんさんへ
＞識別コードが載ってなかったけど最終公開が4月だから何の問題もなっかたでござる

抜けていてすみません。
RN_で追加しておいたので問題があれば言って欲しいにょ。

1416：御茶目菜子：2012/12/09(日) 23:56:01
1画面プログラムは取捨選択が重要
11月23日にプチコンでテキストエディタ「PETIT EDITOR」を作りMEM$の編集をしたり短い
プログラムを作ったりができるようになったのだけどそれを活用できるようなプログラムを
作ってないので作ろうと思ったにょ。
テキストエディタがあるならやっぱりプログラミングということで1画面のリストサイズに
収まるプログラミング言語のインタープリタを作ることにしたにょ。
そこでターゲットとなったのが難解プログラミング言語にょ。
難解プログラミング言語は多くの種類があるけどシンプルなものが多いため小さいサイズで
実現が可能なものも多いにょ。
その中でターゲットに選んだのがBrainfuckにょ。

これは、命令そのものがシンプルだけど奥が深いためにょ。
このBrainfuckはインタープリタそのものは簡単にできるにょ。
ということで、可読性重視で最小限の機能のみを搭載したものをプチコンで作ってみたにょ。

ACLS:CLEAR
MAX=30000:DIM P(MAX)
L=LEN(MEM$)-1
FOR I=0TO L
P$=MID$(MEM$,I,1)
　IF P$==">"THEN C=C+1:IF C>=MAX THEN C=0
　IF P$=="<"THEN C=C-1:IF C<0 THEN C=MAX-1
　IF P$=="+"THEN P(C)=P(C)+1:IF P(C)>255 THEN P(C)=0
　IF P$=="-"THEN P(C)=P(C)-1:IF P(C)<0 THEN P(C)=255
　IF P$=="."THEN ?CHR$(P(C));
　IF P$==","THEN GOSUB @GETCHAR
　IF P$=="["THEN GOSUB @WHILE
　IF P$=="]"THEN GOSUB @WEND
NEXT
END

@GETCHAR
K$=INKEY$()
IF K$==""THEN @GETCHAR
P(C)=ASC(K$):RETURN

@WHILE
IF P(C) THEN RETURN
N=0
FOR J=I TO L
　P$=MID$(MEM$,J,1)
　IF P$=="]" THEN N=N-1
　IF P$=="[" THEN N=N+1
　IF !N THEN I=J:J=L
NEXT
RETURN

@WEND
IF !P(C) THEN RETURN
N=0
FOR J=I TO 0STEP -1
　P$=MID$(MEM$,J,1)
　IF P$=="]" THEN N=N-1
　IF P$=="[" THEN N=N+1
　IF !N THEN I=J:J=0
NEXT
RETURN

可読性重視であるため無駄が多いけどリスト短縮をすれば容易に一画面に収まりそうにょ。
ただし、ここで1つ問題があるにょ。
それは、すでにプチコンではえいださんがBrainfuckのインタープリタを作っているという
ことにょ。
いくら1画面というサイズであっても遙か前に作られたものより劣るものであったら作る
意味は半減してしまうにょ。
しかし、このえいださんが作ったインタープリタは初代プチコンが発売されて間もない頃
（昨年5月）であるためプチコンmkIIのホームメニューには対応してないという点があるにょ。
そして、私が参考として他者が作ったjavascriptで動作するBrainfuckのインタープリタを
いくつか試してみたけどえいださんが作ったものにはポインタの値が分からないというのが
やはり個人的にはかなり気になったにょ。
あと操作性の面も気になったにょ。

というわけで、作るものの方向性は決まったにょ。
「mkIIのホームメニューに対応させる」「実行中の様子を分かりやすくする」「操作性を
良くする」という点を重視することになったにょ。
ホームメニューに対応させるには1回ごとにRUNをするのではなく繰り返して実行を可能にする
必要があるにょ。
そのためCLEARは最初にしか使用できず、初期化を行うためリストがやや長くなるにょ。
それとえいださんと同じくMEMリソースファイルをロードして実行させるだけではなく直接
入力も可能にしようと思ったにょ。
えいださんは起動時にその両者を振り分けを行っていたけどホームメニューに対応するため
にはそれではいけないにょ。
メニューで選択というのもプログラムが長くなってしまうため厳しいにょ。

そこで考えたのが自動選択にょ。
同じ入力場面でファイル名を入力すればロード、コードを入力すればそのコードを実行という
ものにょ。
これは幸いにしてBrainfuckは命令で使う文字ががプチコンのファイル名で使える文字と
被ってないため単純にASC関数で判断可能にょ。
しかし、問題はASC(A$)とした時にはNullの場合だとエラーになってしまうにょ。
LINPUTではなくINPUTにすればそんな問題はないけどINPUTではBrainfuckで「,」を使う
必要性があるためできないにょ。
それと、PETIT EDITORで非常に優れていると私が感じている点である空打ちによる実行は
INPUTではなくLINPUTを使わないと実現できないからね。
空入力の際にASC(A$)がエラーになるという問題はあらかじめN$にCHR$(0)を入れておいて
ASC(A$+N$)とすることで克服できたにょ。
これによって、Aボタンの空打ちで「前回入力したコードを再度実行」というえいださんの
インタープリタでは実現されてない機能も実現することができたにょ。

次に実行中の様子の分かりやすさだけどやはり大きいのはポインタの値の表示にょ。
これは別に難しいことはなく現在の値を表示するだけにょ。
しかし、1画面プログラムにおいては多数のものを表示するとLOCATEだけでも馬鹿にならなく
なってしまうにょ。
また、カーソルはGFILLで描画しているけど実行中のコードとポインタの2カ所にカーソルを
描画しなくてはならないためGFILL命令が2つ必要になるというのも1画面プログラムでは
辛くなるところだけどそれよりも辛いのがカーソルの座標を求めなくてはならないという
ことにょ。
2カ所のカーソルのX、Y座標、つまり4つの座標において固定ステップの整数化が必要になって
くるにょ。
単なる整数化であれば、FLOOR (A) は 0OR A で済むのだけどこれが32単位で整数化（つまり、
32、64、96・・・）であれば (0OR A/32)*32 とする必要があるにょ。
これでは1行に収まらない行が出てきたため 0OR A よりもさらに短縮できる整数化の方法を
用いているにょ。

操作性においては、実行速度可変式が絶対条件にょ。
えいださんのBrainfuckインタープリタはウエイトを0〜9フレームに設定できるけど初期値が
4になっているのだけどボタンの長押し対策がされてないためそれより速くしようものならば
すぐに0に達してしまうにょ。（一番使えそうな1〜3が設定するのが困難）
ということで、1画面でボタンの長押し対策をするのは大変だし、速度を一気に変えたい場合
にはボタンを何度も押すのは不便であるため各ボタンに速度を割り振ることにしたにょ。
これによって実行速度は自由に変えられるようになったにょ。
また、上記の空打ちで前回実行したコードがそのまま実行できるというのは非常に大きいにょ。
やはり、1回実行するたびにロードしなおしなんて非常に面倒だし、（コードの直接実行の
画面だけではなく）ロード画面のファイル名入力行に前回実行されたコードが表示されて
いるためRUNをして、そのコードを削除して、ファイル名を入力というのを1回ごと行うのは
私には耐えられなかったにょ。
ということで、操作性においては十分なできになったと思うにょ。

そうしてできたのが、このPetit Brainfuckにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/2page.htm#brainfuck
http://www.youtube.com/watch?v=QA4aqgKYQ48
ただし、上記の3つのポイントがクリアできた反面で「,」命令の搭載は見送りで多重ループは
不可になったにょ。
これは現在可能なリスト短縮テクニックを駆使してもどうにもならなかったけど「,」命令を
使う機会はあまりないし、追加は非常に容易であるため問題ないにょ。（操作性や画面表示
関係はそう簡単にはいかない）
また多重ループにおいてはMEMリソースを使う以上は255文字が限界となるため多重ループが
不可欠になるような複雑な処理は書けないだろうと判断したのでそれほど問題はないと
思われるにょ。
個人的にはこの命令の一部が非実装となったデメリットよりも上記の3つをクリアできた
メリットの方が遙かに大きく感じるにょ。

とはいえ、やっぱり多重ループを使いたいとか言う人は自分で実装するのも1つの手にょ。
そのための解説ページも作ったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/brainfuck.htm
このページにはBrainfuck入門やサンプルコードなども書いているため参考になるのでは
ないかと思われるにょ。

1417：御茶目菜子：2012/12/10(月) 23:57:46
人は困難を乗り越えてこそ成長できる
昨日は1画面プログラムは取捨選択が重要ということを書いたにょ。
これは1画面プログラムの場合は短くしなくてはいけないからすべての面においてチープに
しがちであり、そうなるとただ短いだけのものになってしまうにょ。
そうならないためにも絶対に入れなくてはならない部分と無くても問題ない部分との
メリハリを付ける必要があるにょ。

プチコンの処理速度があればリストサイズに制限が無ければ大抵のものは簡単に作れてしまう
ために私は「1画面」という絶妙な制限が気に入っているにょ。
そして、ここで簡単に1画面に収まるサイズのものを作っても上記のようなメリハリはあまり
ないし、「1画面に収めた」という達成感も無くなるにょ。
BrainfuckインタープリタもMEMリソースから読み込んで実行するだけで画面表示は出力
命令によるもののみという非常にシンプルなものであれば1画面に収めるのは容易だからね。
それにそれだとえいださんが作ったものの単なる下位モデルのような感じなので作る意味が
なくなってしまうにょ。

リスト短縮テクニックにおいてはすでにTipsコーナーに多くまとめているけどこれはすべて
リスト短縮の必要性があったからこそ生まれたテクニックであり、簡単に1画面に収まるような
ものでは新しいテクニックは生み出せないにょ。
したがって、「この行をあと1文字削らないといけない」という状況下を作らないと技術向上は
望めないレベルになっているということにょ。
これは1画面プログラムにおいてだけの話ではなくどんなジャンルのことでも同じだけど自分で
簡単にできることはいくらやっても成長には繋がらないからね。
壁を乗り越えることによって成長できるにょ。

さて、昨日のPetit Brainfuckにおいて新しい整数化の方法を思いついたと書いたのだけど
それが具体的にどんなものかを書いていくにょ。
通常はプチコンで整数化を行いたい場合はFLOOR関数を使うことになるにょ。
しかし、これは一般的なBASICで多く使われているINTよりも長くて残念な部分といえるにょ。
とはいうもののFLOORを使わなくても別の方法で整数化は可能にょ。

　ビット演算子 OR を使う　→　0 OR A　（0とORの間のスペースは省略可能）
　剰余（％）を使う　　　　→　A-A%1

これに続いて今回思いついたのがこの方法にょ。

　乗除算を使う　　　　　　→　A/Z*Z　（あらかじめZ=4096としておく）

除算でなぜ整数化ができるかというとプチコンは固定小数点による演算をしており内部では
1/4096単位で数値が記録されているためにょ。
だから4096で割ってやれば元の小数部分は無くなりそれを4096倍すれば整数化できるにょ。
注意しなくてはならないのは負の数の場合はFLOOR(-3.5)は4だけど-3.5/Z*Zは-3であるため
異なるものになってしまうことだけどこれも正の数なら問題はないにょ。
しかし、0OR Aが5文字でA/Z*Zも5文字であるためリスト短縮はできてないにょ。
それにあらかじめZ=4096としておかないといけない分だけ不利になるにょ。

とはいえ、この乗除算だけで整数化を行う方法は特定条件下ではリスト短縮の効果が期待
できるにょ。
8単位で整数化したい場合（Aの値を8、16、24、32・・・という形に丸めたい場合）は、
FLOOR(A/8)*8（12文字）、0OR(A/8)*8（10文字）に対してA/8/Z*Z*8（9文字）で1文字分
短縮できてるにょ。
これが昨日のPetit Brainfuckで使用した方法にょ。
でも、あらかじめZ=4096としないといけない分不利になるため6回以上整数化を行わないと
短縮できないにょ。
1画面プログラムでは特定行は数文字余裕があるのにある行だけ1文字分収まらないという
場合にはこの方法が有効になる場合があるにょ。

プチコンの1画面プログラムはエディタの折り返し機能がないため1行あたり29文字という
制限があるので行末がどうしても開いてしまうにょ。
その反面で1行に収まらないという行も出てしまうにょ。
2桁以上の数値（別の命令の直前ならば3桁以上の数値）が使われていれば別の変数に
入れてトータルでは長くなってもその行を縮めるということができるけどそれにも限界が
あるにょ。
また依存性のない処理を並べ替えることで上手い具合に空白を埋めてやったり、コロンが
省略できる形に持っていくことで短縮できるけどこれにも限界があるにょ。
順調にリスト短縮が進んでいたPetit Brainfuckも最後の部分で限界に達したためあきらめ
かけていたのが上記の方法によって一気に改善の方向に向かったにょ。
つまり、Petit Brainfuckはこの乗除による整数化を思いつかなかったら完成していなかった
ともいえるにょ。

この乗除による整数化は小数第1位までに丸めたいという場合はさらに大きな短縮ができて
しまうにょ。
FLOOR(A*10)/10（14文字）、0OR(A*10)/10（12文字）に対して（あらかじめZ=409.6として
おいた場合）A/Z*Z（5文字）で7文字分も縮まるからね。
あらかじめZ=409.6が必要としてもそれ単体で7文字であるため1回使えば短縮できるにょ。
しかも1回の使用であっても14文字や12文字連続して必要なものに対して5文字と7文字に
分割して使えるというのが1行29文字制限のある1画面プログラムではメリットが非常に
大きいにょ。

タネを聞いてしまえばたいしたことではないのだけどそれをひらめくかどうかというのは
プログラミングにおいては非常に重要なものとなるにょ。
1画面プログラムは1つ1つ作るごとに新しい発見があり常に新鮮な思いで作っているの
だけどそれもこうやって1つずつ壁を乗り越えていって初めて獲得できるものにょ。
やはり、人は成長をするためには困難を避けてはだめであり、困難を乗り越えていく
必要があるにょ。

1418：御茶目菜子：2012/12/12(水) 23:34:48
Brainfuckで四則演算
先日プチコンでBrainfuckインタープリタである「Petit Brainfuck」を作ったのだけど
それを使って加減乗除を行うコードを書いてみたにょ。
ちなみに使用環境はPetit Brainfuck（改造点で書いた「入力命令」「多重ループ」「ブレーク
ポイント」を追加したもの）＋PETIT EDITOR＋ラベルスタートの3つのプログラムにょ。
これによって、プチコンのみで快適にBrainfuckのコードが書けるにょ。
しかも、全部合わせても2KB足らずと非常にコンパクトにょ。

では、まずはどのような仕様にするかを考えるにょ。
入力命令「,」を用いてキーボードから2つの数を入力してそれをポインタ0、1に入れて
両者を加算してポインタ2に入れるというものにしようと思うにょ。（入力命令はPetit
Brainfuckではデフォ状態ではオプション扱いになっているので動作のためには追加は必須）
具体的に書けば加算の場合はキーボードから[4][2]を入れたらポインタの値は[4][2][6]に
なるというものにょ。
終わった時に操作しているポインタにカーソルを合わせておけばどれが答えになるかも
分かりやすくなるにょ。
本来ならば出力命令を使って「4+2=6」という感じのものを表示したいところだけど答えが
2桁になった時に非常に難易度が高くなるにょ。
というのも仮に答えが35になった場合に「35」という文字を出力するためには10の位と
1の位に分けないといけないからにょ。
つまり、「35÷10＝3…5」というように除算の商と余りを求めるコードを書く必要性がある
ためにょ。
それは、Brainfuck初心者の私にとってはかなりハードルが高いし、Petit Brainfuckでは
上限が255文字となっているためそんな複雑なコードは書けないため今回は出力命令は使用
しないことにしたにょ。

というわけでまずは、加算のコードにょ。（79文字）

,>,>++++++++[<------<------>>-]<<[>>+>+<<<-]>>>[<<<+>>>-]<<[>>+<<-]>>[<+<+>>-]<

PCで動作させるならば「Brainfuckインタープリタ」はぐぐれば多数見つかるのでその中から
ポインタ（メモリ）の値が分かるものを使ってコピペしてから実行するとこのコードが
どのようなものかが分かるにょ。

まずは、ポインタ0、1にテンキー（0〜9）で入力した文字の値を入れる必要があるけど
「1」は文字コード49であるためポインタ0、1の指す値から48ほどマイナスしているにょ。
次にポインタ0の値をポインタ2にコピー（ポインタ0の値をポインタ2、ポインタ3に移動した
後にポインタ3の値をポインタ0に移動）、ポインタ1の値をポインタ3に移動した後に
ポインタ3の値をポインタ1、2に移動・・・これで完了にょ。
例えば、5、4と入力すれば[5][4][9]となってカーソルは[9]の場所にあり5＋4＝9が計算できた
ことが分かるにょ。
ポインタ0、1の値を破壊していいのならば大幅に短いコードは書けるけど最初に書いた仕様
通りだとこれが一番理解しやすいのではないかと思うにょ。（それでも時間をかけて考えれば
これよりもかなり短縮できそうだけど）

ちなみにポインタ0、ポインタ1の値を破壊してもいいならば同じものが35文字に短縮可能にょ。
,>,[<+>-]++++++++[<------------>-]<

次は減算のコードにょ。（79文字）

,>,>++++++++[<------<------>>-]<<[>>+>+<<<-]>>>[<<<+>>>-]<<[>>+<<-]>>[<-<+>>-]<
最後に1カ所「＋」が「−」に変わっただけであとは加算と全く同じなので省略にょ。

続いては乗算のコードにょ。（94文字）

,>,>++++++++[<------<------>>-]<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<<[>>>+<<<-]>>>[<<+<+>>>-]<-]<

2重ループを使っているけど多重ループはデフォ状態のPetit Brainfuckではオプション扱いに
なっているので追加対応しておかないと動作はしないにょ。
加算と同じくポインタ0、1の値を48ほどマイナスしたあとポインタ0の値をポインタ3にコピー
しているにょ。
「ポインタ1の値をポインタ4に移動した後にポインタ4の内容をポインタ1、2に移動」という
ものをポインタ3の値の回数だけ繰り返しているにょ。
乗算は加算を繰り返せばいいだけなんだけどBrainfuckの場合はループのカウンタ用に使って
いるものは破壊されているため2重ループの外側のループでそのカウンタの元になっている
値を初期化させる（3回ループならば値を3に戻す）必要があるにょ。

最後はいよいよ除算にょ。（96文字）

,>,>++++++++[<------<------>>-]<<[>>>+>+<<<<-]>>>>[<<<<+>>>>-]<[<<[>>>+<<<-]>>>[<-<<+>>>-]<<+>]<

乗算が加算の繰り返しならば除算は減算の繰り返しとなるにょ。
実はこれは割り切れるものでないと計算ができない不完全なコードであるためあえて解説は
しないにょ。
減算を繰り返していって本来ならば「除数＞余り」になった時点でループから抜けなく
てはならないのだけどそのいい処理が思いつかなかったにょ。
昔、マシン語で除算のプログラムを組んだときはキャリーフラグを元に判断をしていたの
だけどBrainfuckではそういうこともできないからね。
まぁすでに除算のコードを書いている人はたくさん居るのでそれを見れば簡単なのだけど
何とか自力でやってみたいにょ。（リベンジはいつになるのか分からないけど）

というわけでとりあえず除算が不完全であるものの一応四則演算はできたにょ。
Brainfuckで多重ループをさせるコードは初めて書いたけどさすがに難しいにょ。
キー入力した2つの値の加算なんてBASICで書けばめちゃくちゃ簡単にょ。

　INPUT A
　INPUT B
　C=A+B

というだけのことだからね。
これが難解プログラミング言語の難しさであり面白さでもあるにょ。
Brainfuckを完全にマスターすればアクションゲーム（リアルタイムで動作するゲーム）
以外のものは作ることが可能でありオセロゲームくらいならば十分できそうにょ。（しかし
疑似乱数発生のコードまでかかないといけないのでかなりハードルは高そう）
といっても、プチコンの場合は制御文字が使えないため表示場所を指定したコードを書く
ことはできないけどね。（そもそもコードが冗長になってしまうので上限255文字のPetit
Brainfuckでは大した物はできない）
とはいえ、Petit Brainfuckはこの規模のコードを書くならば十分な性能であり、お手軽に
コードを書くには最適といえそうにょ。（PC向けではJavascriptやJavaアプレットで動作
するBrainfuckインタープリタはいくつか試したけどどれも今ひとつで「お手軽」という
感じはしなかった）



《　12/13　追記》

四則演算のコードは初出より少しだけ縮まった（48回デクリメントする処理は短くなると
思っていたコードが実は長かった）ので差し替えておいたにょ。（変えたのはそこだけ）
ちなみに画面出力が何もないというのも何なので「4＋2＝6」という感じの画面出力に対応
したものもついでに書いておくにょ。（148文字）

>>++++++++[>++++++>++++++>+++++>
++++++++<<<<-]<<,.>>>>>+++.<<<<,
.>>>>>---.<<<[<<-<->>>-]<<<[>>+>
+<<<-]>>>[<<<+>>>-]<<[>>+<<-]>>[
<+<+>>-]<[>>+<<-]>>.

初期に作ってそのまま放置状態なので短縮の余地はかなりありそうにょ。（完全な除算が
できてないので答えが1桁になるもののみ表示可能）

それとは関係ないけど「Petit Brainfuck」は早くも辞書登録を行ったにょ。（通常は
3〜6ヶ月分の新作をまとめてやることが多い）
http://ww5.tiki.ne.jp/~ochame/ochamewords.htm#p_bf
しかし、「ハ行」の語句がやたら多いにょ（プチコン関係のせいだけど）
1419：hatena：2012/12/13(木) 20:45:01
Brainfuckって凄い！
「Petit Brainfuck」にとても感動しました！
ということで、Visual Basic 2010でBrainfuckの派生言語を作ってみました。
VB.NETであるためWindowsでしか動きませんが。
言語名は「Fuck+2」にしました。

http://www1.atwiki.jp/hatena71869/pages/30.html

1420：御茶目菜子：2012/12/13(木) 23:59:26
レスにょ
hatenaさんへ
＞「Petit Brainfuck」にとても感動しました！

これはどうもにょ。

＞ ということで、Visual Basic 2010でBrainfuckの派生言語を作ってみました。
＞ VB.NETであるためWindowsでしか動きませんが。
＞ 言語名は「Fuck+2」にしました。

すごいけどいろいろ追加されているためもはや別物にょ。
あまり増やすと便利すぎて難解プログラミング言語では無くなってしまいそうにょ。
これはこれで悪くはないんだけど・・・。

というわけで私も即興でPC用のBrainfuckインタープリタを作ってみたにょ。
http://ww5.tiki.ne.jp/~ochame/brainfuck.zip
一応「＋」「−」「＞」「＜」「，」「．」「［」「］」の8つ全部をサポートしているけど
数時間で作ったため最低限の機能しか実装してないにょ。（一応ポインタの値の表示くらいは
しているけど）

1421：hatena：2012/12/14(金) 16:56:51
レスかしら
御茶目菜子さんへ
＞すごいけどいろいろ追加されているためもはや別物にょ。
＞あまり増やすと便利すぎて難解プログラミング言語では無くなってしまいそうにょ。
＞これはこれで悪くはないんだけど・・・。

確かにFuck+2なら「 A 」を表示するのに「6&5.」だけでいいしね。
「6&5.」じゃ可読性がありますね。Aの文字コードはAですからね。
まあ、引数無しで命令が一文字の色々できる変な言語ということにします。

＞というわけで私も即興でPC用のBrainfuckインタープリタを作ってみたにょ。
開発環境を教えて欲しいのですがよろしいでしょうか？

1422：御茶目菜子：2012/12/14(金) 23:29:55
レスにょ
hatenaさんへ
＞まあ、引数無しで命令が一文字の色々できる変な言語ということにします。

それならばまだ未使用の記号は多いので便利そうな命令をさらに追加していくと良さそうにょ。
個人的には前のポインタの値との差分を取る命令や前のポインタの値より大きい（もしくは
小さい）場合のみ繰り返すループ命令があると便利に感じるにょ。
これがあれば複雑な繰り返し処理をBrainfuckより遙かに簡単に書くことができるにょ。
まぁ個人的には無駄なものが全くないミニマム構成ともいえるBrainfuckが好きだけど（笑）

＞開発環境を教えて欲しいのですがよろしいでしょうか？

これはHSPで作ったにょ。
HSPは2.5の頃から使っているけど未だにかじった程度にょ（笑）
VBは6.0の頃から使っているし、普段持ち歩いているPCにはVS2008が入ってるけどどうもVSが
重いので最近はあまり使ってないにょ。
Core Solo 1.2GHz、メモリ1.5GB（←これが上限）なので・・・。

1423：御茶目菜子：2012/12/15(土) 23:50:41
CHRリソースでセーブデータを小さくしよう
何度も書いているようにプチコンmkIIはQRコードでプログラムやリソースのやりとりが
可能になったというのは非常に大きな進歩だけどその反面でネット上で公開されている
プログラムやリソースをどんどん取り込んでいるような人だとすでに「保存のための空き
容量が足りません。不要なファイルを削除してください。」という警告画面を見たことが
ある人も多いのではないかと思うにょ。
私自身はここ最近は頻繁に見ており、少しずつ削除して新しいQRコードを読み込んだり
新しいプログラムを作ったりしている状態にょ。

現状で発表されているプログラムはどうしようもないけどやはりこれから発表してもらう
プログラムでは少しでも多くの人に取り込んでもらうためには「いかに容量を抑えるか」
ということも求められてくるのではないかと思われるにょ。
その1つがCHRリソースなどを大量に使っているプログラムの場合だとリソースファイルを
別途に公開したり、パッケージ形式で公開せず、CHRリソースデータをPRGに埋め込んだ
状態で公開するというものにょ。
ただし、この場合、普通にCHRリソースデータをPRGにDATAで羅列してしまうとリソースで
別途公開した方がサイズが小さかったということにもなりかねないにょ。
そのため、16進数データを圧縮するという方法が求められてくるにょ。
すでに16進数データを256進数に圧縮するプログラムは公開されているのだけどそれを
使ってやれば保存領域の軽減が可能とはいえ、CHRリソースを大量に使っているゲームだと
制作者に多大な負担をかけてしまうにょ。（圧縮するためのデータのPRGへのやりとりも
大変だけど修正も難しくなる）
そして、9999行制限のためすでに数千行も使っているような超大作の場合は事実上PRGに
埋め込むことなんてできないにょ。

さて、そうなると最もお手軽な保存領域の軽減方法として考えられるのがGRPのセーブを
使わないということにょ。
プチコンで標準でデータセーブ用に用意されているMEMリソースは256バイト分しかセーブ
できないということでそれ以上をセーブしたい場合は256バイト単位で分割していく必要が
あるにょ。
しかし、それが数KBもしくはそれ以上のセーブデータになってしまうとファイル数ばかりが
膨らんでしまいユーザーにとってはデメリットでしかないにょ。（SAVE画面は必ずダイア
ログが出るため10分割したら1回セーブするたびに10回も「はい」を押す必要がある）
そのため256バイトに収まらないセーブデータはGRPリソースでセーブするというのが広く
普及しているにょ。

しかし、256バイトのMEMリソースから48KBのGRPリソースになり保存できる量は192倍
増えたのだけど保存領域もそれにしたがって増えているにょ。
GRPリソースは仮に1バイトしか記録していなくても保存するのに48KBの領域を占有して
しまうからね。
というわけで、MEMリソースよりも大きくGRPリソースよりも小さい8KBのCHRリソース
（SPU、BGU）を使ってセーブすれば保存領域は1/6に軽減できるにょ。
とはいうものの1バイト単位で記録ができるMEMリソースやGRPリソースとはCHRリソースは
32バイト単位でしか書き換えることができないにょ。
しかも、書き換えられるのは0〜Fの16進数データのみであるため少しずつデータを書き
換えていくという用途には非常に使い勝手が悪いにょ。
すでにGRPリソースで記録するようにしているプログラムも大幅な改造が必要になってくる
ためCHRリソースを使ってセーブを行う作品は全く見かけないにょ。

そこで考えたのがランダムアクセスや1バイト単位での追記が難しいCHRリソースに随時
書き換えるのではなく普段はGRPに記録しているけどセーブの時だけ一時的にCHRリソースに
変換するというものにょ。
これならば今まで作ったプログラムをほとんど変えることなく変換プログラムを追加する
だけで対応できるため多くの人が利用できるのではないかと思われるにょ。

そういうことで、GRPリソースのセーブデータをCHRリソースに変換するプログラムを
作ってみたにょ。

1行プログラム「CHRセーバー」
FOR I=0TO 255FOR J=0TO 31Z=GSPOIT(I%8*32+J,I/8)C$=C$*!!J+HEX$(Z,2)NEXT:CHRSET R$,I,C$NEXT
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#05

1行プログラム「CHRローダー」
FOR I=0TO 255CHRREAD(R$,I),C$FOR J=0TO 31Z=VAL("&H"+MID$(C$,J*2,2))GPSET I%8*32+J,I/8,Z:NEXT:NEXT
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#06

セーブする際にはCHRセーバーを使うのだけどまずは変数R$に一時保存用に使うリソースの名前
（SPU0〜SPU7、BGU0〜BGU3のいずれか）を入れておくにょ。
GPAGEの設定も忘れずにセーブをしているページに設定して実行するにょ。
そうすればGRPリソースがCHRリソースに変換されるので SAVE R$+":(ファイル名)" でCHR
リソースとしてセーブできるにょ。
ロードする際には同じように設定を忘れずに行いまずは変換されたCHRリソースデータを
LOAD R$+":(ファイル名)" で読み込ませるにょ。
そして、CHRローダーを実行すればGRPリソースのセーブデータとして元に戻るにょ。
つまり、すでにGRPリソースでセーブするプログラムを作っている人ならばわずか1行の
プログラムを2本（約200バイト）を追加するだけで後は無改変でCHRリソースによるセーブ
システムができあがるにょ。（ただし、SPUやBGUの空きが1つ必要となる）

これによって、48KBあったセーブデータが一気に8KBへと小さくなるためセーブデータが
8KB以下のプログラムならばこれによってセーブデータを1/6に圧縮するのと同等の効果を得る
ことができるにょ。
実際はほとんどのプログラムのセーブデータは8KBよりも小さいためこれで問題が発生する
ことはあまりないのではないかと思われるにょ。（リプレイデータを保存する場合には60fpsの
ゲームであっても8KBに2分16秒分記録できる）
とはいうものの、逆に8KBでも大きすぎるという場合もありそうにょ。
1KBや2KB程度のリソースデータがあればそれを使うという方法もあるけど8KBのCHRリソースの
下は一気に256バイトになるためなかなか難しいところにょ。

あと問題となるのはプチコンの保存領域の最小単位にょ。
HDDなどではクラスタサイズに相当するものだけどこれがプチコン（というか、DSiや3DSの
内蔵フラッシュメモリ）の場合はどうなのかということを考える必要があるにょ。
実際にギチギチに詰めて警告が出る状態で1枚のGRPを削除してそこにどれだけのものをセーブ
できるかを検証したら1バイトのプログラム（改行1つ＋ヘッダ）でさえ13回目のセーブで再び
警告が出たにょ。
これから保存領域の最小単位は4KBであると推測されるにょ。
そうなると1KBのリソースがあっても4KBのリソースと同じ分だけ占有されてしまうという
ことになるにょ。
確かにそれでもCHRリソースの8KBというサイズは1〜2KBしかセーブしていない場合には無駄が
多いけれど保存領域の最小単位に適合するようなベストなリソースがないためこれが256バイト
超のセーブとしては最善ではないかと思われるにょ。
256バイトのMEMリソースを2つセーブすればCHRリソースとほぼ同じ分だけ保存領域が必要に
なってしまうということだからね。

プチコンmkIIの後継では3DSに対応によって保存領域の大幅拡大を望みたいのだけど保存する
リソースもユーザーで自由にサイズ選択ができるようになると利便性が高まりそうにょ。
個人的には一般的なBASICのように普通にファイルが扱えるようになるのがベターに感じる
けれど任天堂の厳しいチェックを通過できるためにはセキュリティ面を非常に重視している
ためにユーザーの利便性のみを高めたものをリリースするのは難しそうにょ。

1424：御茶目菜子：2012/12/18(火) 23:59:45
目の付け所がシャープ・・・なのか
シャープが1000ページ保存できる手書き電子ノートを発表したにょ。
http://pc.watch.impress.co.jp/docs/news/20121218_579071.html
安価なタブレット端末が多く登場している中でモノクロ液晶なんて・・・と思うかもしれない
けれどモノクロ液晶を搭載のメリットは長時間駆動が可能というメリットがあるにょ。

タブレット端末はスマホと比べて大容量のバッテリを搭載の機種が多いため普通に使って
5〜7時間程度は余裕で使えるし、機種によっては10時間近く動作するものもあるにょ。
それでも「たったの10時間」にょ。
この感覚はポケコンやモノクロ液晶のPDAを使ったことがある人なら分かるけど毎日数時間
使っても数週間はバッテリ駆動が可能というのがモノクロ液晶を搭載の魅力にょ。
とはいえカラー液晶もIGZO液晶の登場によって液晶そのものの消費電力は激減しているとは
いえ事実上バックライトが必要不可欠であるためバックライト無しでもそれなりにまともに
見えるモノクロ液晶と比べて消費電力の面ではまだ劣っているにょ。
それに3DゲームやHD動画の再生のためCPU（GPU）の消費電力もかなり大きなものになっている
けれどそれを行わないであろうモノクロ液晶のこういった端末であれば長時間駆動が当たり前
とも言えるにょ。

また、昨今のスマホやタブレット端末はほぼすべての機種が静電容量方式のタッチパネルと
なっているにょ。
これは指での操作に優れていると同時にマルチタッチをサポートしやすいというメリットも
あるにょ。
つまり、指でさまざまな操作を行うタブレット端末にとってベストな選択肢といえるにょ。
その反面でペンによる操作性は期待できないにょ。
確かに静電容量方式用のペンは存在するけど静電容量方式による認識を行うためにはある
程度以上の面積も必要であるため細いペン先のペンを作ることはできないにょ。
線自体はソフト次第でいくらでも細い線は描けるけど細かい線を描くのは原理上できないにょ。
そのため昨年8月7日に書いたように実験的にiPadを授業に導入している学校の生徒に聞いて
みた結果は「ノートの代わりになるとは思わない」と答えた人が過半数の55％になったとの
ことにょ。
資料の活用などビューアとしては高く評価されているもののiPadを始めとするタブレット
端末はノート代わりにならないというのはこの学校においてだけの話ではなく上記のような
仕様の問題があるため一般的な意見といってもいいのではないかと思われるにょ。

さて、それを考えるとタブレット端末では実現できない隙間があるにょ。
これを埋める1つの方法として挙げられるのがショットノートやCamiAppといったものにょ。
昨年8月10日にも書いたけどこれらの大きな特徴はデジタルとアナログの融合にょ。
文字だけではなく図などを含めたメモを「書く」という行為はアナログの方が便利なことが
多いけどそれを管理するのはデジタルの方が便利だからね。
それをストレートに行えるものということでヒット商品となったにょ。
確かに（自動的に補正を行うためにはやむを得ないのだけど）専用の用紙が必要ということが
ネックになるものの用紙そのものは自作も可能であるためそういった自作をしている人も
数多くいるにょ。

話は戻るけどシャープがこの度発表した手書き電子ノート「WG-N10」を見るとモノクロ液晶
ということもあり1日2時間の使用で30日間使える（つまりバッテリ駆動時間60時間）という
のはタブレット端末にはない大きなメリットとなるにょ。
そして、感圧式のタッチパネルによって普通のスタイラスで細かい文字が書けるというのも
メリットとなるにょ。
ただし、これは逆に考えてみると昔からあったPDAと何が違うのかということにょ。
手書きによる入力はシャープの端末だけを見ても1992年に登場のPV-F1で可能になったし
翌年に登場した初代ザウルスPI-3000でその地位を絶対的なものにしたにょ。
従来は電子手帳というのはキーボードが付いてそれで入力するというのが当たり前だったけど
ザウルスの前身となったDB-Zですでにタッチパネルは採用されそしてこのザウルスによって
タッチパネルは非常に身近な存在になったにょ。
それから、約20年経っての登場となるけどその年数分の進化があるのかが気になるにょ。

この「WG-N10」はノートに特化しているためか機能は非常に抑え気味になっているにょ。
「PDA」というといろいろなアプリが動作したりというのがイメージにあるけどそういう
機能はなく本当に「手帳」以外のことには使用はできないにょ。
まざまなソフトの追加が可能だったり、通信も行えたかつてのザウルスとは異なりWG-N10は
拡張性も極めて低くPC接続用のmicro USB端子があるだけにょ。
micor SDによって容量を拡張したりWi-Fiで通信ができたりということもできないにょ。
では、WG-N10の容量がどれくらいなのかというと800x600ドット、モノクロ16階調で1000
ページ保存可能ということしか分からないにょ。
1ページ当たり単純計算で240KBなので内蔵フラッシュメモリは256MB程度と推測されるにょ。
これは極めて少ないのだけど今のご時世はこの部分でコストを削ってもほとんど変わらない
ためもう少し奮発しても良かったのではないかと思われるにょ。
液晶も800x600のSVGA液晶は多くのモノクロPDAよりは高いものの今時の安物（1万円以下）
タブレット端末の標準的な解像度であるWSVGA（1024x600）も下回るにょ。
モノクロ電子ペーパー搭載機種ならばSVGAの機種はあるけどそれらは1万円以下で買えるにょ。
それに対してWG-N10は15000円程度の想定価格はあまりに高価にょ。

これが様々な用途（例えば電子書籍閲覧用など）に使えるのであればまだ割高感も緩和できる
もののそんな機能はないにょ。（というか、PDFさえ読めないみたいだし）
いや搭載されても256MB程度の容量では実用的とはいえないにょ。
ここまでスペックを削ってひたすら安価なもの（定価は半額となる7000〜8000円程度）にする
ならばまだ分からなくもないけどこの定価でこのスペックや機能ではさすがに厳しいのでは
ないかと思われるにょ。（逆にこの価格ならばGALAPAGOSストアに対応して、PDF表示もできて
PCとはWi-Fiで繋がりクラウドに保存くらいはできなければ魅力がない）
目の付け所がシャープではなくあさっての方向に向かっている感じにょ。
個人的にはモノクロPDAは「安ければ」魅力的になるけどPDAとしても中途半端で価格も安くは
ないためコレジャナイ感が非常に大きいにょ。

1425：御茶目菜子：2012/12/19(水) 23:20:48
おちゃめくらぶもいよいよグローバル展開か・・・？
「ダミーちゃん危機一髪」の英語版を作ってみたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/dmmy_chan_eng.htm
「ダミーちゃん危機一髪」とは何かというとかつて8ビットパソコン（PC-88/FM-7/パソピア）
向けにエニックスから発売された「マリちゃん危機一髪」をインスパイアして作った
プチコンゲームのことにょ。（実は、このダミーちゃん危機一髪を投稿した日の晩に
コニミルさんが「マリちゃん危機一髪」のプチコン版の動画を公開したことが制作のきっかけ
となった）
http://ww5.tiki.ne.jp/~ochame/petitcom/dmmy_chan.htm
「マリちゃん危機一髪」は要するに脱衣じゃんけん（野球拳の一種）なのだけど「ダミー
ちゃん危機一髪」では脱衣要素は含まれないのでお子様も安心してプレイできるかも
しれないにょ。
ただし、「マリちゃん危機一髪」でもあった「殺（や）るか、殺られるか」という展開は
このダミーちゃん危機一髪でも味わうことができるにょ。

それと「ダミーちゃん危機一髪」は脱衣要素がない代わりにコンピュータの思考ルーチンを
導入してゲーム性を高めているにょ。
この思考ルーチンは別にすごいものではなくユーザーがどのような手を出しているのかという
簡単なパターン分析を行っているものにょ。
普通のじゃんけんゲームだとコンピュータの思考が完全ランダムのものが大半（残りはただの
イカサマじゃんけんで一定確率でコンピュータが勝つように細工をしているものばかり）で
あり、単純とはいえ思考ルーチンを搭載したじゃんけんゲームというのは少ないのではないか
と思われるにょ。
この思考アルゴリズムは昔ポケコンで野球拳ゲームを作った時に使用したアルゴリズムであり
サイズが小さい割にそれなりに思考ルーチンとして機能している優れものにょ。
このルーチンを搭載によってグーだけを出しても勝つのは難しく、「グー、チョキ、パー」の
ようなパターン化をしてしまえばコンピュータに対して大敗してしまうことになるにょ。
逆に言えばこの思考ルーチンの裏を付くことで意図的にプレイヤーが勝率5割以上を達成する
ことも可能になっており（極めれば長期的にみて勝率7割も可能）、運だけに左右されがちな
じゃんけんゲームなのに戦略性が高いものとなっているにょ。

さて、この英語版はどうなっているのかというと基本的にゲームシステムは日本語版と全く
同一となっているにょ。
メッセージが英語になっただけ・・・なんだけど私の英語力が拙いため意外に時間が
かかってしまったにょ。
それと北米版のプチコンはTALK命令は備えているけど音声出力がされない仕様となって
いるためそれは削ったもののあまりに寂しくなったため効果音を増やしているにょ。
ということで、何だかんだで日本語版よりリストサイズが大きくなってしまったにょ。
また、日本語版となる「ダミーちゃん危機一髪」は総制作時間4時間（コーディング時間は
約3時間）という「開発速度重視」の設計となっており、リストに無駄が多いのだけど
この英語版を作るにあたってそこはスルーすることにしたにょ。
やり出したらキリがないというのもあるけどリスト短縮をしてもQRコードの枚数が減る
わけでもないし、プチコンの保存領域の最小単位を考えるとリスト短縮をしてプログラムの
サイズそのものが小さくなっても保存領域減少に繋がることはないためにょ。

それとこの英語版では従来は裏技扱いとなっていたデバッグモードを正式公開することに
したにょ。
実はこのデバッグモードは日本語版（ver1.1）でもすでに搭載されており、[SELECT]
ボタンを押しながら起動すればいいにょ。
このデバッグモードでは上記のコンピュータの思考ルーチンのデータを画面上で見ることが
できるようになるにょ。
具体的に言えば「次にプレイヤーがグー、チョキ、パーを出すであろう確率」を表示する
というものにょ。
単なるデバッグモードであるため日本語版ではウインドウ内に数字が3つ並んでいるだけ
（左からグー、チョキ、パーの確率）となってるのだけど英語版では正式公開となったので
それを分かりやすく画面上で表示することにしたにょ。（この数字を見ながらプレイ
したらコンピュータに対しての勝率は簡単に6〜7割に達することが可能になるため63％の
勝率が必要になる最終ステージも楽にクリアができる）

というわけで、日本語版をダウンロードした人ならばあえて英語版をダウンロードする
必要性は全くないものであり、純粋に英語圏の人向けに作ったものにょ。
この「ダミーちゃん危機一髪」はYouTubeのアクセス解析を見てみると北米からのアクセスが
意外に多いことが分かったにょ。（私がYouTubeに投稿している動画は北米からのアクセスが
7〜15％となっているけどこの「ダミーちゃん危機一髪」は30％以上が北米からのアクセス
となっている）
しかし、言語の問題は非常に大きいにょ。
私が作っているゲームの大半は数回プレイすれば簡単に操作方法が分かるレベルの単純なもの
ばかりであるため言語の壁はほとんどないけどこの「ダミーちゃん危機一髪」は日本語が
分からないとプレイそのものが困難にょ。（公式サイトのプレゼント素材を使っているため
それも日本語の説明から読み取らなくてはならない）
したがって、私が作ったプチコンゲームの中で唯一英語版を出す意味がありそうなゲームと
感じたにょ。
恐らく他のゲームは英語版を用意するつもりはないしツールの類は英語で説明するのが
面倒（というか需要も少なそうだし）であるため現時点では英語版の説明を用意する予定は
ないにょ。

1426：御茶目菜子：2012/12/22(土) 23:39:17
今年のプチコン総まとめ
今年も残り1週間少々になり恐らく年末はプチコンに割ける時間はほとんどないと思うので
最後に1行プログラムを2つ作ってみたにょ。

1行プログラム「タイピング」
T=0FOR I=65TO 90ACLS:GPUTCHR 9,9,"BGF",I,4,8T=T+1P=INKEY$()==CHR$(I)I=I-!P:BEEP,,-P?T/30:WAIT 2NEXT
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#07

1行プログラム「スノーボード」
CLS:S=0FOR X=9TO 32S=S+1LOCATE RND(30),23?S:LOCATE X,3?0:X=X-!BUTTON()*2+!!CHKCHR(X,4)*34WAIT 3NEXT
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#08

どちらも今まで使ってきたリスト短縮テクニックを使ったものであり、新規に開拓できた
テクニックはないのだけど一応工夫した点などについて書いておくにょ。

「タイピング」の方はポケコンなどでいくつも作ってきたタイプのゲームなので作るのは
非常に簡単だったため「GPUTCHRで文字を大きく表示させる」というのを盛り込むことに
したにょ。
あとは正しく押せた時にはBEEP音を鳴らしたいというのがあるためそれも1行に盛り込むと
いうことにしたにょ。
特定時のみBEEPを鳴らすというのは簡単に可能にょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/list.htm#beep
GPUTCHRを入れるのも非常に簡単だけど1行に収めるならば引数が多くて省略もできない
というのがネックにょ。
それでも1行には十分収まったもののタイム表示と重ならない位置になるような表示座標に
する関係で残り使用可能文字数の関係で座標には1桁しか使えなかったというのと後は白の
次に輝度が高い黄緑で表示するということに気を付けた程度にょ。

しかし、GPUTCHRを使うと別途GCLSが必要になるという問題があるにょ。（この時点で
残り使用可能文字数は1文字）
LOCATEの省略と表示の桁落ち問題を避けるためにメインルーチン内にCLSを置いていたので
CLS：GCLSとしなくてもACLSとすれば良さそうだけどACLSはそれだけで約1フレームの時間が
かかってしまうという点がネックとなるにょ。（CLSとGCLSは約0.1フレーム）
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/list.htm#cls
仕方ないのでACLSを用いてWAIT 1だったのをWAIT 2にすることで何とかギリギリ1行に
収まったにょ。（これはWAIT 1では常時処理落ち状態になるため画面がちらついてしまう
ためだけど同じ1行プログラムである「アナログテレビ」はループ中にACLSを用いて意図的に
WAITを入れないことで逆にちらつきを表現している）
というわけでこちらは比較的簡単に1行に収まったにょ。

「スノーボード」の方も昔から作り慣れているタイプのゲームだけど当初は1行に全然
収まらなかったにょ。
そのため表示周りを大きく変える必要性があったにょ。
障害物は適当なキャラを使っていてスコアが上がるごとに文字列の掛け算を使って一定ごとに
その量を増やしていた（?"■"*(S/99+1)のような感じ）けれどこれはスコアそのものを
障害物と見なすことで大幅にリストが短縮されたにょ。
?S だけで障害物表示が行えるのだけどスコアの桁数が増えれば画面内に表示される障害物の
量が増えるため当初考えていたようにプレイを進めるごとに難易度を高めることが可能に
なっているにょ。（同じ難易度でずっと続くのは個人的にはあまり好ましく思わない）
そして、当然のことながらスコアの表示も兼ねているため別途表示していたスコア表示も
省略できるので一石二鳥にょ。
障害物だけではなく自キャラにおいても例えば自キャラが「V」ならば ?"V" のようにしなく
てはならず4文字分必要だけど自キャラを「0」にしてしまえば ?0 で済むため2文字で済み
2文字分短縮できるにょ。

そこまで表示を簡略化しても1行には収まらなかったにょ。
そのためさらにリストを短縮すべく右方向への移動をFOR〜NEXTで使用しているカウンタの
インクリメントでまかなうことにしたにょ。（つまり、メインルーチン内で行っているのは
左方向への移動のみ）
これは私のポケコンゲームは高速化の際におなじみのテクニックだけどここでは高速化だけ
ではなくリスト短縮効果も大きいにょ。
こうして、何とか1行に収めることができたにょ。
実は当たり判定を置く位置を変えればこのような変則手段を使わなくても1行に収めることが
できるのだけど個人的にはこちらの方が挙動が好みだったのでこちらを採用したにょ。
ということで、こちらの方は少しだけ1行に収めるのに苦労したにょ。


というわけでこの2つの1行プログラムをもって今年のプチコンプログラムは終了にする
予定にょ。（突発的によほど作りたいものが浮かんだらこの限りではないけど）
そこで今年作ったプチコンプログラムを振り返ってみることにするにょ。
今年作ったプログラムでQRコードを公開したものは下記のようになっているにょ。
大半はサイト内で公開しているけど一部の作品はtwitterのみで公開していたり、この
掲示板でのみ公開しているものがあるためそれもすべて書き連ねてみたにょ。（なぜ
すべて公開しないかというとサイトで公開しているプログラムのクオリティを一定以上に
保つためであり、pixivで例えるとラクガキは投稿しないというのと似たようなもの）

◎1画面プログラム（17作品）

　・ホワイトデーゲーム（3月14日）
　　http://6407.teacup.com/ochame/bbs/3115
　・自動歌唱ソフトOSP（3月19日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/qr/osp.png
　・棒歌ロイド　OSP2（3月25日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#osp
　・OMP with OSP（3月25日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#omp_osp
　・棒歌ロイドキーボード（1画面版）（4月2日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#bkb
　・CAVE（4月23日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/p007.htm#cave
　・JUMPING ISLAND（1画面版）（5月20日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#jump
　・簡易方位磁針（5月21日）
　　http://6407.teacup.com/ochame/bbs/3253
　・プチコン100m走mkII（5月27日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/petit_olympic.htm#100m
　・プチコンハンマー投げ（6月2日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/petit_olympic.htm#hammer
　・プチコンクレー射撃（6月17日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/petit_olympic.htm#clay
　・プチコンアーチェリー（7月28日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/petit_olympic.htm#archery
　・PETIT RUN mkII（9月16日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#prun2
　・PETIT KEYBOARD mkII（10月28日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#pkb2
　・PETIT EDITOR（11月23日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/2page.htm#edit
　・PETIT EDITOR type B（11月25日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/2page.htm#edit_b
　・Petit Brainfuck（12月9日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/2page.htm#brainfuck

◎1行プログラム（8作品）

　・100m走（11月17日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#01
　・簡易お絵かき（11月25日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#02
　・アナログデレビ（11月25日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#03
　・ラベルスタート（11月26日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#04
　・CHRセーバー（12月15日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#05
　・CHRローダー（12月15日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#06
　・タイピング（12月22日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#07
　・スノーボード（12月22日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#08

◎3行プログラム（1作品）

　・3行スキーゲーム（10月21日）
　　http://twitpic.com/b67nxh

◎1画面超のサイズのプログラム（14作品）

　・プチコンベンチ（3月18日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/p_bench.htm
　・プチコンMML with OSP2（3月25日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/osp_mml.htm
　・棒歌ロイドキーボード（4月8日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/bo_kb.htm
　・JUMP ACTION GAME（5月1日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/p007_2.htm#jump1
　・モグラたたき（5月3日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/p007.htm#mole
　・JUMPING ISLAND（5月6日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/jumping.htm
　・JUMP ACTION GAME2（5月13日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/p007_2.htm#jump2
　・リンクスライダー（5月14日）
　　http://twitpic.com/9ko7si
　・ハカセ射撃（6月21日）
　　http://twitpic.com/9ym2ck
　・ハカセジャンプ（6月23日）
　　http://twitpic.com/9zk3ak
　・ダミーちゃん危機一髪（7月6日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/dmmy_chan.htm
　・JUMPING ISLAND MANIAX（9月30日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/jumping_m.htm
　・Brainfuckインタープリタ（12月9日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/brainfuck.htm
　・DMMY-chan was close call（12月19日）
　　http://ww5.tiki.ne.jp/~ochame/petitcom/dmmy_chan_eng.htm

◎その他、サンプルプログラム（10作品）

　　紹介URL、QRコードは省略


というわけで、今年作ったプチコンプログラムはQRコードを公開分だけで50作品あったにょ。
サンプルとして作った小規模なプログラムを除いても40作品となるにょ。
ぴったりキリが良くなっているのは先日数えてみたのその段階で48作品（サンプルを除いて
38作品）だったためあと2つ作ればキリがいいということを知っていたためにょ。（冒頭で
2作品1行プログラムを公開しているのはそのため）
これを月別に分けてみると次のようになるにょ。

　　　　1画面　1行　3行 1画面超　合計
　　1月　　 0　　0　　0　　0　　0作品
　　2月　　 0　　0　　0　　0　　0作品
　　3月　　 4　　0　　0　　2　　6作品
　　4月　　 2　　0　　0　　1　　3作品
　　5月　　 3　　0　　0　　5　　8作品
　　6月　　 2　　0　　0　　2　　4作品
　　7月　　 1　　0　　0　　1　　2作品
　　8月　　 0　　0　　0　　0　　0作品
　　9月　　 1　　0　　0　　1　　2作品
　 10月　　 1　　0　　1　　0　　2作品
　 11月　　 2　　4　　0　　0　　6作品
　 12月　　 1　　4　　0　　2　　7作品
　 合計　　17　　8　　1　 14　 40作品

今年最初の公開プログラムは単にネタで作ったホワイトデーゲームにょ。
これはmkII購入直前だったり、1月2月とプチコンからしばらく離れていたためブランクが
大きかったので非常にしょぼいゲームになっているにょ。
今だったらナニはGRPで描画してアレはスプライトを使うだろうけどね（謎）
3月にプチコンmkIIを入手したときにはやはり気になっていたのがTALK命令だったので
それを使ったプログラム（歌わせるプログラム）をいろいろと模索したにょ。
その時に役立ったのがOMPにょ。
mkIIではMML演奏機能（BGMPLAY命令のユーザー定義）が標準搭載されているため初代
プチコンで多く見られたようなBEEP命令と独自MMLによる音階演奏は無意味になったのだけど
その積み重ねあったからこそOSPが誕生したにょ。（もっともOMPがポケコンBASICで音階
演奏をしたいという思いがあったからこそ生まれたものであるため実際はそこからの
積み重ねがあったお陰だけど）

そして、ヤマハのボーカロイドキーボードの動画を見てそしてそれをミクミンPさんが
実際にWindowsで再現しているのを見てこれをプチコンで再現しようと思ってできたのが
棒歌ロイドキーボードにょ。
カナ変換はスマホなどでおなじみのフリック入力を元にしているとはいえかなり強引な
処理をしているためあまり良いものではないにょ。
でも、キーボードの処理だけは気に入っているにょ。
このキーボードは10月に作ったPETIT KEYBOARD mkIIで生かされたにょ。
ということで、3月、4月はTALK関連のものばかり作っていたにょ。


しかし、mkIIを購入した3月よりも5月の方が公開本数が多いにょ。
これはGCOPYが便利すぎていろいろ作っていたら本数が増えてしまったためにょ。
最初に「GCOPYを使えばスクロールが超簡単」ということでCAVEを速攻で作ったにょ。
CAVEは2分の1画面だったけど1画面をフルに使ったスクロールするジャンプアクション
ゲームを作ろうと思いそのために疑似乱数ルーチンも作ったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/rnd.htm
しかし、肝心の横スクロールジャンプアクションゲームは1画面に納めることを意識
しすぎていたためあまり面白いものにはならない（当初はジャンプ中に自由に移動できる
というのをウリにしていたけどそれだとゲームがすごく単調になってしまいそれを防ぐには
根本的な面から見直す必要があった）ためそれをどのように改良するかでいろいろ考えた
のが横ではなく縦方向にスクロールするという「JUMPING ISLAND」にょ。

当初考えたジャンプアクションゲームは事実上1次元的な動き（ジャンプを含めて2次元）
だったのがJUMPING ISLANDでは2次元的な動き（ジャンプを含めて3次元）になり自由に
ジャンプができても単純化を避けることができるようになったというのは非常に大きいにょ。
それをまとめたのがプチコン講座 第7回「グラフィック面をスクロールをさせよう」にょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/p007.htm

この「JUMPING ISLAND」は当初は1画面プログラムとして考えていたアイデアなんだけど
基本部分だけで約1KBになってしまい1画面化を断念したにょ。
だから、元々シンプルなゲームであり、ごてごて付け足しても面白くはならないと考えた
ため当初はリプレイ再生機能などもオプション扱いになっていたにょ。
それでも、慣れたら簡単すぎるということで大喜利用に難易度を高めた「JUMPING ISLAND
MANIAX」を作ったにょ。
そのJUMPING ISLANDを公開したあとにようやく当初の目的であった1画面版が完成したの
だけどやはり先にフルバージョンを作ってしまうと1画面版は明らかな簡略版という感じに
なるため完全に自己満足でしかなかったにょ。
それにこの1画面版の「JUMPING ISLAND」は1画面に収めるためかなり妥協をしているけど
今見たらリスト短縮できる箇所が多く見つかったのでその妥協した部分の1つくらいは
改善できそうな感じにょ。（作った当時これは最高とおもっても後になってみれば最高でも
何でもないことに気づくというのはそれだけスキルが向上した現れともいえる）

また5月に公開した「リンクスライダー」はGCOPYのみでどこまで作れるかというテストで
作ったゲーム（アニメ「ファイブレイン」を見てこれならすぐにできそうと思ってそれに
決めた）なのだけどどこからやってきたのか私のTwitterでの公開作品の中で最も多い閲覧数
となったにょ。
半年少々経った今となってはTwitpicの閲覧数は703、リツイート数は35に達しているにょ。
まぁこのゲームを作ってみて思ったのはこの手のゲームならば「スプライトを使った方が
簡単にできる」ということにょ（笑）
GCOPYは万能だけど使いやすい場面はある程度限られてくるからね。


6月、7月はやはりロンドンオリンピック前だったので「プチコンオリンピック」シリーズを
作ることにしたにょ。
このオリンピックもののゲームは古くはロサンゼルスオリンピック（1984年）から作って
いるため私にとってはおなじみのものにょ。
これは私がBASICを覚えて間もない頃にボタンの交互押しをより効果的に行う方法を思い
ついたのが発端にょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/TECH001.HTM
ベーマガなどではIF文を2つ使ってボタンの交互押しを行っているゲームばかりだったけど
これによって高速かつ短いリストで処理が行えるようになったにょ。（プチコン講座の
第1回でもこれについて書いている）
このような経緯があるため「100m走」のゲームは私の中では定番中の定番なのだけど今回は
私が過去にあまり作ってないタイプのゲーム（プチコンのメリットを生かせるような
ゲーム）も考えて何とか1画面に収めることのできた作品は4作品となったにょ。（他にも
3作品作ったけど1画面には収まらないためお蔵入りに）

また、6月、7月はプチコン公式のプレゼント素材が公開されたためそれを使ったものも
作ったにょ。
第1回目が公開されたその日に作った「ハカセ射撃」はプチコンオリンピックシリーズの
クレイ射撃のキャラを変えただけのゲームだったけど次に作った「ハカセジャンプ」は一応
そのゲームの独自要素（ライフ消費型ジャンプ）を加えてそれなりに楽しめるものになった
のではないかと思われるにょ。

7月公開のダミーちゃん危機一髪はそれまでに公開されたプチコンのオリジナルキャラの
スプライト素材と背景に使えるBGキャラ素材とフォント素材をすべて使ったものを作ろうと
思いついたものにょ。
新しく公開された新キャラのDMMY（ダミー）ちゃんを何とかして活かせないかと思ったけど
コニミルさんが「マリちゃん危機一髪」のプチコン移植の動画を公開してこういうゲームに
しようと即興的に作ったものにょ。
包丁のグラフィックは動画を見て座標は脳内座標に変換してプチコンに直接打っていって
作ったので私が公開しているプログラムの中で最も長いのだけどコーディングはわずか3時間
ということでひたすら開発速度重視になっているにょ。

8月はお休みで9月は「非公式プチコンコンテスト」や公式のコンテストとなる「プチコン
大喜利」用のプログラムに追われたにょ。
これはすでに詳しく書いているので簡略化するけど初代プチコンで作った1画面プログラムの
中で最も自信作でありYouTubeでの公開動画の人気も最も高い「PETIT RUN」をmkIIに合わせて
バージョンアップすることにしたにょ。
そして、（1画面でできる範囲内では）これ以上できないというくらい私の技術のすべてを
つぎ込んで完成したのが「PETIT RUN mkII」にょ。
そして、このPETIT RUN mkIIは11月8日にも書いたようにプチコン大喜利にて「技術賞」を
戴くことができたにょ。
http://twitpic.com/bj8hwx
これは私の中では今年最も大きな出来事になったといえるかもしれないにょ。


そして、いよいよラストとなる10〜12月だけどこれは新作ゲームでいいネタが浮かばな
かったためツールがメインとなっているにょ。
プチコン用のテキストエディタは需要がないせいか意外に作っている人が少ないにょ。
そこで私が知る限り唯一QRコードを公開しているえいださんの簡易テキストエディタを試した
ところ不満があったのでそれならば自分で作るしかないということでできたのが11月に
作った「PETIT EDITOR」にょ。
これを作ってからは1行プログラムも作りやすくなったためそれまではプチコンでは作って
こなかった1行プログラムも作るようになったにょ。
そして、それを使ったものとして今月になってから手を出したのがBrainfuckにょ。
「PETIT EDITOR」に加えて1行プログラム「ラベルスタート」を併用することで非常に
快適にプチコンのみでコーディングと実行が行える環境が整うにょ。

ざっと今年1年を振り返ってみたけど当然ながら上記に記載の40作品のプログラムは
QRコードを公開分だけであり、公開していないものもたくさんあるにょ。

＠QRコード非公開作品（＝未完成作品）

　・レイヤー機能付きお絵かきソフト
　　https://www.youtube.com/watch?v=9rgXqMtoUVQ
　・プチコン用マルチタスクOS（もどき）
　　https://www.youtube.com/watch?v=_zzCVJQwKsY

　　　　　　　　　　　　　　　　・・・・など多数

この2作品については仕様上完成させるのが難しいため（というか、単にふと思いついて
一晩で作っただけのものだし）放置状態となっているのだけど1画面プログラムにおいては
いくら普通に動作するレベルであっても1画面に収まった時点で完成となるためそれが
できていないものは未完成ということになるにょ。
また、単に試しで作ってみただけとか面白そうなアイデアがあるからその部分だけひとまず
コーディングしてみただけのようなものなどもたくさんあるにょ。
たとえばマルチタッチの座標検出ルーチンとかスリープ状態の時間をフレーム単位で取得
するルーチンなどもあるけどこれらはそれを使った1画面プログラムができたときに公開
しようと思っているからね。（現在のルーチンはあまりできが良くないので公開に値しない
というのもあるけど）
まぁそんなことを言っていたら他の人に先を越されてしまうかもしれないけど（笑）

というわけで、今年はプチコンに非常に力を入れていたわけだけどそのせいかサイトの
更新回数もサイト立ち上げて14年目で歴代2番目に多い更新回数となったにょ。
1番はサイトを立ち上げて間もなかった2000年なんだけどそれについで多いということにょ。
2001年はポケコンのRAMカードが故障で制作中のプログラムをすべて失う（プチコンでいば
セーブしていた保存領域にギュウギュウ詰めになっていた大量の未公開自作プログラムが
すべて消えてしまったようなもの）という事件があり、ポケコン関係の更新がほとんど
途絶えてしまったのが原因にょ。（そのショックから回復するのに数年かかった）
さすがに来年は今年よりもプチコンの使用頻度は落ちてしまうだろうけどそれでもやっぱり
一番お手軽なプログラミング環境であるためもうしばらくは楽しめそうにょ。（他の手軽な
プログラミング環境であったポケコンは壊れてしまったしね）

1427：天郷思音：2012/12/24(月) 12:30:09
(無題)
行番号のフォントを作った。
PRGにしたらファイルサイズがMEMより小さい240B（1画面版は278B）（ヘッダ込み）になった。

1428：御茶目菜子：2012/12/24(月) 23:05:17
レスにょ
天郷思音さんへ
＞行番号のフォントを作った。
＞PRGにしたらファイルサイズがMEMより小さい240B（1画面版は278B）（ヘッダ込み）になった。

これはいろいろと使えそうにょ。
行番号フォントがあれば2SCのようにリストをキャプチャしたり、標準エディタと同じ外観を
持つテキストエディタを作ることができるにょ。
ただ、プチコンの場合はPRGをファイルとして読み込むことができないのでいちいち手動で
DATAに変換するのが面倒にょ。
だから、PCでPTCを読み込んでそれをBMPに出力するプログラムを作る方が良さそうにょ。
文字コード変換はすでにPTC_PLCがあるのであとはリストを画像として出力する処理を追加
すれば完成するにょ。
CSSでプチコンのリストを再現しているのを画像にするだけのことだけど画像にすれば3DS
などでもそのフォントで見ることができるにょ。（ただし、大きな画像を読み込むことが
できないというのが難点だけど）

1429：御茶目菜子：2012/12/24(月) 23:06:40
2012 今年のpixiv総まとめ
今年も残り1週間となったにょ。
まだこれから急いで描けば年内の投稿は可能（私の場合は普段投稿しているようなレベルの
絵を描くのに1週間程度はかかる）だろうけどこれから年賀絵を描かないといけないため
事実上年内の投稿はもう無理にょ。
したがって、昨年12月30日の「今年のPixiv総まとめ」で書いたような現時点での今年の
まとめを書くとするにょ。

評価総合点　　0〜199点　200〜499点　500〜999点　1000〜1999点　2000点〜　　　合計
　2012年　　　　 0枚　　　　 0枚　　　　 8枚　　　　 2枚　　　　 0枚　　　　10枚
　2011年※　　　 0枚　　　　 6枚　　　　16枚　　　　 6枚　　　　 2枚　　　　30枚
　2010年※　　　 4枚　　　　18枚　　　　 1枚　　　　 0枚　　　　 0枚　　　　23枚
　2009年※　　　10枚　　　　 5枚　　　　 0枚　　　　 0枚　　　　 0枚　　　　15枚
　※2009〜2011年においては昨年の12月30日現在のものを記載している

まず、最初に投稿枚数だけどこれはpixivへの投稿を初めてから最も少ない1年となったにょ。
最多だった昨年と比べて3分の1に減少したにょ。
これは様々な理由があり、まずは長期的なスランプ状態にあったことが挙げられるにょ。
お陰でプチコンのプログラミングが捗ったためプチコンプログラムは12月22日に書いた
ように今年だけで40作品作ることができたにょ。
私は1枚描くのに20時間はかかるのだけどプチコンの1画面プログラムも気合いを入れて
作ったらそれくらいの時間はかかるにょ。
1画面プログラムは17作品作っているけど本気で作ってないものや単なる別バージョンの
ものを除けば12作品程度にょ。
したがって、それをすべてお絵かきに費やしていればプラス12枚は投稿できていたのでは
ないかと思われるにょ。
まぁそれ以外にも結構たくさん作っているためプチコンの時間をすべてお絵かきに費やす
ことができたならば恐らく昨年の投稿枚数である30枚を確実に上回ることができたのでは
ないかと思われるにょ。（あくまで費やした時間のみを元に考えた場合の話であり実際は
そんなに単純なものでもないけど）

それに加えてやはりモチベーションの問題もあるにょ。
従来ならばブクマ20点換算で○○点あればDRに入れるというものがほぼ分かっていたの
だけど10月11日に書いたようにランキング補正の大幅な変更によって男女の支持率によって
ランキングのボーダーは桁違いに変わることになったにょ。
従来ならば私の評価点やブクマ数では総合DR（デイリーランキング）に入るのはかなり
厳しかったのだけどこの変更によって私でも男女の支持率次第では十分に入れる可能性も
あるためそれを目標として考えるのではなく新たな目標設定が必要になったにょ。
しかし、その設定ができていないことがモチベーション維持ができなかった原因と言えると
思うにょ。

まぁその辺はまた改めて考え直すとして今年の投稿内容を振り返ってみるにょ。
まずは今年投稿した10枚における1枚当たりの平均値を求めてみたにょ。

　《　2012年　pixiv投稿成績　》
　　投稿枚数　　　　　10枚（内訳：健全が5枚、R-18が5枚）
　　平均閲覧数　　　　3746
　　平均評価回数　　　77回　　（閲覧数に対する評価率　2.05％）
　　平均評価点　　　　757点
　　平均ブクマ数　　　31.3　　（評価回数に対するブクマ率　40.6％）
　　1作品あたりの被お気に入り増加数　20.5人
　　ランキング入り回数
　　　・イラストデイリーランキング　2回
　　　・男女別ランキング　・・・・　8回

投稿枚数は10枚と少なかった今年だけど結果そのものは悪くない数字だと思うにょ。
平均閲覧数の3746という数字は閲覧数1万や2万を軽く越えている昨年投稿したまどマギ絵と
比べると劣るものの当時のまどマギ人気は異常なレベルであったため閲覧数は他の版権と
比べて5倍くらい増えたし、そもそも昨年の8月までは閲覧数は3倍近い水増しがあったため
閲覧数が24000であっても実質8000〜10000程度しかないと推測されるにょ。
今年の評価率2％というのは一見すると低いけど昨年までは閲覧の水増しがあったため1％を
大きく下回っていたにょ。
それと1月29日の「pixivにおける閲覧数と評価の関係」で書いたように投稿初日評価率は
健全絵で4〜8％、R-18で3〜5％あるもののしばらく経ってしまうと評価率が健全絵で2〜3％、
R-18で1〜2％程度まで落ちてしまうので累計の評価率だとこのような値になってしまって
いるにょ。
その辺はまだまだ常連さん（被お気に入りやマイピクの人など）が投稿初日などには高い
評価をしても後からやってくる一見さんが高い評価をしてくれるレベルには達していないと
いうことであり、投稿初日から評価率を大きく落とさないためにはさらなる技術向上が
必要不可欠であると言えるにょ。

今年の結果を昨年と比較したいところだけど昨年は年末段階で平均は求めてなかったため
直接比較することはできないにょ。（昨年投稿した作品の現時点の評価点の平均は949点）
しかし、どの程度の評価点だったのかは冒頭に書いている評価点数分布で粗方分かるにょ。
それを比較した場合に今年は一見すると昨年よりダウンしているように見えるにょ。
ただし、これは上記のように昨年に投稿した絵はまどマギ人気による影響が極めて大きい
ためダウンしたと一概に言うことはできないにょ。
何せ私が投稿した絵に関して言えばまどマギ全盛時は並の版権キャラ絵と比べて評価が3倍
くらい高くなっていたからね。
それは昨年投稿した30枚中の上位14作品がまどマギ絵であることから見ても一目瞭然にょ。
実は、非まどマギ絵で考えると今年の方が高くなっているにょ。
投稿から1年以上経っている現時点で見ても昨年投稿した非まどマギ絵の平均評価は630点、
平均ブクマ数は19.5だからね。

それを元にして考えると評価点においては2012年で前年比20％アップでそれほど大きな
違いはない（もっとも投稿してから1年間以上経っているため昨年末現在のものだったら
恐らく30％以上のアップになっていたと推測される）けどブクマ数においては前年比
60％アップということでかなり大きく上がっているにょ。
評価回数に対するブクマ率で考えた場合は（現時点の数字は）昨年投稿した作品において
非まどマギ絵はブクマ率30.4％（評価回数64.1回、ブクマ数19.5）、まどマギを含めた
すべてにおいてはブクマ率21.1％評価回数96.6回、ブクマ数20.4）となっているのに
対して今年は40.6％に達しており明らかに昨年よりも高くなっているにょ。
まどマギ絵は閲覧数大幅に増えてそれに応じて評価もそれなりに増えたもののブクマは
それと比べてほとんど増えなかったため非まどマギ絵の平均ブクマ数と、まどマギ絵を
含めた平均ブクマ数にはあまり差はなくて評価に対するブクマ率だとまどマギ絵を含めた
昨年の投稿作品全体ではブクマ率大幅に落ちているにょ。
評価回数に対するブクマ率は昨年と比べて大幅に増えている（昨年投稿した作品の現時点
での数字と比較すると約2倍になっている）というのはランキング入りにも如実に反映
されているにょ。
あれだけ高い評価点でも入れなかったイラストDRに今年は入れているわけだしね。

それは1作品あたりの被お気に入り増加数にも現れていて昨年は1作品あたり6人程度
だったのが今年は20人以上になっているにょ。
もっともこれは投稿枚数の大幅な違いがあるため直接数字を比較はできないにょ。
単純に考えると今年は1.2ヶ月で1枚に対して昨年は1.7週間で1枚だからね。
とはいえ、私の場合は被お気に入りの増加は投稿してから2、3日の間は多いけど投稿
して1週間も経つとその増加ペースはかなり鈍化するにょ。
そのため仮に今年に（昨年と同じ）30作品を投稿していたとしても1枚あたり20人だった
のが15人前後になる程度だと思われるにょ。
被お気に入りの増加数そのものはそれなりの絵が描けていれば（よほど投稿間隔が短く
ない限り）投稿枚数によって大きく変わるため「投稿1作品当たりの増加数」の方が
重要になってくるにょ。
これが昨年と比べて大きく上昇しているということが評価やブクマにおいてかなり
プラスに働いているといえそうにょ。（逆にプラスになるような絵を投稿できている
からこそ被が多く増えるようになったとも言える）

以上から考えて2009年から続いている評価やブクマ数の右肩上がりの向上は現時点でも
まだ続いていると言っても良いのではないかと思われるにょ。
このまま続いてくれればそれほど遠くない将来にはランカーになれると思うのだけど
そんなに簡単にはいかないにょ。
というのも、まずは伸びているのは私だけではないためにょ。
pixivのユーザー数によって評価やブクマなどは総合的には上昇傾向があるからね。
ただし、それは人気順検索の導入などによってさらなる上下格差によって上の方は伸びて
いる反面で100点前後となる下の方は変わらない、もしくは減少したという人もいるにょ。
私はその中間付近にいるため何とか減少は免れてしかも増加になっているというのは
ある意味運がいいのかもしれないにょ。

それと練習を積み重ねることで上達はするのだけど右肩上がりで実力がアップすると
いう単純なものではないので右肩上がり（常に前作よりも良い絵を描こうとすること）を
考えているとスランプになりやすくなってしまうにょ。
より良い絵を投稿するためには描いている途中の段階で「ダメ」と感じたものは切り捨
てる勇気が必要になるにょ。
ダメと分かっていて惰性で完成させた絵は駄作になることが多いからね。
ただし、その基準を厳しくしていけばいくほど絵は完成しなくなってしまうにょ。
昨年12月20日の「スランプを脱出するには」で書いたように上手くなるためには練習が
必要不可欠だけどスランプになった場合にさらに練習量を増やすことがスランプの泥沼化に
繋がる場合もあるためにょ。

上記のように評価を右肩上がりで増やすためにはよほどの人気版権、人気ジャンルに手を
出さない限りは自分の実力（画力だけではなく絵の魅力も含む）を向上させる必要が
あるにょ。
また人気版権、人気ジャンルに手を出した場合には右肩上がりにするためにはさらに
人気のものに手を出す必要があり必ずどこかで破綻するにょ。
そのため私はジャンル人気などには拘らず「自分の描きたいものを描く」ということを
優先しているにょ。（これは趣味で描いている以上は特別なことではなく当たり前のこと
なんだけど）
そして、その上で「より良い絵（魅力的な絵）が描ければそれに評価なんて後から付いて
くる」という考えがあるからこそ前作よりも良いものを書き続けることで評価は上がる
はずなんだけど良い絵を描くというのは練習量だけで決まるわけではないからね。
スランプ状態の時は自分の絵は何もかもダメに見えてしまうにょ。

私の場合は単に趣味で描いていて「上手くなりたい」（自分が頭でイメージしている
ような萌え絵を100％表現できるようになりたい）というのが根底にあり、それを達する
ためにもより多くの人に見てもらいそして評価してもらいたいという思いがあるにょ。
まぁ、ネットで公開している以上はより多くの人に見てもらいたい（評価してもらいたい）
という思いが無いという方がウソだろうけどね。
「描くだけで満足」という状況下では長年描いてきてそれほど上達していない現状を
踏まえて考えると「たくさん描く」というのは上手くなるための必要条件であって
十分条件ではないと言えそうにょ。
これは、ちゃんと考えながら描かないと上達はしないということにょ。
ただし、「考えれば考えるほどどんどん分からなくなってしまう」という状態に陥ることが
あるにょ。
これが要するにスランプ状態ということにょ。
そう考えれば「スランプから脱出する」ということはレベルアップにも繋がる場合も少なく
ないとも言えるためスランプこそチャンスといえるにょ。
ただし、頻繁にスランプに陥っている状態は決して望ましいことではない（絵が完成する
ことはない）ためよりスランプに陥りにくくさせるようなモチベーションの保ち方が重要に
なってくると思われるにょ。
これは要するにまだまだ基礎が足りてないせいと言えるかもしれないにょ。
この辺は来年以降の課題として練習を積み重ねていく必要がありそうにょ。



さて、続いてpixivのシステム面においてこの1年間を振り返ってみるにょ。
上半期においては7月18日の「2012年pixiv上半期報告」で書いたように「グループ機能」と
「オリジナルランキング」の創設、「人気順検索」の導入が主な点にょ。
では、下半期はどうだったかというと主な点は下記の2つだと思われるにょ。

　(1)ランキング入り基準の大幅な変更
　(2)表現やジャンルのフィルタリング導入（の可能性）

(1)DR（デイリーランキング）に入るための基準というのは従来であれば投稿した日の24時
現在の評価点と公開ブクマ数で判断されていたにょ。
公開ブクマは1つ20点で換算されていると推測されておりこれで検算することでランキング
順位は（数字だけから判断すると）客観性の高いものになっていたにょ。
もちろん、一部の人気版権や人気タグにはマイナス補正、そしてオリジナルにはプラス
補正が取り入れられているためそのブクマ加味した換算した評価点が順位通りに並ぶとは
限らないのだけどそれでも補正値は逆算すれば出てくるためその補正値を掛け合わせた
補正込みの評価点だと順位通りに並んでいたため客観性が確保されていたにょ。
ところが、投稿時間帯別補正が加わりそれもかなり厳しくなりつつあったにょ。

それに加えてさらに別の新しい補正が加わったにょ。
これは10月11日に書いた「pixivでランキング入りするための条件 PART5」で詳しく書いた
ものの男女別の支持率が大きな影響を与えていると推測しているにょ。
pixivにおいて多くのユーザーに不満が出ていたのはpixivは女性ユーザー比率が高いため
「腐女子向け」の絵がランキング上位に犇めいていたにょ。
これは「黒バス」の人気と相乗効果によってすさまじい状態にあったにょ。（DRの上位
100作品中で黒バスの絵が6〜7割を占めていた時期もあった）
もちろん、人気版権マイナス補正はあったもののpixivにおける男女比は女性比率が圧倒的に
高いと思われるため多少のマイナス補正（0.8〜0.9倍）程度では影響がなかったにょ。
かといって特定の版権キャラ絵のみ1/5倍、1/10倍にするような極端なマイナス補正は
さすがにできないにょ。（あえてそのタグを付けないという手段を執る人が多くなって
しまうだけ）

しかし、男女別の支持率を補正に加えればその問題は一気に解消できるにょ。
作品によっては桁違いの補正が働いているため従来はブクマ20点換算で2000点はないと
入ることができなかった総合DRに換算で300点程度から入れるようになったにょ。
その反面で極端に男女の支持率に差があるような作品は換算で1万点近くあっても総合DR
入りができなくなったにょ。
これは女性向けのみが不利になっているというわけではなく男性向けの健全（非R-18）で
投稿したちょいエロ絵も女性からの支持がないと難しいにょ。
版権別で見ると東方関係は男性の支持率が高いため全般的に換算評価点が高くても低い順位に
なっているにょ。
つまり、DR上位に入るためには男女万遍なく支持を得られる絵を描く必要性が求められて
きているというわけにょ。
そういう絵が描けていれば従来ならばRR（ルーキーランキング）入りさえ難しかった評価点や
ブクマ数でもDR総合に入ることが可能になっているにょ。

(2)pixivに投稿の作品は投稿段階で「R-18」「R-18G」「閲覧制限無し」（いわゆる全年齢
向けや健全と言われるもの）の3つのいずれかを選択する必要があるにょ。
それらはおおざっぱなガイドラインは定められているものの投稿する人の判断に委ねられて
いる状態にょ。
健全絵といっても実際はR-15レベルの絵は非常に多く氾濫しているけどそれらをR-18にすべき
というのも無理があるにょ。（パンチラ程度ならばR-18にする必要はないという人が大半
だと思われる）
また暴力関係もよほどグロテスクな描写がない限りR-18Gにするというのも無理があるにょ。
したがって、「純粋な健全絵」（←定義はよく分からないけどニュアンスは分かるのでは
ないかと思う）を閲覧している人にとってはそれを排除したいという思いはあるにょ。
それに腐女子向けとなる「男性同士のキャラの絡み」や主に男性向けとなる「女性同士の
絡み」もそれを嫌悪している人は少なくないけどR-18レベルに達していると投稿者が判断
しない限りは健全絵に含まれてしまうにょ。

ということで、作品の閲覧者が不快感を抱くような可能性のある描写のある絵を分類できる
ようにするため11月から作品情報には従来の「R-18」「R-18G」以外に次のようなものも
追加されることになったにょ。
まずは、表現においては「軽度な性的描写」「暴力」「飲酒・喫煙・薬物」「言語・思想」
「反社会的表現」「宗教」が選択肢として用意され、作品属性においては「未成年」
「ケモノ」「同性愛（男性同士/女性同士）」が選択肢として用意されているにょ。
それらの項目が実際にどのようなものかはマウスカーソルを合わせるとポップアップで
概要が説明されるためその説明を見てそれらの項目にチェックを入れるか否かを判断する
ことになるにょ。
投稿者の負担が増えてしまうもののより多くの閲覧者に快適にpixivを使ってもらうため
にはやむを得ない方法ではないかと思われるにょ。

現時点ではこの情報はシステム面へは反映されてないものの今後は特定の表現を含むものを
非表示にできるサービス（フィルタリングサービス）も開始すると予想できるにょ。
ただし、それはプレミアム会員限定のサービスになるかもしれないにょ。
プレミアム会員用としては作品を投稿した作品の再投稿ができたり、キャプションにタグが
使えたりという便利な機能があるものの普通に投稿するだけならば無料会員で特に困る
ことはないためプレミアム会員比率はそれほど高くはないと思われるにょ。
しかし、閲覧する側にとってみれば便利な人気順検索などはプレミアム会員限定となって
いるにょ。
検索したものの中から特定のタグを含むものを見たくないという場合はそれをあらかじめ
登録しておけばサムネにも出てこないタグによるフィルタリングサービスもプレミアム会員
限定となっているにょ。
そうなると、新たに追加された作品情報を元にしたフィルタリングサービスもプレミアム
会員限定になると考えるのが妥当にょ。

ただし、フィルタリングサービスが仮に始まったとしても作品情報にチェックを入れるか
否かは投稿者の判断に委ねられているため人によってはアウト、セーフの判断が分かれる
ものもたくさん出てきそうにょ。
現時点でR-18にするか否かの判断が難しい作品（それを閲覧する大半の人はR-18にする
必要はないと感じるような作品であっても一部の人がR-18と判断される可能性のある作品）も
少なくないためそのガイドラインが拡大されるというだけのことであり、結局客観的な
線引きなんて不可能だからね。
それでも、ユーザー数が増えて単に閲覧目的でpixivを利用する人が多くなっている現状を
考えるとページビューを維持するためにはユーザーの意見が反映されなくては厳しいため
今回のような新たな作品情報の導入が始まったのだと思われるにょ。
しかし、どのような形でシステムに導入されるかが現時点では不明だし、このような分類で
本当に改善できるか疑問視の人も少なくないにょ。
これが正しいかどうかの判断はこの情報を元にしたサービスが実際に始まるまではとりあえず
保留とするにょ。


《　関連リンク　》

　◎今年のPixiv総まとめ
　　　http://6407.teacup.com/ochame/bbs/3033
　◎2012年pixiv上半期報告
　　　http://6407.teacup.com/ochame/bbs/3413
　◎pixiv人気順検索導入の是非
　　　http://6407.teacup.com/ochame/bbs/3074

　◎底辺絵師のpixivランカーへの道
　　　http://6407.teacup.com/ochame/bbs/2755
　◎底辺絵師のpixivランカーへの道 PART2
　　　http://6407.teacup.com/ochame/bbs/2820　（前半）
　　　http://6407.teacup.com/ochame/bbs/2819　（後半）
　◎底辺絵師のpixivランカーへの道 PART3
　　　http://6407.teacup.com/ochame/bbs/3066
　◎底辺絵師のpixivランカーへの道 PART4
　　　http://6407.teacup.com/ochame/bbs/3560

　◎pixivでランキング入りするための条件
　　　http://6407.teacup.com/ochame/bbs/2824
　◎pixivでランキング入りするための条件 PART2
　　　http://6407.teacup.com/ochame/bbs/2909
　◎pixivでランキング入りするための条件 PART3
　　　http://6407.teacup.com/ochame/bbs/2969
　◎pixivでランキング入りするための条件 PART4
　　　http://6407.teacup.com/ochame/bbs/3498
　◎pixivでランキング入りするための条件 PART5
　　　http://6407.teacup.com/ochame/bbs/3565

　◎pixivにおける閲覧数と評価の関係
　　　http://6407.teacup.com/ochame/bbs/3069
　◎pixivの評価はどうやったら上がるのか？
　　　http://6407.teacup.com/ochame/bbs/3497

1430：御茶目菜子：2012/12/26(水) 23:53:20
疑似3D表示と立体視の相性は抜群！
本日発売された3DS用ダウンロードソフト「3Dスペースハリアー」を購入してみたにょ。
私は3DSを昨年10月に購入したのだけど無料ソフトや体験版などはいくつかダウンロード
してみたものの有料ソフトはDSiウェアの「プチコン」および「プチコンmkII」しか購入
してなかったにょ。
そのため普段は3DS本体にチャージしておらず欲しいソフトがあるときだけチャージしようと
思っているのだけど気軽に買えるのがダウンロードソフトのメリットなのでわざわざ
プリペイドカードを買いに行かないと購入できない状況だと必然的にダウンロード購入の
機会も減少してしまっていたと思われるにょ。

今回は事前に発売が分かっていたためにあらかじめ1000円のプリペイドカードを購入して
準備していたにょ。
http://game.watch.impress.co.jp/docs/news/20121121_574435.html
まずは、私のスペハリ歴からいうと・・・実は語るほどのものは何もなかったりするにょ。
というのも、確かにアーケードではそれなりにプレイしたもののシューティングゲームが
あまり得意ではない私はそれほどお金を費やしてプレイしたというわけでもないにょ。
スペハリはコンシューマ移植の数も多くダウンロードソフトといしても発売されていたり
するけど結果としてどれも手を出さずじまいになっていたにょ。
今回購入したのは私が現在最も使用しているゲーム機である3DSでプレイできる（というか
最近は3DSしか電源を入れていない）というのに加えてやはり600円という安さが決め手と
なったにょ。
あと、3D立体視でどのように見えるのかというのも気になっていたにょ。

さて、実際にプレイするとあまり得意なゲームではないためすぐにゲームオーバーになって
しまったもののこのゲームはクリアしたステージまでは自由にステージセレクトをして開始
できるような親切な設計になっているので安心にょ。
これによって少しずつクリアをしていけば私でさえ全18面をクリアすることができたにょ。
気になっていた3D立体視なんだけどこのゲームでは非常に有効に働いているにょ。
スプライトの拡大縮小を駆使することで疑似3D表示を実現しているのだけど弾や柱までの
距離はその見た目の大きさで判断するしかないにょ。
したがって、「これならば避けられる」というのは身体で覚えていくしかないにょ。
しかし、3D立体視に対応しているこの「3Dスペースハリアー」はそんなことを考えなくても
これは当たりそうだというのが立体視によって把握できるようになるにょ。
もちろん、それでもプレイヤーである私の反応速度が間に合わず当たってしまうこともある
けれどこの辺は疑似3Dゲームと立体視の相性は非常によいといえそうにょ。（難易度が高く
なってしまいがちな疑似3Dゲームの難易度を下げることが可能になる）

この「3Dスペースハリアー」はオプション設定も非常に充実しているにょ。
難易度、残機設定というありがちなものだけではなくアーケードの体感筐体を再現するモード
まで用意されているにょ。
これをONにすると左右に移動するごとに画面が回転するというものにょ。
さらに環境音をONにするとその時に筐体から発生す音まで再現するにょ。
サウンドはイコライザーを完備で自分好みに設定も可能にょ。
あと表示においては初のワイド画面に対応した「スペースハリアー」なのだけどアーケードの
画面比率などにに設定することもできるにょ。
そして、「ハリアーの移動範囲」なんていう項目もあるにょ。
これはレバーが経年劣化して稼働領域が変わってしまっている筐体でプレイしていた人だと
アーケードからの完全移植をしてしまうと違和感を感じてしまうため自分の中でのスペハリを
設定できるものとして用意されているみたいにょ。
詳しくは下記の記事やインタービューに書いているので読んでみるのが良いと思われるにょ。
http://game.watch.impress.co.jp/docs/news/20121219_579344.html
http://game.watch.impress.co.jp/docs/interview/20121226_580214.html

購入前はただのアーケード移植＋立体視程度にしか思っていなかったのだけど実際にプレイ
してみて上記リンク先のインタービューなどを読んでみるとそうではなく完全に3DS用に作り
直されたスペハリであることが分かるにょ。
バーチャルコンソールなどとは違い新規に作ったからこそこのような新しいモードを入れる
ことができたと言えるにょ。
これだけ手間をかけているソフトなのに600円というのは破格の安さだと思われるにょ。


この「3Dスペースハリアー」によって実感できたのが上記のような疑似3Dと3D立体視の相性の
良さにょ。
話は変わるけどプチコンでは私のプチコン講座 第5回、第6回で書いているように疑似3Dは
簡単に実現できるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/p005.htm
http://ww5.tiki.ne.jp/~ochame/petitcom/p006.htm
ただし、疑似3Dというのは「遠くの物を小さく表示している」というだけの単純なものであり
距離感を量るというのはかなり難しいにょ。
大きさから距離を判断する必要があり、それだとどうしても慣れが必要になってくるにょ。
例えば、「遠くの大きい物体」と「近くの小さな物体」では画面上の見た目では判断できない
ためプレイヤーの自機との当たり判定から判断するしかないにょ。（当たれば近くの物体で
当たらなければ遠くの物体と判断できる）
これが自機を含めて動作しているキャラがすべて地面に接地しているならば地面との接地の
位置を元に粗方判断可能だけど空中の物体はそういうわけにはいかないにょ。（接地している
物体も上記講座にある「不自然なもの」だったら距離感というか速度感が狂ってしまう）
そういう意味では3DS用として発売されるであろう次世代プチコンでは3D立体視表示が可能に
なると非常にプレイしやすい疑似3Dになるにょ。

確かに現行のプチコンでも立体視ができないわけではないにょ。
それは古くから行われている赤青のアナグリフによって可能になるにょ。
これは少し視点をずらした2つの画像と赤青眼鏡を組み合わせることで立体視を可能にしている
けれどこれを1つの画面で行うためにはピクセル単位で画像合成をする必要がありプチコンでは
処理速度の問題でゲームとしてリアルタイム表示はできないにょ。
しかし、Ackieeeさんがプチコン大喜利にてユーモア賞を獲得した「上からハカセ」では
1フレーム単位で視点の異なる画像を表示することで処理速度面の問題を克服しているにょ。
これによって、通常モードではプレイが困難なこのゲームは立体視モードでは普通にプレイ
できるような難易度になっているらしいにょ。（私は赤青眼鏡で試してないけど）
とはいえ、せっかく3DSはせっかく標準で備えている裸眼立体視に対応した液晶を備えている
ためこれが活用できるのがベターなのは言うまでもないことであり、やはり次世代プチコン
にはポリゴン命令は無くてもいいので3D立体視には対応して欲しいと思うにょ。

1431：御茶目菜子：2012/12/27(木) 23:57:20
これが本当の今年最後のプチコンプログラム（？）
12月22日にこれで年内に作るプチコンプログラムは終了と書いたばかりなのにまたもう1つ
作ってしまったにょ（1行プログラムだけど）

1行プログラム「VS」
X=128ACLS:FOR I=-60TO 1GCLS:X=X+!((20AND BUTTON())%5)*6-3GLINE-1,9,X,9,2WAIT-I:I=-GSPOIT(X,9)NEXT
　　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#09
　　（※リンク先のプログラムは初出分から改良を加えているため上記のリストとは異なっている）

これはポケコンではおなじみの対戦型ゲームにょ。
元祖となっているのはPB-100用なのだけどこれは同時キー入力ができないことを上手く
活用した内容になっているにょ。（複数のボタンを押した場合には押していないのと同じ
ように認識される）
しかし、その判定を悪用も可能になっているので同時に複数のボタンを入力判定が可能な
プチコンではその悪用ができないようにするにょ。

大したことはやってないのだけど一応解説を書いておくにょ。
このゲームで必要な処理はボタン判定とゲーム終了処理にょ。
まずは、ボタン入力判定を書くとこのゲームで使われているのは[←]ボタンと[A]ボタンのみ
となっているため20AND BUTTON()でそれ以外のボタンを押している場合の排除が可能にょ。
この値が「0もしくは20」、「4もしくは16」という2つのIF文によって判定を行うのが最も
簡単だけどそんなことをしなくても5で割り切れるか否かで判断が可能にょ。（10で割っても
20で割ってもいいけど5ならば1文字で済む）

ちなみに上記リンク先の新バージョンでは(20AND BUTTON())%12%8となっているけどこれは
「0もしくは20」、「4もしくは16」を%12で「0もしくは8」、「4」にして、次の%8で「0」と
「4」にしているにょ。
相対的な移動量を4（マイナス方向2、プラス方向2）に設定すれば別途移動量を掛け合わせる
ことも不要になるためさらに2文字分短縮できるにょ。（これによってゲーム終了時にBEEPを
入れることも可能になった）

ゲームの終了はメーターが一杯になったかどうかはX>=255かどうかで判断できるし、
メーターが無くなったかはX<=0かどうかで判断できるけど勝敗は見た目で分かるため
X<=0もしくはX>=255の場合を考えればいいにょ。
ここでX=0やX=255になることがないならばXの値が画面外を指しているかどうかだけで
問題ないためGSPOIT(X,9)の値が-1かどうかで判断できるにょ。

この時点のプログラムはこれにょ。
X=128ACLS:FOR I=0TO 1GCLS:X=X+!((20AND BUTTON())%5)*6-3GLINE-1,9,X,9,2I=-GSPOIT(X,9)WAIT 1NEXT

GLINEのY座標が0ではなく9なのは先日作った「タイピング」と同じように「OK」の文字と
重ならないようにするためのものにょ。
これで一応は問題ないのだけどやっぱりこのゲームの場合はRUNをしてすぐに始まった場合には
1Pの方が圧倒的に有利になるにょ。
そのためゲームをRUNをしたら1秒（60フレーム）くらいは待ってゲームを開始したいところ
だけどあと残り使用可能文字数は5文字しかないにょ。

残り5文字だと先頭にWAIT 60を入れることもできないにょ。
実際は先頭ではなく最初の表示をした後にウエイトが欲しいにょ。
WAIT 1の部分を最初だけWAIT 60にしたいのだけど最初かどうかはループのカウンタの数字を
-1より小さくすることで判定が可能にょ。（このゲームでは実行中はIの値は-1となる）
つまり、FOR I=-2TO 1 としておけば WAIT 1+(I<-1)*59 でスタート時のみ60フレームの
ウエイトになるにょ。
しかし、これでは1行に収まらないにょ。（最初のACLSを省いても1文字入らない）
したがって、唯一短縮できる可能性があるのはこのWAIT処理なのでそこを簡略化するしか
ないにょ。
それでできたのが冒頭のプログラムにょ。

実はこのプログラムは3Dゲームではなく1Dゲームを希望しているツイートがあっため即興で
考えたものにょ。
1D（1次元）となると使えるのは1本の線分だけしかないためそれで成立するようなゲーム
ということで思いついたのがおなじみの対戦ゲーム「VS」だったにょ。
これは本来は1P用のゲージ、2P用のゲージがありそれで勝敗を競っていたのだけど2Pの
ゲージを背景と同じ色にすれば1本の線だけでゲームができるため1行に収めることが可能に
なったにょ。
というわけで、今年発表したプチコンプログラムはこれで51作品（サンプルを除き41作品）
となったにょ。

1432：天郷思音：2012/12/28(金) 17:56:31
(無題)
プチコンユーザーの間ではやってる
http://www48.atpages.jp/kolang/businessstory/akimono/index.cgi
しかしこれのせいでプチコンに費やす時間が減ったのは言うまでも無い

1433：御茶目菜子：2012/12/28(金) 23:56:56
レスにょ
天郷思音さんへ
＞プチコンユーザーの間ではやってる
＞http://www48.atpages.jp/kolang/businessstory/akimono/index.cgi
＞しかしこれのせいでプチコンに費やす時間が減ったのは言うまでも無い

一種のソーシャルゲームにょ。
確かに知り合い同士で競争となるとかなり熱中してしまいそうにょ。
それがソーシャルゲームの怖さであり、カードなどのアイテムに何万円も使ってしまうにょ。
もっとも、これは無料のCGIゲームだからそんな心配は要らないけどね（笑）
ということで、プチコンでソーシャルゲームを作ってはどうにょ？（さすがに無理か）

1434：御茶目菜子：2012/12/28(金) 23:58:24
PS Vitaはなぜ失敗したのか・・・？
SCEがPSPの後継機として満を持して発売したPS Vitaは先日発売から丸1年経ったにょ。
発売前から何かと話題が多く発売週には32万台の販売台数を記録してまずまず好調な滑り
出しとなったもののそれ以降は伸び悩んでしまったにょ。
最近ようやく販売台数100万台突破して現在では105万台となっている模様にょ。
http://gamedatamuseum.web.fc2.com/psvita.htm
さて、この販売台数を見てどう思うかは人それぞれだけど昨今のハード事情や過去の実績を
踏まえるととても成功しているレベルとは言い難く現時点では失敗と言っても過言ではない
感じにょ。

では、PS Vitaの発売してからからの国内累計販売台数の推移を見てみるにょ。

　　　《 PS Vita、PSP、DSのの国内における累計販売台数 》
　　　　　　　　　　　PS Vita　　　 PSP　　　 　DS
　　　　発売後 4週　　483007台????451138台　 1095930台
　　　　　　　 8週　　543802台　　701680台　 1508241台
　　　　　　　12週　　587385台　　897167台　 1642295台
　　　　　　　16週　　631402台　　952181台　 1748799台
　　　　　　　20週　　667067台　 1143386台　 1902542台
　　　　　　　24週　　694025台　 1277990台　 2124349台
　　　　　　　28週　　756451台　 1390270台　 2263507台
　　　　　　　32週　　812124台　 1477541台　 2412921台
　　　　　　　36週　　849295台　 1562593台　 2594400台
　　　　　　　40週　　925989台　 1653558台　 2889999台
　　　　　　　44週　　962293台　 1779992台　 3121479台
　　　　　　　48週　　985048台　 1918078台　 3311406台
　　　　　　　52週 　1026491台　 2003979台　 3651082台

こうして見ると異例の大ヒットとなったDSは別格であるため除外すると発売後1ヶ月までは
PSPと比べて決してひけを取ってないことが分かるにょ。
それが、1年後にはそのPSPに対してダブルスコアで負けているにょ。
他のハードにおいては携帯機と据え置き機では状況が異なるもののWiiは発売後6週間で販売
台数100万台を突破しており、発売当初高額だったPS3も35週間で100万台を突破しているにょ。

ここまでVitaがなかなか普及しない理由としては以下のような理由が考えられるにょ。

　(1)　キラーソフト不在
　(2)　PSPと互換性がない
　(3)　スマホ、タブレット端末の影響

(1)ゲーム機で何と言っても一番重要なのはソフトにょ。
PS Vitaのソフトラインナップは他機種と比べてどうなのかというとローンチタイトルに
おいては12月17日に書いたように決して悪いものではなかったにょ。
これぞというタイトルこそないものバリエーション豊富な24タイトルが用意されていたわけ
だからね。
そのローンチタイトルにおいては昨年12月28日に書いたように装着率（＝本体1台当たりの
ソフト販売数）は0.92とかなり低めだったにょ。
これは店頭販売における数量しか見てないためダウンロード版がもっと売れているのかも
しれないけどローンチタイトルが24タイトルあってこの装着率ということで本体はそこそこ
売れたけどソフトはあまり売れてないという印象となってしまったにょ。

しかし、ローンチだけですべてを語ることはできないにょ。
むしろ、それ以降に継続してどれだけのソフトを販売できるかということが重要になってくる
のではないかと思われるにょ。
ここで、Vitaにおいてローンチ以降にヒットした（販売本数10万本以上）ソフトとなると
「ペルソナ4 ザ・ゴールデン」と「初音ミク -Project DIVA- f」の2本だけにょ。
人によってキラーソフトの意味合いは変わるもののハードを牽引するかどうかというのが
非常に重要となってくるにょ。

　《　PS Vitaの週間販売台数　》
　　　　　　　　　　　　　　発売前週　　発売週　　発売翌週
　ペルソナ4 ザ・ゴールデン　 12256台　 31657台　　 12100台
　初音ミク -Project DIVA- f　 9751台　 46857台　　 11382台

このデータから判断するとそのソフトが発売されることによって本体販売台数に2〜3万台の
影響を与えているにょ。
規模は小さいもののキラーソフトの1つといってもいいにょ。
しかし、そのソフトのファンのみがハードを買ったためかソフト発売翌週にはソフト発売
前週の販売台数に戻っているにょ。
これはソフトの販売本数を見ても分かるにょ。
ペルソナ4の方は発売週に152499本販売で累計が193412本となっており、初音ミクの方は発売
週に158009本販売で累計が185353本となっているため発売週以降は2割程度しか伸びてない
ためにょ。
ミクロ（ごく短期間）で見ればキラーソフトだけどマクロ（長期間）で見ればキラーソフト
と言っていいか微妙なものといえるにょ。

例えばPSPでキラーソフトといえば何と言ってもモンハンだけどその中で最も売れた
「モンスターハンター ポータブル 3rd」は400万ヒットとなる累計4502446本の販売本数を
記録しているというのは驚異的なのだけどこのソフトは発売週から2倍以上数字を伸ばして
いるにょ。
これはこのソフトに限らずキラーソフトと呼ばれているソフトの多くが販売数量のみならぬ
長期的なヒットによりハードの売り上げにおいて多大な貢献をしているにょ。
つまり、このようなソフトが出るかどうかが重要になってくるというわけにょ。
過去に遡ってみると初代プレステはサターンに対してやや劣勢だったのだけどFFVIIの発売
決定によって一気に盛り返しそのまま勝利へとなったにょ。
これはFF VIIはただのきっかけにすぎずその後にいくつものキラーソフトが続いたお陰にょ。
Vitaにおいては、このような「このソフトが出たからVitaを買おう」と多くの人が思うような
ソフトは不在といえるにょ。


(2)PSPとの互換性に関しては昨年の11月15日にも書いたようにPSストアからダウンロード購入
したPSP用ソフトは動作するにょ。
これはエミュレーション動作によって互換性を取っているもののあくまでダウンロード販売用
として用意されているもののみが動作するだけに止まり、手持ちのUMDソフトに関してはUMD
ドライブが搭載されていないVitaで動作することはないにょ。
すでにVita発売前からダウンロードソフトのみを購入しダウンロード用として用意されてない
ものに関しては興味なしというような人ならば「VitaはPSP互換がある」という認識かも
しれないけどそれは全体から見たらかなり少数派でありほとんどの人は手持ちのUMDソフトを
動作させたいと思っていると思うにょ。
互換性というからには従来メディアとの互換性が最も重要であり、ダウンロード用ソフトのみ
動作するから互換性があると言うのであればアーカイブスで用意されているPS1ソフトしか
やらない人にとっては「PSPはPS1互換がある」ということになってしまうにょ。
ハードウェアの互換性がなくてエミュで一部のソフトが動作するというのはそういうことで
しかないにょ。（CPU、GPUの互換性がないだけではなくメディア互換性がないわけだし）
「互換性がある」のではなく「一部のソフト（＝ダウンロード用として用意されている
ソフトのみ）が動作する」というだけにょ。

しかし、「互換性がそんなに重要なのか」と思っている人もいるかもしれないにょ。
これは、同じハードで旧世代機と互換性のあるモデルと互換性のないモデルが同時に発売
されてその販売状況を見てみないと分からないにょ。
ところが、それを数字で確認できるデータもあるにょ。

　《 PS VitaとPSPの週間販売台数 》
　　　　　　　　　　PS Vita　　　 PSP　　　3DS（参考）
　2012年10月第1週　　8118台　　 16596台　　 58233台
　　　　　　第2週　　7028台　　 15107台　　 78401台
　　　　　　第3週　　7031台　　 15179台　　 60033台
　　　　　　第4週　　6093台　　 14575台　　 60079台
　　　　11月第1週　　5368台　　 13351台　　 82644台
　　　　　　第2週　　4263台　　 11749台　　168662台
　　　　　　第3週　 12019台　　 11197台　　170559台
　　　　　　第4週　　9246台　　 16197台　　158527台
　　　　12月第1週　　9830台　　 14248台　　154654台
　　　　　　第2週　 10348台　　 17379台　　219103台
　　　　　　第3週　 12590台　　 28779台　　333409台
　　　　　　第4週　 19056台　　 58378台　　433788台

これは両機種ともにここ3ヶ月間の週間販売台数の推移となっているのだけどVitaの方は
すでに十分普及していると思われる旧世代機であるPSPにさえ販売台数で負けているにょ。
このデータから言えることは「互換性が無いため売れない」ということにょ。
これは互換性の問題ではなく(1)で書いた「キラーソフト不在」が原因と思う人もいるかも
しれないけどもしもVitaにPSP互換がある（UMDソフトがそのまま動作する）というのならば
PSPではなくVitaを選択する人が大勢いると予想できるからにょ。

さんざんソフト不足がささやかれ一時期失速していた感があった3DSでさえDSの販売台数を
下回ることなんてことは無かったにょ。

　《 2011年5月の3DSとDSの週間販売台数 》
　　　　　　　　　　3DS　　　 　DS
　2011年5月第1週　 25331台　　 13341台
　　　　　 第2週　 26107台　　 14839台
　　　　　 第3週　 16379台　　??6961台
　　　　　 第4週　 16465台　　??6554台
　　　　　 第5週　 25096台　　　6389台
　　　　※DSの販売台数はDS Lite、DSi、DSi LLの合算数量

これは最も3DSが売れていなかった昨年5月のデータだけどこれは例年5月は売れない月という
だけではなく販売ソフトも弱いことが多いためにょ。（決算時期やボーナス、年末商戦には
絡まないというのが理由）
その数量はいいとして、問題なのは3DSとDSの本体販売台数の関係にょ。
見ての通り、3DSが売れてない時期であってもDSより圧倒的に上であるというのがこの数字で
分かると思うにょ。
当時はDSi本体が定価15000円、3DSが定価25000円だったにょ。
3DSはDSとの互換性があるためDSi本体を新規購入や買い増しをする人にとっては実質1万円で
3DS用ソフトが遊べるため3DS本体を選んだ人が多いというのがこの数字から読み取れるにょ。
ちなみに5月第3週以降DSの週間販売台数が5桁（1万台）に達することは無くなり減少の一途を
たどることになったにょ。
逆に3DSは7月に値下げが発表され買い控えによって8月第1週のみ極端な販売台数減によって
一時的にDSに週間販売台数で負けてしまったけどその反動で翌週は21万台という発売当初の
次に多い販売台数を記録してそれ以降は値下げ前と比べて数倍に販売台数が伸びたにょ。

互換性の有無の影響はこのように同時期における旧機種との販売台数比較で明確に分かる
と思うにょ。
互換性があることでその差額分（上記の3DSだと1万円）と新ハード用のゲームをプレイできる
ソフトとの天秤に掛けることが可能になるにょ。
実際は3DSが1万円で買えるわけではなく当時25000円だったわけだけどユーザーにとっては
この心理的な差は非常に大きなものとなっているにょ。
やりたいソフトが無ければ安くても買わないけど3DSにはDSとの互換性があるため安ければ
現在3DSでやりたいソフトがなくてもDSのソフトのプレイのために買って将来性に期待する
という人も大勢いるのではないかと思うにょ。
3DSにDSとの互換性が無ければ25000円払ってやりたいソフトがあるかどうかということに
なりソフトに求められるハードルが非常に高くなるにょ。

現在のPS Vitaの定価は24980円、PSPの定価が13800円にょ。
PS Vitaの価格が変わらずに互換性があればPS Vita用のソフトをプレイするのに11180円
払う価値があるかということになり、その価値があると判断する人はPSPではなくVitaを
選択することだと思うにょ。
しかし、現実は上記のようにPSP用として発売されたパッケージソフト（UMD）はVitaでは
プレイできないため24980円払ってやりたいソフトがあるかどうかで判断する必要があるにょ。
そして、現在はその払う価値が無くPSP用ソフトならば13800円払う価値があると判断する
人が多いというのが上記のようにVitaがPSPに販売台数で負けている理由となっているにょ。
発売当初（ローンチ）は目新しいもの好きな人（アーリーアダプター層）が購入するため
このように旧機種と天秤にかけて買うことはあまりないけど発売から1年経った今だから
こそこの互換性の影響がもろに出てきているにょ。
やはりある程度新ハードが普及するまではこの互換性の有無が非常に重要であり、それを
搭載することでよほど大きな価格上昇にならない限りは互換性を保つというのが普及を
促進する効果があると言えるにょ。


(3)PSPは確かに発売当初は携帯ゲーム機としては非常に高性能であったものの新規ハードで
ありソフトウェア資産には乏しかったにょ。
それがここまで発売当初に売れたのは音楽や動画などのマルチメディア再生のプレイヤー
として購入した人も多かったためにょ。
2000年代前半、多くの家電メーカーからこのようなプレイヤーの類は発売されてきたものの
どれも高額でありヒットしたものはほとんど無かったにょ。
そんな中で本体価格19800円（税別）というPSPは非常に安価だったにょ。
確かに使用するためにはSDカードよりも割高となるメモリースティックDuoが必要になった
もののそれを加味しても国内メーカーが発売していたどのプレイヤーよりも安価だった
からね。（ただし、型落ち処分で一時的に安くなっていたものを除く）

では、今はどうなのかというとそういった音楽や動画はスマホやタブレット端末があれば
楽しむことができるにょ。
そして、安価な端末ならば1万円程度から入手可能だしケータイからスマホに乗り換えを
した人ならば（スマホの小さな画面で問題が無ければ）別途端末を買う必要性も無くなって
いるにょ。
つまり、PSPが発売された当時とは全然状況が異なっているというわけにょ。

逆にVitaは一応は汎用性のあるMS Duoを採用していたPSPと異なり、Vita専用のメモリー
カードを買わないと何も記録できないにょ。
そのメモリーカードの定価は16GBで5500円、32GBで9500円となっているにょ。
この価格はVitaが発表された当時のMS Duoとほぼ同レベルの価格帯であり決して高額ではない
もののMS Duo自体がSDカードと比べて割高なのに加えて常に価格変動が行われているSDカード
などとは異なり、このようなゲーム機の周辺機器は滅多なことでは値下げが行われないにょ。
実際PS1の純正メモリーカード（128KB）は発売当時2000円（税別）だったのが1800円（税別）
になったのだけどこれはケースを別売りにしてようやく200円値下げをしただけであり、
PS2の純正メモリーカード（8MB）は発売当初から現時点においても2800円（税別）を維持して
いるにょ。
現時点ですでに大幅な割高感があるのに今後さらに大きくなることが予想できるにょ。
つまり、音楽、動画再生用としてVitaを使用するのは単に割高であるためそういった方面での
販売は期待できず、ゲームのみの価値で販売していかなくてはならずPSPが発売された当初と
比べてハードルが上がっているにょ。


このようにとりあえず、VitaはPSPと比べると完全に厳しい状態にあることは否めないにょ。
しかし、これを持って失敗というのはまだ時期尚早にょ。
では、逆にどれくらい行けば成功と呼べるのかというとゲーム業界の経験則でいえば1つの
国でハードが500万台以上普及することがビジネスとして成功するための条件と言われて
いるにょ。
そのボーダーラインである国内販売台数が500万台前後の機種を羅列するとセガサターン
（590万台）、PCエンジン（584万台）、ニンテンドー64（554万台）、ゲームキューブ
（402台）となっているにょ。
http://gamedatamuseum.web.fc2.com/hardhistory.htm
そのハードに対するイメージは人それぞれだろうけどこれくらいいけば失敗とは言えない
レベルだと感じるのではないかと思われるにょ。

このハード販売台数だけど国内においては上記リンク先を見て分かるようにその世代の
普及台数がトップのハードで2000万台前後となっているにょ。
数年前までは2番手ハードは600万台にも満たなかったにょ。
任天堂の任天堂の山内前社長は「一強皆弱」という言葉を残しているけどこれは娯楽の
世界というのは1つの秀でたものが独占するという意味にも捉えられるものの「他が思い
つかない唯一無二のものを作れば他は追いつけないということ」を意味するみたいにょ。
確かに山内前社長の言うことは分からなくもないけど個人的には棲み分けが行われるだけで
あり、強弱とはそれほど関係がないような気もするにょ。（仮にすごく楽しめる娯楽が登場
してもその1つの娯楽だけが受け入れ他の娯楽が受け入れられなくなるわけではないため）
しかし、この山内前社長の言うことはビジネスモデルとしてどうなっているのかを考える
と納得がいくにょ。
それは売れたハードというのは必然的にサードパーティにとっても開発コスト回収の確率が
アップするためそのハードでソフトを発売する機会が増えるのでソフトがどんどん充実して
くるからにょ。
逆に売れないハードは開発コスト回収の目処が経たないため避けられてしまうにょ。
そう考えると必然的に一強皆弱の状態になってしまうことになるにょ。
それが過去において、トップは2000万台でも2番手以降は600万台にも満たないという
大差になっていたにょ。

ただし、これは近年変化が訪れているにょ。
例えばDSとPSPではその過去の法則からはかけ離れたものになっており、トップのDSの国内
累計台数は3200万台に達し国内2番手のPSPでも1900万台に達しているにょ。
1900万台というのは従来ならば一強皆弱における勝ちハードの販売台数に匹敵する数量にょ。
これは国内においてはDS、PSPの世代では「携帯ゲーム機が主役」といってもいい状況と
なっていたため過去に前例がない特別な数字になったといえるにょ。
その割を食っているのが据え置きハードであり、トップのWiiでさえ累計1200万台程度にょ。
ただし、国内2番手となるPS3の860万台も従来の2番手では考えられなかった数字にょ。
もちろん、これはまだ伸び続けているためあくまで現時点の数字だけどね。
国内においてはXbox360はふるわないものの海外では非常に強い力を発揮しているため
世界シェアならばコンシューマゲーム機市場ほとんど例のない三つ巴のほぼ拮抗した状態に
なっているといえるにょ。（数字ではWiiがややリードしているもののこれはスタートの価格が
安かったため普及が速かったのとHD非対応であるため昨今は売り上げがダウンしている
というのを考えるとほぼ拮抗した状態になっているといえる）

PSPは先代携帯機では2番手であり、従来の「一強皆弱」の考えで言えば負けハードになる
もののこの販売台数は立派であり少なくとも国内においてはこの互換性の有無は非常に
重要なものだったといえるにょ。（海外では国内ほどPSPが強くなかった）
それを採用しなかったのはUMDを採用することでデメリットも多いためにょ。
まず、搭載すると「サイズが大きくなる」というだけではなく「バッテリ駆動時間が短く
なる」「コストがかかる」という問題があるにょ。
PSP発売当時のUMDの最大のメリットであったROMカードリッジに対して容量の優位性も
ROMカートリッジの大容量化によってほとんど無くなったにょ。
これはディスクシステムがROMカートリッジの大容量化によって駆逐されたのと同じ原理
であり、ディスクの方がROMカートリッジよりも製造コストが安くても容量で追いつかれた
時点で終了してしまう運命だからにょ。
もっとも、DVDと同じ赤色レーザーを採用しているUMDもBlue-rayと同じ青色レーザーに
対応した新モデルを開発、投入するという方法もあっただろうけど開発コストやそれを
搭載することによる原価アップなどを考えると搭載は見送らざるを得なかったのではないか
と思われるにょ。（搭載しても数年後にはROMカートリッジに容量で追い抜かれてしまう
可能性が高いわけだし）
ただし、Blue-ray UMDを搭載していればPSPとの互換性を保つことは可能になっていた
ため搭載しない方が良かったのかどうかは今になって考えると評価が分かれるのでは
ないかと思うにょ。

3DSはすでに国内販売台数は累計で約950万台になっているにょ。
恐らく来年早々には1000万台の大台に達するにょ。
それに引き替えVitaは3DSより10ヶ月遅れの登場とはいえ辛うじて100万台を越えたレベル
であり、年末商戦、クリスマス商戦が始まっている12月第3週の時点でも週間販売台数が
2万台にさえ達しないというのは危険な状態だと言えるにょ。
国内では「あまり売れてない」というイメージがあるXbox360だけどそれでも発売して
翌年の年末商戦における販売台数はピークの週で38096台に達しているにょ。（Xbox360の
国内販売数はゲームギアと同レベルだからイメージだけの話ではなく決して多いものでも
ないけど）
これはXbox360のキラーソフトであったブルードラゴンが発売されたというのが大きいため
だけど年末商戦にキラーソフトを投入できたというのが非常に大きいにょ。

(2)で書いたように互換性がないためその新ハード用のソフトだけの力（キラーソフトの
力や豊富なソフトラインナップ）で売って行かなくてはならないし、PSPのようにゲーム
以外の要素で販売するのは今となっては厳しすぎるためキラーソフトの影響はPSPの時と
比べて遙かに大きなものとなっているのにそれが用意できていないわけだからね。
このままの販売台数推移だと開発コストを回収できないためVita用に自社の命運をかけた
ような主力製品を投入するなんて無謀なことをするようなメーカーなんていなくなって
しまうにょ。
そうなると必然的に他機種用に出した分で開発コストが回収可能なマルチか低開発コストの
ソフトとなってしまうにょ。（開発コストがかかってないからつまらないゲームなんて言う
つもりはないけど宣伝にもコストを掛けられないためそういうソフトは本体の売り上げを
牽引していくようなキラーソフトにはなりにくい）

任天堂の場合はサードパーティ（他社）のソフトに頼らなくてファースト（自社）ソフトで
何とかするということができるし、それで負けハード扱いのゲームキューブにおいても
十分な利益を出せているけどSCEには難しいためサードパーティの力に頼らざるを得ないにょ。
Xbox360は国内では振るわなくても海外市場が大きいためサードはそちらにターゲットを
しぼったソフトを販売することで十分に開発コストを回収することが可能だったけどVitaは
現時点においては国内においても海外においても苦戦をしているためハードがもっと普及
しないとじり貧になる一方にょ。
もしも、潤沢な資金があればそれを元にサードを引っ張ることもできるけど今は親会社で
あるソニーもかなり厳しい状況であるためそれも難しいからね。
そして高画質なゲームをプレイしたいならPS3、安価でソフトが充実しているPSPといった
感じで自社内でVitaのシェアを奪われている感じであり、Vitaの立ち位置が未だに不鮮明
というのがさらにVitaを苦しめているにょ。

1435：御茶目菜子：2012/12/29(土) 23:55:43
PS4は出すべきではないハード
12月8日に発売されたWii Uは発売週の販売台数が30万台を越え2週目13万台、3週目12万台と
なり、早くも50万台（ハーフミリオン）突破となりまずまずの滑り出しといえそうにょ。
発売週37万、2週目、3週目10万のWiiのスタート時にほぼ匹敵するレベルにょ。
世間はWii Uで盛り上がっているけどライバルであるSCEやMSがこのまま何もしないわけでは
ないにょ。
すでにPS3の後継機であるPS4（仮称）やXbox360の後継機であるXbox720（仮称）のウワサが
多く出回っているにょ。
やはり気になるのはPS4がどのようなスペックで登場するかということにょ。
Wii Uはすでにダイサイズなどから性能が粗方分かっているし、実際に発売されてそのゲームの
動作状況から実効性能が分かったにょ。

ダイサイズから見た性能は10月12日に書いているようにWii UはCPU性能においては現行の
ライバル機と比べてやや劣るレベルだけどGPU性能においてはそこそこ高いと判断できるにょ。
単純計算は難しいけどPS3の2〜3倍くらいの性能はありそうにょ。
GPU性能を高める必要があったのはPS3やXbox360の性能では見た目（1画面当たりのポリゴンを
減らすなどの措置を執ったりする）を落とさない限りはフルHD、60fpsで動作するゲームを
作るのは難しいためにょ。（コンシューマゲームの場合はそのハードの性能を100％出し切る
ことも可能なので汎用性のあるPCとは異なるとはいえGeForce 7800GTX未満の性能のPS3では
フルHD、60fpsのゲームは荷が重いのも事実）
実際Xbox360ではほとんどのゲームが1280x720だし、PS3においてはそれよりも下になっている
ものも多いからね。（それをフルHDに拡大表示している）
そうなると2〜3倍の性能があってようやくフルHDでの表示が可能になると言えるにょ。
しかし、Wii Uでは2画面対応であるため単純に処理の負担が大きくなるというだけではなく
発売から年数が経ち十分使い込まれているXbox360やPS3（コンシューマゲーム機は発売当初
から基本的にCPUやGPUの性能向上はないのだけどそれでも開発側がその環境に慣れることで
性能が十分に発揮できるようになるため実効性能がアップする）とは異なりそこまで性能を
発揮しきれてないせいかフルHD、60fpsで動作どころかPS3やXbox360とあまり変わらない
解像度であると検証されているWebサイトもあるにょ。

これは発売して間もないハードであるためやむを得ないといえるけどそれを見越してもう少し
余裕を持たせた性能にしておくのがベターだったにょ。
これがGPUが28nmで製造されていれば単純計算で性能は現状の2倍に出来たのでフルHD、60fpsで
動作させることも十分可能であり、開発が十分に慣れてない初期段階であってもライバルと
比べて同レベル（フルHD、60fpsには大幅に足りない）なんてことにならなかったにょ。
そのためライバルとの関係を考えるならば28nmが量産可能になるまで待ってからWii Uを発売
すべきとも考えたにょ。（とはいえ、Wii UはCPUがやや貧弱なのでGPUが十分でもCPUがボトル
ネックになる可能性はあるけど）
次世代機がすべてフルHD、60fpsになればその中でWii Uの性能が最も低くても見た目で明確に
分かる差が出てこないからね。
そうなると、Wii用ソフト資産に加えてタブコンという独自性や任天堂ソフトがプレイできる
というアドバンテージがあるWii Uは昨年の7月27日書いたように次世代機競争で勝利する
確率が極めて高くなると考えたにょ。

しかし、ビジネス面から考えるとそうもいかないにょ。
現行の据え置き機の中で国内で最も普及しているWiiだけどすでにそのピークは完全に
過ぎていてマイナス成長となっているためにょ。
Wiiは現時点では普及台数において同世代に登場したライバル機に何とか勝利しているけど
HD非対応であるためここ1、2年は国内ではPS3負けてるし海外ではXbox360に負けているにょ。
昨年の国内での週間販売台数も年末年始を除けば1万台前後となっており、今年に入って
からはWii Uの情報が出回ったためか週間販売台数は1万台にさえ達しなくなってしまった
からね。（さすがにこの年末商戦では週間販売数は再び1万台以上となっているけど）
WiiとWii Uの発売間隔は6年ということでコンシューマゲームの世代交代の時期からすれば
Wii Uの登場は時期尚早というわけではなく極めて妥当な時期での発売といえるにょ。
まぁ元々WiiはHD非対応であるため登場した当初からPS3やXbox360と比べて次世代機に交代
する時期は早いと推測されていたわけだしね。
国内においては昨年の7月に地デジに完全移行しHDTVが急速に普及した（そのせいで今年は
TV製造メーカー全社が大幅な前年割れとなり苦しんでいる）ということもあり、HD対応が
急務だったとえいるにょ。


それでは、すでに様々なウワサがされているPS4はどうなのか・・・？
ウワサでは来年末〜再来年に登場するのだけどすでに発売から6年経っており、来年登場
としても7年、再来年ならば8年ということでコンシューマゲーム機の世代交代としては
やや長目となるにょ。
ここまでくると性能もPS3と比べて桁違いにアップしそうだけどそこまで高い性能にはなり
そうにないにょ。
http://pc.watch.impress.co.jp/docs/column/kaigai/20121225_580059.html
後藤氏の予測ではAMDのAPUをベースとしたものをPS4では採用予定となっているからにょ。
世代的には来年登場予定のTrinity後継となる28nmプロセスのものが搭載されるにょ。
恐らくCPU部分は第2世代BulldozerアーキテクチャとなるPiledriverコアから強化された
第3世代のSteamrollerコアへとなり、クアッドコアのSKUが採用されされると思われるにょ。
GPU部分はGCN（Graphic Core Next）アーキテクチャーのGPU（RADEON HD7000シリーズで
採用された新アーキテクチャー）を一体化したものになると思うけど28nmで製造されると
なれば搭載されるものはRadeon HD7750クラスであると思われるにょ。
ただし、11月22日に書いたようにGLOBALFOUNDRIESの28nmプロセスの製造が芳しくないため
AMDのロードマップは変更されておりSteamrollerコアの市場への投入は再来年にずれ込む
可能性も高くなっているにょ。
そのため、もしもPS4を来年中に発売するならばTrinityを採用するかBobcatの後継となる
となるJaguarコアを採用するしかなくなるにょ。（その場合は、スペック不足ならば別途
GPUを搭載する必要があり、コスト増になってしまう）

もしも、PS4がTrinityの後継であるKaveriを採用した場合にはGPU性能はWii Uと比べて
2倍かそれよりやや上くらいの性能となりそうにょ。
それでも、PS3と比べた場合には5倍程度の性能向上に止まるため従来の世代交代で実現
されていたような桁違いの性能向上は難しいにょ。
もっとも、APUといってもメモリ帯域次第で性能は大きく変わるにょ。
http://akiba-pc.watch.impress.co.jp/hotline/20121020/sp_review.html
メモリのチップ数を増やした方が帯域面では有利なのだけどコストアップになるし後に
コストを削減しにくくなるためいくつのチップを搭載するかは難しい選択になりそうにょ。

かつて、PS3を立ち上げた時はその主力となるCellを自社で生産すべくFabを建造したにょ。
確かに自社生産は初期投資がかかるもののある程度の生産数があれば量産効果で1つ当たりの
コストを減らせるというメリットがあるにょ。
しかし、同じ製造でずっと製造し続けるのではその量産効果にも限界がある（微細化が進む
ことで同じ性能のチップならばダイサイズが小さくなりコスト軽減があるだけではなく
消費電力の軽減も行うことが可能になる）のだけど微細化が進むにつれてどんどんハードルが
高くなってきているためにょ。
現在業界最先端の製造プロセスでCPUを製造しているIntelだけどそのようなビジネスモデルは
ほとんどの半導体メーカーには難しいにょ。
そのためソニーはCellの工場を東芝に売却してしまったくらいにょ。
そうなるとPS4でそこまでコストをかけて自社開発や自社生産するというのは無理であり
パートナーの企業から購入するという形にせざるを得ないにょ。
実際、Vitaにおいても専用設計ではなく汎用のCPUとGPUを組み合わせて製造しているわけ
だしね。（その結果Vitaはすでに最新のスマホやタブレット端末にCPU、GPU性能において
追い越されてしまっている）


ここで問題となるのがPS3との互換性にょ。
AMDからの供給となれば搭載されるのがx86CPUとなるにょ。
x86CPUを搭載によってPCゲームとのマルチはしやすくなるというメリットがあるものの
PS3で採用されたCellとアーキテクチャが全く異なるCPUを採用すれば互換性が無くなって
しまうにょ。
上記のように設計コストをかけてCellと互換性のある高性能なCPUを用意するのも難しい
のでこれはやむを得ないにょ。
互換性の問題ならばPS2がPS1のCPUをサブとして内蔵していたり、PS3の初期モデルでPS2の
CPU、GPUであるEEとGSの統合チップを内蔵していたようにPS4で同じことをやればいいという
考えもあるにょ。（ソフトウェアエミュレーションはPS3とPS2の性能差があっても難しい
レベルであるためPS4でPS3のソフトウェアエミュレーションはどう考えても無理）
しかし、Cellは45nmの段階で微細化が止まっており、それを使い続けるとなると消費電力の
面でもコストの面でも厳しいにょ。
かといって、Cellをさらに微細化するのもそれなりの投資金額が必要になるにょ。
結果としてCellを搭載し続けるならばまた高価格なゲーム機となってしまいかねないにょ。

もっとも、PS3が登場時とは異なり、BDドライブも値下がりをしているため発売時の定価は
6万円オーバーというような高額にはならないにしても（逆ざや無しならば）3万円台後半
くらいの定価（高くて39800円）になるのではないかと思われるにょ。（AMDの28nmが間に
合わない場合は別途GPUを搭載する必要があるためその価格でも逆ざやになる可能性がある）
デフレが進んでいる今となってはこの価格帯では普及させるのは厳しいにょ。
逆ざやに関してはやや否定的な任天堂もWii Uでは本体のスペックは必要最小限のコストに
押さえたものの標準コントローラのコストアップから25000円（税別）に抑えるのは難しく
ソフト1本分（千円単位）の逆ざやになっているみたいにょ。
PS4もそれくらいの逆ざやは十分考えられるため3万円台前半での投入（高くて34800円）は
十分考えられるもののPS3発売当初のような大きな逆ざやは現状では厳しいためさすがに
いきなり2万円台で発売するのは難しいではないかと思われるにょ。（Wii Uとは異なり
HDDを内蔵するだろうから恐らく本体の製造原価は3万円を少し切るくらいになると思うので
あとはコントローラにどれだけコストをかけるかで原価が変わってくる）

では、互換性を削ればいいという考えもあるにょ。
それは昨日書いたようにVitaの敗因の1つになっているため難しいにょ。（Vitaもダウン
ロード用のソフトならPSP用として作られたものが動作するけど主力となるUMD媒体による
ソフトが動かない関係上互換性は無い物として語らざるを得ない）
互換性が無くても新ハード用に作られた魅力的なソフト、キラーソフトがどんどん投入
されていけば問題はないのだけどサードパーティも開発コストの回収をしなくてはならない
ために普及するかどうかは未知数のハードに多額のコストをかけたソフトを投入すると
いうのは難しいにょ。（マルチならば別だけどそれだとその新ハードの牽引効果は低い）
互換性はその新ハードが普及してその新ハード用のソフトが充実するまではハードを普及
させる面でのプラス効果が期待できるのは過去の勝ちハード（シェア1位のハード）との
互換性がある機種がほぼすべて勝ちハードになっているという前例を見ても明らかにょ。

ハードの末期になると前世代ハードとの互換性の有無はハードの売り上げにとってそれほど
重要な要素にはならないけど世代交代時には大きな影響があるにょ。
上記のようにハードが普及しないとソフトが充実せず、そしてソフトがないからハードが
売れないという負のスパイラルができあがってしまうからね。
したがって、ハードメーカーはコスト的に不利になっても前世代ハードとの後方互換性を
保とうとしたり、ハードによる利益がないどころかマイナスになってしまう逆ざやとなる
価格によって少しでも多くのハードを売ろうとしているにょ。（もっとも、安ければ売れる
という単純なものではないけど安ければ売りやすいのは事実）
新ハードがビジネスとして軌道に乗るためには最低でも500万台の普及が必要だけどPS3が
500万台を越えたのは逆ざやを解消した2010年になってからだからそれからのPS3の状況を
考えるとこの「500万台普及したハード」というのはソフトが売れる下地としては必要不可欠な
ものであるといえそうな感じにょ。（まぁ勢いがあるかどうかも重要なのであくまで必要条件
であって十分条件ではないけど）
ゲーム業界では国内市場においてアーリーアダプター層だけでも50万台の売り上げは堅い
ため100万台突破はあくまで初期の通過点にすぎず、この500万台にいかに早く到達するか
という点が重要となってくるにょ。（勝ちハードになるためには500万台も通過点にすぎず
1000万、2000万というレベルになってくるけど）

もしもPS4にPS3互換がないならば昨日書いたPSPとVitaとの比較と同じように前世代機で
あるPS3よりも売れないという状況になる可能性も十分に考えられるにょ。
そこでSCEが考えているのがクラウドゲーミングだと思われるにょ。
実際クラウドゲーミングのGaikaiを買収したくらいだしね。
http://japanese.engadget.com/2012/07/02/gaikai-300/
クラウドゲーミングとは何かというと要するにゲームの実行はサーバ側で行いユーザー側に
ある端末ではそれに指示を与えるだけであり、ごく掻い摘んで言えば「リアルタイムで操作
可能なストリーミングムービー」みたいなものにょ。
そのため端末のスペックはかなり低くても問題ないし、端末側はアーキテクチャに縛られる
ということはなくなるにょ。
PS4でPS3のソフトを動作させるためにはサーバ側にCellを搭載していればいいだけにょ。
しかし、クラウドゲーミングにはサーバのコストと遅延（タイムラグ）の問題があるにょ。

まずサーバだけどどれだけの利用があるか分からないので投資金額はまったく計算ができない
もののPS4所持者がすべて使うならば初期段階で100万台売れたと想定してその3割が同時に
使用するならばCellを30万個使用したサーバが必要になるにょ。
要するにそれをネイティブに実行するマシンが本体かネット上（サーバ）にあるかという
だけであって、サーバを用意するのもタダではないのでそのコストはユーザーが支払うことに
なるにょ。（手元にPS3ソフトのメディアがあるならばそのタイトルにおいてはPS4のクラウド
ゲーミングで無料で遊べるかというと投資を考えると厳しいのでそのメディアの有無は関係
なく別途利用料金が必要になると思われる）
そうなるとPS3互換を省くことでユーザー側は初期投資が抑えられるかもしれないけどPS3の
ソフトをプレイする場合には結果として高く付くなんてことも十分に考えられるにょ。
もちろん、事前に十分なサーバ設備を用意しておく必要があるためメーカー側（SCEもしくは
その協力会社）の初期投資はかなりの金額になるにょ。

また、サーバからの演算結果を表示する場合には帯域や遅延の問題をどうするのかがが重要に
なってくるにょ。
フルHDのゲームをプレイする場合は常時フルHDの動画を再生し続けるほどの帯域が必要に
なってくるからね。
しかし、ゲームでは帯域だけではなく遅延の問題の方が重要にょ。
これがただの動画であれば数100m秒の遅延があっても気にならないのだけどアクション系の
ゲームならば100m秒の遅延となると6〜7フレームの遅延となるため致命的になるにょ。
遅延を減らすためにはユーザーとサーバの物理的な距離を縮める必要があるにょ。
クライアント側（ユーザー側）の端末で操作を行いホスト側（サーバ側）の処理が実行
される時間はサーバー側での処理時間がゼロであろうとping値の上りと下りの合算値の
遅延が起きてしまうわけだからね。（光回線であっても10m秒単位の遅延はある）
そのためより遅延を減らすためには全国各地にサーバを用意しなくてはならずそのコストは
非常に大きなものになるにょ。

Wii Uでは本体で演算されたデータをその専用コントローラ（通称「タブコン」）をその
データを受信して表示するだけという仕組みでありクラウドゲーミングのミニマム版の
ようなことをやっているのだけど同一空間内に限定することで遅延をゼロ（厳密に言えば
1フレーム未満の遅延）に押さえているわけだからね。
ネットゲームはサーバ側ですべての演算を行っているのではなくユーザー側の端末で行って
いるからこそそれなりに遅延を減らせているもののこれがすべてサーバー側で処理が行われ
再生のみを端末で行うクラウドゲーミングはその設備コストや遅延の問題が改善されない
限り実用レベルにはならないと思われるにょ。


こうして見るとPS4の課題は山積みにょ。
そもそもPS3ユーザーにPS4への買い換えを喚起できるかというと微妙だからね。
従来であれば世代が変わるごとにゲームの画面を見ただけでではっきりとその性能差が
分かるレベルの差があったにょ。
見た目が変わればゲームが面白くなるかというとそれは別問題ではあるけど見た目という
のはユーザー需要を喚起させる大きな要素であるのには間違いないにょ。
しかし、すでにPS3の段階でHD対応となっていてPS4では「従来のPS3は小さいサイズの
ものをフルHDに拡大させていただけなのに対してこちらは標準でフルHDだ」と公式で
PS3を陥れるようなことを言わない限りはほとんどのユーザーにはその差なんて分から
ないレベルになりそうにょ。
見た目ではなくWiiのリモコンのような新しい遊び方を提示できればまた変わってくる
だろうけど恐らくそれはSCEには無理にょ。（アナログコントローラにしてもPS MOVEに
しても過去にやってきたことはすべてライバルの後追いみたいなものだし）

もしもPS4が4K対応ならばまた話は変わってくるけどその見た目の差は4K対応のTVでないと
分からないにょ。
4K対応のTVはまだコンテンツがないため普及にはしばらく時間がかかりそうだし、何より
4Kでプレイするためには予想しているPS4の性能から少なくとも4倍以上高める必要がある
ため2014年に登場させるならばかなりの高コストになってしまうにょ。（ポリゴン数を
落として4K表示するのは可能だけどそれでは意味がない）
そうなるとPS4は従来のPS1、PS2、PS3の時のような見た目で差別化というのは無理にょ。
ライバルとの差もWiiが非HD対応であったのに対してWii UではフルHDに対応しているため
PS4では見た目で明確に分かるような差にはならないと思われるにょ。

見た目でPSPと明確に分かるような差があるVitaでさえこれだけ苦戦しているのにPS4は
現時点ではクラウドゲーミングくらいしか強みがないにょ。
クラウドゲーミングはアーキテクチャの差に左右されないというというのもあるけど
端末性能の貧弱さをカバーできる技術であるため新製品がそれに対応しているというのは
大きな強みにはならないと私は思うにょ。
ソフトメーカーにとっては海賊版防止にはなるもののすでに開発コストを回収したような
ソフトならともかく新作をクラウドゲーミングでの配信となるとよほど多くのユーザーが
プレイしない限り開発コストを回収できない可能性があるにょ。

ユーザーにとっては月額固定で様々なゲームが遊べるのは魅力的かもしれないけどやはり
それは「魅力的なゲームが多数ある」「月額固定」でそれに似合った料金があった場合に
限られるにょ。
1日だけのプラン、1ヶ月プランとかいろいろ選べることで料金面のハードルは下がるけど
それだけではなく高速なブロードバンド環境がないとプレイそのものができないなどの
プレイ環境なども問題もあるにょ。
客寄せコンテンツの1つとして考えるならばクラウドゲーミングはありだと私も思うけど
それをメインにするならば非常に多くの問題を抱えることになりPS3よりも遙かに普及が
難しいハードになってしまうにょ。
そもそも高性能なゲーム機が不要で初期投資が安くなるとというのがユーザーにとっては
クラウドゲーミングの最大のメリットなるはずなのにわざわざ高額な最新ゲーム機を買って
プレイするとなるとそのメリットが失われてしまうにょ。（あくまでおまけ機能ならば
問題ないけど）

販売店にとっても流通が無くなるクラウドゲーミングは歓迎されずそれをメインとした
場合にはハードの取り扱いを行われなくなる可能性もあるにょ。
ゲーム機本体は定価で売っても5％前後の利益しかないため割引などをした場合には利益
無し、もしくはマイナスになってしまうためソフトや周辺機器を買ってもらわないと
かなり厳しくなるからね。
そのため、Vitaではダウンロードに主軸を置きたかったSCEだろうけど販売店がハードを
取り扱わなくなったらハードの普及も見込めないためパッケージ販売は継続して行って
いるにょ。


PS3は発売5年目（2010年）にしてようやく逆ざやが解消され本体価格も安くなり小型化
されてユーザーの購入のハードルもかなり下がってきているにょ。
そして、世界合計のPS3用ソフトの売り上げも昨年は過去最高となっているにょ。
要するにPS3はようやく収穫の時（ハーベストタイム）になったといえるにょ。
そんな時期に次世代機の話題をちらつかせてユーザーの買い控えを誘うというのはプラス
どころかマイナスにさえなってしまうにょ。
個人的には「少なくともあと2、3年は後継機種を出さないから安心してPS3を買ってくれ」と
公式に宣言する方がSCEにとってはプラスになるのではないかと思うにょ。

次世代機では何かと性能向上の話題が大きく採り上げられてしまうけど下手に高性能化
してしまうと開発コストばかりが跳ね上がるからね。（これもスペックを使い切らずに
作ればいいのだけどそれだと次世代機ではなく開発のこなれた旧世代用としてリリース
する方が有利になるため必然的にハイスペックな次世代機だと開発コストが上昇してしまう）
PS3からPS4へと世代交代することで開発コストが倍増すると言っているメーカーさえある
くらいにょ。
開発コストが2倍になってもソフトが2倍売れてくれればその開発コストが回収できるものの
現実的にはそんなことは無理であり、開発コストはソフトの価格に転嫁させるしかないにょ。
しかし、ソフトの価格を上げると売り上げ数に影響するため簡単にはいかないにょ。
開発コスト増で苦しむ中で一番開発コストが安く（ライバルが次世代機に交代した場合）
最も普及しているPS3で作るというメーカーも増えるのではないかと思われるにょ。
実際現在のPSPがそんな感じだからね。（開発コストがそれなりに安くそれなりに普及
している現行機であるため）
したがって、ライバルたちが開発コスト増で苦しんでいる中、あえてPS4を出さずにお茶を
すすりながら尭深・・・ではなく、高みの見物をするのが最も得策だと私は思うにょ。

確かに見ているだけだと市場シェアをどんどん失ってしまうことになるけど「急がば回れ」
ということわざもあるように早く新ハードを投入するのが勝利に繋がるという単純なもの
でもないにょ。
魅力が無ければいくら早かろうと意味がないし、ソフトを含めて魅力的なハードならば
登場が遅くても十分に勝機はあるからね。（キラーソフトとなるような魅力的なソフトの
準備が整う前にハードだけ出してもハードは普及せず「売れないハード」となってしまい
昨日も書いたようにサードからも見放されてさらに売れなくなる負のスパイラルになって
しまいかねない）
コンシューマゲームはWii、3DSというシェアトップのハードを抱えて世界でもトップレベルの
ソフトベンダーである任天堂でさえ黒字を出すのは厳しいため新規ハードで下手をすれば
また莫大な赤字を抱え込むことになるにょ。
見た目で高性能というのが分かるくらいスペックを高めるのが無理だし、そんな高性能
競争を望んでいるユーザーやソフトメーカーだけではないためならばせめてPS3から
PS4に買い換えを喚起できるカードをいくつか用意すべきだと思うにょ。（クラウド
ゲーミングはそのカードの1つだろうけど私にはそれは切り札になるようなレベルには
到底思えない）
したがって、Vitaの失敗（まだ現時点での失敗を挽回するチャンスはあるもののかなり
厳しい）を据え置き機で繰り返さないようにもここは慎重な判断が求められてくるにょ。
資金が潤沢な任天堂やMSとは異なり、下手なことをすればPS4でSCEどころかソニーが倒産
なんて大惨事になってしまうにょ。（クラウドゲーミングをPS4のウリにするならば初期
投資の金額だけでも莫大になってしまうし、コストが回収できないからといってもやめる
ことが難しくなる）

そんな次世代機で盛り上がっている中でPS2は昨日12月28日に国内向けの出荷を終了したにょ。
DVDの普及に大きな貢献をして世界で最も売れた据え置きゲーム機となったのだけどそんな
PS2の終了のニュースを聞いて寂しがっている人も少なくないにょ。
では、PS4はPS2のように非常に惜しまれるような存在になれるのか・・・？
現時点の情報を見る限りはかなり厳しそうにょ。

1436：御茶目菜子：2012/12/31(月) 20:56:57
今日で今年も終わりだけど・・・
今年も今日で最後ということで毎年恒例の無駄遣いチェックをしてみるにょ。
今年購入した高額（1万円以上）デジタル機器は下記の通りにょ。

　11月　デジカメ　Cybershot DSC-WX100　12800円

昔は5、6個は購入していた（ノートPCも中古ながら毎年2〜3台購入していた）けれどここ
数年かなり経済的に厳しい状況であるためどんどん減っており今年はこれ1つだけにょ。
今まで使っていたTX1の充電器が行方不明になったため買い換えたわけだけど後継機種の
WX170が発売済みだったので安価になっていたにょ。
とはいえ、実を言うと購入して3日後に充電器が見つかってしまったにょ。
1週間探しても見つからなかったのに・・・（笑）
まぁTX1はすでにボロボロだったのでそろそろ買い換えないといけないと思っていたため
問題ないけどね。


さて、年賀絵もそろそろ描かないといけないのだけどまだ全然できてないにょ。
こんな調子では正月中に描き終わるのは難しいかもしれないにょ。
それなのにまたプチコンプログラムを作ってしまったにょ。

1行プログラム「新年カウントダウン」
Z=86400FOR T=0TO!!T*Z:CLS?"LAST"Z-T:TMREAD(TIME$),H,M,S:T=S+M*60+H*3600WAIT 1NEXT:BEEP 42?"NEW YEAR
　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#10

1行プログラム「カウンター」
CLEAR:FOR C=0TO 9CLS:B=BTRIG()C=LOG(B+!B)*1.5C(C)=!!B+C(C)BEEP,,-B:FOR I=0TO 7?C(I):NEXT:WAIT 1NEXT
　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#11

「新年カウントダウン」の方は元旦の0時までの残り時間（秒数）をカウントダウンする
プログラムにょ。
事前に本体の時計を正確に合わせてから使用するにょ。
何も難しいことをしてないけど0時を起点とした現在の時刻は変数Tに入っているので0時の
時点ではTの値は0になってしまうにょ。
T=86400ならば終了というプログラムならば簡単だけどT=0の時に終了するようにしなくては
ならない。
これはIF文を使えば簡単だけどそれだと1行に収まらないためFOR〜NEXTの終了値を設定して
いるにょ。

「カウンター」の方は[↑][↓][←][→][A][B][X][Y]で8種類までの数字をカウントできる
プログラムにょ。
こちらは、工夫した部分といえば各ボタン配置から配列変数の割り当て方法くらいにょ。
変数Bの値（BTRIG関数の値）はBUTTON関数と同じく[↑][↓][←][→][A][B][X][Y]は1、2、4、
8、16、32、64、128となり、これを0、1、2、3、4、5、6、7に変換する必要があるにょ。
見ての通り2のN乗をNに変換するだけだから対数を計算すれば簡単にょ。

さて、ここで問題なのはボタンを押さなかったらBの値は0となり、LOG(0)の値は計算が
できないためエラーになってしまうということにょ。（1行に収めるためIF文で判定する
こともできない）
そこで、何もボタンを押してない時にはBの値に1を足すことにしたにょ。
それだとLOG(1)となるため[↑]ボタンを押していると見なされるにょ。
したがって、何もボタンを押してない時にはカウンタの加算を0にしているにょ。

また、2^NをNに変換するためにはLOG(N)/LOG(2)を計算すればいいのだけどLOG(2)だと1行に
収まらないにょ。
ここで「1/LOG(2)≒1.443」であるため「1.5」を掛けているにょ。
これで、問題なのは誤差によってボタンを押した場合には誤認識されてしまわないかどうかと
いうことだけど[→][A][B][X][Y]の5つのボタンを1フレームのずれもなく完全に同時に
押した場合（Bの値が247以上になった場合）に認識されないという程度であり、そんな
ことは狙っても容易にはできないため普通に使用する限りはこの1.5という値で何ら問題は
ないにょ。

これで、今年公開したプチコンプログラムは53作品（サンプルを除き43作品）となったにょ。
（今年公開したものは12月22日にまとめを書いているのでそれ以降の12月27日と今日の分を
足せば今年私がどんなプチコンプログラムを公開したのかすべて分かる）


というわけで、本年はお世話になりました。
来年もよろしくお願いします！

1437：御茶目菜子：2013/01/01(火) 00:06:38
あけましておめでとう
新年あけましておめでとうございます。
本年も当サイトをよろしくお願いします。


おちゃめくらぶも今年で開設14年目となるにょ。
ポケコンサイトとして誕生した当サイトも手持ちで唯一動作可能なポケコンPC-E650が
壊れてしまい昨年はプチコンメインで更新してきたにょ。
お陰で1年間で大小含めて（というか、大なものはないけど）50作品以上を発表したにょ。
恐らく今年もプチコンメインでの活動となりそうにょ。
現状のように1画面プログラムをメインにして1行プログラムも作る予定にょ。

さて、お絵かきも今年は頑張らないといけないにょ。
昨年はpixivに10枚しか投稿できなかったからね。
しかし、依然としてスランプなので年賀絵が全然進まないにょ。
せめて1/3〜4くらいまでには完成させたいけどどうなることやら・・・。

昨日作った1行プログラム「新年カウントダウン」は正常に動作したにょ。
たぶん大丈夫と思ってまともに動作確認をしてないから少し不安だったにょ（笑）


1行プログラム「おみくじ」
CLS:FOR A=0TO 1A=FUNCNO:NEXT:A=A+RND(8)?MID$("ﾀﾞｲﾁｭｳｼｮｳ",(0OR A%8/2)*3,3)+MID$("ｷｮｳｷﾁ",A%2*3,3)
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#12

ファンクションキーで選択できるにょ。
10分くらいで作ったしょぼい内容だけどファンクションキーを使うことで「自分で選ぶ」
という感覚を得られるのではないかと思われるにょ。
大、中、小、（無印）に凶、吉を掛け合わせた8通りの結果が得られるけどそれぞれを
カナ3文字の別の言葉で改造して楽しむのもありかもしれないにょ。

ちなみにおみくじの配列はプログラムを見れば一目瞭然だけど次のようになっているにょ。

　　　[大凶][大吉][中凶][中吉][小凶][小吉][凶][吉]

この中から5つのおみくじが選択可能にょ。（つまり、大吉の左は必ず大凶になる）

1行プログラム「サイコロ」
FOR I=0TO I+1LINPUT A$FOR B=0TO 32B=BTRIG()ACLS:GPUTCHR 99,9,"BGF",RND(6)+49,3,8BEEP B+47NEXT:NEXT
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#13

[A]ボタンで振って、[B]ボタンで止められるにょ。
アナログのすごろくゲームなどで使用するといいにょ。
止める前に[→]を連打することで場の雰囲気を盛り上げる機能も搭載しているにょ。

1438：マリモーマ：2013/01/01(火) 00:10:30
挨拶だけ
あけまして　おめでとうございます　今年もよろしくお願いします

http://liv0.com
1439：御茶目菜子：2013/01/01(火) 11:53:49
レスにょ
マリモーマさんへ
＞あけまして　おめでとうございます　今年もよろしくお願いします

あけましておめでとう！
今年もよろしくにょ！

1440：御茶目菜子：2013/01/02(水) 21:18:10
巳年なのでヘビゲーム特集！？
今年は巳年ということで元旦早々スマイルブーム公式のプチコンtwitterアカウントで
プチコン用のヘビゲームが公開されたにょ。
https://twitter.com/PetitComputer/status/285767777262907392
ヘビゲームは昔からあるジャンルだけど私は最初に入手したポケコンが1行表示のポケコン
だったためヘビゲームには向いてないこともあり、ポケコンで初めてヘビゲームを作ったのは
4行表示に対応したPC-1350を入手してからにょ。（マイコン部の部室にあったPC-8001mkIIで
簡単なヘビゲームは作ったことがあるけど）
どっちかというと私は最初に作ったのが100m走系のゲームだったためそれが私の中では
基本となっているにょ（笑）

プチコンでもヘビゲームを作っている人は多いのではないかと思われるにょ。
ヘビゲーム特集と称して作ったヘビゲームをこれを機会にツイートする人も多いにょ。
https://twitter.com/fusuian/status/286129698231169024
https://twitter.com/fusuian/status/286127944483622913
https://twitter.com/fusuian/status/286126581682929664
https://twitter.com/pman4416/status/286125509346201600
私はまだプチコンではヘビゲームを作ってなかったにょ。
これを機会に何か作ってもいいけど簡単なものならすぐできるけどそれでは面白くない
からね。
1画面プログラムを作るという考えもあったけどすでに1画面で作っている人もいる以上は
少なくともそれに勝てるくらい面白い1画面プログラムを作る必要があるためアイデアを練る
時間やリスト短縮にかかる時間やバランス調整をする時間を考慮したらとても正月中には
完成しそうにないにょ。

そこで私はまだ誰も作ったことがない1行（改行コード抜きで最大99文字）のヘビゲームに
チャレンジしてみることにしたにょ。（数時間〜10数時間かかる1画面プログラムとは異なり
1行なら10分〜1、2時間程度で出来るため）
しかし、1画面（最大29文字x24行）ならば（リストの長さ的に）簡単にできるためゲーム性を
アップできる様々な要素を加えられるのだけど1行で作るとなるといかに最低限の要素に
絞るかが重要になってくるからね。（普通に作ったら1画面に収まりきらないような要素を
リスト短縮などによって1画面に収めるのも1画面プログラムの醍醐味だけど）
何せ普通にキャラを4方向に移動させるだけでも1行に収めることはできないからにょ。
「4方向に動かせないなら2方向にすればいいじゃない」ということで2方向に絞ることに
したにょ。

というわけで、最初に考えたのは[A]ボタンを押せば右に曲がり[B]ボタンをを押せば左に
曲がるというものにょ。
そもそも、（リストの長さの都合上）障害物やアイテムが出せないためこれだとゲームが
簡単すぎるにょ。（それにどうやっても1行にも収まらないし）
そこでさらなる別の移動方法として考えたのが[A]を押せば上移動、[B]を押せばで左移動、
何も押さないと右下に移動という方法にょ。
これならば、上記の2方向移動とは異なり回転をするための変数（Aの値を0、1、2、3として
それが順に上、右、下、左の進行方向を示していた）も不要になるためリスト短縮が可能に
なるからね。

[A]を押せば上移動、[B]を押せばで左移動、何も押さないと右下に移動というのは変数Bに
BUTTON関数の値が入っているときX方向の移動量をVX、Y方向の移動量をVYとすると次の
ようになるにょ。

　《　表1　》
　B= 0 のとき VX= 1、VY= 1
　B=16 のとき VX= 0、VY=-1
　B=32 のとき VX=-1、VY= 0

ここでVX=(B==0)-(B==32)、VY=(B==0)-(B==16)とすればいいというだけの話になるけれど
それでは1行には収まらないにょ。（パターン性のあるものは論理式を使うと大抵無駄が
出来てしまう）
見てのように移動量VX、VYは-1、0、1のいずれかとなるため3で割った時の剰余を計算
すれば良いことが分かるにょ。
そこで、B%3の値を見てみると次のようになるにょ。

　《　表2　》
　B= 0 のとき B%3=0
　B=16 のとき B%3=1
　B=32 のとき B%3=2

これを表1と比較するとVX=1-B%3になっていることに気が付くと思うにょ。
さて、問題はVYの方にょ。
VYの値が表1のものを満たすためにはB=0、B=16、B=32のときの3で割った時の剰余は組み
合わせは（0,1,2）もしくは（2,0,1）である必要性があるからね。（そうすれば「1-○%3」
もしくは「○%3-1」とすることができる）
そこでBに2を足すことにしたにょ。

　《　表3　》
　B= 0 のとき (B+2)%3=2
　B=16 のとき (B+2)%3=0
　B=32 のとき (B+2)%3=1

これで、必要条件を満たすことが可能になり、VY=(B+2)%3-1になったにょ。
このように剰余を使えば上記のように論理式を使うよりも14文字も短縮できたにょ。
論理式は万能的に使えるのだけどこのようにパターン化された操作の場合には剰余などの
他の方法を使った方がリスト短縮においては有利になることが多いにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/list.htm#ronri

これでボタン操作に関しては問題はないのだけどこの式ではB=0、B=16、B=32以外の場合を
考慮しておらず、[A]、[B]ボタン以外を押した場合にも反応してしまうため注意が必要と
なるにょ。
Tipsの「制限付きの左右移動」で書いているようにB%3の値が1と2のボタンであればすべて
同じように認識されてしまうからね。（これは必ずしもデメリットというわけではなく
プチコンスキーのように十字ボタンでの移動とLRボタンでの移動が1つの式で済むという
メリットもある）
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/mod.htm#LR_move

リスト短縮のためにはB%3の値が異なるボタン2つ（B%3=1のボタンとB%3=2のボタン）を
操作用に選択するのがセオリーだけどここであえてB%3の値が同じになるボタンについても
書いておくにょ。
例えばB%3=1になっている[A]（B=16）と[X]（B=64）で操作する場合にはあらかじめB%7と
しておけば[A]は16%7で2になり、[X]は64%7で1になり異なる値を示すためそのボタンを
押した時の判定が可能になるにょ。（VYの方は2を足す必要があるため(B+2)%7%3となる）

あとはゲームオーバーの判定だけどこれは自分の軌跡に当たったら1になり、画面外に
出たら-1になるため0以外の状態になれば終了となるにょ。
これはFOR〜NEXTのループ終了値を論理式「CHKCHR(X,Y)==0」にすればいいのだけど
論理否定で置き換え可能なので!CHKCHR(X,Y)でOKにょ。
これで、何とかギリギリ1行に収めることができたにょ。（実際は画面表示と終了判定は先に
出来ていたので1行に収めることの移動方法を考える方が後になった）
実際にはこれはヘビゲームというよりただの歩け歩けゲームなので広義に言えばヘビゲームと
言えなくはないけど一般的なヘビゲームとは異なるためこれで「1行でヘビゲームができる」
と言って良いのかは微妙だけど1行でも何とかなるというのいうのが分かるのではないかと
思われるにょ。

ということで、これが完成したヘビゲームにょ。

1行プログラム「ヘビゲーム」
CLS:CLEAR:FOR I=0TO!CHKCHR(X,Y)LOCATE X,Y?"蛇":B=BUTTON()X=X-B%3+1Y=Y+(B+2)%3-1S=S+1WAIT 4I=0NEXT:?S
※「蛇」はキャラコード27のヘビキャラを示す

あと「5秒止め」と「シュウォッチ」もついでに作ったにょ。

1行プログラム「5秒止め」
FOR T=0TO 1LINPUT A$FOR B=0TO 32B=BTRIG()T=T+1WAIT 1NEXT:B=T==300BEEP,,-B?T/60,"ﾌ"*!B"ｾｲｺｳ":T=0NEXT

これはバイカウントメルビルさんの「1行5秒止め」のアイデアを元にリトライ機能や
効果音を追加したものにょ。（1行プログラムでリトライ機能を搭載しているものは
プチコン史上初かも）

1行プログラム「シュウォッチ」
CLS:WAIT 60P=0BEEP 3FOR T=1TO 600Z=BTRIG()==16P=P+Z:BEEP,,-Z:CLS?"GO",P:WAIT 1NEXT:BEEP 7?P/10"ﾚﾝｼｬ

これはえいださんの「140シュウォッチ」のアイデアを元に効果音を追加したものにょ。
これら2作品はいずれも元のプログラムのアイデアを参考にしただけでプログラムそのものは
一から作り直しているにょ。
でないと、1行には収まらないしね。

これで、今年作った1行プログラムは2日で6作品となったにょ。
大晦日から数えたら3日で8作品にょ。

　◎新年カウントダウン　2012/12/31
　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#10
　◎カウンター　2012/12/31
　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#11
　◎おみくじ　2013/01/01
　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#12
　◎サイコロ　2013/01/01
　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#13
　◎ビンゴマシーン　2013/01/01
　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#14
　◎ヘビゲーム　2013/01/02
　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#15
　◎5秒止め　2013/01/02
　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#16
　◎シュウォッチ　2013/01/02
　http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#17

このペースならば年間1000作品も可能だけどさすがにそれは無理にょ（笑）
1画面プログラムよりは1作品にかかる時間は短くて済むけど1行に収まるネタには限界が
あるからね。
それに1画面プログラムではある程度余裕があるため操作性やゲーム性を重視して作ることが
可能だけど1行プログラムは1行に収めることにすべてを費やす必要があるため面白いゲームを
作るのは非常に困難にょ。（ラベルスタートのような単機能ツールは1行プログラムのメリット
ともいえるけど）

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

1442：御茶目菜子：2013/01/04(金) 23:49:57
何がダメなのかを把握しないと良いものはできない
昨日作った1行プログラム「SOUND PAD」はボツになった1画面プログラムを元にして作られた
ものと書いたのだけど元になったプログラムがないと比較ができないような気がしたため
そちらも仮公開（＝サイト上で通常公開せずここで公開）することにしたにょ。

1画面版「SOUND PAD」
http://twitpic.com/bsdur7

この1画面版「SOUND PAD」は私が初代プチコンを入手してそれほど経ってない頃に作った
ものであり、時系列的に言えば初代PETIT KEYBOARDを公開して直後に作ったものにょ。

PETIT KEYBOARD
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#kb

このPETIT KEYBOARDはポケコン（PC-E500）用で作った1行プログラム「1LINEオルガン」が
ベース（というかベタ移植）となっているにょ。
ポケコンでは1行には行番号を除き最大252文字入れることができるのだけどプチコンでは
1行には改行を除き99文字しか入らないし1画面プログラムではエディタの折り返し機能が
ない関係上1行には29文字しか入れることはできないにょ。
そのため元が1行プログラムなのに移植では11行まで膨らんでいるにょ。

この「PETIT KEYBOARD」はポケコン用の「1LINEオルガン」を移植しただけであり機能は
ほとんど無く非常にシンプルなものとなっているのだけどポケコン用には1LINEオルガン
ではなくサイト上では「2LINEオルガン」の方を公開しているにょ。

2LINEオルガン
http://ww5.tiki.ne.jp/~ochame/E500/SOFT/SHORTP.HTM#ORGAN

この2LINE版（2行版）には1行版には無かったリプレイ機能を搭載しているにょ。
要するに録音再生機能を備えているということにょ。
1画面にはこちらも十分に収まりそうだけどなぜこちらを移植しなかったのかと単に当時の
技術では実現できなかったというだけにょ。
それはGRPにデータを記録する方法を知らなかったためにょ。
録音機能がないなら鍵盤をグラフィック表示してやればいいのだけどそれも難しいにょ。
したがって、消去法でポケコンの1LINEオルガンのベタ移植となったにょ。
まぁちゃんとした鍵盤表示による1画面プログラムはそれから約1年後（昨年10月）にようやく
PETIT KEYBOARD mkIIで実現したにょ。

「1画面のサイズで鍵盤が表示できないならば鍵盤を表示しなくても済むようなものを作れば
いいじゃない」ということで作られたのが1画面版「SOUND PAD」にょ。
単なるポケコンプログラムのベタ移植のPETIT KEYBOARDとは異なり、プチコンのBEEP命令は
音色や音量も簡単に変えられるためそれを操作に盛り込むことにしたにょ。
それで一応は完成したものの下記のような理由で公開は踏みとどまったにょ。

　(1)　[A][B][X][Y][R]の同時押しが困難
　(2)　右利きだと[A][B][X][Y][R]ボタンを押しながらタッチペン操作しにくい
　(3)　ドラムなどの打楽器の音がうまく表現できない

(1)タッチパネルが使えるため音量と音程は二次元的に操作は可能だけど問題となったのは
音色の変更にょ。
プチコンでは（初代でも）70種類の豊富な音色をサポートしているもののそれをいちいち選択
するのが面倒だからね。
使いたい音色は有る程度限られるだろうからそれをボタンに設定して使えるようにしたら
使い勝手がかなり良くなりそうと考えたにょ。

それで十字ボタンで音色を選択して[L]ボタンを押しながら[A][B][X][Y][R]を押すことで
各ボタンにその音色を登録できるとい機能を搭載したにょ。
十字ボタンと違って[A][B][X][Y}[R]は独立動作するため同時押しによって2の5乗＝32通りの
音色を登録可能になるにょ。
とはいえ、実際に作ってみるとその考えは甘かったにょ。
というのも「同時押し」での登録は1フレーム（1/60秒）でもずれたらアウトだからにょ。
一旦登録したものを読み出す場合はゆっくり1つずつボタンを押せばいいのだけど登録は押した
時点で行われるため[A][B][X][Y]を順番に1つずつ押した場合には[A]ボタン（16）、[A]＋[B]
ボタン（48）、[A]＋[B]＋[X]ボタン（112）、[A]＋[B]＋[X]＋[Y]ボタン（240）に全部同じ
音色が登録されてしまうにょ。
そうなると事実上同時押しは使いものにならないので実質5つしか登録できないにょ。
それだと8通りの登録ができる十字ボタンを使った方がマシとなってしまうにょ。
もっとも32個の音色を設定できても設定ファイルのセーブ機能がないためRUNするごとに設定
しなおす必要があるため実用的とはいえないにょ。

これは棒歌ロイドキーボード（タッチパネルでフリック入力を行うバージョン）を作る際に
[A][B][X][Y][L][R]の同時押しによって音階を表現するという案が出てきたときにも問題と
なったにょ。
しかし、それは遅延時間を設けるという方法によって改善することができたにょ。
1フレームのずれも無く複数ボタンの同時押しをするのは困難だけど最初の1つ目のボタンを
押してから数フレームの猶予があれば複数ボタンの同時押しは飛躍的に簡単になるからね。
もっとっも、その方法は1画面というリストサイズ制約がないからこそ可能な方法であって
このような1画面プログラムの場合は実現が難しいにょ。（元がシンプルなのに1画面で
収まらないならば作る価値がほとんど無くなってしまう）

(2)これは[A][B][X][Y][R]ボタンを右手で操作すると必然的に左手でタッチペンを操作する
ようになってしまうためにょ。
左利きならば何の問題もないけど右利きだとこれでは使いづらいにょ。
ボタン操作ならば左右どちらの手でもできるけどペンの微妙な操作は利き腕でないと難しい
からね。（これは単なる慣れの問題だけど慣れないと使いづらいものは使いやすいとは
言えない）

これは後日作った棒歌ロイドキーボードの1画面版でも問題となったにょ。
タッチペンで文字を入力してその音階の音声を出すことでリアルタイムに歌わせることが
可能なこのプログラムはその性質上音階指定は十字ボタンを使う必要になったにょ。

(3)これは0番のような単純なBEEP音ならば問題ないのだけどタッチしている間ずっと音が
鳴り続けるため叩いた瞬間のみ音が鳴る打楽器は表現できないし、自然減衰するピアノの
ような音も上手く表現できないにょ。
それならば押した瞬間のみ音が出るようにするのがいいかというとそうでもないにょ。
これが鍵盤演奏ならばそういう手段も執れるけどせっかく「鍵盤」というしがらみがない
ものとなっているのに鍵盤演奏みたいなことをすると単に音階演奏しにくいというだけの
プログラムになってしまうからね。
したがって、考えられる方法は音色によって「押した瞬間のみ鳴るもの」「押している間
ずっと鳴り続けるもの」などあらかじめ登録しておく必要があるということにょ。
これが音色を固定でユーザーがプログラムを書き換えて使用するようなものならばそれに
合わせて設定してもらえばいいだけのことだけどプログラム実行中に音色を自由に変更
可能ならばその設定もそれに追従して自動的に変更するようにすべきにょ。
とはいえ、それをすべての音色に対してデータとして用意するのも面倒だし、1画面に
収めるのも難しくなってしまうにょ。


というわけで、（1）〜（3）の問題点が残されており改善するための良い方法が（少なく
とも1画面に収まる範囲内では）見あたらなかったためそのままお蔵入りとなって別の
ゲーム（ピョン子）を作り始めたにょ。
では、昨日作った1行版「SOUND PAD」はどうなのかというと(1)の問題はプリセットの音
のみを使用することで改善できたにょ。
プリセットのみだと最大32種類の音色しか鳴らせないものの数値を変えながら一番良いと
思えるようなものにしたのでそれほど問題はないにょ。

(2)の問題は持ち方そのものを変えることで克服したにょ。
「[A][B][X][Y]ボタンは右手で操作するもの」という固定観念を捨てて「左手で[A][B]
[X][Y]ボタンを操作するにはどのような持ち方にすべきか」ということから新しい本体の
持ち方が生まれたにょ。
これは非常に簡単なことで、まずはDS本体を[A][B][X][Y]ボタンの方が下になるように
縦位置に左手でつかむように持ってそのつかんだ状態で[R]ボタンに左手の親指が来る
ようにポジション調整するだけにょ。
これによって、右手がフリーになるのでタッチペン操作は簡単にできるにょ。

(3)の問題はWAIT 1ではなくWAIT 4にすることで解決したにょ。
といっても、WAIT 4にしたのは元々それが狙いではないにょ。
1画面版ではタッチしたときのみBEEP命令を実行しているのに対して1行版はリスト短縮の
都合上、常にBEEP命令を実行する必要があるためタッチしてない時は無音のBEEP命令を
実行しているにょ。
昨日も書いたようにBEEP命令では同時発音数は最大で8音となっているためこれでは
最大でも8フレームで音が途切れてしまうにょ。
BEEPで鳴る音は音長調整ができないもののほとんどの音は8フレーム以上鳴るため事実上
スタッカートがかかった状態でしか鳴らすことができなくなったにょ。
これが、WAIT 4ならば32フレームとなるため多くの音は問題なく使用できるにょ。
そして、その代償として素早くタッチして離したら反応できないという問題があるものの
鳴った瞬間に離せば1音だけ鳴らすということも可能になるためドラムなどの打楽器も
普通に演奏が可能になったにょ。（私の場合はWAIT 3だとすぐに離しても連続して鳴る
ことが多いためWAIT 4にした）
実際に[B]＋[Y]で太鼓の音を鳴らしてみて判断してみるといいにょ。

「問題点が改善されている」というのには微妙な部分も多いけど1画面で作ったものを
1行ですべての面において良いものにするというのが無理な話であり有る程度は妥協が
必要になるにょ。
1行版の唯一の問題は1画面版では明確だったホームポジション（C4）の位置が分かり
にくいということくらいにょ。（これはコンソール文字を一度に表示している関係上
やむを得ないことであり、これを改善するにはループ内でPNLSTR命令をもう1つ追加
する必要がある）
これは実行動画で見ても明らかなようにホームポジションの迷いが見られるにょ（笑）
まぁインチキ臭い方法だけど実行モードで「GPAGE 1GFILL 122,0,124,191,2」と
あらかじめ実行するという方法もあるけどね。（とはいえ、これが許されるならば
あらかじめGLINEで線を32本引いておけばさらにリスト短縮可能になってしまうけど）


あと本日公式サイトから新作キャラ素材が公開されたにょ。
プロ生ちゃんこと暮井慧さんが作ったキャラにょ。
http://smileboom.com/special/ptcm2/co_present/html_present06.php
待望の人型女性キャラにょ。
すでに女性設定のキャラとしてはダミーちゃんがいたけどあくまでAIキャラであり人型でも
ないからね。
というわけで、早速この素材を使ったゲーム「プロ生ちゃん100m走」を作ってみたにょ。

「プロ生ちゃん100m走」
http://www.youtube.com/watch?v=zB1WM-znAu0　（プレイ動画）
http://ww5.tiki.ne.jp/~ochame/petitcom/qr/pronama100m.png　（QRコード）

用意されているのが走っている動作ということで、手っ取り早く公開できるものを作るため
「プチコン100m走mkII」のデータ差し替えバージョンにしたにょ。（さすがにこのサイズ
だと2倍拡大しなくても十分使えるのもうれしい）

「プチコン100m走mkII」
http://ww5.tiki.ne.jp/~ochame/petitcom/petit_olympic.htm#100m

単にデータを変えるだけではつまらないので音声も加えてあと用意されているすべての
モーションを使ってみたにょ。
立ちポーズはスタート前で使用できたけどダメージポーズは何にしようかと思っていたら
走っていてこけたという設定にすれば問題ないとすぐに思いついたにょ。
[A][B]ボタンを連射することで走るのだけど「[A][B]ボタンを同時に押したらこける」
という新要素を追加によってゲーム性は変わったにょ。
1回こけたら最低でも0.4秒、平均でも1秒以上タイムロスをしてしまうのでこけないように
走るという操作が求められるからね。
つまり、[A][B]を何かでひたすらこすってはこけまくるためきちんと交互に押すという
必要性が増すことになったということにょ。

新規に作るならば最低でも2〜3時間、ある程度の完成度を高めるためには10〜20時間
欲しいところだけどこの程度の仕様変更であるためコーディングは非常に簡単だったにょ。
コーディングにかかった時間は30分程度だし、あとはテストプレイやデバッグなどを
込みで完成まで約1時間といったところにょ。（作り始めてから動画撮影してtwitterで
公開するまでの時間をすべて合わせてもわずか1時間20分程度）
ちなみにこけたキャラの切り替えはSPCHRは使用せず別のキャラとして用意しているにょ。
ミスフラグを設定しているためそれが立っているときのみそのこけたキャラを画面上に
表示して、フラグが立ってないときは画面外に表示しているにょ。（通常の走っている
キャラはその逆）
こうすることで、キャラを変えて元に戻すという処理が不要になるためコーディング量が
少なくて済むにょ。（ポピュラーなテクニックなので使用している人は多いと思う）
ミスフラグは立った後に一定時間後に自動消滅するのでこけたキャラはフラグが立った
時に自動的に表示されてフラグが消滅したら自動的に元の走っているキャラに戻ることに
なるにょ。
速度面ではわずかに不利になるもののそれでもこのゲームは60fpsで動作しているため
問題ないにょ。（背景のスクロールはプチコン100m走と同様にGCOPYでスクロールさせて
いるけどそれでも速度面で全く問題がない）

1443：op：2013/01/05(土) 11:16:03
qrコード載せて
プチコンまとめwikiに
Petitcom OS
を載せて。

http://www.youtude.com/watch?v=_zzCVJQwKsY

1444：御茶目菜子：2013/01/05(土) 22:59:04
レスにょ
opさんへ
＞プチコンまとめwikiに
＞putccon_os
＞を載せて

OSもどきが流行っていたので適当に何か作ってみようと作りながら仕様をあれこれ考えた
ためプログラムもぐちゃぐちゃだし、アプリの仕様もまだ決まってない（これを作ったあと
下記の「プチコンでマルチタスクOS PART2」に書いたような多数の問題点が発覚した）
ため現状では横スクロールゲームの「CAVE」しかプレイできないにょ。
したがって、私の「公開できる基準」には達してないため現状で公開予定は全くないにょ。

一晩で暫定的な仕様の策定ととりあえず動くレベルのものを作ったためアプリを追加
しやすいような仕様にはなってないため事実上CAVE専用といってもいい状態にょ（笑）
CAVEをプレイするならばこちらのCAVE単体の方がいいにょ。
マルチタスクに対応可能といってもこの小さい画面のCAVE単体でも30〜40fps程度しか
出てないため実質マルチタスクは使い物にならないと思うし（と書いたけど動画を撮影
してから少しだけ改良を加えたため昨年6月28日のログを見るとCAVE動作時で73fps、
デスクトップ表示時は790fpsになっている）
http://ww5.tiki.ne.jp/~ochame/petitcom/p007.htm#cave

そもそも、構想だけはいろいろあってもまだほとんどの機能を実装してないしね。
このPetitcom OS（仮称）を作るにあたってどのような構想を掲げてどのような機能を
どうやって実装していくかという予定については下記に書いているのでそれを見てもらうと
いいにょ。（といっても単にネタで作っただけだから私の気が変わらない限りは今後進展
することはないと思うけど）

　プチコンでマルチタスクOSを作る
　http://6407.teacup.com/ochame/bbs/3335
　プチコンでマルチタスクOS PART2
　http://6407.teacup.com/ochame/bbs/3357

動画に映っている範囲内のことで何か聞きたいことがあればそれに対しての質問ならば
回答できるので遠慮無く言ってにょ。

1445：御茶目菜子：2013/01/05(土) 23:08:27
今年買いたいデジタル機器2013
昨年1月3日に「私が2012年に買いたいデジタル機器」について書いたのだけどそれが昨年の
1年間でどの程度達成できたのかを見てみるにょ。

　○デュアルコアCPU搭載モバイルノートPC　→　達成できず
　○ミラーレスカメラ　→　達成できず
　○デジタル一眼レフカメラ（中級機）　→　達成できず
　○スマートフォン　→　達成できず

というわけで、昨年の結果は見事に達成率0％にょ。
これは、予算的な問題もあるためやむを得ないけどさすがに悲しいにょ。
昨年の12月31日に書いたように昨年1年間で購入した1万円以上のデジタル機器はコンデジ
（WX100）1台だけだしね。
しかし、今年もあきらめずにまた購入候補のものを挙げてみるにょ。

　(1)デュアルコアCPU搭載モバイルノートPC
　(2)ミラーレスカメラ
　(3)デジタル一眼レフカメラ（中級機）
　(4)スマートフォン
　(5)7インチクラスのタブレット端末
　(6)自作PCの組み替え

(1)現在使っているLet'snote R5（CoreSolo 1.2GHz）は4年前に中古で買ったものにょ。
買った当時はそこそこ快適だったけど今となってはCPUもメモリ（MAX1.5GB）もかなり
厳しくなっているにょ。
個人的にはUltrabookレベルの性能があれば全く問題ないと感じるのだけどUltrabookは
薄型に拘っていてフットプリントの小さいものが選べないというのが難点にょ。
R5はB5用紙サイズより小さい（週刊少年ジャンプよりも小さい）ものとなっているの
だけどUltrabookの多くは13.3インチ液晶を搭載であり、筐体のフットプリントサイズは
A4用紙サイズよりも大きいからね。
小さめの11.6インチ液晶搭載機でさえA4用紙サイズ並であるためR5からの買い換えだと
かなり大きくなってしまうのがネックにょ。

筐体サイズで考えるならば現行で新品が入手可能なものといえばLet'snote Jシリーズが
許容限界となっており、筐体サイズを重視するならば中古のRシリーズしかないにょ。
ここで問題なのが予算にょ。
R9はRシリーズ最終モデルであるため後継となっているJシリーズよりも割高になっている
からね。
その点、R8ならば手が届く範囲内だけどスペック的にやはり厳しいにょ。
R7以前はいくら安くてもSO-DIMMではなくmicro-DIMMであるためメモリ搭載量の面で厳しい
わけだし、GPUもHD動画の再生支援機能がないため低クロックのULV CPUではフルHD動画を
再生するのはかなり厳しいにょ。
やはり、最低でもR8H（R8最終モデル）くらいの性能は欲しいところにょ。
R8HだとデフォでWin7が入っているし、メモリもDDR2であり、今となっては割高（とっても
2GBのSO-DIMMは手元にあるため問題ない）であるものの最大で3GB搭載可能だからね。

(2)私は普段コンデジ（WX100）を持ちあるいているけどやはり画質面では全く満足する
ことはできないにょ。
コンデジは「小さい」ということで常に持ち歩けるというメリットがあるものの単純に
画質面でいえば昨今の高画質化が進んでいるスマホ用内蔵のカメラとそれほど大きな差は
ないにょ。（さすがに高級コンデジならば十分差別化できるくらいの差はあるけど）
現状で私が使っているのは905SHという7年前のガラケーであるためWX100の画質はそれを
上回っているものの気軽に持ち運びができるレベルのサイズで画質面で納得できるものが
欲しいところにょ。

サイズと価格とレンズラインナップを考えるとマイクロフォーサーズがベターなんだけど
従来は高感度に弱いというのがネックだったにょ。
しかし、最新のE-PL5とE-PM2ではソニー製センサーを使用していると見られ高感度画質は
従来よりかなり向上したにょ。
高感度画質重視でいくならばNEXシリーズが一番にょ。
型落ちモデルならば安価で入手可能だし、レンズも徐々に増えつつあるからね。
Nikon 1はJ1、V1は微妙に感じたけどV2はかなり魅力的なものに生まれ変わったし、もうすぐ
J3とその下位モデルであるSシリーズ（？）の登場のウワサがあるにょ。
J1ならば近所のキタムラでレンズキットが22800円という破格値で売られていたのだけど
どうもJ1、V1は（1インチということで高感度画質で他のミラーレスに劣るのはやむを
得ないとはいえ）解像力にも不満があるためJ1が安くても食指が動かないにょ。
携帯性重視ならば同じ1インチのRX100の方が魅力に感じるけど5万円近い価格であるため
予算を捻出するのは厳しいにょ。

(3)私の現在メインで使っているデジタル一眼のPENTAX K200Dは2008年発売の機種であり
サブで使っているNikon D50は2005年に発売の機種にょ。
画質面はD50の方は今となっては厳しいけどK200Dの方は好条件下でうまく撮影できれば
最新の機種と比べてそれほど大きな差はないにょ。
とはいえ、ISO800が許容限界であり、ISO1600は非常用レベルに感じるくらい高感度画質は
低いにょ。
XGAくらいにリサイズした場合だとコンデジのWX100の方が上に感じるレベルだからね。
また、ファインダーもペンタミラーということであまり見え方が良くない（ボケ量が
ファインダーであまり分からない）というのもあるし、今時動画が撮影できないどころか
ライブビュー撮影さえできないのには不満があるにょ。（花火撮影など三脚を使って
撮影する場合にはライブビューの搭載機がうらやましく感じる）
私は動体撮影はあまりしないけどする場合には所持している両機ともに3コマ/秒程度の
連写速度であり、バッファサイズも小さいためろくに連写ができないというのはネックと
なるにょ。

というわけで、最近の機種ならば入門機レベルでもファインダー以外は十分に満足でき
そうな気もするけどやはり買うならば中級機レベルが欲しいにょ。
いや、予算が潤沢にあればフルサイズに行きたいところだけどフルサイズはボディが
高価というだけではなくレンズも高価になってしまうためいくら本体が型落ちで安く
なっても気軽に買うことはできないにょ。（もっとも型落ちでも10万円台であるため
そんなに安くはなってないけどね）
ペンタックスならばK5IIsが欲しいところにょ。
ニコンならばウワサのあるD7000の後継機が欲しいところにょ。
まぁ新モデルが出たあとに価格が下がった現行機を買うというのもありだけどね。
というか、恐らく予算的に10万円以上もするようなものは買うことは無理なので最初
から型落ち狙いにょ（笑）

(4)上記のように現在使っているのは7年前に発売されたガラケーにょ。
通話だけならばこれで問題ないし、当時最先端だったワンセグ機能もついているにょ。
今は使えなくなったけどアナログTVとワンセグの両方を搭載していてさらに録画機能も
搭載しているのはすべてのケータイの中で唯一この機種だけだと思われるにょ。
といっても、Webやメールに関しては不満が多いにょ。
Webはフルブラウザを使ってもまともに見れないサイトが多いしね。
メールは文字入力はケータイ方式はあまり好きではないためどうしてもケータイでの
メールはどうしても必要な時しか使ってないという状態にょ。

それらは昔はPDAでカバーしてきたにょ。
VAIO UXを購入してそれで一応ポケットに入るWindows PCということでPDAの代わりに
なるかと思ったけど実際はバッテリ駆動時間や起動時間の面でPDAの代わりにはならな
かったにょ。
そして、現在使っているiPod touchだけどモバイルルータと合わせることでようやく
それなりに使える環境になったにょ。
というか、iPod touch＋モバイルルータがあればスマホは必要ないような気もするけど
従来スマホを使うとスマホのパケット定額＋モバイルルータのパケット定額ということで
多くの通信料金が必要だったことが購入への足かせとなっていたにょ。（ケータイも
パケット定額に入っているもののこちらは常時下限で収まっているけどスマホだと
そういうわけにはいかないため）
しかし、スマホでテザリングが出来るならばモバイルルータを解約してスマホ1本に
絞ることができるからね。

(5)モバイルノートやスマホがあってさらにタブレット端末を使うことがあるのかという
人もいるかもしれないけどスマホとタブレット端末はサイズ面の違いがあるため操作や
閲覧性での差があるし、PCとタブレット端末は全くの別ものにょ。
タブレット端末はビューア目的で使うならば非常に優れていると思われるにょ。
その中でもやはり電子書籍用途に適しているにょ。
スマホだと画面が小さいし、PCだと電子書籍は読みにくいからね。

(6)自作PCも前回組んでから今年で5年経つにょ。
従来ならば2〜3年間隔で組み替えてきたためここまで間隔が開いたことはないにょ。
最初に自作PCを組んだのは2001年でその時のスペックはコストパフォーマンス重視で
セレロン800MHz、HDD40GB、メモリ256MB、GPUはGeForce2MX400だったにょ。
それからメモリを512MB、HDDを80GBに換装（元々あった40GBのものはDドライブとして使用）
したもののそれでもスペック的に厳しくなったので2003年にマザーボードはそのままで
CPUとGPUのみ交換することにしたにょ。
CPUをセレロン1.4GHz、GeForce4Tiに変えることでCPU性能は約2倍、GPU性能は約5倍に
跳ね上がったにょ。（これでCPU6000円、GPUが約1万だったのでコストパフォーマンスは
非常に良かった）

それでも、厳しくなったため2005年にマザーボードごと一新することにしたにょ。
当時はIntelよりもAMDの方がスペック面で優れていたためCPUはAthlon64 3500+（2.2GHz）
GPUはGeForce 6800GTを選択したにょ。（下位モデルながら6800GTにベンチ性能で
上回る6800GSが登場によってハイエンドな6800GTが在庫処分価格となっていてスペックの
割に安価だった）
メモリも当時は高価だったDDRだけど2GB搭載したので重い作業も余裕でこなせたにょ。
これで最新3Dゲームも不満なく遊べるようになったのだけどやっぱりシングルコアだと
厳しいし、エンコをする時にもデュアルコアCPUの方がいいということで2008年には再び
組み替えることにしたにょ。（実際は、マザーボードの故障でPCが起動不可になったと
いうのが最大の理由だけど）

2008年には当時最新だったPenrynコアのCore2Duo E8400（3GHz）、GPUはハイエンドに
位置していたGeForce 9800GTX並の性能で2万円程度という安さのRADEON HD4850を選択
したにょ。
メモリは当面XPでの利用を考えていたため4GBに抑えたにょ。
電源から一式丸々交換した（マザーボードの故障が電源が理由である可能性もある）
ため約10万円かかったけれど実際の性能面や使用感では十分に満足できたにょ。
本来ならばそれから5年経っているわけだからとっくに組み替えていてもおかしくない
のにそれからそのままにょ。

それはなぜかというと最近はPCでゲームやエンコといった重い処理はあまりしないという
のが理由にょ。
しかし、画像加工などでメモリを増やしてメモリを8〜16GB搭載したいところにょ。
現在使用しているマザーボードも最高で16GBまで対応しているもののDDR2で16GBとなると
メモリが非常に割高となるにょ。
地元だと16GB買えば2万円以上の価格になってしまうためそれだけの予算があるならば
新しくマザーボードを買った上で16GBのDDR3メモリを買うことができてしまうにょ。
まぁそれでもCPUは別途必要であるため最低でもあと1〜2万は必要になってしまうけどね。
というわけで、今のところ予算面の問題があるので現状のをそのまま使って優先順位の
高いものに予算を回すことになるにょ。


こんな感じで6品目を挙げてみたけどほとんどは急を要しているというものではないため
なかなか購入には至らないのではないと思うにょ。
物欲があっても先立つものがないわけだしね（笑）
その中でも強いて挙げるならばやっぱり一番辛いのは(1)にょ。
さすがにスペック面の問題だけではなく経年劣化や故障の問題もあるからね。
急な故障の際には旧モデルのR3が手元にあるためそれが登場することになるけど今と
なってはメモリMAX768MBではかなり厳しいためあくまで応急手段程度でしかなく早期購入が
求められてしまうにょ。
それにバッテリが劣化して厳しい状態だけどバッテリも新品を買えば2万円以上するわけだし
安価な互換バッテリでも1万円以上するため今更このPCのためにバッテリを買うのも躊躇
してしまうにょ。

1446：御茶目菜子：2013/01/08(火) 23:59:58
NVIDIAがTegra4を発表
NVIDIAがTegra4を発表したにょ。
http://pc.watch.impress.co.jp/docs/news/event/20130108_580835.html
クアッドコアのCortex-A15に72コアのGeForceコアを搭載して従来（Tegra3）比で6倍のGPU
性能となっているにょ。
PC向けのCPUは90年代にはクロックの大幅な向上によって性能向上がもたらされ、2000年台に
入ってからはリーク電流問題によってクロックの伸びが鈍化したためアーキテクチャの改良や
マルチコアによって性能向上がもたらされたにょ。
そのマルチコアも45nmのPenrynの時点でハイエンドがクアッドコア、ミドルがデュアルコア
だったのが現時点の22nmのIvyBridgeでは依然としてコンシューマ向けではクアッドコアが
メインとなっているにょ。
これは、PC向けのCPUとしては現在の4コア、8スレッドで十分であり、それ以上コア数を
増やしてもアムダールの法則によって性能を十分に発揮できないためと思われるにょ。
したがって、これからはより省電力な方向にシフトしていくにょ。

モバイル向けのCPUはPC向けの後追いをするようにここ数年で急速な性能向上となっているにょ。
性能上昇率ではPC用のものを遙かに凌いでいるのだけどこれはPCに近い体験を行えるように
するためには必要不可欠だからにょ。
ネットの利用1つをとっても昨今はWebサイトが動的になっており非常に重くなっているため
PenMクラスでさえ厳しくなってきているにょ。
そして、画面解像度の高解像度化が性能上昇を必要不可欠なものにしているにょ。
iPadがRetina液晶搭載の第3世代でGPU性能を上げて第4世代ではさらにそれを上げたのは
高解像度化による体感速度を低下を防ぐためにょ。
単純に考えれば画面のピクセル数が4倍（縦横2倍）になれば性能は4倍になってようやく
プラマイゼロだからね。（PC向けのAPUでもこの考えはあり、IvyBridgeでは内蔵GPUはフルHDを
越える2560x1600までサポートしているためSandyBridgeより大幅にGPU性能を上げているけど
今年の第2四半期に登場が予定されているHaswellではそれをさらに大幅に上回るものなると
予想されている）
Tegra4でGPU性能を大幅に上げたのはタブレット端末においては今後はフルHD以上の解像度の
機種が主流になっていくという考えによるものだと思われるにょ。
何せ動画再生も4Kに対応しているくらいだしね。

ただし、その際に問題となるのがメモリ帯域にょ。
ピクセル数が4倍になればこの帯域が4倍にならないとボトルネックになってしまうからね。
このモバイル端末向けのDRAMの帯域はここ数年で劇的に進化したにょ。
http://pc.watch.impress.co.jp/docs/column/kaigai/20130108_580768.html
PCはノートPCにおいてはWXGAがメインであり、デスクトップPCもようやくフルHDがメインと
なった感じなので単純にピクセル数で言えばハイエンドなタブレット端末は一般的なPCを
完全に凌駕している感じであり、メモリ帯域もそれ相応なものが求められてくるにょ。
ノートPCもつい数年前まではDDR2-667（理論帯域5.3GB/s）が主流だった（実際にネット
ブックではシングルchで使用されていたけど解像度が低いこともあり、メモリ帯域不足が
問題になることはなかった）のに今やモバイル端末でもその2倍が当たり前だからね。


さて、この度NVIDIAはこのTegra4を搭載した携帯ゲーム機「SHIELD」も発表したにょ。
http://pc.watch.impress.co.jp/docs/column/ubiq/20130108_580839.html
実際は純粋なゲーム機というよりもゲームに特化したAndroid端末であり、Google Playを
利用することでアプリを使用することができるということでハードメーカーがあってその
ライセンスを受けることでサードパーティが対応のソフトをリリースするという一般的な
コンシューマゲーム機とは少々異なっているにょ。
一般的なコンシューマゲーム機はそういうビジネスモデルを採用している関係上、ハードは
製造原価を下回るいわゆる「逆ざや」で提供することも可能になっているのだけどこの
「SHIELD」ではそういうわけにはいかないにょ。
つまり、一般的な高性能Android端末と同レベルの価格帯になると予想されるにょ。
したがって、スペックなどを考えるとPS Vitaよりもさらに高価になると予想できるにょ。

では、ただのゲームがプレイしやすい高性能なAndroid端末というだけではなく仮想化技術
NVIDIA GRIDを使用したクラウドゲーミングやGeForce Experienceを利用してGeForce搭載の
PCで動作しているゲームをこのSHIED上でプレイ可能になるというものにょ。
これはかいつまんでいうとWii Uが本体でレンダリングしたものをTVを使用することなく
専用のコントローラでプレイできるというのと同じようなものにょ。
その際には遅延が発生するのだけどWii Uは専用化によってその遅延をほぼゼロにしたの
だけどSHIED上でそこまでの遅延問題を克服できるのかが問題にょ。
これはサーバ上でレンダリングをするクラウドゲーミングではさらに遅延は拡大することに
なるため非常にシビアとなるにょ。
クラウドゲーミングについては昨年12月29日に書いたように次世代のプレステ3後継機（PS4）
にも採用が予想されているのだけどまだまだ問題点が多いにょ。
将来的にはビジネスモデルとして確立されるのは間違いないけど現時点では初期投資コストの
大きさや回線や遅延の問題を考えると普及には時間がかかりそうにょ。

1447：御茶目菜子：2013/01/09(水) 23:52:58
Nikon 1はJ3、S1の追加でラインナップが完成か
ニコンが「Nikon 1 J3」と「Nikon 1 S1」を発表したにょ。
http://dc.watch.impress.co.jp/docs/news/20130108_580848.html
http://dc.watch.impress.co.jp/docs/news/20130108_580874.html
J3はJ2の後継モデルであり、S1はJ3の下位モデルとなっているにょ。

　　　　　　　　　　　J3　　　　　　　　　S1　　　　　　　　　J2 （参考）
センサーサイズ　　　1インチ　　　　　　 1インチ　　　　　　 1インチ
画素数　　　　　　　1425万画素　　　　　1011万画素　　　　　1015万画素
ISO感度　　　　　　 160-6400　　　　　　100-6400　　　　　　100-6400（拡張）
液晶モニタ　　　　　3インチ92万ドット　 3インチ46万ドット　 3インチ92万ドット
連写速度（AF追従）　15コマ/秒　　　　　 15コマ/秒　　　　　 10コマ/秒
サイズ　　　　　　　101x60.5x28.8mm　　 102x60.5x29.7mm　　 106x61x29.8mm
重量（バッテリ込み）244g　　　　　　　　240g　　　　　　　　237g

さて、新しいモデルの投入はいいのだけど3ヶ月前にJ2を発売したばかりということもあって
J3の発表は登場間隔が短すぎるという声もあるにょ。
しかし、J2は外観はJ1と同一であり、液晶モニタの高解像度化と撮影モードの追加程度の
完全なマイナーチェンジにすぎなかったにょ。
というわけで、このJ3こそがようやく後継機種といってもいい感じにょ。

J3がJ2と変化があるとすればセンサー部分だと思われるにょ。
画素数は先日発売されたV2と同じであり、恐らく同じセンサーが搭載されているものと
思われるにょ。
画素数の増加が画質に必ずしもプラスの影響を与えるとはいえず、センサーサイズが小さい
機種の場合はマイナスになる場合もあるにょ。
例えば昨今のコンデジは普及クラスのもので1600〜1800万画素に達しているけどセンサーの
画素ピッチを考えるとまともにその画素数で解像できるレンズを搭載しているなんてことは
ありえず、実際に私も1800万画素のWX100で様々な被写体を撮影してみたところ500万画素
クラスの旧世代のコンデジと解像感は変わらなかったからね。（被写体によっては旧世代の
500万画素機よりも劣っているレベル）
1インチというセンサーサイズで1000万画素から1400万画素への増加はフルサイズ換算だと
7400万画素から1億画素へと増えたのとほぼ同じことにょ。
したがって、解像感が必ずしもプラスになっているとは言い難いのだけどV2はローパス
フィルタを省くことによって解像感をアップさせているみたいなので恐らくこのJ3も同じ
だと思われるにょ。

ローパスフィルタはレンズの解像力がセンサーの画素ピッチより大きい場合にはモアレの
原因となるためベイヤー配列センサーでは必要なもの（とはいえ、ある程度は画像処理
エンジンによって軽減できる）とはいえ、その影響は被写体にもよるためニコンはD800E
においてはフルサイズなのにローパスレス（実際はローパスフィルターを装着しているの
だけど姉妹機であるD800とフランジバックが変わらないようにローパスフィルターを単に
無効化しているだけ）となっているくらいにょ。
ペンタックスにおいてもK-5IIｓにてローパスレスを実現しているにょ。
このような状況下であるため「ローパスレス＝高解像感」という認識が強まっているのだけど
これはレンズの解像力がセンサーの画素ピッチを上回っている場合のみに言えることであり
レンズの解像力がセンサーの画素ピッチを下回っている場合にはローパスフィルタを付ける
本来の意味もなくなるため現在発売されているコンデジはすべてローパスレスになっている
と思われるにょ。（「ローパスレス＝高解像感」ならば「コンデジ＝高解像感」になって
しまう）
1インチセンサーで1400万画素で解像するかは微妙なラインだけど実際にV2の撮影サンプルを
見る限りでは解像感は上がっているため「プラスに働いている」といってもいいのではないか
と思われるにょ。

Nikon 1といえば初代のJ1/V1の段階で像面位相差検出方式によるAFを実現しているというのが
他のミラーレスと比べると強味になっているにょ。
それはV2ではさらに強化されたにょ。
AF速度の向上によってAF追従15コマ/秒というプロ機顔負けの速度になっているからね。（とは
いえ、この数字だけでプロ機を越えるAF性能なんてことは言えないけど）
その強化されたAFはJ3にも搭載されているにょ。
あと筐体も1周り小型化されCXフォーマット（1インチ）以上のセンサーを搭載したレンズ
交換式カメラで世界最小を謳っているにょ。
V2がモデルチェンジで中級者以上やデジタル一眼のサブ機用という認識が強くなり、Nikon 1
シリーズが掲げてきた「コンデジでは物足りない層」の中でのライト層とは若干客層が合わ
なくなってきたためJ3がNikon 1の中核モデルとなりそうにょ。


ここで問題となるのがS1の存在にょ。
V2と同じ新世代のセンサーを搭載のJ3と比べると恐らくV1/J1/J2の旧世代のものを流用して
いると思われるのだけどそれだけではなく上部のダイヤルも省略されるなどの大胆なコスト
ダウンが見られるにょ。
ミラーレスをほぼフルオート専用として割り切って使うユーザー向けだと思われるにょ。
それならばJ3を発売後J2をJ3の下位機種として販売すればいいのだけどJ2は筐体部分に
おいてS1よりコストがかかっている（S1はダイヤルがないだけではなく液晶の解像度も
低い）ということでJ2の卸値を下げた状態で出荷し続けるよりもそれを流用して徹底的に
コストダウンをした別モデルを投入した方が利益面で有利になると考えたからだと思うにょ。

そうなるとS1は「安さこそすべて」なんだけど実際は新発売の機種ということで当初は
ご祝儀価格になっているにょ。
価格comの最安値を見ると以下のような感じになっているにょ。（レンズセットは付属レンズに
違いがあるためボディの価格で比較）

　　Nikon 1 S1　ボディ　・・・　最安値　49300円　※発売前であるため参考価格
　　Nikon 1 J3　ボディ　・・・　最安値　62800円　※発売前であるため参考価格
　　Nikon 1 J2　ボディ　・・・　最安値　45800円
　　Nikon 1 J1　ボディ　・・・　最安値　27679円

こうしてみると「安いから」という理由でS1を買おうとしている人は必ずしもそれが得策とは
いえない状況にあるにょ。
何せJ3発表によって型落ちとなてしまったものの3ヶ月前に発売された（S1より上位となる）
J2の価格の方が安いわけだからね。
もっとも、この程度の差ならば発売してすぐにS1の方が逆転すると思うけど安さというか
コストパフォーマンス重視ならばJ1が圧倒的にょ。
この価格もボディ単体よりもレンズセットの方が量が多い関係上そちらの方が値下げ幅が
大きくなっているため何と標準ズームキットのJ1は価格com最安値で24000円まで下がって
いるにょ。（私の地元のキタムラでも最終処分価格22800円で売っているのを見かけた）
そうなると、S1にこだわりがある人でない限りは安くなっているJ2かJ1を購入するという
のがベターな選択肢といえるにょ。

S1とJ3の登場によって「上位モデル（V2）」、「中核モデル（J3）」、「廉価モデル（S1）」
と3本柱が揃いラインナップとしてはかなり強力になってきたにょ。
これはNEXにおいても「上位モデル（NEX-7/6）」「中核モデル（NEX-5シリーズ）」「廉価
モデル（NEX-3シリーズ）」のように3本柱で構成されており、力を入れて販売展開するならば
1モデルだけでは店頭での販売スペースを確保するのも難しいため当然の措置だと思われるにょ。


レンズ交換式のカメラの場合は本体だけでは意味がないにょ。
NEXもボディだけはたくさん出るけど肝心のレンズがないとずっと言われていたからね。
ここ最近はそれもようやく克服されつつあるけどNikon 1シリーズとなるCXフォーマット対応
レンズはまだ絶対量が全然足らないにょ。
ということで、今回新レンズが2本投入されたにょ。

1 NIKKOR VR 10-100mm F4-5.6
http://dc.watch.impress.co.jp/docs/news/20130108_580812.html
1 NIKKOR VR 6.7-13mm F3.5-5.6
http://dc.watch.impress.co.jp/docs/news/20130108_580827.html

10-100mm F4-5.6の方は35mmカメラ換算で27-270mmとなる10倍ズームで6.7-13mmの方は換算
18-35mmとなる超広角ズームとなっているにょ。
10-100mm F4-5.6は現行モデルは全長95mm、最大径77mm、重量530gという決して小さいとは
いえないレンズであったのが全長70.5mm、最大径60.5mm、重量298gと劇的な小型軽量化と
なっているにょ。
これは一見するとAPS-C用の（3倍クラスの）標準ズームかと思うようなコンパクトサイズ
であり、1インチというミラーレスの中では小型なセンサーを搭載した恩恵といえるにょ。
なかなか需要の大きそうなレンズではあるものの問題は価格にょ。
定価89250円という価格は同クラスの焦点距離となる同社製のズームレンズよりも安いとはいえ
センサーサイズを考えると割高感は否めないにょ。（前モデルは99750円だったことを考えると
これでも安くなったのだけど）

これはフルサイズの300mm F2.8（サンニッパ）は昔から憧れのレンズといえるのだけど純正品
だと実売価格で50万円以上もする非常に高額なレンズにょ。
それがフォーサーズで換算300mm F2.8（つまり150mm F2.8）のレンズが50万円をやや下回る
程度の金額で発売されたらどうかというと実焦点距離は150mm F2.8であるため割高感を抱く
人が大半だと思うにょ。
明るい望遠レンズと高倍率ズームではレンズそのものにかかるコストが異なるため単純比較は
できないものの小さいセンサー専用のレンズならばそれに似合った価格でないと割高感を
感じてしまうにょ。

10-100mm F4-5.6は現時点での価格を見ると価格com最安値では68200円となっているにょ。
値引率は妥当なところだと思うのだけどここで注目すべきはJ3の10倍ズームセットモデルにょ。
これは現時点での価格comの最安値は89800円となっているにょ。
上記のようにJ3ボディの最安値は62800円であるためこの高価な10倍ズームレンズが27000円で
入手可能な計算になるにょ。
これは、ズームレンズ単体の価格はそれを単品で売っても十分に利益が出せる価格付けと
なっていて、レンズセットモデルの方はそれよりも利幅を抑えた価格付けとなているため
だと思われるにょ。

このようなことは多くのレンズセットモデルに当てはまるためレンズが不要な人でない限りは
レンズセットで購入した方がお得な場合が多いにょ。
しかも、レンズ単品の価格は発売後も価格の下降は緩やかなのだけど本体の方は急激な価格
下落が予想されるにょ。
そのため現時点でこの価格差ならばJ3の10倍ズームセットモデルの価格が下落したらレンズ
単品と同等もしくはそれよりも安くなるという可能性もあるにょ。
これは実際にPanasonic GF1のパンケーキレンズモデル（20mm F1.7付き）で実際に起きたこと
であり、レンズが欲しい人はほぼ同価格で入手可能なパンケーキレンズセットモデルを購入
した人も多いのではないかと思われるにょ。
そのボディが不要ならば中古ショップやオークションで売却すればさらにお得感が増すわけ
だしね。

1448：マリモーマ：2013/01/12(土) 00:27:50
マザーボード
パソコンが調子悪くなって　いろいろやってるうちに
ディスプレイが表示しなくなったから　新しい　グラボ買ったよ
geforce gtx650というやつだけど　補助電源がいらないから
少し消費電力が減るかも？
マザーボードと同じ　asusだから　相性は　いいような気がする

http://pc.watch.impress.co.jp/docs/news/20121213_578566.html

http://liv0.com

1449：御茶目菜子：2013/01/12(土) 22:12:35
レスにょ
マリモーマさんへ
＞パソコンが調子悪くなって　いろいろやってるうちに
＞ディスプレイが表示しなくなったから　新しい　グラボ買ったよ

私も5年前に自作PCでモニタに出力されなくなったため応急処置として中古の安いビデオ
カードを買ったけど映らなかったので結局マザーボードごと買い換えたにょ。（GeForce
6800GTから7600GSへの買い換えなので消費電力は落ちたけど性能も落ちた）
後から調べたらビデオカードではなくマザーボード側の故障だったにょ。（買い換える
前のビデオカードも応急処置で買った安いビデオカードも新しく組んだ自作PCでは
問題なく使用できた）
自作PCを組んだ直後に発売されたRADEON HD4850に買い換えて現在に至っているにょ。

＞geforce gtx650というやつだけど　補助電源がいらないから
＞少し消費電力が減るかも？

これを見ると性能は1〜3割くらいアップで消費電力が半分以下なので現状で3D描画性能に
不満を感じてなかったのならばベターな選択といえそうにょ。
http://www.hwcompare.com/13552/geforce-gts-250-1gb-vs-geforce-gtx-650/

1450：御茶目菜子：2013/01/12(土) 22:13:58
プチコンで鍵盤楽器を作ろう
久々となる第8回のプチコン講座を書いたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/p008.htm
今回のテーマは「楽器演奏プログラム」ということで鍵盤楽器（キーボード）を作るという
ものにょ。
実はこのテーマは数ヶ月前から考えていたのだけどなかなか公開には至らなかった理由と
しては下記の2つのものがあるにょ。

　(1)ゲームではないから
　(2)1画面プログラムが初心者講座向きではないから

(1)私が書いているプチコン講座は「プチコンゲーム制作講座」ということでゲーム関係が
中心となっているにょ。
第3回の「BEEPで音階演奏をしよう」もゲームと音楽（BGM）とは密接な関係があるため
ただの音階演奏ではなくゲームに絡んだものと言えるにょ。
つまり、音階演奏はゲームを引き立てるのが目的であってそれそのものが目的というわけでは
ないということにょ。
それに引き替え今回は楽器演奏プログラムを作ることが目的となっているにょ。

百歩譲ってこれも一種のゲームだということにするか、例外的に認めるということにしても
問題はそんなに需要があるのかということにょ。
せっかく書くならば役に立つだけではなく需要の多いものにしたいからね。
Googleのアクセス解析を見てもゲーム関係は需要が多いにょ。
プログラムを作るならば自己満足で好きなようなものを作ればいいのだけど講座は人に読んで
もらいそして活用してもらって初めて意味があるものだからね。（といいつつ、私の書いて
いる講座は自分の研究成果の発表みたいな感じにすぎないけど）
そういうわけで結局途中まで書いたけどやめてしまったにょ。（講座を書くより自分が作る
という方に集中したかったというのもあるけど）

(2)私の講座はあくまで「初心者向け」と言いつつも実践力を重視となっているにょ。
そのため基本要素は入れてもそれを重点にせず、いかに実践力（自分自身の力で作り上げて
いける力）を身につけるようにしているにょ。
そのため、いかにも「初心者向けプログラム」を用意するのではなく自分の自信作品を元に
その作り方を細かく解説しているにょ。
それは初心者が脱初心者となるために重要なものだと考えているからにょ。
私の講座は操作性やバランス調整などには非常に気を遣っているけど初心者の場合は「完成
して動く」ということにすべてを注いでいるためかそういうこだわりをもてる余裕がない
からね。
そのため他所で見かける初心者向けの講座というのは操作性やバランス調整といった点に
注意しているものはほとんど見かけないにょ。
したがって、私はその点には力を入れているけど操作方法や計算式を変えるなどの簡単な
工夫次ですごく良くなるというのがこの講座で伝われば良いと思っているにょ。

私のプログラムは多くが1画面とか1行といった極めて短いプログラムとなっているにょ。
短いプログラムは解説も簡単なので初心者講座向けかと思いきや実際はそうではないにょ。
最初の頃は私の1画面プログラムスキルが低かったため「単純に1画面に収まっただけ」という
プログラムばかりだったけど最近はどれだけスパゲティ状態になろうと「これだけのものが
1画面に収まるのか」というようなものを作っているにょ。
つまり、スキルが上がれば上がるほど初心者講座向けではなくなるというわけにょ。
かといって、講座のために初心者に分かりやすいプログラムを作るというのは私のポリシーに
反してしまうにょ。


さて、このような考えからこの鍵盤楽器の講座はお蔵入りになってしまったのだけどそれが
こうやって公開に至った大きな理由は先日ASAさんのプチコン講座で同じく鍵盤楽器の講座を
書いていたためにょ。

　「プチコンのプ その8 鍵盤楽器を作ろう」
　　http://togetter.com/li/437045

このASAさんの講座は初心者向けの良い内容だけど「私だったらこうしたい」という考えが
いろいろ出てきてしまったにょ。
「だったら自分で書くしかないじゃない！」というわけで今回の講座に至ったわけにょ（笑）
両方を読み比べてもらえば分かるけど同じテーマであっても切り口がまるで異なるため
両方を読むことでさらに理解が深まるのではないかと思われるにょ。
同じ「鍵盤楽器」を作っているはずなのに考え方が異なると完成したものも別のものに
なっているしね。
例えば、タッチした状態で隣の鍵盤を押すという場合は私は指での操作を考えて誤動作
防止のためあえて音が出ないようにしているけどASAさんはタッチペンでの操作を行うため
操作面で問題ないので意図的に音が出るようにしているにょ。

ASAさんの講座は入門者〜初級者向け、私の講座は初級者〜中級者向けという感じなので
先にASAさんの講座を読んでから私の講座を読むとちょうどいい感じかもしれないにょ。
一部は共通したようなものを書いているけど私の講座では意図的にASAさんが書いている
ことは書いてない（逆にASAさんが書いてないことを書いている）ため両方読んでも損は
ないと思うにょ。
まぁ私の講座も基本的には公式サイトの初心者講座を読んでいれば分かるレベルである
ためそれほどレベルが高いわけではないけどね。（特に第1回の講座は公式の初心者講座
と大差ないレベルだし）


今回、私が書いた講座は普通に完成させたものを最後に1画面化するという内容にしている
ため上記の(2)の問題点は無くなっているのではないかと思われるにょ。
1画面プログラムは1画面化する際に極めて複雑な処理が要求されてくるけどその元に
なるプログラムは単なる短いプログラムだからね。
過去の講座もこの手を使えば初心者にもより分かりやすい内容になったと思うけど今更
書き直すのも面倒なので過去の分は現状のままということにしておくにょ。

さて、次回の講座の内容は・・・。
現時点では未定だけど楽器繋がりで今作っている1画面ギターにする可能性が高いにょ。
ただし、現状では1画面に収まりそうにないため1画面プログラムとともに講座の企画まで
お流れしてしまいそうにょ（笑）

1451：御茶目菜子：2013/01/14(月) 23:58:48
あきらめたらそこで試合終了だよ
先週から作っていた1画面ギタープログラム「PETITGUITAR」がついにできたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/2page.htm#guitar
http://www.youtube.com/watch?v=Ura6mHkGkPQ

プチコンでギタープログラムというと私が知っている限りではSHIROさんのプチギターと
彬兄さんのギターの弾き語りができるツールがあるにょ。
彬兄さんのは初代プチコンで作られていてBEEP命令によるコード演奏が可能ではある
もののボタンに割り当てられたコードを演奏するものとなっているにょ。
SHIROさんのはmkIIに対応しており、BGMPLAY命令を使っているもののコード演奏は
できず単音のみとなっているにょ。
そうなると、少なくとも私が知る限りでは画面上の弦を弾いてコード演奏ができる
ギタープログラムはプチコンではないことになるにょ。
ということで、今回「画面上の弦を弾いてギターを演奏するような雰囲気を感じられる
もの」を作ろうと思ったにょ。
きっかけは、先日作った1行プログラムの「SOUND PAD」なんだけどね。
これを作る際に左手で[A][B][X][Y]ボタン操作をするという手法を思いついたけどこれで
ギターを作ればそれっぽいものが出来そうと感じたからにょ。

さて、思いついたのはいいけど問題となるのは操作体系にょ。
右手は演奏に集中したかったので左手のみでコードが自由に変えられるようにしなくては
ならないからね。
コードを選んでそれをボタンに割り当てるという方法で8通り（[A][B][X][Y]の単独押し
および、[R]ボタンとの併用）ならば簡単にできるのだけどあくまで「1画面」というのが
目指すものなのでそれではサイズ的に厳しいにょ。
というわけで、考えたのがコードを登録せずに理論上12音階×16種別＝192通りが選択可能
となるPETIT GUITARに採用されている方式にょ。

UIは決まったので制作に入ったのだけど最初にやったのはコードではなくすべて開放弦で
演奏ができるプログラムにょ。
これによって画面の弦の位置や快適な反応が得られるかが分かるにょ。
ここで陥りがちなのが当たり判定を鍵盤楽器と同じようにすることにょ。
つまり、弦そのものに当たり判定を用意するということにょ。
鍵盤のように面積が大きいものならば単純に鍵盤に対する当たり判定でもいいけど弦は幅が
ほとんどない（細いものは1ドット）ということで当たり判定が非常にシビアになって
しまうにょ。
弦と弦の間隔を30ドットと仮定して0.1秒でコードを弾いた際には1フレームの移動量は3ドット
となるため3ドット幅未満の弦だと反応されない恐れがあるにょ。
これがゲーム内の移動量ならば上限が分かるけど人がどれくらいの速度で弾くかなんて
分からないため常識的に考えられる限界までの速度に対応したいにょ。
別に当たり判定は見た目と同じにする必要はないため隣の弦ギリギリまで当たり判定を
大きくしたら反応は良くなるものの「コレジャナイ」感が強くなったにょ。

というわけで、すぐに改善したのが画面を7つのエリアに分割してタッチした状態で隣の
エリアに入ったら反応するというものにょ。
私がどれだけ速く操作しても1フレームで20数ドットだったので30ドット幅にすればこの
方法によってどれだけ速く弾いても取りこぼしは100％無くなるにょ。

次に問題となるのがBGMPLAY命令の仕様にょ。
BEEPを使用すれば何も考えなくても勝手に和音演奏が可能だけどBGMPLAY命令の場合は
ユーザーがチャンネル指定をしないと和音演奏にはならないにょ。
BGMPLAY命令はあらかじめ用意されたMMLを演奏するならば簡単に和音（コード）を鳴らす
ことができるけどリアルタイム演奏をするならばチャンネル指定をあらかじめ行うという
ことが足かせになってくるにょ。
何せBGMPLAY "0:C":BGMPLAY "1:E":BGMPLAY "2:G"としてもドミソの和音は鳴らずドの音と
ミの音とソの音が交互に鳴るだけだからね。
これは、BGMPLAYでMMLを直接指定した場合には記述していないチャンネルは自動的に無音と
見なされるからにょ。
そこで、考えたのがBGMSET命令で半音単位で必要な音を1音ずつ定義していくというものにょ。
あらかじめ定義されたMMLならばチャンネル単位で独立して鳴らすことが可能だからね。

これで、何とか形になったので次はコードを入れることになったにょ。
当面は動作確認のため最も単純な押すフレット番号をDATA文で入力していくことにしたにょ。
Amならば002210（「0」は開放弦を示す）となり、1つのコードが6桁の数字になり、これを
12音階分入力すれば1種類のコードに対応できるにょ。
データ量の問題があるためメジャー、マイナー、セブン、マイナーセブンに絞ったにょ。
これより少ないと実用にならないというギリギリのラインに感じるけど1画面に収めるという
ことが最終目標なのでこれでも限界にょ。

さて、とりあえず操作性や動作確認をして一応はプログラムとしては完成となったわけだけど
これからが本番にょ。
現在はシステム部分だけでほぼ1画面となる24行分となっており、それにコードデータが別途
16行もある（1種別4行×4種別）わけだからね。
そこで出てくるのがデータ圧縮にょ。
もちろん、圧縮効率の高さと展開ルーチンの小ささを考慮して合算で最も小さくなるような
ものを選択する必要があるにょ。
ルート音が分かってるのだからそこから自動生成するという方法もあるけど自動生成も
そんなに短くできないからね。
人間の指の配置を考慮しないと人間の手には弾けないようなコードデータが生成されてしまう
恐れがあるにょ。
そういう例外処理を行う必要性を考えるならばデータ圧縮をした方が遙かに簡単で短く済む
と考えたにょ。

ギターコード表を見る限りフレット番号は0〜8が使われているにょ。
単純に考えると1つの弦あたり4ビットなので6本の弦では3バイトになるにょ。
とはいえ、8が使われているのは一部だけなのでそれを例外として処理すれば3ビットで表すと
18ビットで済むにょ。
256進数表記する場合には8ビット単位で扱うことになるので8ビット単位でないと展開
ルーチンが複雑化してしまいデータは小さくなってもトータルでは小さくならないという
可能性があるためさらに別の方法を考えたにょ。
それは押さえるフレット番号は（人間の指の可動範囲を考えると当たり前だけど）どのコード
であっても3つ以下しかないにょ。
つまり、差分を取れば1つの弦を2ビットで表現できるにょ。
12ビットで表現できるため8ビット単位で扱うとすれば16ビットで残り4ビット余るにょ。
その4ビットをフレット番号の最大と最小の差分の数に充てたにょ。
あとは、CHR$(0)、CHR$(13)、CHR$(34)などが圧縮データとして生成されないようにコードを
ずらせば圧縮の完成にょ。
これによって16行あったデータはわずか4行になったにょ。（3分の1のはずなのに4分の1に
なっているのは区切りコードも無くしたため）

その圧縮ルーチンはこんな感じにょ。

INPUT D$
A=9
FOR I=0TO 5
　P=VAL(MID$(D$,I,1))
　A=A+!!P*(P<A)*(P-A)
P(I)=P
NEXT
A=A-1
FOR I=0TO 5
　P(I)=P(I)-A*!!P(I)
NEXT
E$=CHR$(A+P(0)*16+P(1)*64+1)+CHR$(P(2)+P(3)*4+P(4)*16+P(5)*64+1)

さて、これで1画面に収まるかというと全然そんなこともないにょ。
まだデータ展開ルーチンはリスト短縮が不十分であるものの約4〜5行分あり、それにデータを
合わせると8〜9行分になるにょ。
すでにシステム部分で24行使っているためそこから8〜9行分短縮する必要があるにょ。
最初から無駄だらけのプログラムならばそれも可能だけどすでにある程度はリスト短縮が
されているためここから大きな短縮は難しいにょ。
というわけで、一昨日も書いたようにほぼ1画面化はあきらめていたにょ。

とはいえ、やってみたら案外できるかも・・・ということでまずは上画面の表示をばっさりと
切り捨てたにょ。
これによって3行開いたので残りは約5行にょ。
あとは地道なリスト短縮で何とか残り1行までたどり着いたにょ。
そして、使用チャンネルを0〜5ではなく1〜6にすることでIF文を1つ減らしなんとか1画面に
収まる目処が付いたけどその代わりS=S+1というのをどこかに入れる必要が出てきたにょ。
すでにリスト短縮によって0〜2文字分しか開いてなかったため連続で5文字開いた行を捻出する
なんて不可能な状態にょ。（実際に入れる場所は音を鳴らす直前にしないといけないので
S=S+1を入れるために元々その行にあった何かを別の行に移動する必要がある）
そこで目を付けたのがD=C*2-(C>2)-(C>5)+E-2という論理式にょ。
これはD=0OR(C*5-4)/3+Eという変形が可能になるため何とかS=S+1を入れることができたにょ。
あと開いた場所におまけ程度に上画面表示を追加して完成したにょ。（数字で表示するだけ
ならば2文字の空きがあれば入る）

こうやって、ほとんど無理と思われたプログラムの1画面化が多少の妥協があるものの
完成したにょ。
あきらめずに1画面化にチャレンジして本当に良かったにょ。
しかし、音に関しては全く妥協はせず当初のものを完全に入れることができたにょ。
もしも、改造点にあるようなシンプルな表示であってもメインとなる音の部分をかなり
削らないと実現できなかったからね。
今回書いたことは今月末〜来月くらいに第9回のプチコン講座で具体例を交えて書くので
お楽しみに！（といっても、鍵盤楽器よりもさらに需要が少なそうだけど）

1452：マリモーマ：2013/01/15(火) 09:08:15
ASUSが好きになってきた
ASUS (エイスース)、Android 4.1 を搭載した
7インチサイズの低価格タブレット「MeMO Pad」を発表。
http://himasoku.com/archives/51761064.html

買う気はないけど　安いのは怖いかもね

http://liv0.com

1453：御茶目菜子：2013/01/15(火) 23:32:48
レスにょ
マリモーマさんへ
＞ASUS (エイスース)、Android 4.1 を搭載した
＞7インチサイズの低価格タブレット「MeMO Pad」を発表。

安いのはいいけど同じASUSが製造しているNexus7よりはスペックで劣っているにょ。
今時シングルコアCPUというのが少し気になるにょ。
タブレットのデフレ競争のせいで今や7インチタブレットは1万円台が普通になって
きてしまっているにょ。

＞買う気はないけど　安いのは怖いかもね

名の知れない中華パッドだと不具合が起きた場合に厄介なので安くても「使い捨て」
くらいの感覚でないと買えないからね。
その点はASUSならば世界的に有名なメーカーだから大丈夫だと思うにょ。

1454：御茶目菜子：2013/01/18(金) 23:27:18
MMLで任意の周波数の音を出す
プチコンmkIIを買ってからBGMPLAYでをまともにMMLを使ってなかったので最近になってから
ようやくいろいろ試しているにょ。
まぁ基本的なMMLくらいは昔PC-8801mkIISRのCMDPLAY命令などを使ったときに覚えたけど
その時もそんなに使いこなしていたわけではないにょ。
ポケコンではBASICでは標準では音階演奏をサポートしていなかったにょ。
中には和音演奏ができるマシン語プログラムなどもあったけどゲームの中で使いづらかった
ため専ら自作のMMLを使っていたにょ。
そして、できたのがOMPにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/OMP.HTM

OMPは独自色がかなり強いもののプチコンと比べて100倍くらい遅いポケコンのBASICでも
リアルタイムのMML解析を行いつつ十分な処理速度が出せるように速度重視であるとともに
MMLのデータが極めて小さくなるようなものとなっているにょ。
さらに、複数の機種での発表によって他機種でもそのMMLでそのまま実行できるため機種間で
互換性がなく移植の際の妨げとなっていた音楽部分の互換性を取ることができているにょ。
このOMPは私がプチコンを入手した際にはプチコンに移植してポケコンで作ったMMLがそのまま
動作するようになったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#omp

しかし、mkIIでは今までプリセット音楽しか鳴らせなかったBGMPLAYでユーザーの手による
任意のMMLが演奏できるようになってそのOMPを使用する意味があまり無くなったにょ。
とはいえ1画面プログラムをメインに作ってきたため自作曲を入れたゲームはプチコンでは
作ってこなかったにょ。
まぁそれでも音楽系ツールをこれだけ作っていてまともにBGMPLAYを使いこなしていないと
いうのも何なのでいろいろ試しているというわけにょ。

今回試してみた@Dコマンド（デチューン）だけどこれはいい用途が思いつかなかったにょ。
日本のオーケストラで流行っていると言われている442Hzで演奏する場合には（後述のことを
を元にすれば）@D5とすることで可能なんだけどね。
鳴らしたあとに自由に周波数の微調整ができるのならばギターのチョーキングビブラートも
再現できそうだけど鳴らす前に指定しなくてはならないため使いどころが限られそうにょ。
しかし、上手く使えば任意の周波数の音が出せそうと気が付いたので早速作ってみたにょ。

　《　任意の周波数の音を出すルーチン　》
　　N=LOG(F)*17.313-36.378
　　BGMPLAY"T1@D"+STR$(0OR N%1*64)+"N"+STR$(0OR N)

これは、簡単に言えばN69（ラの音）が440Hzというのを元にしているにょ。
そして半音変わるごとに周波数は2の1/12乗分変わるため簡単に計算ができるにょ。

　　Nの値＝LOG(F)/LOG(POW(2,1/12))-LOG(440)/LOG(POW(2,1/12))+69
　　　　 　※POW(2,1/12)　は　2^(1/12)　を示す

ただし、これをプチコン上で実行すると誤差が非常に大きくなるため関数電卓で正確に計算
したにょ。
演算誤差の蓄積を避けるため定数をすべて計算してプチコンで扱える小数第3位で表すの
だけど最後にLOGの計算でまた誤差が発生するため小数第3位はLOGの演算誤差を考慮して
一般的な周波数の範囲だと最も誤差が少なくなるように調整したにょ。
上記の複雑な式のままだとそのままプチコン上で計算したらN69から1オクターブ変わる
ごとに10セントくらいの誤差ができてしまうけど簡略化した式では0.1セント未満になって
いるため精度は数100倍まで高まっているにょ。
もちろん、メモリや速度面のアドバンテージも大きいにょ。

しかし、Nの値が分かったところで半音単位でしか音を鳴らすことができないにょ。
そこで出てくるのが@Dコマンドにょ。
とはいえ、@Dの値を変えるとどの程度音の高さが変わるかはマニュアルには記載して
いないにょ。
そこで、適当な値を入力してみた結果64でぴったり半音分、127でほぼ半音2つ分高さが
変わっていることが確認できたにょ。（まぁ絶対音感がない私の耳で確認しただけなので
正しい保証はないけど数セントの音のずれならば分かるためそれほど大きな誤差もないと
思う）
これを元にして考えると@Dコマンドの値1つにつき約1.5セント変わると言えそうにょ。

それが分かればNの値の小数部分を64倍すれば1.5セントを分解能として任意の周波数の音を
発生させるものは簡単にできるにょ。
それが上記のルーチンにょ。

さて、これを使って何ができるかというと・・・なかなか使いどころがないにょ（笑）
ということで、とりあえずドップラー効果のサンプルプログラムを作ってみたにょ。
ドップラー効果についてはWeb検索をすれば簡単に分かると思うけど最も身近なのは走って
いる救急車のサイレンの音が近づいている時と遠ざかっている時では聞こえる音の高さが
異なっているというものにょ。
これは単純な公式があるのでそれを元にすれば誰でも簡単に分かるにょ。

　観測者に聞こえる周波数＝周波数×（音速−観測者の動く速度）÷（音速−音源の動く速度）

この公式を使って聞こえる周波数を計算してやれば先ほどの任意の周波数の音を出す
ルーチンによってそれをシミュレートできるにょ。
プチコンのMMLではMMLで変数が使えBASICでその値をやりとりも可能になっているにょ。
BGMSETVでMML内変数に書き出し、BGMGET()でMML内変数の値を読み出せるにょ。
これを使ってやればSTR$を使って文字列演算を繰り返すなんていう手間が省けるため
リストがシンプルになるにょ。（上記の任意の周波数の音を出すルーチンのように書き込む
ものがNと@Dだけならば大差はないけど沢山書き込めば書き込むほど差がでてくる）

さて、いろいろ試した結果どうもNコマンドに変数を書き込む場合だけ挙動がおかしいにょ。
私の耳ではちょうど半音4つ分ずれている感じにょ。（N69の音がN65に聞こえる）
使い方が悪いのかと思って様々な方法で試してみたけど改善されないためMML変数を使う
場合には上記のルーチンにおけるNの値を求める式は次のように変更する必要があるにょ。

　通常　　　　　　　　　　　　MML内変数使用時
　N=LOG(F)*17.313-36.378　→　N=LOG(F)*17.313-32.378

これであとは簡単なんだけど音量はどうやら数値に比例しない感じなのでそれっぽくなる
ように調整しているにょ。（そのため本来ならば距離はX座標とY座標の二乗の差分の
平方根をとる必要があるけど多少の誤差があるのを承知で簡易的な式にしている）
周波数の変化は観測者のY座標と音源のY座標が異なるためそれを加味して計算する必要が
あるけどその辺は考えておらず、上記の公式そのまんまとなっているにょ。

というわけで、以上のものを元にしたサンプルはこちらにょ。


◎踏切の遮断器の警告音
　QRコード　http://ww5.tiki.ne.jp/~ochame/petitcom/qr/fumikiri.png

　 INPUT"ｿｸﾄﾞ(km/h)=";S
　 S=S/3.6:X=-500:L=200
　 A$=":0@1[@V$0@D$1N$2]
　 B$=":1@1[@V$0@D$3N$4]
　 F(0)=329.6:F(1)=392
　 BGMPLAY A$+B$

　@LOOP
　 FOR I=0TO 1
　?? F=F(I)*(340-S*SGN(X))/340
　?? GOSUB @SOUND
　?? BGMSETV 0,0????,V
　?? BGMSETV 0,I*2+1,D
　?? BGMSETV 0,I*2+2,N
　 NEXT
　 IF X>L THEN BGMSTOP:END
　 X=X+S/60:?"ｷｮﾘ="0OR X"m"
　 WAIT 1:GOTO @LOOP

　@SOUND
　 N=LOG(F)*17.313-32.378
　 D=N%1*64
　 V=255/SQR(ABS(X)+4)
　 RETURN


◎救急車のサイレンの音
　QRコード　http://ww5.tiki.ne.jp/~ochame/petitcom/qr/kyu_kyu_sya.png

　 INPUT"ｿｸﾄﾞ(km/h)=";S
　 S=S/3.6:X=-300:L=300
　 A$="T100@60[P$0V$1@D$2N$3P$4V$5@D$6N$7]
　 X=-300:L=300
　 F(0)=493.8:F(1)=392
　 BGMPLAY A$

　@LOOP
　 FOR I=0TO 1
　?? F=F(I)*340/(340+S*SGN(X))
　?? GOSUB @SOUND
　?? BGMSETV 0,I*4??,P
　?? BGMSETV 0,I*4+1,V
　?? BGMSETV 0,I*4+2,D
　?? BGMSETV 0,I*4+3,N
　 NEXT
　 IF X>L THEN BGMSTOP:END
　 X=X+S/60:?"ｷｮﾘ="0OR X"m"
　 WAIT 1:GOTO @LOOP

@SOUND
N=LOG(F)*17.313-32.378
D=N%1*64
V=255/SQR(ABS(X)+10)
P=ATAN(X/10)*40.7+64
RETURN

音量は上記のようにVコマンドの指定値と音量が比例しないため両方とも結構適当な計算
なんだけど救急車のサイレンの方のパンポットはATANを用いてそれなりに正しくなるように
計算しているにょ。（踏切は観測者から4m離れた地点を通過、救急車は10m離れた地点を
通過という設定でなおかつずっとまっすぐ走っているということを前提に計算している）
まぁ難しいことは何もやってないし、音色選択も適当なのでより近い音色を選択もしくは作る
などをした方がいいかもしれないにょ。
まず居ないと思うけどこれを使ったプログラムは自由に発表してもらってOKにょ。

1455：御茶目菜子：2013/01/20(日) 23:57:58
ついにiPhoneがポケコンになる・・・？
iPhoneがポケコンとして使えるアプリ「DPC-100」が発売になったにょ。
http://www.detune.co.jp/dpc100.html
iPhone用にBASIC開発環境はいくつか出ているけどほとんどが英語版で日本語でメーカーの
サポートがあるアプリというのは皆無にょ。
そういうわけで期待度は大きいのだけどDPC-100はポケコンライクな外観となっているにょ。
DSのように2画面あればソフトウェアキーボードを使用時であってもフルに画面が使えるの
だけど一般的なスマホだとソフトウェアキーボードを表示したら使用できる領域はわずかしか
ないからね。
それを懸念したからかどうかは知らないけど外観をポケコン風にすることで狭い表示領域を
逆にウリにしているにょ。

時代と逆行するかのごとく5x7ドットのドットマトリックス液晶風のディスプレイを
16桁1行表示というのはポケコンでいえばPC-1245相当の表示エリアとなるにょ。
確かに30年前ならばそのサイズでも何とかなったとはいえ、それはポケコンのメモリが
少なかったからそれで問題にはならないというだけのことにょ。
快適に使うならば少なくとも編集画面では高解像度の方が望ましいにょ。
そういう意味ではかなりユーザーを選んでしまいそうなアプリにょ。

しかし、実際にプログラムを作る場合には表示エリアが広い方が必ずしも有利というわけ
ではないにょ。
それはゲームなどにおいては多くのものが表示できるほどユーザーの負担が大きくなって
しまうからにょ。
単色より256色の方が使いこなすには負担が大きいし、16桁1行より32桁x24行の方が使い
こなすには負担が大きくなるにょ。
プチコンではそれを懸念して豊富なプリセットデータを用意することでユーザーの負担を
軽減しているにょ。

それでは、DPC-100が使いやすいのかというと私はまだ使ってないので何とも言えないにょ。
今度プリペイドカードを買ってきて試してみようと思うにょ。
Web上のマニュアルを見る限りではかなり方言の大きなBASICといった感じにょ。
演算子やPRINTF命令などC言語をかなり意識している感じだし、加速度センサーや
タッチパネル用の命令も用意されているにょ。
まぁこれで本格的なアプリ開発というのは無理だろうけどお手軽にプログラミングを
したいという人にはちょうどいいかもしれないにょ。
価格は850円（27日までは発売記念価格500円）ということで高くもないからね。

1456：みっぴゅ：2013/01/27(日) 00:40:29
エミュレータ
使ってるスマホがiphoneではなくて、そのアプリを試すことが出来ず悔しくて、他のエミュレータを探していました…
すると見つけましたよ！『PokeEmul』を！
早速スマホ(Android)とタブレットPC(Windows7)に入れてみました。
御中茶目さんは、おそらく既に知っていらっしゃるかと思いますが…

若干、実機と異なる部分はみられるものの、プログラムの内容によっては多少の修正で問題なく使えそうですね。

御茶目さんのポケコンが御陀仏してしまってからずいぶん経ちますが、エミュレータを使おうと考えたことはありませんでしたか？？？
??

1457：御茶目菜子：2013/01/27(日) 23:59:27
レスにょ
みっぴゅさんへ

＞御中茶目さんは、おそらく既に知っていらっしゃるかと思いますが…

知っているけどまだ試してはいないにょ。

＞若干、実機と異なる部分はみられるものの、プログラムの内容によっては多少の修正で問題なく使えそうですね。

実機並の動作をさせるにはROMの吸い出しが必要であるためそれはやむを得ないかも
しれないにょ。

＞御茶目さんのポケコンが御陀仏してしまってからずいぶん経ちますが、エミュレータを使おうと考えたことはありませんでしたか？？？

ポケコンはポケコン実機で使いたいのでエミュを使おうとは考えてなかったにょ。

1458：御茶目菜子：2013/01/28(月) 00:00:34
拡大縮小回転はロマン・・・！？
次回のプチコン講座に予定しているのはGRP面（グラフィック面）の拡大、縮小、回転に
ついてにょ。
もちろん、プチコンにそのような機能はないためソフトウェアで実装する必要があるにょ。
それらは基本的にはそれほど難しくはないということで、とりあえず、講座用にサンプルと
なるゲーム「2D→3D RACE」を作ったので講座に先駆けて公開するにょ。
http://twitpic.com/byq6ew
http://www.youtube.com/watch?v=k6vrMHPMO8I

このゲームはGFILLのみで作られた縦スクロールレースゲームなのだけどリアルタイムで
X軸の回転処理を行っているため疑似3D表示となっているにょ。（PETIT RUNの疑似3D
表示はポケコンで作ったレースゲームでも使用していたアルゴリズムを採用した非常に
シンプルなものであり、速度重視となっているものの表示には少し誤差がある）
視点切り替えも可能でデフォ設定では[X]ボタンを押すことで90度見下ろしとなるにょ。
回転処理は一次変換を使用しているだけなので非常に簡単にょ。
さて、このゲームに関しては詳しくはその講座で書くとしてやはりプレイ開始前デモの
拡大縮小処理はF-ZEROをかなり意識したものとなっているにょ（笑）

さて、拡大、縮小、回転といえばやはりすぐに出てくるのがスーファミにょ。
当時はハードウェアでBG面に拡大、縮小、回転機能を搭載しているということで今までの
コンシューマゲームでは見ることができなかったようなゲームも多数作られたにょ。
F-ZEROもこの機能が搭載されていなかったら恐らく作られなかったと思うにょ。
GRPの回転処理そのものはそれほど難しくないのだけどZ軸を回転させると演算量が飛躍的に
増えてしまう（X軸回転だったら上記のゲームだと道路の部分だけ演算を行えば良いのに
対してZ軸回転はすべての座標を計算する必要がある）というのが大きいにょ。

やはり、作るならばZ軸だけではなくスーファミのような2軸回転をやってみたいにょ。
Z軸回転だけよりさらに演算量が増えてしまうのだけど工夫次第では速度面は何とかなると
信じて試しに作ってみたにょ。
http://www.youtube.com/watch?v=LoDkoQcveoU
いいGRPデータを用意できなかった（というか空き容量もないし）ということでプチコン
まとめwikiで公開されているoさんの作品「Petit Slash」の面データの上を走り回って
みたにょ。（ちなみにこれはまとめWikiに公開されているバージョンではなく初期の
バージョンの方）

32x12ドットx8倍拡大で10fps程度の速度となっているにょ。
GFILLで描画しているため拡大率は自由に設定できるのだけど概ね1秒間に3000ドット程度の
処理速度であるため30fps出そうとすれば縦x横で100ドット程度に抑える必要があるにょ。
これでも、かなり高速化処理をしているためここから大きな速度向上は難しいそうにょ。
拡大率8ドット固定であればGFILLではなくBGPUTを使用することで描画部分の速度は向上
できるものの演算速度がボトルネックとなっているため描画速度が2倍近く速くなったと
しても全体の速度向上はそれよりもかなり小さなものになるにょ。
ただ、現時点のバージョンでは少し不具合があるにょ。
2軸回転だから本来ならばカメラアングルを自由に変えることができるのだけど90度上から
見下ろしてもトップビューにはならないにょ。
どこかで計算式が間違っているだろうけど高速化のため複雑怪奇なことをしているため
なかなかそれを見つけ出すことができないにょ（笑）
講座でこの2軸回転を公開するならば何とかしてそのバグだけは潰さないといけないけど
現時点では原因不明であるためなかなか苦労しそうにょ。（※このバグは翌日あっさりと
改善されました）

書きたいことも大量にあるため次回の講座は完成はかなり先になりそうにょ。
それまでの穴埋めとして途中まで書いているギタープログラムの講座を書くかもしれないにょ。
こちらは難しいことは何もないし、書くことも極めて限られるからね。
といっても、需要もかなり限られそうだけど（笑）


《　1/28追記　》

上記のGRP2軸回転プログラムで表示部分のみGFILLからBGPUTに変更したらどうなるかを検証
してみたにょ。

　32x12ドット8倍拡大時
　GFILL　10fps　→　BGPUT 11fps

しかし、BGPUT使用時には上下画面でのGPAGE切り替えが不要になるのでそれを省略すれば
13fpsになったにょ。
これは表示をGFILLからBGPUTに変えたものよりも大きいにょ。
BGPUTではパレット0限定では引数を省略可能なのでそれを省略してみたにょ。
そうしたら、14fpsになったにょ。
2重ループの内側は処理速度の向上のため加減算しか実行してないためこれ以上の高速化は
無理に思えたけどコロンなどの省略できるものを省略して変数名を1文字にするなどの地道な
変更によって17fpsにまでなったにょ。

ちなみに各命令や演算速度を単独で計測してみた結果は下記の通りにょ。

10万回実行時のフレーム数（1フレーム＝1/60秒）
BGPUT　引数省略無し269　引数省略時172
GFILL　8x8　233
GPAGE??51
GSPOIT 65

A=1 　 59（代入処理）　※1文字変数の処理1つ当たり「15」が含まれた時間
A=A+2??81　加算　　　　　変数名の処理は1文字増えるごとに「2」増える
A=A-2??81　減算　　　　　四則演算は変数処理と代入処理を含んだ時間となっている
A=A*2??78　乗算
A=A/2??91　除算
改行　　5
コロン　7
FOR〜NEXT 91（1回当たり）※FORとNEXTの間に何も含まない10万回ループで測定

　※同一処理、同一条件下でも測定するごとに微妙に処理時間が異なっているため複数回
　　計測して最も処理時間が短くなった値を記述した

これを見るとBGPUTは引数を省略しないとGFILLよりも遅いにょ。
それなのにGPAGEを省略する前にすでにGFILLより速くなっているのは変数の処理に時間が
かかっているためにょ。
それを込みで計算すると例えば G=GSPOIT(X,Y) は 59+65+15+15 で154となるにょ。
実際に G=GSPOIT(X,Y) を計測すると154フレームとなっており、その計算通りの時間と
なっているためこの表の数値に間違いないことが分かるにょ。
ただし、上記の値はすべて小数点以下は切り捨てであるため誤差が積み重なった場合には
無視できるレベルの誤差は十分に考えられるにょ。
上記の一覧では加算は81となっているけど代入が59含まれているということを考えると
加算や減算を1つ省略するよりも代入1つ省略する方が大きいといえるにょ。
実際G=GSPOIT(X,Y)を代入せずに使用したらだけで一気に2fps上がったにょ。
まぁ小数点以下は切り捨てだから2fpsといっても実際は1fps少々だと思うけど代入を1つ
省略するだけで処理速度が1割近く跳ね上がるというのは非常に大きいと言えるにょ。

1459：天郷思音：2013/01/29(火) 17:06:23
レス、考察
>>コロンなどの省略できるものを省略して変数名を1文字にするなどの地道な
変更によって17fpsにまでなったにょ。

コロンで命令の境界を明示したほうが探す手間が省けて速くなると思ったらそうでもないのか。

1460：御茶目菜子：2013/01/29(火) 23:49:31
レスにょ
天郷思音さんへ
＞コロンで命令の境界を明示したほうが探す手間が省けて速くなると思ったらそうでもないのか。

基本的に構文解析は頭から順に行っているため区切りが明確に判断できた後のコロンはただの
蛇足でしかないからね。（何らかの方法でコロンだけを調べられるとしても命令の区切りとして
使っているのかDATAとして使っているのかの区別を付けることはできないため）
したがって、コロンを省略できる場合はプチコンに限らずほとんどのBASICにおいて高速化に
繋がると思うにょ。
だから限界まで高速化を行うならば省略できるものはどんどん省略していくのがベターにょ。
ここで重要なのは改行が10万回で5フレーム、コロンが7フレームということにょ。
したがって、マルチステートメントで記述するのはコロンが省略できる場合のみに止めて
おいてあとは1行に1命令という書き方の方がプチコンの場合は速くなるにょ。
まぁそこまで限界まで高速化する必要性がある場合はほとんどないけどね（笑）

例のGRP2軸回転のプログラムのように1回のルーチンで数100回繰り返し処理をする場合は
1つ省略できたら数100個省略できたのと同じだけの価値があるから些細なことでも馬鹿には
できないにょ。
実際ルーチン内の内側のループではGSPOTとGFILL（もしくはBGPUT）と加算が3回のみで
2軸回転を実現しているわけなので「これ以上は高速化の余地がほとんどない」という特殊な
状況であるため有効に働いているにょ。（そうでない場合は1つや2つ省略できても速度
向上はほぼ誤差のレベルとなる）
ちなみに2軸回転ルーチンの表示バグは簡単に原因が分かったので今は1度〜90度まで
どのようなアングルからもプレイできるようになっているにょ。
後はもう少しテストして問題が無ければ次回の講座で正式公開する予定にょ。

あと中学生視点で回答が欲しいことがあるにょ。
次回の講座について各ルーチンの使い方とアルゴリズムの簡単な説明だけでいいのか
それともそれに使用した式などもちゃんと書いて説明する方がいいのかということにょ。
講座の内容を理解するには少なくとも三角関数と行列などの知識は必須であるため中学生
にはかなり困難なものになりそうなのでそれについても解説すべきか悩んでいるにょ。
その解説が不要ならば前回（第8回）よりは長くなるものの第7回の講座よりは短く収まりそう
だけど解説をするならば過去最長クラスの講座になってしまいそうにょ。
長くなれば当然のことながら公開するまで時間がかかってしまうことになるにょ。

1461：天郷思音：2013/01/30(水) 20:00:32
レス
＞次回の講座について各ルーチンの使い方とアルゴリズムの簡単な説明だけでいいのか
それともそれに使用した式などもちゃんと書いて説明する方がいいのかということにょ。

説明があったほうがいいですね。三角関数も時計の針を描画するぐらいで、理由とかも全然知らないですし。

1462：御茶目菜子：2013/01/30(水) 23:59:54
レスにょ
天郷思音さんへ
＞説明があったほうがいいですね。三角関数も時計の針を描画するぐらいで、理由とかも全然知らないですし。

回答どうもにょ。
やっぱり、あった方がいいのか・・・。
拡大、縮小、回転ルーチンは変数の値を変えるだけで簡単に使えるようにしているし
パラメータの数が12個（プレイヤーのX座標、Y座標、向き、画面表示の横ドット数、
縦ドット数、その横拡大倍率、縦拡大倍率、表示位置X座標、Y座標、カメラ距離、カメラ
アングル、下画面の最小読み取り幅）もあって使い方が難しい2軸回転プログラムは
サンプルで設定できる項目を増やして主な機能はこのサンプルだけで使えるようになる
ためこれをベースに改造するだけでゲームが作れるようになっているにょ。
そのため「使うだけ」ならば簡単なんだけど理解しようとするならば必然的に数学の
知識が必要になるため厄介にょ。
これが高校生相手（数II以降を選択している人）ならば「教科書を読め」で済ますことが
できるのだけどプチコンで使用者が多い中学生だとそれもできないからね。

ただ、どこから書けばいいのかというのも結構難しいにょ。
今回必要なものは三角関数の基礎知識と行列（主に一次変換）に関する知識なのでそれだけを
書くならばそれほど膨大な量にはならないかもしれないけど図表も準備したりしないと
いけないためその数学講座だけでも結構な時間がかかりそうにょ（笑）
大幅に公開が遅れるようであればGRP2軸回転ルーチンでゲームを作ってそれから書くという
のもありかもしれないにょ。（2軸回転ルーチンはあれからさらに高速化して19fpsになった
のでこれならば「十分に実用レベル」と感じるようになったため）
そうなると先にギタープログラム講座を仕上げるとしようかな。

1463：御茶目菜子：2013/02/01(金) 00:00:01
Win8なんて要らないけど・・・
Windows8proのアップグレード版の発売記念価格が今日で終了したにょ。
http://pc.watch.impress.co.jp/docs/news/20130121_584294.html
というわけで早速1本だけ買ってきたにょ。
私が現在主に使用しているPCはネット用（Vista）、モバイル用（XP）、TV録画用（XP）
自作PC（XP）ということでVistaが1台ある他はすべてXPとなっているにょ。
他の予備機も軒並みXPもしくはそれ以前のOSにょ。

さて、XPは来年4月でMSのサポートが完全に終了するにょ。
終了したから即使えなくなるというわけではないけど対応ソフトや周辺機器が今後確実に
減っていくわけだからね。
さすがに旧OSをサポートするというのは無駄にコストがかかってしまうわけであって、
現在はXPを使用者はまだそれなりにはいるためその余分なコストを払ってでも対象ユーザーを
広げるということにメリットがあると感じている周辺機器メーカーやソフトメーカーは
XPに対応しているけどMSのサポートが無くなる来年4月以降になるとさすがに今よりは確実に
XP利用者も減るわけであっていつまでXPに対応させてくれるかは微妙なところにょ。

確かに現在使用している機器やソフトを使う分にはXPで問題ないけど今後セキュリティ
ホールが見つかった場合に完全放置となるためネットに積極的に接続するPCには使えないにょ。
すでに3年前にサポートが終わっているWin2Kも今やネットに接続してしまえばあっという間に
ウイルスやスパイウェアで溢れてしまうにょ。
そういうことを考えるとネットに繋がなければ大丈夫ともいえなくはないけど問題なのは
XPの場合はプリインストールの機種以外はアクティべーションがあるということにょ。
このアクティべーションがある限りはネットに繋がないということは不可能にょ。

さて、このアクティべーションだけど問題はサポート終了後もちゃんと行われるのかと
いうことにょ。
それについてはまだ正式にはアナウンスされていないけど「サポート終了＝アクティ
べーション終了」というのも視野に入れておく必要があると思われるにょ。
MSほどの大企業ならばサポート終了してもアクティべーションを継続してくれるだろう
という楽観的な考えは先日のAdobeのサポートを見て怪しくなってしまったにょ。
Photoshop CS2などのAdobeのソフトはサポート終了によってアクティべーションサーバが
先月停止してしまったにょ。
つまり、今までインストールしていたPCで使用するならば問題ないけど再インストールを
したら使えなくなるという問題が出てきたにょ。
それに対してAdobeはアクティべーション不要のCS2を公開するという措置を執ったにょ。
http://www.itmedia.co.jp/news/articles/1301/08/news026.html

これに関しては「CS2を無償公開」という認識を持っているユーザーが非常に多いけど
あくまでCS2の正規ライセンス所持者のみが使えるというだけにょ。
しかし、ファイルをダウンロードするのに正規ユーザーかどうかという判断は行われて
おらず、誰でもダウンロードできしかもそのインストールに必要なシリアルナンバーまで
ご丁寧に同一ページに記載されているわけだから無償公開という認識の人が大量に出ても
おかしくないと言えるにょ。
この辺は正規ユーザーかどうかの識別を行う負担を考えるとアクティべーションサーバを
止める必要はないわけであってコスト削減のためには仕方ないとはいえこのAdobeの対応は
本当に良いといえるのか判断が分かれているにょ。

MSもどのような措置に出るかが問題となるにょ。
遅かれ速かれXPのアクティべーションが終了するわけだけどそうなった際にはAdobeのように
アクティべーション不要のXPを無料ダウンロード・・・なんてことにはなりそうもないにょ。
つまり、サポート終了以降はいつアクティべーションサーバが止められてもユーザーは文句が
言えないためそうならないためにもOSの乗り換えが必要になるにょ。
逆にそれがあるからこそXPのサポートが終了したらそれほど遠くない時期にはアクティ
べーションを終了する可能性が高いともいえるにょ。

もっとも、OSのみを乗り換えるのではなく多くの人はPCの買い換えを行うと思われるにょ。
最短でも5年、最長で約10年ものサポート期間がある（例えばWin7は2009年発売で2020年
まで延長サポートがある）わけだからその間に多くの人が買い換えるのではないかと
思われるにょ。
しかし、昨今はPCで普通に使うならば十分なスペックであり80年代〜90年代のように3年で
陳腐化してしまっていたのとは大幅に異なっているにょ。
今はUltrabookレベルの性能で普通に使う分には何ら問題はない性能があるわけだからね。
もっとも、4K動画が当たり前の時代になればまた話は変わるけど4Kが普及するにはまだ時間が
かかるため現時点でそれについて心配する必要はないと言えるにょ。

さて、私の場合は主に使っている機種だけでもXP搭載が3台あるわけだから本来ならば
Win8は3本買うべき・・・なのだけど現実的に考えるとそれらを今後買い換えないという
保証はないわけだからね。
昨年10月26日に書いたようにWin8はタブレット型以外ではメリットよりもデメリットの方が
多いため今後Win7搭載機に買い換えたらWin8は不要になるにょ。（まぁ8の方が残りサポート
期間が長いというメリットはあるけど）
そう考えるとTV録画機は搭載しているチューナーがXPにしか対応していないためこれを
買い換えは現時点では無理なのでモバイルPCか自作PCに導入となるにょ。
しかし、モバイルPCもそろそろ買い換えを考えているためWin8を導入するとすれば自作PCに
限られるため1本で十分と考えたにょ。
それでも現時点では要らないわけだから余分に買ってもしかたがないにょ。
まぁWin7がWin8の発売記念価格と同レベルで購入可能ならば少し考えてしまうけどね（笑）

1464：御茶目菜子：2013/02/01(金) 23:59:40
プチコンで32bit整数演算を行う方法
プチコンの1つの問題点として32bit固定小数点であり、小数部分に12bit使用され整数は
19bit＋符号1bitとなっているため最大で±525287までの数値（2^19-1）までしか扱うことが
できないにょ。
実務用に使うことはほとんどなくほぼホビー用に使われるであろうプチコンであればそれほど
問題はないとはいえ、最大52万程度の数しか扱えないということで不満を感じている人も
結構いるにょ。

制限があってもそれを工夫すれば乗り越えることは可能にょ。
1つの改善作として考えられるのが多倍長演算のようなことをするというものにょ。
多倍長演算はその言語でサポートしている最大数に収まる範囲内で桁を区切りそれを元に
数値表記を行うものにょ。
例えば1つの変数に10000まで入れるという場合は簡単に言えば1万進数で表記するという
ような感じにょ。
こうすることでその言語がサポートしている上限数を大幅に越えた計算をすることが可能で
あり、非常に多くの桁数の演算が必要になる円周率などの計算にも活用されているにょ。
多倍長演算をデフォでサポートしている言語も一部にはあるものの基本的にはソフトウェアで
実装する必要があるにょ。
これはそれほど難しいものではなく人が筆算で行うのと同じアルゴリズムで行われるにょ。

2桁＋2桁の加算の例として36＋47を計算する場合は次のようになるにょ。

　　　　３６
　　　＋４７
　　　−−−
　　　　８３

この場合は6と7を足して13となり、1の位は3になるにょ。
10の位は1+3+4で8になるにょ。
したがって、答えは83にょ。

これを211万6789＋315万7895を計算する場合に1万進数で行う場合0〜9999を1つの変数に入れて
計算することになるにょ。
変数AH（変数Aの上位桁）、変数AL（変数Aの下位桁）、変数BH（変数Bの上位桁）、変数BL
（変数Bの下位桁）と4つの変数にAH=211、AL=6789、BH=315、BL=7895を入れておくにょ。
そうすれば下位桁同士をまず計算して14684となり、1繰り上がって下位桁は4684となるにょ。
1＋211＋315で上位桁は527となるにょ。

このように加算は繰り上がり処理だけ注意すれば簡単に実現できるにょ。
減算は同様に繰り下がり処理だけ注意すればいいにょ。
しかし、乗算はそうはいかないにょ。

　　　　３６
　　　×４７
　　　−−−
　　　２５２
　　１４４
　　−−−−
　　１６９２

これも同じく筆算の要領で計算すれば良くまずは36x7を計算して7x6=42（4繰り上がり）、
7x3+4=25（2繰り上がり）となるにょ。
そして、36x40を同様に計算して最後に同じ桁同士で加算を行えば答えが出るにょ。
ここで1つ重要な問題があるにょ。
それはプチコンの演算における上限数の問題にょ。
加減算だと10000を1まとめにして計算しても最大でも9999+9999であるため上限数に達する
ことはないけど乗算の場合は最大数では9999x9999という場合が起こりうるからね。
SQR(524287)を計算すると724.07・・・であるため乗算をサポートするならば2桁単位で
計算する（つまり100進数とする）必要があるにょ。（724進数までなら大丈夫なので256進数
でもいいけど後から10進数に直すのに処理時間がかってしまう）
その場合には10桁の演算をサポートする（2桁単位で5つ分）だけでも数10回の演算が必要と
なりさらに後述の例外処理も非常に複雑になってしまうにょ。（基本的に区切る数の二乗の
割合で演算量は増えていく）

多倍長演算は扱えるデフォでその言語がサポートしている演算桁数の制限を突破するには
非常に有用な方法だけど演算速度がポケコンや8bitパソコンのBASICよりも桁違いに速いとは
いえそれほど速くはないプチコンにおいてリアルタイムで求めるためには加減算程度しか
実装は難しいと思われるにょ。
ゲームのスコアに使うならばそれで困ることはほとんどないけど四則演算を行いたいならば
あと多倍長演算は加減乗除それぞれ演算ルーチンが必要になるため必要なルーチンを別途
実装するならばプログラムが長くなってしまうのも厄介だしね。

そこで考えられるのは32bit整数演算を行うということにょ。
プチコンでは1つの数値変数は上記のように32bitで記録されているため小数部分を何とか
うまく活用できるならば±2147483647まで対応可能になるにょ。
最大52万では不満を感じることが多くても最大21億ならば不満を感じることはかなり少なく
なりそうにょ。
というわけで早速作ってみたにょ。

@INT
Z=4096:IL=INT%(10000/Z)*Z:IH=0OR(INT-IL/Z)/10000*Z
INT$="-"*!IH*(INT<0)+STR$(ABS(IL)):INT$=STR$(IH)*!!IH+LEFT$("0"*4,(4-LEN(INT$))*!!IH)+INT$
RETURN
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#int

固定小数点で記録されている数値を32bit整数に変換するというアイデアを考えた人は数多く
いると思うけど現時点で発表されたものはほぼないにょ。
それには次のような問題点があるからにょ。

　(1)小数型から整数型への変換処理
　(2)例外処理
　(3)計算法則の確立

(1)一番の課題はこれにょ。
最も簡単なのは1bitずつ抜き出していって順に1、2、4、8・・・の値を加算していくという
ものだけどそのためには多倍長演算のように数10回もの演算が必要になってしまうにょ。
配列変数同士の加算処理を1回行うだけで3ミリフレーム以上の時間がかかってしまうため
300回行うと1フレームくらいの時間となるからにょ。
少しでも高速化を図りたいならば別の観点で考える必要があるにょ。
そこで利用できそうなのはA%1でAの小数部分だけが取り出せるというものにょ。
これで小数部分を取り出したところで残った整数部分が4096の倍数となっているためそこから
特定の桁を得るためには結局ビット演算で各桁の値を抜き出す必要があるにょ。
しかし、「1」の剰余ではなく「10000/4096」の剰余であれば小数を整数と見なしたときの
下位4桁を抜き出すことが可能になるにょ。
つまり、残ったものは10000の倍数となるにょ。

ただし、ここからがまた厄介にょ。
A-A%1ならばそのAは整数になっているけどA-A%(10000/4096)の場合はAは小数のままだからね。
ここからどうやってAの上位桁の値を求めるかを考えなくてはならないにょ。
これは少し発想を変えれば簡単に分かるにょ。
内部では4096単位で記録されているため例えば1234という値は4096x1234=5054464という値を
示すのだけどこのまま4096を掛けるというのはOverflowになるためできないにょ。
ところが、1万で割って4096を掛ければ万単位の値は出せるにょ。
A/10000*4096でAが何万かということが分かるわけにょ。
実際に1234/10000*4096を実行すれば505という値になるからね。

しかし、これはぴったり何万という数ならばいいけどそうでないときには困るにょ。
例えば1235/10000*4096もプチコン上で505になり、実際に計算して505.856になるからね。
単に整数化すれば良いだけのことなんだけど問題は負数の場合にょ。
プチコン上でぴったり割り切れない限りは整数化した場合には絶対値が1大きな値となって
しまうにょ。
それならばぴったりの値にすればいいだけであって、すでに分かっている下位数を引いて
いるためぴったりの値にしてあるので問題はないにょ。
この簡易化によって6ミリフレームで上位、下位の各数値（ルーチン内の変数でいえばIHと
IL）を特定する処理が完了するにょ。（プチコンは配列変数と代入処理が遅いのはそれを
できるだけ減らすことが高速化に繋がる）
これは配列変数同士の加算2回分という速さにょ。
しかも、これは結果を出力する前に行う処理であるため毎回結果出力をしないのであれば
4096で割るという処理（0.37ミリフレーム）演算時間が増えるだけなので非常に高速にょ。

(2)例外処理とは例えば10240という値を上位と下位に分けた場合には1と240になるけど
そのままだと1240となってしまうため間に0を埋める処理が必要になるにょ。
しかし、これはそれほど難しくはないにょ。
問題なのはどのような例外処理が考えられるかをすべて掃き出しそれをすべて実装する
必要があるということにょ。
上位桁が0の時は0240ではなく240のみでいいというのはすぐに分かるけど問題は負数にょ。
負数の時は剰余も負数になるためSTR$で下位桁を文字化してしまうと上位と下位の間に
不要なマイナスが入ってしまうにょ。
したがって、下位桁は絶対値でないとダメにょ。
とはいえ、さらに例外もあり、上位桁が0の時は絶対値ではだめでその符号もそのまま付ける
必要があるにょ。
簡単な処理とはいえ、私の作ったルーチンの大半はこれら例外処理に対応するためのものと
なっているため（処理時間の面では）馬鹿にはできないにょ。

(3)計算法則の確立については加減算と乗除算のときの小数点の移動がどうなるのかを理解
していれば良いだけなので難しくはないにょ。
そうなるとあとはプチコンの内部演算の仕組みさえ理解していれば問題は全くないにょ。
そもそも1/4096単位で記録されており、それ未満は切り捨てられるということを知らないと
(1)も作ることができないので(1)ができた時点で(3)の条件は満たせそうな気がするにょ。


ということで(1)さえできればあとは難しいことはあまりないといえるにょ。
さて、そうなるとこれまで作られなかったのは(1)が難しいためかもしくは需要そのものが
無かったためだと思われるにょ。
確かに(1)はA%(10000/4096)で固定小数点で記録されたAを整数化した時の下位4桁が抜き出せる
ということを知らなければ詰んでしまうからね。（1bitずつ抜き出せばいいだけなので難しく
ないけどそうすると処理速度が大幅にダウンしてしまう）
あと、ゲームのスコアで使う場合上位、下位に分けた簡易多倍長演算の加算のみで十分に
対応できるため四則演算の必要性もないわけだからね。（加算のみなら例外処理も短くて
済むわけだし）
確かにゲームなどを作る際に何百万、何千万という整数値で四則演算をするという機会は
ほとんどないためこれは仕方ないのかもしれないにょ。
もっとも誤差の出ない整数演算で21億まであれば今までプチコンでは困難だった多くの実務
演算はこなせるけど元々プチコンでそういう需要は少なそうだからね。
実際、このルーチンを作った私でさえ何に使うのかと聞かれたら困ってしまうにょ（笑）
単に出来そうだから作ってみたというだけのことにょ。


さて、話は変わるけど先日twitterのプチコンクラスタにてラスタースクロール祭があったにょ。
http://togetter.com/li/447861
みんなでラスタースクロールを使ったサンプルプログラムを発表しあったけど私も2つほど
作ったにょ。

まず1つ目が旅の扉風ラスタースクロールにょ。
http://twitpic.com/bzsaer
ドラクエの旅の扉のような演出で2枚のGRPを入れ替えるという単純なものだけどRPGにおいては
GPUTCHRでGRPに描き出せば実際に旅の扉みたいな感じで使うことができるにょ。
あとはこれを使って文字を表示して少しずつ見えていく文字を当てるクイズゲームなどにも
使えるかもしれないにょ。

続いてテキストラスタースクロールにょ。
http://twitpic.com/bzsbi8
こちらはコンソール文字をすべて書き換えて強引にラスタースクロールを実現しているもので
非常に重いのが特徴にょ。
これはプチコンのCHRSETによる書き換えがこういう用途には向いていないというのもあるけど
横1列がすべて同じ文字で代用が効く横縞模様にすれば大幅に高速化が可能だと思われるにょ。
実際何に使えるのかというのは悩みどころだけどGRPに余裕がなくBGFしか利用できないという
特定条件下でなら使えるかもしれないにょ。（そういう状況はよほどの例外だけど）

1465：マリモーマ：2013/02/02(土) 19:56:44
HDD
HDDなどのPCパーツが値上がりしてるらしい
http://news4vip.livedoor.biz/archives/51929436.html

今　壊れたら高くつくかも
もしかしたら反動で　すごく安くなるかもね

http://liv0.com

1466：御茶目菜子：2013/03/02(土) 02:03:02
レスにょ
マリモーマさんへ
＞HDDなどのPCパーツが値上がりしてるらしい

急激な円安が起きているから仕方ないとはいえ値上げはあまり良いものではないにょ。

＞今　壊れたら高くつくかも
＞もしかしたら反動で　すごく安くなるかもね

HDDは元々タイの大洪水以降極端な値上がりになってしまっていてそれから1年半もの歳月を
かけて徐々に元の水準に戻りつつあったのがここにきてまた値上がりとなってしまった
からね。
確かにまた以前のような極端な円高になれば値下がりの可能性もあるけど極端に安くなると
いうことはないかもしれないにょ。
そもそも、HDDは競争が激しくどんどんメーカーが吸収合併してきているし、一昨年、昨年
と2年連続マイナス成長（一昨年は洪水被害で十分な供給ができなかったため仕方がない）
となっているため薄利多売よりもより利幅の大きなエンタープライズ向けを重視している
傾向があるにょ。
したがって、価格を下げて（つまり利幅を下げて）たくさん売ろうとするメーカーも
無いのではないかと思われるにょ。
とはいえ、プラッタ密度が上がれば同じ容量当たりの製造コストが下がるため長期的に
見れば容量単価は値下がりすると思うにょ。

1467：天郷思音：2013/03/03(日) 07:47:53
プチコンの怪しい挙動
FOR I=9 TO 7のように中をスキップするFORがあるとき 、FOR I=8 TO 4NEXTのように:を省略するとnextがあるにもかかわらずFOR without NEXTがでる。

1468：御茶目菜子：2013/02/03(日) 23:31:19
レスにょ
天郷思音さんへ
＞FOR I=9 TO 7のように中をスキップするFORがあるとき 、FOR I=8 TO 4NEXTのように:を省略するとnextがあるにもかかわらずFOR without NEXTがでる。

先日も書いたようにプチコンはインタープリタである以上はリアルタイムで構文解析が
行われているため「スキップする」けど中はちゃんと読み取られているにょ。
そうなるとなおさら「FOR without NEXTが出るのはおかしい」と思うかもしれないけど
これはプチコンにおいてはNEXTがどのような形で現れたら実行されるというのが定義付け
られているためだと思うにょ。

例えば次のような場合もFOR without NEXTが出るにょ。

FOR I=9 TO 7
BEEP 1NEXT　（改行を間に挟んでもNEXTは認識しない）

FOR I=9 TO 7:BEEP 1NEXT　（FORの後にコロンを入れてもNEXTは認識しない）

つまり、プチコンにおいてスキップ状態から復帰するためにはNEXTの前にコロンを入れる
必要があるということにょ。

FOR I=9 TO 7NEXT:BEEP 1:NEXT

これを実行すればBEEPは鳴らず最初のNEXTとBEEP 1はスキップされて後のコロン付きNEXT
のみが実行されていることが分かるにょ。
あと、常に行頭から実行されるためNEXTを行頭においておけばコロンを含まなくてもちゃんと
認識可能になるにょ。

FOR I=9 TO 7BEEP 1
NEXT　（コロンを入れてないけどNEXTは認識する）

つまり、これは命令の区切りはコロンを省略していてもちゃんと行えているけどコロンが
ないと誤動作する場合もごくまれにあるという例だと思われるにょ。
とはいうものの本来はコロンを付けるのが当たり前であり、これをバグとして捉えるのは
正しいとはいえないけどね。

1469：御茶目菜子：2013/02/05(火) 23:49:02
プチコンでマルチタッチを行おう
プチコンはDSで採用されている感圧式のタッチパネルというハードウェアの制約によって
マルチタッチでは使用できず、1点タッチのみとなっているにょ。
普段はこれで困ることはないけどマルチタッチに対応していれば作れるプログラムの幅が
広がるのも事実にょ。
それならば、「無い物は作る」の原則によって作ってみたにょ。

　マルチタッチ検出ルーチン
　http://ww5.tiki.ne.jp/~ochame/petitcom/multi_touch.htm

では、ハードウェアが対応していないマルチタッチにどうやってソフトウェアで対応が可能に
なるかというとそれは実は非常に簡単なものにょ。
プチコンではタッチした座標はシステム変数TCHX、TCHYに入っているけど2点以上同時にタッチ
した際には2点のうちのどちらかを示すのではなくタッチした座標の中間付近の座標を示す
ためにょ。（これは感圧式タッチパネルならばだいたいそうなっている）
具体的に言えば(80,60)と(180,120)をタッチすれば(130,90)付近の座標を示すということにょ。
次のようなプログラムによって2点タッチした場合にはほぼ中間を示すというのは実際に目視
できるようになるにょ。

PNLTYPE "OFF"
GPAGE 1
@MAIN
GCLS
GCIRCLE TCHX,TCHY,5,2*TCHST
WAIT 1
GOTO @MAIN

ならば、TCHX、TCHYの値さえ分かれば2点の座標が分かるかというとそんなことはないにょ。
(80,60)と(180,120)をタッチすれば(130,90)付近の座標を示すけれど(100,90)と(160,90)を
タッチしても(130,90)付近の座標を示すわけだからね。
これは当然のことであり、結果的にほぼ中間になるわけであって逆算はできないにょ。
しかし、タッチしている2点のうち1点が分かればその座標を元に計算が可能になるにょ。
この場合も1フレームの差もなく完全に2点を同時押ししてしまうとただの中間の座標以外は
分からないけど2点のうちどちらかが1フレームでも先に押していればそれを元に計算が
できるわけにょ。

では、すでに1点タッチしている状態から2点タッチと認識させる方法について考えてみるにょ。
「TCHX、TCHYが変動したら2点タッチ」と見なすと1点タッチして少し手がぶれただけで2点
タッチと認識してしまうにょ。
したがって、ある程度の許容量が必要になるにょ。
普通に押していてほぼありえない1フレーム距離20ドットという基準にしたければ2点間の
距離が20以上になれば2点タッチフラグが立つようにすればいいにょ。（2点間の距離は
X座標の差分の2乗とY座標の差分の2乗を加算したものの平方根を計算すればいい）

20ドット動いた時点で2点タッチを確定してしまうとまた厄介な問題があるにょ。
というのも、上記の2点タッチした場合のTCHX、TCHYの位置を示すサンプルを実行したら
分かるように1点タッチの状態から別の場所をタッチしても瞬時にその中間付近の座標を示す
わけではなく数フレームかかっているにょ。
20ドット動いた瞬間にそこが中間地点の座標と確定してしまうと大きな誤差が生まれてしまう
ことになるためTCHX、TCHYの値の変動がある程度収まってから確定した方がいいにょ。
これは0ドット（完全停止）でもいいけどそうすると精度が高くなる反面で少しでも動いている
間は2点タッチを確定できないため設定で自由に変えられる方が望ましいにょ。
さて、問題は2点タッチが確定される前に離した場合にょ。
その場合はTCHX、TCHYの値の変動が止まった時点で確定されるため1点目とほぼ同じ点を押して
いると認識されてしまうにょ。
そのため一定以上の距離でないとマルチタッチとは認識しないという判定が別途必要になって
くるにょ。

次に2点タッチの状態から1点タッチになったかを判定する処理だけどこれはマルチタッチでも
2点タッチまでに限定することで非常にシンプルになるにょ。
タッチポイント数が変動する場合は上記のように一定以上TCHX、TCHYが変動したかどうかで
判定すればいいのだけど2点タッチまでであれば0点、1点、2点のいずれかになり、TCHSTで
タッチ判定があるならば1点タッチ、そうでなければ0点タッチになるにょ。
つまり、2と1を繰り返すカウンタを用意してそれにタッチ状態にあるか否かを示すフラグ
（1か0）を組み合わせるだけでタッチポイント数が分かり、特に難しいことは何もないにょ。
これが3点タッチに対応させる場合には変動したTCHX、TCHYから計算したタッチ座標を
1点目や2点目と比較してそれと同一ではない（一定以上離れている）かどうかという判定に
よって実現することが可能になるにょ。
このようにすでにタッチしている座標を比較することで理論上は何点でも対応できるけど
後述のような誤差の問題があるため3点以上に対応させるメリットは無いと言えるにょ。


このようにマルチタッチと認識させる処理そのものは比較的簡単なのだけど実はそれよりも
精度を上げる方が遙かに難しいにょ。
今までは2点をタッチしたらTCHX、TCHYはその中間付近の座標を示すと書いたけどこれは正確に
いえば正しくはないにょ。
面積が無限大で均一となっている理想的なタッチパネルならばほぼ正しいのだけどタッチ
パネルのサイズは有限だからね。
端に行けばいくほどタッチした場合には枠からの力という全く別の力が働くし、四隅だと
縦横の枠があるためより複雑な力が働きそれに対するずれがあるにょ。
実際四隅付近をタッチした場合には中間よりも30〜40ドットずれることもあり、その2倍
したものが2点目の座標となるため誤差も倍増されてしまうにょ。
つまり、何も補正しなければ60〜80ドットのずれは覚悟しないといけないということにょ。
それだけずれたら縦横2分割（田型）のボタンをタッチパネル上に表示してもそれを正しく
マルチタッチで認識することはできないにょ。

では、どうやって補正を加えたら良いのかというとこれがなかなか難しいにょ。
分かっていることは「画面中央より隅の方がずれが大きい」「四隅の枠はどれもずれる量が
異なる」「タッチしている2点のX座標（Y座標）が同じ場合はどの座標をタッチしてもTCHX
（TCHY）の値はそれと同じものを示す」ということにょ。
つまり、中央より端に行くごとに大きな補正を与えて、四隅にはすべて異なる基本補正量を
与えて、X座標（Y座標）の差分に応じた補正を与えれば良いといえるにょ。
この辺をすべて加味して作ったのが今回のマルチタッチルーチンにおける補正ルーチンにょ。
四隅に与える異本補正量は私の3DSを元にして数値を入力したため個体差は十分に考えられる
けれど簡単に変更できるようにしてあるためそれは各自の手持ちの本体に合わせて補正を
行えばいいのではないかと思うにょ。

ここまで補正を行っても平均で10ドット程度の誤差が発生しているにょ。
あくまで平均だからタッチする座標によってはさらに大きな誤差があるにょ。
とはいえ、端の方をタッチしたら50ドット以上の誤差は当たり前という補正前のものと
比べると補正効果は極めて大きいことが分かるにょ。
これ以上正確にするためには補正ルーチンの分割数を上げたりとか、補正アルゴリズムを
変更したりする必要があるにょ。

では、今回発表したマルチタッチ検出ルーチンが実用になるかというと微妙にょ。
まずは2点の完全同時押しには対応できないし、（これでも）精度優先であるため検出まで
数フレームの時間を要してしまい激しいタッチ操作のゲームなどには使えないからね。
あと問題は誤差によるものにょ。
例えばこうやまさんの4方向タッチペン素材（タッチパネル上のソフトウェア十字ボタンと
ソフトウェアABXYボタンによる操作が可能になるルーチン）に組み込んで使用してみた
ところ、画面上のボタンの中心を完璧に押すことができたら何とか使えるものの座標に
よってはずれが大きいため隣のボタンとして認識されてしまうことも多々あったにょ。
私が作ったPETIT KEYBOARD mkIIに組み込んで使用してみたところ、白鍵数が5以下ならば
それなりに使えるもののそれよりも多くすると隣の鍵盤として認識してしまうことも少なく
ないためかなり微妙にょ。
やはり、実用レベルにするためにはワーストケースで10ドット以下、平均だと5ドット程度
まで誤差を減らさないと厳しいと言えそうにょ。
最大誤差が10ドットならば白鍵数が8（鍵盤サイズ32ドット）でも確実な当たり判定は12
ドット分確保できるためそれなりに使えるレベルになるからね。

したがって、実用になるかどうかは微妙だけどプチコンで「マルチタッチは無理」ではなく
動作させるだけならばいくらでも可能ということくらいは分かってもらえたのではないかと
思うにょ。
今までプチコンでマルチタッチということで多くの人が考えそのものがあっただろうけど
実際に発表されたものは簡易マルチタッチ検出ルーチンのように左右検出くらいがせいぜい
だったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#multi
「2点タッチの場合はTCHX、TCHYの値が2点のほぼ中間付近の座標を示す」とはいえ実際に
それで実用レベルのものを作るのは今回書いたように極めて難しいことが分かり発表には
至らなかったというせいもありそうにょ。
私も実用レベルにまで完成度が高まったら発表しようと思っていたけどこれ以上の大幅な
精度向上は難しいと判断したため今回の発表に至ったにょ。
とはいえ、認識ルーチン（基本部分）と補正ルーチンは分離させているため補正ルーチンの
方は今後良いアイデアがあればどんどん改善していく予定にょ。

1470：天郷思音：2013/02/07(木) 20:49:15
正しく変換できるかな
蠣焼くときは火気に注意と下記に書き

1471：御茶目菜子：2013/02/07(木) 23:28:05
レスにょ
天郷思音さんへ
蠣焼くときは火気に注意と下記→牡蠣焼くときは下記に注意と下記に書き

となったにょ。（by ATOK16）

あと
金星か土星か火星→金星か土星か火星
ウニとエイ→ウニ都営
だったにょ。

一旦正しく確定したら次からは一発変換されるもののさすがにATOKといっても日常会話でよく
出るような言葉でないと100％の変換はできないにょ。（もっともかなり古いバージョンを
そのまま使っているので今のバージョンならばもう少しは変換率は良くなってそうだけど）

1472：御茶目菜子：2013/02/08(金) 23:59:59
プチコンでは画像にGRPリソースは使わない方がいい・・・？
MONOistのプチコン虎の穴も今回で10回目となったにょ。
http://monoist.atmarkit.co.jp/mn/articles/1302/07/news003.html
今回はコンソールキャラではなくグラフィック命令を使って女の子の絵を描くというものにょ。
プチコンではユーザーの手によって非公式ながらPCで作成したデータを使用可能になって
いるにょ。
例えばPC上で描いた絵や写真などをで256x192にリサイズしてBMP形式で保存すればそれを
プチコンで読み込める形式に変換可能になるようなツールはいくつも作られているにょ。
そのため1枚絵をふんだんに使ったギャルゲーなども作ることは可能なのだけど問題はQR
コードの枚数にょ。
公式変換ツールを使った際には1枚のQRコードには630バイト分のデータしか入らないからね。
256x192ドット256色の画像は無圧縮だと48KB（49152バイト）になるためQRコードの枚数は
単純計算で79枚に達するにょ。

しかし、QRコード化の際にはzip圧縮がかかるためサイズは大幅に軽減可能にょ。
とはいえ、半分のサイズに抑えられても40枚弱となるにょ。
例えば私が書いたこの桔音紺の絵があるにょ。
http://ww5.tiki.ne.jp/~ochame/CG/kon.jpg
これをプチコンで読めるように変換した場合にはQRコードは25枚になったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/kon/
これでもグラデーションを削るなどの多少の軽減措置は行っているものの枚数を減らす
ためにはアニメ調のベタ塗りやタイルパターンを使うか減色するしかないにょ。（PC上で
リサイズする場合にはサイズ縮小時に補完機能が働き逆に色数が増える場合がある）
しかし、減色によってサイズを半分にするためには単純計算では256色から16色にする
必要があるためかなり無理があるにょ。（実際にPC上で減色ソフトを使って256色の画像を
16色に減色してみれば分かるけどどんなソフトを使っても無理矢理減色した感じがはっきり
出てしまうため極端に減色するならば塗り直す必要がある）

QRコードの枚数は何とかなるという場合でも問題はプチコンの保存領域にょ。
具体的にどれくらいかは分からないけど私の感覚だと数MB（4〜5MB程度）といった感じに
なっているにょ。
QRコードでは圧縮された状態となっているため色数を減らしたり塗りを単純化することで
枚数を減らせたとしてもプチコン内部に保存するときは無圧縮となっているためQRコード
1枚に収まるような単純なGRPでも48KBの保存領域を消費してしまうにょ。
それでも数10枚のGRPが保存できることになるのだけどそのプログラム1本だけ保存する
というのではなくWeb上で公開されているプログラムをどんどん保存しているような人
であればGRPは極力避けたいと思っているのではないかと思うにょ。

その1つの改善策となるのが私が作ったCHRセーバーとCHRローダーにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#05
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#06
これはプチコンで広まっているGRPによるセーブだけどほんの数KBのセーブデータであっても
上記のように48KBも保存領域が必要になるためそれを何とかしたいということで考えて作った
ものにょ。
CHRリソースは8KBなので8KBまでのGPRによるセーブデータならば単純計算で保存領域を1/6に
圧縮したのと同等の効果が得られるにょ。
ただし、CHRリソースは32バイト単位でないと読み書きできないという不便さがあるため
その手助けをするために作ったのがCHRセーバーとCHRローダーというわけにょ。（要するに
GRPの1/6の領域をCHRリソースに変換するだけのもの）
このCHRセーバーをGRPの1枚絵を保存するためにはGRPの絵を圧縮して8KB以内に抑える必要が
あるにょ。
GRPの圧縮そのものは難しくはないけど圧縮後のサイズは圧縮してみないと分からないため
8KBに収まらないときは絵の修正が必要になるという問題があるにょ。（CHRリソースを複数
使うという方法もあるけどその場合は圧縮効果が小さくなるし連番で何枚あるのかを別途管理
しなくてはならなくなってしまう）

そこで、プチコンでGRPによる1枚絵を用意するならば（保存領域やQRコード枚数の両面に
おいて）サイズ面で最もお手軽となるのが今回のプチコン虎の穴で使われているような
座標データを元にGLINEでつなげてGPAINTで塗るという方法にょ。
この方法はかつて8ビットパソコンにおいてもデータ量の関係から画像データとして1枚絵を
用意することが難しかったため同様の方式で描いていたゲームも多数存在したにょ。
MAG形式などの圧縮形式が確立した頃からようやく座標を元にプログラムで描くのではなく
1ドット単位で構成された画像データの1枚絵として用意されることになったにょ。
現在でもドロー系、ペイント系として両者は残っているけどそれぞれにメリットとデメリットが
あるため片方だけが残るということは今後もないと思われるにょ。

さて、現実的に考えると座標指定で女の子の絵を描く場合は少なく見積もっても200〜300個
程度の線画用の座標が必要になるにょ。
1つのデータが3桁＋コンマの4文字でX、Y座標で合計8バイトとすると200個ならば1.6KB、
300個ならば2.4KBとなるにょ。
これにペイント用の座標が必要になるため2〜3KBが最低ラインといえそうにょ。
仮に50枚用意したら100〜150KBという（プチコンとしては）かなり大きなデータ量になって
しまうにょ。
しかし、これはあくまでDATA文で記述する場合であり、この頂点座標をGRPに入れるならば
また話は変わるにょ。
GRPでは1ドットで0〜255が表現できるためX座標、Y座標の指定は2バイトで収まるにょ。
そうなるとDATA文による2KB分の頂点座標データはGRPならばわずか512バイト程度に収まる
計算になるにょ。
3KB分でもその1.5倍にょ。
1枚のGRP（48KB）にはこのレベルのデータ量ならば64〜96枚はいる計算になるにょ。
1枚ごとに座標データが何個あるのかなどの管理データが別途必要であるものの1枚のGRPには
50枚程度の1枚絵は十分に入りそうな感じにょ。（もっとも200〜300個の座標データという
のはかなり少なめであるためもう少し緻密な絵にしたければその数倍のデータ量になるけど）

私がその方式で描いた絵というのはダミーちゃん危機一髪での包丁のグラフィックがあるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/dmmy_chan.htm
ただし、これはDATAではなくGLINEを直打ちで作ったにょ。
それは短時間で作るには脳内座標をそのまま打てるGLINEの方が便利だったからにょ。（大量に
あればちゃんとDATAで作った方がいいけどこの程度ならばGLINEで記述してもそれほど多くの
サイズアップにはならない）
そして、今回はまた別の絵を使ったプログラム「神風の術」を作ってみたにょ。
http://twitpic.com/c1uyjv
2月1日に書いたラスタースクロール祭の時に続いて第3弾として作った簡単なものであるため
1枚絵といっても見ての通りの単純なものだけど今回も制作時間短縮のためDATAではなく
GCIRCLEの直打ちで作ったにょ。
GLINEではなくGCIRCLEなのは簡単に説明するとその方が自然な曲線が描けるからにょ。
包丁データを作った時は直線が多かったので楽だったけど今回はかなり長目の曲線が多用
されているためGLINEだと上手い曲線を引くには時間がかかるし、さらにデータも多めに
なってしまうからにょ。（ちなみに今回も脳内画面に円を描いてその脳内座標をプチコン上に
転写して誤差を修正したもの）
やはり、プチコンで1枚絵を使ったものならばGRPで1枚1枚の画像を用意するよりもこのように
プログラムで座標データを元に描くのが1番かもしれないにょ。

1473：御茶目菜子：2013/02/10(日) 23:59:34
プチコン用の便利なルーチン
私はプチコンにおいては音楽系のツール（主に楽器演奏や音階演奏）を良く作っている
けれど画像系のツールはあまり作ってないにょ。
その理由は簡単で標準で備わっているCHREDやGRPEDなどの画像系のツールはそれなりに
あるからね。
そして、ユーザーの手によって多くのものが発表されていて私が作る必要性がほとんどない
というのが結局のところ理由となっているにょ。（それにプチコンでキャラや絵を描いたり
しないし）

さて、誰も作って無さそうということでレイヤー対応のお絵かきソフトも即興で作った
もののレイヤーに対応しているだけでそれ以外の出来はあまり良くないので試作品を作って
そのまま放置状態にょ。（レイヤーに対応させるためレイヤーを2枚使った段階でGRP面を
4面フルに使っており機能を拡張する余地がないというのもあるし）
PC向けの画像処理ソフトだとレイヤーだけではなくレイヤーモードも充実しているにょ。
レイヤーは単なる不透明度100％の画像の重ね合わせだけではなく不透明度は自由に調整
できるし、乗算やスクリーンといった重ね合わせ用のモードも豊富にょ。

では、プチコンで乗算やスクリーンといった処理は可能なのか・・・？
これは実は難しいことは全くないにょ。
ただし、これには条件があって、単色重ね合わせに限るけどね。
別の絵を重ね合わせる場合には256色のパレットによる処理であるため理論上不可能（高速で
2枚を交互に表示して重なっているように見せかけることは可能だけど単にちらついた絵に
なるだけ）とはいえ、単色の重ね合わせ処理ならば256色からさらに必要な色数が増えることは
ないからね。

というわけで、今回ターゲットになったのは通常、乗算、スクリーンの3つにょ。
通常は一般的な重ね合わせであり、乗算は重ねた分だけ暗くなる、スクリーンは重ねた分だけ
明るくなるというモードにょ。
これはGRP、SP、BGの各面ともに256色すべて所定の方法による演算を行えばこの3つにおいては
非常に簡単に実現できるにょ。

@BLENDCOL
FOR J=0 TO 2
　RS$(J)=MID$("GRSPBG",J*2,2)+"P"*!J
　RS$=RS$(J):GOSUB @COLREAD
　COL(J)=VAL("&H"+MID$(COL$,J*2,2))
NEXT
COR=COL(0):COG=COL(1):COB=COL(2)

FOR J=0TO 2
　RS$=RS$(J)
　ON BM GOSUB @BMNORMAL,@BMMULTI,@BMSCREEN
NEXT
RETURN

@BMNORMAL
FOR I=0 TO 255
　CR=CR(I,J)+(COR-CR(I,J))*OP
　CG=CG(I,J)+(COG-CG(I,J))*OP
　CB=CB(I,J)+(COB-CB(I,J))*OP
　COLSET RS$,I,HEX$(CR,2)+HEX$(CG,2)+HEX$(CB,2)
NEXT
RETURN

@BMMULTI
FOR I=0 TO 255
　CR=CR(I,J)-(255-COR)*OP:CR=CR*(CR>0)
　CG=CG(I,J)-(255-COG)*OP:CG=CG*(CG>0)
　CB=CB(I,J)-(255-COB)*OP:CB=CB*(CB>0)
　COLSET RS$,I,HEX$(CR,2)+HEX$(CG,2)+HEX$(CB,2)
NEXT
RETURN

@BMSCREEN
FOR I=0 TO 255
　CR=CR(I,J)+COR*OP:IF CR>255 THEN CR=255
　CG=CG(I,J)+COG*OP:IF CG>255 THEN CG=255
　CB=CB(I,J)+COB*OP:IF CB>255 THEN CB=255
　COLSET RS$,I,HEX$(CR,2)+HEX$(CG,2)+HEX$(CB,2)
NEXT
RETURN

@COLREAD
FOR I=0 TO 255
　COLREAD(RS$,I),CR(I,J),CG(I,J),CB(I,J)
NEXT
RETURN

@COLINIT
FOR J=0TO 2:COLINIT RS$(J):NEXT
RETURN
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#blend

256色x3画面分の色を処理するわけだから処理速度面では難があるけどあらかじめすべての
パレットの色を配列変数に入れておいておけば処理速度は高速化でき表示の色が部分的に
じわじわ変わるという問題も防ぐことができるにょ。
拡張性を重視した設計になっているので今後さらに他の描画モードが欲しくなったら
その時に簡単に追加は可能にょ。
単色の重ね合わせといってもこれによって表現力はかなり増すにょ。
例えば夕焼けのステージやフィールドだったら全体をオレンジ色っぽくすることで雰囲気を
出すことができるし、海の中ならば全体的に青っぽくすることで雰囲気を出すことが可能に
なるにょ。
これはあらかじめそれ専用のパレットを作っておけばいいけどこのルーチンを使えばそんな
ことをしなくても手軽に実現でき、さらに微調整もいくらでもできるというのが大きいにょ。
これによってゲームの表現力が増すのではないかと思われるにょ。（もっとも画面内にGRPを
使用しておらず、60fpsで動作しており不透明度50％固定の通常重ね合わせに限定するならば
このようなルーチンを使わなくてもGRPIO 1にして特定色のGRPの表示と非表示を繰り返す
だけで簡単に擬似的な重ね合わせができるけど）

このパレットを彩度や色相ではなく明度だけに絞って少しずつ変化させればフェードインや
フェードアウトのルーチンも簡単にできるにょ。

@FADEIN
FOR K=1 TO ST
　FOR J=0 TO 2
　　RS$=RS$(J)
　　FOR I=0 TO 255
　　　COLSET RS$,I,HEX$(CR(I,J)*K/ST,2)+HEX$(CG(I,J)*K/ST,2)+HEX$(CB(I,J)*K/ST,2)
　　NEXT
　NEXT
NEXT
RETURN

@FADEOUT
FOR J=0 TO 2
　RS$(J)=MID$("GRSPBG",J*2,2)+"P"*!J
　RS$=RS$(J):GOSUB @COLREAD
NEXT
FOR K=1 TO ST
　FOR J=0 TO 2
　　RS$=RS$(J)
　　FOR I=0 TO 255
　　　COLSET RS$,I,HEX$(CR(I,J)*(ST-K)/ST,2)+HEX$(CG(I,J)*(ST-K)/ST,2)+HEX$(CB(I,J)*(ST-K)/ST,2)
　　NEXT
　NEXT
NEXT
RETURN

@COLREAD
FOR I=0 TO 255
COLREAD(RS$,I),CR(I,J),CG(I,J),CB(I,J)
NEXT
RETURN
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#fadein

フェードイン、フェードアウトはR、G、Bを同じ割合で減らすことで明度だけを変えているにょ。
この徐々に変えるというのは上記の色の重ね合わせ処理でも可能であり、昼→夕方→夜という
変化を画面上でシームレスに行うことも可能になるにょ。
単に思いつきで作ったもののそれなりに使えそうなルーチンだと感じるにょ。
まぁ自分で使うかどうかは別問題だけど・・・（笑）

便利そうなルーチンというとプチコンでは様々な使い方が模索されているけど縦持ちでゲーム
などを作るというのは結構ハードルが高くなっているにょ。
というのも標準では縦持ちフォントは用意されてないからにょ。
しかし、90度回転させたものをCHRSETで定義するだけでいいのでやり方さえ分かれば非常に
簡単にょ。

@FROTATE
FR=1:Z=3.5
GPAGE 1
FOR I=0 TO 255
　GCLS:C$=""
　GPUTCHR 0,0,"BGF",I,0,1
　FOR X=Z-FR*Z TO FR*Z+Z STEP FR
　　FOR Y=FR*Z+Z TO Z-FR*Z STEP -FR
　　　C$=C$+HEX$(GSPOIT(X,Y))
　　NEXT
　NEXT
　CHRSET "BGF",I,C$
NEXT
GCLS
RETURN
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#font_tate

縦持ちといっても十字ボタンを下にするかABXYボタンを下にするかで回転方向が変わってくる
けれど上記のプログラムは両方に対応させたものとなっているにょ。
しかし、縦持ち用フォントができたからそれで縦持ち用ゲームが簡単にできるかというとそう
ではないにょ。
例えば、座標(10,5)に「OCHAME」と表示する場合には普通だったらLOCATE 10,5:?"OCHAME"と
すればいいわけだけどABXYボタンを下にした縦持ちをしている場合にはLOCATE 5,13:?"O":
LOCATE 5,12:?"C":LOCATE 5,11:?"H":LOCATE 5,10:?"A":LOCATE 5,9:?"M":LOCATE 5,8:?"E"と
いう感じで1文字ずつ分けて表示する必要があるにょ。
この表示方法には規則性があるので表示ルーチンを作ってしまえば簡単ということでこれも
作ってみたにょ。

@TPRINT
LN=LEN(MES$)
L1=INSTR(MES$,",")
L2=INSTR(MES$,":")
X=11.5-FR*11.5+VAL(MES$)*FR
Y=15.5+FR*15.5-VAL(RIGHT$(MES$,LN-L1-1))*FR
FOR I=L2+1 TO LN-1
　Z$=MID$(MES$,I,1)
　IF!CP THEN COLOR COL:LOCATE Y,X:?Z$;
　IF CP THEN PNLSTR Y,X,Z$,COL
　X=X+FR
　IF X>23THEN X=0 :Y=Y-FR
　IF X<0 THEN X=23:Y=Y-FR
NEXT
RETURN

@FROTATE
FR=-1:Z=3.5
GPAGE 1
FOR J=0 TO 1
　FOR I=0 TO 255
　　GCLS:C$=""
　　GPUTCHR 0,0,"BGF"+"L"*!J,I,0,1
　　FOR X=Z-FR*Z TO FR*Z+Z STEP FR
　　　FOR Y=FR*Z+Z TO Z-FR*Z STEP -FR
　　　　C$=C$+HEX$(GSPOIT(X,Y))
　　　NEXT
　　NEXT
　　CHRSET "BGF"+"L"*!J,I,C$
　NEXT
NEXT
GCLS
RETURN
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#tate_print

プチコンの場合は上画面用と下画面用ではフォントが異なるため上記の縦持ち用フォント
生成ルーチンを上下画面に対応するように改変しているにょ。
実際表示に関する部分はサブルーチン@TPRINTのみにょ。
しかし、表示を行うにしても座標のためにいちいちX座標用の変数、Y座標用の変数に値を
入れて表示内容を文字列変数に入れてGOSUB @TPRINTとするのは面倒なので表示内容に
座標情報も含むことにしたにょ。
どのようにするかもポイントの1つだけどこのルーチンでは(10,5)に「OCHAME」と表示する
場合にはMES$="10,5:OCHAME"とするだけでいいにょ。
X座標、Y座標を,と:で区切っているというだけのことだけどこれにVAL命令が文字の場合は
スルーされるという特性を加味すれば構文解析は簡単に済むにょ。（これはOMPでも使用
されている私が昔から使っている手法だけど）
その特性を使えば追加処理をしなくても「0」の場合は引数も省略可能になるためにこの
ルーチンを使うユーザーも記述が楽になるというメリットがあるにょ。
私が縦持ち用のゲームを作るから作ったというわけではないのだけど少しでも役に立てれば
いいかなと思っているのでどんどん使ってもらえたらうれしいにょ。

1474：トービンウルフ：2013/02/11(月) 23:14:41
(無題)
電子機器類の更新を検討中とのことですが

PCについては
・1kg前後のモバイルノート、
・デスクトップによる画像処理、
・数年以上の保守性はあったほうが望ましい
ということを考えると

強めのGPUと交換可能なバッテリー,13インチ前後の1600x900 〜 1920x1090の液晶を積んだ thinkpad
の1.3kg前後のが出るのを待ってPCは一台で済ませるというのはありうるのではないでしょうか。
中古二つなら新品一つとそれほど値段に差は出ないと思いますし。お使いのlet'snoteからだと
ちょっと重くなっちゃいますが。

あとスマートフォンはMNPなどを駆使して維持費などを非常に安く済ませる手段があるようなので
その辺りを追求するとよいのではないでしょうか。（なんでもMNPを弾丸としてどうこうとかそういう世界があるようです。）Wimax回線のものなどをうまく使うと自宅の回線なしで済ませられることもあるようです。大型のスマートフォンでタブレットとしても使うというのもありえますね。　

1475：御茶目菜子：2013/02/12(火) 00:39:06
レスにょ
トービンウルフさんへ
＞強めのGPUと交換可能なバッテリー,13インチ前後の1600x900 〜 1920x1090の液晶を積んだ thinkpad
＞の1.3kg前後のが出るのを待ってPCは一台で済ませるというのはありうるのではないでしょうか。

ご意見どうもにょ。
モバイル用と自宅用を兼任して1台で済ませるならばそのクラスがベターだと思うけどやはり
モバイル重視で考えると現在使っているR5のサイズがベストだと私は考えているにょ。
モバイル用には長年アンダーB5サイズのPCを使い続けており、途中で11インチクラスを使った
時には（私にとっては）大きすぎてモバイルには使えず結局買い換えたくらいにょ。
スマホやタブレット端末でPCが不要になるならばそこまでモバイル重視にする必要はない
ものの現実的にはまだそういうわけにはいかないので買い換えるならば中古のRシリーズか
サイズ面では少し妥協してJシリーズになると思うにょ。

＞あとスマートフォンはMNPなどを駆使して維持費などを非常に安く済ませる手段があるようなので
＞その辺りを追求するとよいのではないでしょうか。

普段PCを持ち歩いているしiPod touchもあるので別にスマホをそんなに急いで買わないと
いけないというわけでもないにょ。
欲しいといえば欲しいけど優先順位を付けるとすれば上記のモバイルノートの方が上にょ。

1476：御茶目菜子：2013/02/12(火) 23:59:56
プチコンによる塗りつぶし描画ルーチン
またあれば便利そうなルーチンをいくつか作ってみたにょ。
まず、1つ目は塗りつぶし円（楕円）描画ルーチンにょ。
ネット上でプチコン関係の書き込みを見ると塗りつぶし円や楕円が描けないということに
不満を持っている人がいるからね。
塗りつぶし円は簡単なんだけど実は落とし穴があるにょ。

　GCIRCLE 128,96,60,2
　GPAINT 128,96,2

これで(128,96)を中心とした半径60の赤色の円が描けるのでそれをGPAINTで塗れば赤色に
なるかというと必ずしも塗りつぶせるとは限らないにょ。
というのも円の下に何も描かれてないとは限らないためにょ。
したがって、GPAINTで中心点を指示したらそこからどこまで塗りつぶせばいいかを明確に
する必要があるにょ。
それさえ分かれば後は簡単で画面上で使ってない色を境界線に設定すればいいだけにょ。
GCOLOR 255を使ってないならばこれで塗りつぶせるにょ。

　GCIRCLE 128,96,60,255
　GPAINT 128,96,2,255

これではこの上からさらに描くことはできないので最後にGCIRCLE 128,96,60,2としておけば
完璧にょ。
では、塗りつぶし楕円はどうなのかというとそもそもプチコンでは楕円を描く命令がないため
自前で用意するしかないにょ。
楕円の前に円をGCIRCLEで描く方法を考えてみるとこれは正多角形を細かく描けば円に近くなる
ということを利用すれば簡単にできるにょ。
例えば時計の文字盤の12時の方向を0度として時計回りに描画していく場合には正180角形は次の
ように描けるにょ。（どのように描画されているかはNEXTの前にWAIT 3を置けばよく分かる）

　X=128:Y=96:R=60:C=2
　X1=0:Y1=R
　FOR I=0TO 360 STEP 2
　　X2=SIN(RAD(I))
　　Y2=COS(RAD(I))
　　GLINE X+X1,Y-Y1,X+X2,Y-Y2,C
　NEXT

これで円の描画ルーチンは完成したので上記のように境界色を変えて描いてGPAINTしてそして
描画色で描き直せば完了にょ。
楕円の場合はX座標、もしくはY座標に加える値に一定の比率で掛け合わせるといいだけにょ。
しかし、そんなことをしなくても塗りつぶし円は描けるにょ。
というのもY軸に平行な直線を用意してそれをX座標を1ずつ大きくしていき円と直線の交点の
座標を求めてその2点を繋げばいいだけにょ。
こうして書くと難しそうだけど実は簡単で半径10の円ならばX座標は描画座標の中心点を原点と
した相対座標で-10、-9、ｰ8・・・8、9、10と変化させていきX軸上との点と直線と円の交点と
原点を結んだ直角三角形で考えると斜辺は円の半径であるため交点のY座標は三平方の定理から
簡単に求めることができるにょ。
楕円の場合はその縦横比を変えただけなので簡単に求められるにょ。

　FOR I=-R TO R
　　A=F*SQR(R*R-I*I):GLINE X+I,Y-A,X+I,Y+A,C
　NEXT
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#circle

次に考えたのは塗りつぶされた多角形にょ。
多角形は三角形さえ描ければ何とかなるので塗りつぶされた三角形を描くことにするにょ。
これは上記の塗りつぶされた円と同様に境界線の色を変えて三角形を描いてそしてGPAINTで
塗ったら終了にょ。
しかし、ここで厄介なのはどこを基準に塗るかということにょ。
GPAINTの場合はその領域の中の座標を指定しなければならないからね。

これは実は簡単にょ。
確実に三角形の中にある点を指定すればいいにょ。
例えば重心を基準にするならば三点の座標を合算して3で割ればいいので簡単にょ。
そしてできたのがこれにょ。

　FOR J=0TO 1
　　FOR I=0TO 2
　　　GLINE X(I),Y(I),X((I+1)%3),Y((I+1)%3),C*J+!J*255
　　NEXT
　　IF !J THEN GPAINT (X(0)+X(1)+X(2))/3+0.5,(Y(0)+Y(1)+Y(2))/3+0.5,C,255
　NEXT
　RETURN

本来ならば3本＋3本で6本のGLINEが必要になるけどFOR〜NEXTを用いて1本のみの記述で
済むようにしているにょ。
これで概ね問題はないのだけどGPAINTだと細長い三角形の場合は隅の方が塗れないという
問題があるにょ。
それに加えて高さがほぼ0の三角形だと表示誤差によって重心の座標が画面上に描かれている
三角形の中には来ないという問題があるにょ。
要するに細長い三角形は塗れなかったり塗るのに失敗してしまうことがあるということにょ。

これではまずいので別のやり方を考えるにょ。
三角形でも上記の円のようにY軸に平行な直線をX座標を1ずつ大きくしながら変えるという
方法で描くことができるにょ。
ただ一律ではいかず両端の点との間にある頂点を挟んで左右の2回に分ける必要があるにょ。
この変化の割合は1次方程式なので簡単にょ。
できるだけ高速にするためループ内には増分だけ記述することにしたにょ。
ここで問題としてはX座標が同じ点が2つあったらどうなるのかということにょ。
2回に分けることなく1回で済むのだけどそうなると基点の座標も変わってくるためその修正が
必要になるにょ。（あとX座標が同じ2点があったら傾きが無限大、つまり、三角形の辺がY軸に
平行になるためその例外処理も行う必要がある）
そうしてできたのがこれにょ。

　SORT 0,3,X,Y
　X=X(0):Y=Y(0):Z=Y:Q=(Y(2)-Y(0))/(X(2)-X(0))
　FOR J=0TO 1
　　M=X(J)-X(J+1):P=(Y(J)-Y(J+1))/(M+!M):Y=Y+(Y(1)-Y(0))*!M
　　FOR I=X(J)TO X(J+1)-1
　　　GLINE I,Y,I,Z,C:Y=Y+P:Z=Z+Q
　　NEXT
　NEXT
　RETURN
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#triangle

このルーチンでは上記のGPAINTにあるような塗りミスはなくなっているにょ。
塗りつぶし三角形が描画できればポリゴン表示が可能になるにょ。
もっとも、1回平均1.2フレームということで1秒間に平均50回しか実行できないのでこれで
まともにポリゴンゲームが作れるとは到底思えないけどね（笑）
これでも処理速度はほぼ限界に近いのであとは原理上X方向に広い（横長）三角形が遅い
ため横長に最適化したルーチン（Y座標方向に1ずつ大きくしていくようなルーチン）を作り
座標を調べて2者から高速な方を選択するということくらいしかここから大幅な速度向上は
ないにょ。
基本アルゴリズムさえわかればその使い回しがいくらでも効くのでいろいろ試してみるのが
一番だと思うにょ。（アルゴリズムによってキレイさが変わるだけではなく処理速度が数倍〜
10倍変わる場合もあるのでいろいろ考えて比較してみると面白い）
もちろん、すでにできあがっているルーチンを利用するだけでもいいけどね。


《　2/13　追記　》

昨日作った塗りつぶし三角形の描画ルーチンをさらに高速化してみたにょ。
すでに書いているように縦横どちらに長いかを事前に判断してループ回数の短いものを選択
することにしたにょ。
そして、ループの初期値と終了値に使われていた配列変数を固定変数に変えて、不要な
コロンを省略などの方法をとることによって1回あたり平均1.24フレームだった処理を平均
0.72フレームへと約1.7倍高速化ができたにょ。

@TRI
SORT 0,3,X,Y:P=X(2)-X(0)
SORT 0,3,Y,X:Q=Y(2)-Y(0)
IF Q>P THEN @T
X=X(0)Y=Y(0)M=Y-Y(2)Q=(X(0)-X(2))/(M+!M)Z=X
FOR J=0TO 1
　M=Y(J)-Y(J+1)P=(X(J)-X(J+1))/(M+!M)
　X=X+(X(1)-X(0))*!M:A=Y(J)B=Y(J+1)-1
　FOR I=A TO B
　　GLINE X,I,Z,I,C:X=X+P:Z=Z+Q
　NEXT
NEXT
RETURN
@T
SORT 0,3,X,Y
X=X(0)Y=Y(0)M=X-X(2)Q=(Y(0)-Y(2))/(M+!M)Z=Y
FOR J=0TO 1
　M=X(J)-X(J+1)P=(Y(J)-Y(J+1))/(M+!M)
　Y=Y+(Y(1)-Y(0))*!M:A=X(J)B=X(J+1)-1
　FOR I=A TO B
　　GLINE I,Y,I,Z,C:Y=Y+P:Z=Z+Q
　NEXT
NEXT
RETURN
http://ww5.tiki.ne.jp/~ochame/petitcom/qr/triangle_h.png

まだ高速化するならば他に使われている配列変数をすべて固定変数に書き直すという方法も
考えられるけど内側のループではそれによる速度向上は大きいものの外側のループではその
速度向上はほとんどないにょ。
というのも、縦長、横長を判別してループ回数が短いものを選択しているものの内側の
ループは平均80回実行しているのに対して外側のループは2回しか実行していないためにょ。
処理時間でいえば内側のループが92％くらいで外側のループが8％くらいにょ。
そうすると配列変数を固定変数に書き直すことで3倍速くなったとしても8％かかっていた
時間が3％に減るだけであり、全体としては100％から95％へと5％程度の高速化しか見込め
ないにょ。
サイズの大きな三角形ばかり表示しているためこのようになっていてこれをポリゴン表示に
用いる場合にはそこまで大きな三角形を表示する機会は少ないということを考えると5％の
数倍の速度向上効果が見込めそうにょ。

では、1回あたり平均0.72フレームという現状の描画速度も画面の半分程度でいいのならば
ループ回数が半分になるのだけど実際に1/2画面でのランダム表示で試したところ1回あたり
平均0.36フレームとなりほぼ2倍速になったにょ。（本来ならばループ回数が半分に減っても
2倍速には満たないはずなのだけどGLINEで描画する長さも半分に減っているため）
さらに高速化すべく現状の1ドット単位での描画から2ドット単位での描画に変えたところ
1回あたり約0.24フレームとなったにょ。（当初と比べるとループ回数は1/4になっており
外側のループ処理の処理時間の割合が高くなるためそこを改善すればここからさらに1割
以上は高速化できそう）
昨日発表した段階と比べると5倍の速度にょ。（まぁ表示しているものが異なるため同一の
環境下だと最初の1.7倍速になるけど）
この速度ならば250ポリゴン/秒の描画が可能となるため1画面内で表示するポリゴン数を
20ポリゴン以下に抑えればジオメトリ演算込みでも10fpsを確保できそうな感じにょ。
ポリゴンゲームを作るには少々（というか、かなり）厳しいけどチャレンジ精神旺盛な人は
試してみるのもいいかもしれないにょ。

1477：けん：2013/02/15(金) 13:31:52
直輸入が円高でお得ですね。
ご参考になると嬉しいのですが今、円高なので、私はショップUSAというところからニコンなどををいつもを輸入代行してもらっています。国内で買うより２〜３割は安いですね。見積もりは無料なので他の商品でも見積もってもらうと安く手に入りますよ。

1478：御茶目菜子：2013/02/16(土) 00:00:58
N進数変換
昨日はバレンタイン絵もバレンタインプログラムも用意できなかったにょ。
バレンタインとは全く関係ないけど1行プログラムのネタを思いついたのでプチコンでN進数
変換プログラムを作ってみたにょ。
N進数への変換アルゴリズムは昨年の2月11日に書いたのだけど単にN進数への変換を行うだけ
では1行に収めるのは簡単すぎるので先日作った32bit整数演算ルーチンを使って2147483646
まで対応してみることにしたにょ。（まぁ外部ルーチンを使う時点でメインが1行に収まった
としても1行プログラムではなくなってしまうけど1行に収めている通常版をちゃんと用意して
おけば問題ない）

◎10進数→N進数　変換プログラム

通常版
N$=""INPUT A:INPUT"N=";N:FOR I=1TO A>0I=0N$=HEX$(A%N)+N$A=0OR(A/N):NEXT:?N$
32bit整数演算対応版
N$=""INPUT INT$GOSUB@INT2:A=INT:INPUT"N=";N:FOR I=1TO A>0I=0N$=HEX$(A%(N/Z)*Z)+N$A=A/N:NEXT:?N$
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#19


10進数をN進数に変換する場合はNでどんどん割っていき出てきた余りを逆順に羅列していく
だけでいいのだけど32bit整数演算はあくまで小数部分を活用して擬似的に行っているだけで
あるため注意する必要があるにょ。
当然ながらNの剰余ではなくN/4096の剰余になるにょ。
そして、その剰余を4096倍すれば正しい結果を得ることができるにょ。

◎N進数→10進数　変換プログラム

通常版
A=0INPUT N$INPUT"N=";N:L=LEN(N$)-1FOR I=0TO L:A=A+POW(N,I)*VAL("&H"+MID$(N$,L-I,1))NEXT:?A
32bit整数演算対応版
A=0B=1/4096INPUT N$INPUT "N=";N:L=LEN(N$)-1FOR I=0TO L:B=B*(!I+!!I*N)A=A+B*VAL("&H"+MID$(N$,L-I,1))
NEXT:INT=A:GOSUB@INT:?INT$
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#20

N進数を10進数に変換する場合はアルゴリズムそのものは上記の10進数をN進数に変換するもの
より分かりやすいにょ。
例えば8進数で4567は4x8^3+5x8^2+6x8^1+7*8^0だからね。
つまり、1桁ずつ抜き出してそれにNの0乗（＝１）〜Nの（元の数値の桁数-1）乗を順番に
掛けていけばいいだけにょ。
これはmkIIで加わったPOW関数を使ってもいいのだけど32bit整数対応版はそれができないにょ。
それは2進数を10進数に変換する場合には最大時には2^30（＝1073741824）を計算する必要が
あるためにょ。
32bit整数演算は4096で割ることで擬似的に行えているのだけど1/4096*POW(2,30)とした
ときには4096で先に割ってくれることはなく最初に2の30乗が計算されてしまいOverflowに
なってしまうにょ。
POW関数を使うならば524287を越えないような値の累乗計算を2回に分けて行えばいいのだけど
Nの何乗ならば524287を越えないかは対数計算によって導き出す必要があり、せっかく単純化
できるPOW関数なのに逆に長くなってしまうという問題が出てくるにょ。

POW関数を使わなくても初期値1にNをどんどん掛けていけばNの累乗は計算できるけどその
初期値を1/4096にすれば問題はないといえるにょ。
ただし、開始段階でいきなりNを掛けるとNの0乗を飛ばしてNの1乗になってしまうためループ
開始ではそれをスルーする処理（Iの値が0ならばNを掛けるのではなく1を掛ける）を実行
しているにょ。
それによって、ようやく32bit整数演算に対応できるようになったにょ。
ちなみに32bit整数というと2147483647まで対応しているはずだけどプチコンの場合は
2147483646までしか使えないため注意が必要にょ。
ということで、これだけは1行に収まってないので1行プログラムではないにょ（笑）

さて、この32bit整数演算ルーチンを作ったものの微妙にその使用用途が見あたらなかったけど
こうやって徐々に対応プログラムが作られればその価値は高まると思われるにょ。
同じ1行プログラムのCHRセーバーやCHRローダーも最近になってプチコンの保存領域を節約する
ということに賛同してくれる人が増えたためか採用プログラムも増えつつあるにょ。

1479：otya：2013/02/17(日) 18:55:50
(無題)
おちゃめさんのpixiv探していたら顔写真を発見してしまうとは

1480：御茶目菜子：2013/02/17(日) 22:20:17
レスにょ
otyaさんへ
＞おちゃめさんのpixiv探していたら顔写真を発見してしまうとは

サイト上から消したはずだけどまだあるところにはあるということにょ。
ネットで一度公開したら消えることはないため公開は慎重に行う必要があるにょ（笑）
pixivはotyaさんが18歳になってからのお楽しみにょ（謎）

1481：御茶目菜子：2013/02/17(日) 22:21:39
プチコンでポリゴン表示をしよう
先日作った塗りつぶし三角形描画ルーチンだけど今ひとつ使いどころがないにょ。
唯一使えそうなのがポリゴン表示くらいということで、せっかくなのでポリゴン表示を行う
プログラムを即興で作ってみたにょ。
プチコンにはポリゴン表示命令はなく基本的にポリゴンは表示できないのだけど命令で
備わってないものは代用ルーチンとなるプログラムを作ってしまえばいいだけの話にょ。

実はプチコンでポリゴン表示というのはすでに初代プチコン時代にやっている人がいる
わけであって今更やってもただの後追いにしかならないにょ。

　「プチコンで3Dのテスト」　epoxyさん
　http://www.nicovideo.jp/watch/sm14096563
　「トライフォース」　ウルさん
　http://www.nicovideo.jp/watch/sm16276657

そこで、高速化を重視してみることにしたにょ。
ただし、mkIIは初代と比べて1.2〜1.5倍くらい高速になっているにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/p_bench.htm
上記のプチコンでの3Dテストを見る限りでは4〜5fps程度なのでmkIIのアドバンテージを考慮
すれば「すでに発表されているものより高速」と謳うためには10fps以上は欲しいところにょ。

ポリゴン表示を行う場合の大まかな流れを考えると次のようになるにょ。

　(1)データを用意
　(2)ジオメトリ処理
　(3)レンダリング

(1)データとして必要なのはまずは頂点データにょ。
x、y、zの3次元データを頂点の数だけ用意する必要があるにょ。
頂点座標は回転の中心を(0,0,0)とした時の相対座標で用意しておくと回転処理が簡単にょ。
次に用意するのがポリゴンデータにょ。
基本的にポリゴンは三角形の集合体であるため用意した頂点データのうち何番と何番と何番の
座標を結んだ三角形にするのかという情報が必要になるにょ。
それに描画色を加えた4つのデータを1組として構成ポリゴン数の分だけ用意する必要しなく
てはならないにょ。
あと、ワイヤーフレームに対応するならば何番の頂点と何番の頂点を結ぶかというデータを
用意しておけばいいにょ。（ポリゴン用のデータを使用して三角形の周りをGLINEで結ぶと
いう方法もあるけどそれだとフレームレートが半減してしまう）

(2)ジオメトリ処理はそのデータを元に回転などの座標変換処理をしてスクリーン座標に変換
することにょ。
このサンプルプログラムでは下画面をマウス代わりにして上下回転、左右回転、拡大縮小が
自由自在にできるようになっているにょ。
上下回転はX軸回転、左右回転はY軸回転を行えばいいにょ。
これは単純に行列式に入れて計算するだけなので何ら難しいことはないにょ。
もちろん、高速化のためにこの式も簡略化して出来る限り無駄のないようにしておく必要が
あるにょ。
そして、それをスクリーン座標に変換する必要があるにょ。
スクリーン座標変換は「プレイヤー視点＝カメラ視点」という場合には単純な1次式で表す
ことができるため非常に簡単にょ。（これが斜め見下ろしだと計算が少し難しくなる）
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#3d_screen

(3)これで回転したオブジェクトの頂点が画面上でどこにくるのかが分かるためあとはポリゴン
表示（レンダリング）を行うだけなんだけどその前にワイヤーフレームを行ってみたにょ。
ワイヤーフレームに関しては私はポケコン（PC-E500）でも作った経験があるけどポケコンでは
高速化を駆使しても1〜2fps程度の速度しか出なかったので事実上使い物にはならなかったにょ。
しかし、プチコンならば頂点数によっても異なるけど今回用意したデータ程度ならば60〜90fps
であるため非常に高速にょ。

ここからがいよいよ本番にょ。
ポリゴン表示には例の高速三角形描画ルーチンを使えばいいのだけど普通にポリゴン番号順に
表示したのではダメで本来ならば手前の部分に隠れている奥の部分が見えないような処理を
する必要があるにょ。
これは3D演算用のハードウェアならばZバッファを搭載しているためピクセル単位で深度を記録
していけばいいのだけどプチコンではZバッファによる処理をソフトウェアで実装しなくては
ならず、それでは速度面で非常に厳しいものになるため単純なZソートを行うことにしたにょ。
これは面ごとにどれが手前でどれが奥かを頂点座標から判断して並べ替えるというものにょ。
ただ、ここで難しいのは単純に頂点座標からは手前か奥かは判断しにくいケースが非常に
多いということにょ。
ということでZソートは不完全だけど座標に重みを付けることで速度を維持しつつある程度は
正確な判断ができるようになったにょ。
しかし、Zソートの導入のせいで24面体の表示は10fpsを割り8〜9fpsになったにょ。（24面体で
10fpsを確保するには240ポリゴン/秒の速度が必要だからやむを得ないけど）

ここから速度を上げるために行ったのが陰面消去にょ。
これは、本来ならば見えない裏側からみたポリゴンを判定してそれを表示しないようにする
というものにょ。
Zバッファのようにピクセル単位の深度情報を処理しているならばそれでこの陰面消去処理も
行えるのだけど面単位（ポリゴン単位）でしか処理ができないため行える方法といえば
視線ベクトルと法線ベクトルとの内積を計算してそれを元に判断するというものにょ。
これによって、処理は増大したものの表示しなくてはならないポリゴン数が減ったために
24面体の表示は12fpsにまで向上したにょ。（トライフォースで13〜14fps、立方体ならば
16〜17fps）
さらにZソートではカバーしきれてなかった奥にあるポリゴンの非表示も行えるように
なったにょ。
ただし、ポリゴンの表と裏を判断するためにポリゴンのデータはベクトルの向きを考慮した
順番にする必要があるにょ。（といっても、ポリゴンを構成する3つの頂点の順番を反時計
周りに統一したというだけの話だけど）

このようにして、今回のプログラムはとりあえず完成したにょ。
http://www.youtube.com/watch?v=NUZD6W5qw2M
ちなみに1日で作ったためあまりできの良いプログラムではないのでもう少しリストを見直して
から公開するにょ。（1月28日に書いたGRPの2軸回転の方が速度を出すために今回のポリゴン
プログラムよりも作るのに苦労した）
あとモデリングは上記の他の方の動画を見て脳内で3次元座標に変換をしたためモデリングに
かかった時間は0分にょ（笑）
公開しても使ってくれる人がいるかどうかは微妙だけど自分が作った3Dデータをプチコンで
表示するというだけでも最初は感動が味わえると思うにょ。（ジオメトリ処理を込みで
概ね120〜200ポリゴン/秒くらいだからゲームで使うにはかなり厳しい速度）
解像度をデフォの256x192から縦横半分の128x96にすれば描画速度は1.5倍程度に高速化可能
だけどジオメトリ処理の負荷は変わらないのでここから大幅な速度向上は難しそうにょ。
ワイヤーフレームならば実際のゲームでもそれなりに使えるレベルの速度はあるのでそれを
使ったゲームならば十分作るのは可能ではないかと思うにょ。

1482：進：2013/02/20(水) 21:51:29
プチコンユザー識別コードについて。
SH、SH_にしていただけますでしょうか？
また、このコードに関する情報を使わせて頂きます。（ttp://www48.atpages.jp/~kolang/pukiwiki/index.php?Petc%2FUser%2F%BF%CAこんな漢字にまとめているのですが。、、）

1483：御茶目菜子：2013/02/20(水) 23:58:55
レスにょ
進さんへ
＞SH、SH_にしていただけますでしょうか？

変更しておいたにょ。

＞また、このコードに関する情報を使わせて頂きます。

まとめ作業を頑張ってにょ。
こういうのは情報が集まることで価値が増すからね。

1484：御茶目菜子：2013/02/21(木) 00:00:04
文字だけでドット単位の絵は描けるのか・・・？
今月はまだ1画面プログラムを作ってなかったので即興で作ってみたにょ。
題して「コンソールお絵かき」にょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/2page.htm#oekaki
私はプチコンではお絵かきツールを作ってこなかったけどそれは標準で入っているGRPEDなど
よりも優れたものを作る必要があるためにょ。
確かにすべての面で劣っていても短い方がいいというのであればすでに私も1行で「簡易
お絵かき」ツールを作っているからね。
私は1画面においても単に短さだけではなくある程度実用性のあるもの（使えるかどうかは
別にしてそれなりに使い勝手の良いもの）を作ってきたつもりだけど1画面で作るお絵かき
ツールを考えてみるとなかなか良いものが思いつかなかったにょ。

というわけでGRPEDなどとは同じ土俵に立とうとするからダメなのであって全く異なる
観点で考えることにしたにょ。
先月末のラスタースクロール祭りのときも「コンソール（文字）のみでラスタースクロールは
できるのか」ということに対して私は「テキストラスタースクロール」を作ったにょ。
今度は「コンソールのみでお絵かきツールはできるのか？」ということから始まったにょ。
これは本当に文字単位であれば非常に簡単にょ。
タッチした座標が入っているシステム変数TCHX、TCHYの値を8で割ってその座標に下画面用の
コンソール表示命令であるPNLSTR命令を使って■を表示すれば良いだけだからね。

しかし、それではあまりに手抜きだし、「テキストラスタースクロール」のようにコンソール
オンリーでも文字列操作を行えば（速度面では難があるけど）グラフィック面を操作するのと
同じようなことができてしまうわけだからね。
今回はラスタースクロールと違って1度に書き換えるのはタッチしている座標の1文字で良い
ため速度面での問題は無いにょ。
ただし、問題は256文字をすべて使ったとしても縦横16キャラ分（128x128ドット）の領域しか
自由には使えないにょ。
これがポケコンだったらPC-E500シリーズは40文字×4行で1画面は160文字だからすべての
文字を書き換えれば画面全体を使用することができたにょ。（OPASはこれによって画面
全体をコンソールキャラなのにプチコンのBG画面のように1ドット単位でスクロール可能と
なっている）
実際にすべての文字を書き換えたら困るのでキャンバスサイズは16文字×15行の240文字分
としたにょ。

問題はタッチした座標からどのように1ドット単位で書いていくかだけどこれはプチコンが
CHRSETでどのようにキャラ定義されるかを考えれば非常に簡単にょ。
CHRSETでは1ドットごとにパレット0〜15（0〜F）の文字を横8ドット×縦8ドット分の64文字で
定義しているため上記のようにタッチ座標を8で割ってタッチしているキャラの表示座標が
分かりそのキャラの中での相対座標を求めればその64文字のうち何文字目を書き換えれば良い
かは分かるにょ。
書き換えにはmkIIからはSUBST$命令が加わったのでMID$を駆使する必要もなく非常に簡単に
できるにょ。

さて、こうやってとりあえず完成したにょ。
その初出版はtwitterのみで公開したにょ。
というのも、即興で思いついたネタをプログラムしただけであり1時間程度で作ったプログラム
であるため無駄が多いし、何よりセーブやロード時には画面が乱れるという問題を抱えている
ためにサイト内で正式公開するようなクオリティには達してないと判断したためにょ。

では、なぜセーブ時に乱れるかというと仕様上下画面のコンソール文字をすべて書き換えて
いるためにょ。
だいたいの流れを書くと次のようになっているにょ。

　ツールで使用するためにキャラを書き換えてキャンバスを初期化
　　　　↓
　ファイルロード
　　　　↓
　メインルーチン
　　　　↓
　ファイルセーブ
　　　　↓
　キャラを元に戻す

つまり、セーブの段階ではキャラが書き換わった状態であるため下画面表示が乱れた
状態になっているわけにょ。
ならばセーブ前にCHRINITで元に戻せばいいという話になるけどCHRINITで元に戻すという
ことはグラフィックを用いたお絵かきツールでセーブ前にGCLSを実行するようなものである
ためそれはできないにょ。
そこで、考えたのはGCLSをする前に別のグラフィックページにコピーするという考えにょ。
要するに使用していないSPUなどのCHRリソースにコピーしてやればいいにょ。
しかし、リストに無駄があるとはいえ現状ですでに24行埋まっているためその処理を入れる
ためにはここからさらに数行分スト短縮をしなければならないにょ。

まぁ実際にリスト短縮を始めたらどんどん無駄な部分が見つかり何と5行分くらい縮める
ことに成功したにょ。
これによって、次のような流れに変更できたにょ。

　ファイルロード
　　　　↓
　ちゃんとロードができなかった場合
　ツールで使用するためにキャラを書き換えてキャンバスを初期化
　　　　↓
　メインルーチン
　　　　↓
　キャラを別のリソース（SPU）にコピー
　　　　↓
　キャラを元に戻す
　　　　↓
　ファイルセーブ

キャラをSPUにコピーするだけではなく最初のロード時にも使用されてないファイル名を
入力した際にすでに書き換えられた状態になっていて画面の乱れがあったのも解消したにょ。
これはRESULTで判断しなくてはならないためそれで1行分つかってしまうけどさすがに
ここまで短縮できれば余裕で搭載できたにょ。
さらに余裕があったのでファイルの上書き保存が簡単になるようにセーブ時にはロード時の
ファイル名がデフォで入るようにしてみたにょ。
ツールとしての使い勝手はイマイチだけどプログラムそのものは何とか自己基準を満たす
レベルには達することができたにょ。

ツールとしての使い勝手がイマイチなのは実質GPSET相当しかないためにょ。
本来はなめらかな線を描くためにはGLINEでつなげていく必要があるけどこれはGPSETのみで
GLINEと同等の機能を持つルーチンを作ることを考えると1画面で収めるのはほぼ無理になる
ということで諦めたにょ。
実用性はそれほど高くはないものの他所では見られない変わり者のツールにはなったのでは
ないかと思われるにょ。
実用性の高さを目指すのもいいけど誰も作らないものを作るというのも個人が作るプログラム
なのだからそれはそれでありかもしれないにょ。

1485：御茶目菜子：2013/02/21(木) 23:57:38
PS4がついに発表されたものの・・・
ついに本日PS3の後継となるPS4（プレイステーション4）がSCEから発表されたにょ。
http://game.watch.impress.co.jp/docs/news/20130221_588698.html
詳細はメーカーから公式のPDFが配布されているにょ。
http://www.scei.co.jp/corporate/release/pdf/130221a.pdf

やはり気になるところといえば下記の点だと思われるにょ。

　(1)性能
　(2)従来との互換性
　(3)コントローラ
　(4)価格
　(5)ソフト

(1)まずは気になるのはPS3と比べて何倍くらいの性能かということにょ。
ここで分かっているPS4の性能指標はGPUの1.84TFlopsというものにょ。
これは1秒間に1.84T回（1T≒10^12）の浮動小数点演算を行える理論性能があるというもの
だけど実はPS3では発表当初は「システム全体で2TFlops」と公式に発言されていたにょ。
それはCPUであるCellが218GFlops、GPUであるRSXが1.8TFlopsという内訳だったにょ。
この数字だけを見ると「PS3とPS4の性能はあまり変わらない」と言えるにょ。
しかし、これは正しくないにょ。
それは、PS3のRSXが1.8TFlopsに達することがないためにょ。
独自計算式で1.8TFlopsになったのだろうけど普通に計算すると下記のようになるにょ。

　RSX　8VS 24PS 500MHz
　 (4+1)x2FP/cycle x 8 VertexShader??x 500MHz　　　　 ＝　40GFlops
　(4x2x2FP + 2x2FP+7)/cycle x 24 PixelShader x 500MHz ＝ 324GFlops
　　　　　　　　　　　　　　　　　　　　　　 　　　　合計364GFlops
　G70のPS、VSのFlops計算方法は下記参照
　http://pc.watch.impress.co.jp/docs/2005/0622/kaigai193.htm

これからするとGPUだけを見ると5倍になっているにょ。
ただし、これは単純に理論演算性能を比較したものであり実際の性能差を表しているわけでは
ないにょ。
演算速度が高いからといって高い描画性能があるとは言えないし、理論値が高くても実効値が
高いともいえないからね。
では、PS4のGPUがどの程度のものなのかは、すでにRadeonのHD7xxxシリーズで採用されている
GCNであることが分かっているためある程度想像が付くにょ。
それは、18個のユニットで1.84TFlopsという数字で判断が可能にょ。
GCNは1ユニットが16x4基（SP）のRadeonコアで構成されており18ユニットではRadeonコアは
1152SPとなるにょ。
1SPで1クロックあたり2Flopsであるため1.84TFlopsになるのは799MHzであるためPS4のGPUは
800MHzと予想できるにょ。
これは概ねRadeon HD7850クラスといえそうにょ。（さすがにFlops性能をGPUメーカーが正式
発表していなかったPS3の時とは異なり、NvidiaもAMDも新GPUが出るたびにFlops性能を発表
しているためこの1.84TFlopsというのがいろいろ盛りまくった数字であるとは思いにくい）

　Radeon HD7970 2048SP 925MHz→　3.79TFlops　TDP250W
　Radeon HD7950 1792SP 800MHz→　2.87TFlops　TDP200W
　Radeon HD7870 1280SP 1GHz　→　2.56TFlops　TDP175W
　PS4用GPU　　　1152SP 800MHz→　1.84TFlops
　Radeon HD7850 1024SP 860MHz→　1.76TFlops　TDP130W
　Radeon HD7770??640SP 1GHz　→　1.31TFlops　TDP 80W
　Wii U用GPU　　 320SP 550MHz→　 352GFlops

PC用のGPUの中ではミドルクラスの性能であり、決して高性能なものではないけどPC用の
GPUはハイエンドなものだとTDPが200〜300W（最上位となるデュアルGPUになるとTDPは
400〜500W）に達しておりコスト面でも消費電力の面でもコンシューマゲーム機に搭載は
極めて困難であるためゲーム機用のGPUとしては無難な選択肢ではないかと思われるにょ。
ちなみにWii Uと比較するとすでにWii Uを分解、解析している人がいてその解析結果より
320SP、550MHzとされているにょ。
これから単純に考えるとPS4のGPU性能はWii Uの約5倍といえるにょ。
GCNはRadeon HD 6xxxまでと比べて実効性能が向上しているためアーキテクチャの違いを
考慮すればWii Uの約6倍といえるにょ。
Wii UのGPUもPS3と比べて1.5倍程度はあるためPS3と比べると10倍近い実効性能があると
いえそうにょ。

現行のHD機（PS3、Xbox360、WiiU）はどれも「フルHD、60fps」が難しい状態なのだけど
PS4のGPUならばそれは十分達成できそうにょ。
ただし、4Kを視野に入れているならば十分とは言えないにょ。
4K対応TVも徐々に発表されてはいるものの現時点でコンテンツがないということを考えると
今後5、6年で普及することはないだろうからそれほど問題は無さそうにょ。（HDTVもBS、
CSでのHD放送によって普及が始まり、地デジへの完全移行でようやく普及した）

ゲームにおいてはGPUの存在が非常に大きいのだけどやはりそれに似合うCPUがあって
初めてその恩恵を得られるにょ。
Wii UはGPUはPS3と比べて高性能なのにフレームレートが大きく落ちる場面があるのは
CPUがボトルネックになる場面があるためにょ。
確かにCPU性能が高ければ高い方が有利なのは確かだけど昨今は昔と違ってGPUのウェイトが
高くなっているためボトルネックにならないレベルのCPU性能があれば十分といえるにょ。

上記の公式配布のスペックを見るとAMDのJaguarの8コアと記されているにょ。
JaguarはAMD Eシリーズに搭載されているBobcatの後継となるCPUにょ。
http://pc.watch.impress.co.jp/docs/column/kaigai/20120831_556374.html
2〜4コアでの投入が予定されているためPS4用のCPUは4コアのものをMCMでパッケージした
ものと推測されるにょ。
さて、問題はどのような性能になるかということにょ。
現行のBobcatは低消費電力がウリだけど性能は同社のメインストリーム用CPUである
Trinityと比べてもクロック当たりでは8割程度しかなくHTTのないCore i3と比べても
クロック当たりでは半分程度の性能しかないにょ。
256bit-SIMDであるAVXに対応したりとか従来は2クロックで実行されていた128bit-SIMDが
1クロックで実行できるようになるとかいうように拡張命令を使用した際にはBobcatと比べ
大きな改善がありそうだけどそうでない場合はクロック当たりの性能は微増に止まりそうな
感じにょ。

PS4に搭載のCPUの動作クロックがどの程度になるのかは分からないけど例えば2GHzになって
も4コアのTrinity換算だと2.4GHz程度にしかならないにょ。（8コアで4コアの1.5倍の実効
性能になると仮定した場合）
決して高いCPU性能ではないもののGPUに特化したゲームならば問題はないのではないかと
思われるにょ。

Jagarを採用する背景にはBullzozerアーキテクチャの電力効率の低さがありそうにょ。（あと
GLOBALFOUNDRIESが28nmの立ち上がりが芳しくないためPS4を年内に登場させるのが難しくなる
というのも大きな理由であると考えられる）
最新のプロセス技術で作られるIntel製のCPUを使えばそのような問題は一気に解消されるの
だけどIntel製にするとコストの面で不利になるのと自由なカスタマイズが難しいというのが
AMDを採用した理由ではないかと思われるにょ。
CPUはある程度の性能があれば良くてPCで開発に慣れているx86CPUを搭載することでサードが
参入しやすい環境を作り出すということが重要なわけであり、そしてコストが最も重要に
なってくるからね。

Jagarを採用によって低消費電力が期待できるにょ。
BobcatのTDPは1.7GHzのE2-1800でTDP18Wとなっているにょ。
「TDP＝消費電力」ではないのだけどここでは消費電力と考えて計算してGPUが18Wのうち8Wを
占めていると仮定すればCPU1コアあたり5Wとなるにょ。
仮にPS4に搭載のCPUが2GHzであっても32nmのE2-1800から28nmへと微細化によって相殺される
ためCPUの消費電力は多く見積もっても8コア分で40Wとなるにょ。
実際はCPU、GPU以外のロジック部分やキャッシュの消費電力もありかなり丼勘定で計算して
いるため実際の消費電力はこれより低いものになると思われるにょ。（恐らくCPUコアだけ
ならば20〜30Wくらいか）
これに上記のGPUをパッケージングしているのだけどGPUのTDPはRadeon HD7850で130Wとなって
いるにょ。
ただし、2.18TFlopsのモバイル用となるRadeon HD7900MのTDPは100Wということを考えると
GPU部分の消費電力は100Wを下回る可能性が高そうにょ。
そもそもGPUのTDPはメモリを込みの値で発表されているわけだからね。
そうするとPS4のAPU（Jagar8コア＋1152SPのRadeon）の消費電力は100W前後ではないかと
思われるにょ。
これはPS3が発売当初のCellやRSX単体と大差ない数字であるためこれならばそれほど大きな
筐体でなくても十分な冷却ができそうにょ。

実は、PS4のスペックで目を引く部分といえばメモリにょ。
何せGDDR5で8GB搭載しているわけだからね。
メモリ帯域は176GB/sにまで達しているにょ。
これは一般的なPCのメインメモリに搭載されているDDR3-1600の12.8GB/sの13.7倍の帯域にょ。
とはいえ、これはGPUと共有ということを考えると決してずば抜けている数字ではないにょ。
Radeon HD7850は153GB/sだけどこれは独立して使えるわけだからRadeon HD7850よりメモリ
クロックは若干高いとはいえCPU用にDDR3-1600のデュアルchメモリを確保できていれば
そちらの方が合算ではメモリ帯域は広くなるにょ。
実際に使用する場合には共有だと不利な点が多いけどコスト面では有利になるにょ。

もっとも現状では広く量産されているDDR3の方が圧倒的に低コストにょ。
だからコスト面を考えるとメインをDDR3にしてVRAMをGDDR5にした方が低コストになりそう
という計算ができるけど時代とともに性能が上がっていくPCとは異なりゲーム機の場合は
同じスペックでずっと生産されることになるので現時点で低コストだから将来的にも
低コストで済むとはいえないにょ。
GDDR5はx16モードとx32モードが選択できるにょ。
GPUと256Mbitでデータをやりとりしている場合にはx16モードであればチップを16枚搭載
可能であり、x32モードであればチップを8枚搭載可能にょ。
容量を稼ぎたい時にはx16モードは有用だけどチップ数を減らしてコストを押さえたい
ゲーム機だとx32モードになるにょ。
そうするとGDDR5を256Mbitで接続する限りは現時点ではチップ数は8枚もしくは16枚必要
だけど将来的に微細化が行われてもチップ数は8枚必要になってくるにょ。

そして、メインとVRAMが共用でないならばメインメモリ用のDDR3も別途必要になるにょ。
DDR3は16bitとなっているため64bitのシングルchでも最低4枚、デュアルchで動作させる
ならば8枚のチップが必要となり、どれだけ微細化が進んでもメインとVRAMを合わせて全部で
メモリは16枚も必要になってくるにょ。
メモリチップ数は微細化によって変えることは出来ない部分であるため将来的なコスト
ダウンを見込むならば出来るだけ少なく済むような構成にする必要があるというわけにょ。

さらに異なるメモリを搭載したらメモリコントローラは2つ分搭載する必要があるにょ。
そうなるとコントローラの分よりもAPUとして1つにパッケージしている関係上CPUから出る
ピンの数に問題があるにょ。
メモリを分けてしまうと必要以上にピンの数が増えて複雑な構成になるにょ。
これはコスト面の問題だけではなく将来的な小型化を行う場合にも設計の自由度を下げて
しまうことになるにょ。
つまり、PS4がメイン、VRAM共有でGDDR5のみに絞ったのは性能面と将来的なコストダウンを
考えると十分納得がいくにょ。

ただし、メインメモリにDDR3を使うのとは異なりGDDR5を使うということはレイテンシが
大きくなるという点と粒度が大きいという点が問題になるにょ。
一般的なPCはメインメモリとCPUは64bit単位でデータをやりとりしているけどPS4の場合は
これが256bit単位になるからね。
GPUの描画に用いるだけならば並列性が極めて高く粒度が高くても問題になることはなく
単にコストの問題だけに止まるのだけど条件分岐が多いCPUに使用となると粒度が高くなると
スループットは下がってしまうにょ。
http://pc.watch.impress.co.jp/docs/2007/0326/kaigai346.htm
このレイテンシと粒度の問題はキャッシュがうまくヒットすればある程度は隠蔽が可能で
あるため十分なキャッシュを搭載すればそれほど問題ではなくなるもののそれはCPUの
ダイサイズの増大を招きコストアップにも繋がるため難しいにょ。
したがって、PS4の実効性能は今回書いた数字だけでは量りきれない部分があるにょ。

(2)現行機であるPS3との互換性はCPUもGPUもアーキテクチャが変わっているため確保する
ことはできないにょ。
エミュレーションによってカバーするためには性能が全然足らないので難しいからね。
特にCellはピーク性能が極めて高くこれを速度を落とさずエミュレーションできるx86CPUは
現時点では存在しないにょ。
というか、理論性能で218GFlopsのCellは4コアのIvyBridgeならば6.8GHzにOCしてようやく
互角レベルだからね。
これはCellが単精度浮動小数点演算に特化したベクトルプロセッサと言ってもいいような
ものであり、汎用的に使える一般的なPC向けのx86CPUとは単純比較ができないものの
リアルタイムでのエミュレーションを行うためには桁違いの性能差が必要ということを
考えるとx86CPUを用いてPS3をエミュで動作させるというのは不可能であることが分かるにょ。
そうするとPS4がCellを搭載していない時点で互換性はないといえるにょ。

そこでクラウドゲーミングが導入されるにょ。
これによってPS3用に発売されたゲームもPS4でプレイ可能になるにょ。
クラウドゲーミングには昨年の12月29日にも書いたような問題点が存在するにょ。
メーカー（SCE）にとってはサーバコスト、ユーザーにとっては遅延が問題となるにょ。
クラウドゲーミングはいくら頑張っても遅延ゼロ（≒1/60秒未満の遅延）は不可能である
ためにいかに遅延を抑えるかが重要になってくるけどそのためにはサーバを増強する必要が
あり多くのコストが必要となるにょ。
所持しているPS3タイトルはソフトのディスクを挿入したら自動的にクラウドサーバに繋がり
意識せずにクラウドゲーミングが可能になるというギミックもあれば良さそうだけどそうなると
ユーザー登録や支払いの面の問題があるにょ。（所持ソフトが無料でクラウドプレイが可能で
あればその問題は無くなるけど）

(3)新ゲーム機は「単に性能が上がっただけ」ではなくそのゲーム機だからこそ遊べる要素も
必要となるにょ。
それを可能にするのがコントローラにょ。
その辺はやはり任天堂は優れており、ファミコンでは十字ボタンによる操作を確立して
ニンテンドー64では3Dスティックを取り入れることで3Dポリゴンを使ったゲームも快適に
プレイできるようになったにょ。
そして、WiiではWiiリモコン、DSではタッチパネルを導入などそれに合わせたゲームも
多数登場したにょ。

では、SCEはどうなのかというとN64のコントローラの影響を受けてデュアルショックを
発売し、Wiiリモコンの影響を受けてPS Moveを発売したにょ。
デュアルショックはSCPH-7000以降のプレステには標準添付して大きく普及に貢献したものの
PS Moveは別売りのままであるため対応ゲームは極めて限られるというのが現状にょ。
そのコントローラがあることで真価が発揮できるようなゲームがたくだん登場するためには
コントローラがデフォルトになる必要があるにょ。
したがって、標準コントローラがどのようなものかというのは新たなハードのスタート
ラインを決める上では非常に重要なものになるにょ。

ここで、PS4のコントローラを見ると新型となるデュアルショック4が標準添付となって
いるにょ。
デュアルショック4はデュアルショック3の6軸検知に加えて小型のタッチパッドとPS Moveの
ような3D位置検知システムを導入しているにょ。
WiiにおけるWiiリモコンのようにPS Moveを標準コントローラにするというのは避けてその
技術を用いて無難な形に仕上げた感じにょ。
タッチパッドはただのポインティングデバイスくらいにしか使用できそうにないけど
PS Vitaを見ても「タッチ対応」というのは重要な要素になっていくため今後数年間戦う
ゲーム機ならば外すことはできないと思われるにょ。
あとWii UのようにPS Vitaやスマホやタブレット端末でPS4用のゲームをプレイするという
セカンドスクリーンもPS4では標準サポートされるけど遅延がほぼゼロのWii Uとは異なり
遅延を無くすことができないPS4ではこれはメインではなくあくまでサブ的なものに止まり
そうな感じにょ。
ということで、コントローラに関しては想定の範囲内といえるにょ。

(4)さて、普及させるならば重要なのは価格にょ。
PS3の時は初期型においてはPS2との互換性があったものの苦戦したのは価格が高価であった
というのが大きいからね。
やはり、据え置き機は3万円を切ったあたりから普及の勢いが大きくなり広く普及（国内で
販売台数が1000万台を大きく越える）させるためには2万円を切るということが重要になって
くると思われるにょ。（つまり、初期段階で高価であっても将来的に2万円を切ることが可能
になる設計にしておくということが1000万台以上売るハードには求められてくる）

ハードの価格においてはやはり重要なのは製造のためのコストにょ。
PS4は高コストになりそうな部分といえばAPU（CPU＋GPU）と8GBのメモリにょ。
恐らく両方とも原価は1万円を越えると思われるにょ。（GDDR5については単体での販売が
ないためいくらくらいという予想も立てづらい）
あとHDDもコストアップの要因になる部分であり現行のPS3よりも少ない容量を搭載する
というのは考えにくいためここも高コストになるにょ。
同クラスのPCを組んでメモリが少し高めということで単純に考えると現時点での原価は
5万円程度になりそうな感じにょ。
PS3のときよりはコスト面ではかなり下がっているとはいえ逆ざや無し（もしくは逆ざやが
わずか）ならば販売価格は49800円くらいになってしまいそうにょ。

ただし、これはあくまで現時点での話であり将来的には微細化によってAPUの価格が下がり
GDDR5の価格も量産効果で安くなれば現在のPS3並の価格に抑えることは可能になりそうにょ。
したがって、ある程度の逆ざやを許容して量産効果によるコストダウンを加味すれば
39800円の発売開始は十分に可能だと思われるけどこれでもデフレが進んだ現状では苦戦を
しそうな感じにょ。
かといって、現状分かっているスペックで29800円で登場させた場合には逆ざやが極めて
大きなものになるためいくらハードが売れても巨額の赤字を抱えてしまうにょ。
ソフトによって得られるロイヤリティ収入を加味しても1台あたり1万円の赤字ならば
100万台売れたら100億円の赤字だからね。（定価29800円ならば恐らく1台あたり1万円では
済まないと思う）
Wii Uが発売前のウワサ通りの性能ではなくコスト重視の性能になったということを考えると
29800円で出すためにコストを抑えるという可能性も考えられなくもないけどね。
ということで、私の予想は本命39800円、対抗49800円、大穴29800円にょ。

(5)やはりユーザーとしては最も重要なのがソフトにょ。
昨年12月28日にPS Vitaの敗因をいくつか挙げてみたけどやはり最大の原因はモンハンのような
「キラーソフトがない」というのが一番の理由だからね。
現時点でソフトが発表されていないPS4でまだ何とも言えないのだけどやはり昔のような独占
タイトルの登場は期待は薄そうにょ。
ハードが高性能化によって開発コストが増大になってきているのだけどそれを抑えるには
開発しやすい環境であるということが求められているにょ。
Cellは確かにピーク性能は高いもののそのピーク性能を活かすのは科学技術演算（行列演算
など）に限られてくるにょ。
普通にゲームを作る上では性能を発揮できないというのが問題だったにょ。
任天堂もかつてN64で「開発しにくいハード」という汚名を着せられたにょ。
そのためGCでは開発のしやすさを重視して、その流れはWii、Wii Uと続いているにょ。
ただし、Wii UはGPUの性能に釣り合わない貧弱なCPUということで再びソフトメーカー
泣かせのハードになっているような気がするにょ。

PS4はどうかというとGPUを重視したPCのようなハードであり、PCでの開発に慣れている
ソフトメーカーであれば開発はPS3よりも楽になっているのではないかと思われるにょ。
もっとも、8コアJagarの性能がどれほどのものかは分からないためCPU性能がボトルネックに
なってしまう可能性も考えられなくもないけどね。
あと、開発費をより効率よく回収させるにはマルチに頼るしかないにょ。
昨今はPC、PS3、Xbox360というマルチタイトルは非常に多くなっているけどこれもマルチ
前提で開発しておけばわずかな開発コスト増で済むためにより開発コストを下げる効果が
期待できるからにょ。
そういう面からするとPS4はアーキテクチャから考えてもPCとのマルチは非常に有利にょ。
次世代Xboxの性能はまだ分からないもののPS4とそれほど大きな開きはないため次世代Xboxも
PS4とのマルチタイトルになりそうにょ。（Wii Uはそういう面では当初の予想よりも性能が
低いため今後はマルチタイトルにおいてはかなり苦戦しそうな感じ）
もっとも、マルチだけではなく独占タイトルを確保できるかも重要になってくるのだけど
この辺は今後のSCEの手腕にかかっているにょ。（というか、ローンチタイトルに関しては
すでにある程度できてないと年内の発売はできないけど）


さて、以上のようにPS4を見てきたけど思っていた以上に性能を高めてきた感じにょ。
4Kをターゲットにせず、フルHD、60fpsが目的ならばもう少し低くても十分に出せるのだけど
ギリギリだとセカンドスクリーンを実行するのが難しいにょ。
Wii UはそもそもフルHD、60fpsが微妙なスペックなので専用のWii Uゲームパッドへの出力の
ため2画面出力を行うには性能が足りないみたいだしね。
あと、その余力を活かしてPS4では常時ゲームプレイを録画しているにょ。
この録画によって、プレイ動画をネットで手軽に公開が可能になっているにょ。
メモリも本来であれば半分の4GBで十分足りると思うけどそうやってさまざまなことに使用
できいる余力が残されているということを考えると奮発して8GB搭載した恩恵は十分にあるの
ではないかと思われるにょ。

とはいっても、すでにHD対応はPS3が出てきた時に謳っておりユーザーからすればぱっと見た
感じはPS3から大きな向上があるようには見えないかもしれないにょ。
実際はフルHDどころか720pもないようなゲームもあり、60fpsに満たないゲームも多く存在
するため異なるのだけどそれを大きくアピールするのは難しいにょ。
よって、性能以外の部分でアピールしていかないといけないにょ。
従来であれば理論値でも何でもいいから数字が前モデルと比べてこれだけ大きくなったという
ことをひたすらアピールして高性能であることを謳っていたけどそれが通じなくなってしまう
となるとどんなゲームがプレイできるか、どんな遊び方、楽しみ方ができるかをユーザーに
強くアピールしていく必要があるにょ。

そういう観点からするとやはりPS3登場時とは異なり高価格では売りにくいためやはりローンチ
から定期的に有力ソフトを投入していかない限りはかなり苦戦をしそうにょ。
Wii Uも発売した昨年12月は年末商戦と合わさって売れたものの年が明けてからはソフト不足に
よって売り上げは鈍化してしまい現状はかなり苦戦をしているにょ。
Wii UはWiiとの互換性があるため徐々に売れていくとは思うけどその互換性がないPS4（上記の
ようにクラウドゲーミングによって互換性を持つともいえるけどこのクラウドゲーミングが
十分快適にプレイできなおかつ現在所持しているPS3ソフトに関しては無料プレイができない
限りは互換性があるとは認めることはできない）は厳しいものになることが予想されるにょ。

1486：御茶目菜子：2013/02/25(月) 23:59:08
D7100はDXフォーマットの最上位機種に相応しいのか・・・？
ニコンから中級機となるデジタル一眼レフD7100が発表されたにょ。
http://dc.watch.impress.co.jp/docs/news/20130221_588730.html
公式ではD7000の後継機ではなくD7000の上位モデルとのことだけどこれは現行機との併売が
行われる間に限っての慣習的なものであり、事実上の後継機種と言えるにょ。
両方のスペックを比較すると下記のようになるにょ。

　　　　　　　　　　D7100 　　　　　　　　D7000
センサーサイズ　　　APS-C　　　　　　　　 APS-C
画素数　　　　　　　2410万画素　　　　　　1620万画素
画像処理エンジン　　EXPEED 3　　　　　　　EXPEED 2
連写速度　　　　　　6コマ/秒　　　　　　　6コマ/秒
　　　　　　　　（7コマ/秒 ※クロップ時） −−−−−
AFポイント　　　　　最大51点　　　　　　　最大39点
液晶モニタ　　　　　3.2インチ122万ドット　3インチ92万ドット
サイズ　　　　　　　133.5x106.5x76mm　　　132x105x77mm
重量（バッテリ込み）765g　　　　　　　　　780g

気になる点といえば下記の点にょ。

　(1)センサーと画像処理エンジン
　(2)連写速度
　(3)AF

(1)センサーを見ると2410万画素ということで画素数は前モデルより1.5倍に増えているにょ。
すでに何度も書いているように画素数の増加は画質向上に必ずしもプラスになるとはいえ
ないにょ。
とはいえ、そのセンサーで十分に解像するレンズを装着した場合には高い解像感を得ることが
できるにょ。
APS-Cで2400万画素というのは個人的にはやや多すぎると感じるけど単焦点レンズや一部の
高解像力のズームレンズを装着時にはその恩恵を得られるため必ずしもダメというわけでも
ないにょ。
ニコンの場合はすでにAPS-Cは入門機であるD3200からすべて2400万画素で固められているため
D7100の2400万画素は必然的な物だったといえるにょ。（キットズームしか使わない人も多い
入門機は高画素の恩恵はなくファイルサイズが大きいだけというデメリットしかないので
個人的には1600万画素で十分に感じる）

D7100は単に画素数が増えたというだけではなくローパスレスになり、クロップ撮影ができる
ようになったにょ。
1月9日にも書いたようにローパスレスというのは高画質化を行うものではないにょ。
ベイヤー配列のセンサーの場合はモアレや偽色のためローパスフィルタが多くの機種で採用
されているけどコンデジはずっと前から普通にローパスレスであり、センサー性能にレンズ
性能が追いついてない場合はローパスフィルタは不要にょ。
フルサイズのデジタル一眼であるD800Eではローパスレスが話題になったけどこのクラスに
なると十分な解像力のレンズを使用時にはレンズ解像力はセンサーの画素ピッチを上回る
ためローパスフィルタによって解像感を落とすのを避けるためにローパスレスになって
いるにょ。
D7100も同様に解像力アップのためにローパスレスとなっていると思われるにょ。

クロップ撮影は単純に言えばトリミングズームにょ。
拡大による画素補完を行うデジタルズームとは異なり画質の劣化はないというメリットが
あるにょ。
コンデジの場合はすでにレンズが解像していない状態なのでこのようなトリミングズームには
意味がないけど一般的なコンデジと比べて桁違いに大きなセンサーサイズのデジタル一眼の
場合は十分な解像力のあるレンズを使用していれば恩恵は十分にあるにょ。
ニコンにおいてはFXフォーマット（フルサイズ）でDXフォーマット（APS-C）用のレンズを
使用時には自動的に1.5倍のクロップになるけどD7100の場合は画素数の多さを活かして
DXフォーマットでさらなる1.3倍のクロップ撮影を可能にしているにょ。
画素数は1540万画素となりセンサーサイズはフォーサーズより若干小さくなるものの
クロップ撮影によってレンズの焦点距離はフルサイズ換算で約2倍となるにょ。
つまり、300mmのレンズが約600mm相当の画角になるにょ。

(2)クロップ撮影時には連写速度が上がっているというのもメリットとなるにょ。
とはいえ、標準が6コマ/秒でクロップ時が7コマ/秒ということでもD7000が6コマ/秒という
ことを考えると少し頑張って欲しかったところにょ。
しかし、1番の問題は連写速度ではなく連続撮影可能枚数にょ。
D7100のバッファ容量はD7000から改善されてないみたいなので12bitRAWだとD7000が11コマに
対してD7100は7コマに減っているにょ。
つまり、7コマ/秒だと1秒でバッファフルになるということにょ。
JPEGならば最大100コマまで連続撮影可能とはいえ、さすがにRAWでこの枚数というのはこの
クラスのデジタル一眼としては少なすぎるにょ。
バッファが増やせないならばキヤノンのようにsRAWを導入して欲しいところにょ。

(3)恐らく強化されているであろう部分がAFにょ。
AF測距点は従来の39点から上位機種と同じ51点にまで増えたにょ。
これは下位機種のD5200が39点になったことから差別化として増加したのだと思われるにょ。
AF測距点の増加は必ずしもAF性能の向上に繋がるというわけではないけどより広いエリアを
カバーできるようになったということは喜ばしいことにょ。
特に1.3倍のクロップ撮影時には画面のほぼ全域をカバーしているのは圧巻にょ。
あとは、実際に動体にどれくらいの追従性があるかどうかが問題だけどこれはレビューを
待つことにするにょ。
あと中央1点のみとはいえF8に対応したのも大きいにょ。
これによってズームレンズ＋テレコンという使い方でもAFが可能になるわけだからね。
まぁ600mmF4クラスの単焦点超望遠と組み合わせてもいいけどね。
クロップ撮影と合わせると換算焦点距離はかなり稼げそうにょ。


(1)〜(3)以外も防塵防滴がかなり強化されている感じにょ。
そして、D7000より若干小型軽量化されているというのも良い点にょ。
こうしてみると、D7000での不満点（解像感が低い）などが改善された正統派の後継機種と
いえそうにょ。（2400万画素もあり、不満点の1つだった高感度画質においては改善が
難しいだろうけどそれをクロップモードという方法で活かすことにしたのはプラスかも）
これはD5200が出たこともありスペックを底上げする必要があったのだろうけどそれでも
やはり、従来のDXフォーマットのフラッグシップモデルであったD300sの後継として考える
ならば力不足に感じている人も多いにょ。
特に連写や筐体の作りなどは依然として劣っているからね。

D300sは国内ではすでにディスコンとなっているため後継機種を求める声をよく見かけるにょ。
20万円弱のFXフォーマットのD600がすでに発売されていて、それに予価13万円のD7100が
加わるということはD300sの後継機種（D400もしくはD9000あたりか）のポジションはかなり
微妙になっているにょ。
仮に出すとしてD7100との差別化は十分可能であり、連写は通常時10コマ/秒、1.3倍クロップ
時には12コマ/秒くらいになれば多少高価になってもこちらを選ぶという人はいるのではない
かと思われるにょ。
というか、D7100は将来出るであろうDXフォーマットのフラッグシップモデルとの差別化のため
意図的に連写速度と連続撮影枚数を落としているような感じさえさせてしまうからね。

これに関しては海外では「D7100はDXフォーマットのフラッグシップモデルではない」という
正式なアナウンスがあったみたいだけどこれによってD300s後継機種が登場するかというと
登場するまでは安心はできないにょ。
D300sが発売された当時とは異なりFXフォーマットの選択肢が増えており単純に画質を求める
ならばDXのフラッグシップモデルには価格分のメリットはないということもあり、そこまで
大きな需要があるかというと微妙なわけだしね。
とはいえ、ライバルであるキヤノンがAPS-CフラッグシップモデルとしてEOS 7D mkIIを投入
する見込みでありニコンも出さないというわけにもいかないからすでに準備はしている
だろうけど7Dの投入はもう少し先になりそうなのでニコンもその様子見をしているのかも
しれないにょ。（私の予想としてはD300sの後継機種を出すならば今年の秋〜来年初頭かも）
個人的にはD300sの後継機が出ても予算面で手が出せないためD7100が限界なのだけど唯一
不満に感じるのはやはりRAW連写で7枚という点にょ。
まぁ連写で撮影する機会がそれほど多くはないとはいえ現行のEOS 7DがRAWで23枚、RAW＋
JPEGで17枚でありそれと比べて大幅に劣るスペックなわけだからね。
EOS 7DがAPS-Cフラッグシップなのに対してD7100はフラッグシップではないということで
単純比較はできないけど格下のEOS 60DでもRAWで16枚撮影できることを考えるとやはり
少ないと言わざるを得ないにょ。（D300s後継機との差別化のためにこうしたのであれば
非常に残念）
この辺に不満を感じない人であれば上記のようにD7000から多くの面で改善されているため
D7100は良い機種だと思うにょ。

1487：御茶目菜子：2013/02/26(火) 23:59:24
固定小数点と浮動小数点はどちらがいいのか？
プチコンでは浮動小数点ではなく固定小数点が採用されているにょ。
一見すると扱える範囲が広そうな浮動小数点の方がいいのだけど果たして本当にそうなのか？
まずは次の式を見て欲しいにょ。（N88BASICなど多くのBASICで動作するはず）

A=(A+1) mod 4
※modは剰余を返す演算子とする

これは、どのような動作をするのかというとすごく簡単でAの値は0、1、2、3、0、・・・を
繰り返すにょ。
つまり、0から特定の値-1まで繰り返すカウンタが欲しい場合はこれで簡単に実装できるにょ。
プチコンにおいては剰余を返す演算子はC言語と同じ％だけどプチコンがC言語や他の多くの
BASIC言語と異なる点は剰余の演算にで小数を含む値を使用できるという点にょ。（剰余で
小数が扱えるため2月1日に書いたようなことも可能になる）
それをふまえて次の式を見て欲しいにょ。

A=(A+0.25)%1

プチコンで実行したことがない人には分かりにくいけどこれは最初に書いたものを単純に4で
割っただけなのでAの初期値が0ならば0、0.25、0.5、0.75、、0、・・・を繰り返すことは
予想ができると思うにょ。
実際にループで実行して表示を繰り返してみれば分かるけど初期値がどのような数であっても
ループ4回で初期値に戻るにょ。
では、Aに加算するのが0.25ではなく0.1だったらどうなるのか・・・？

A=(A+0.1)%1

これをプチコンで実行すればループ10回で初期値に戻るように見えると思うにょ。
しかし、実際はそうならないにょ。
というのも0.1には固定小数点による誤差があるからにょ。
プチコンは32bit固定小数点であり、符号1bit、整数19bit、小数12bitとなっているにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/p005.htm#column
つまり、0.1という定数はプチコン内部では409/4096という形になっているわけにょ。

それを踏まえて考えるとA=(A+0.1)%1というのはA=(A+409)%4096というものを4096で割ったもの
といえるにょ。
そう考えるとAの初期値が0ならば10回ループした後ではAの値は4090/4096でありちょうど1に
なっていないためループ10回では初期値に戻らないというのが分かると思うにょ。
それではループ何回で初期値に戻るのかを考えてみるにょ。
初期値に戻るためには409を一定倍して4096の倍数になるかを求めればいいのだけど409は
素数であり、4096＝2^12で互いに素であるため409n＝4096k（n、kはともに整数）が成立する
最小のnは4096となるにょ。
つまり、A=(A+0.1)%1という式はループ4096回で初期値に戻るというわけにょ。

これが何の役に立つのかというと難しいところだけど以前作った疑似乱数発生ルーチンで
有用になってくるにょ。
0〜1の疑似乱数を発生させるルーチンはY=(Y+1)%4095X=(X*479232+Y)%4096/4096というように
なっていたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/rnd.htm
X=(X*479232+10)%4096/4096という式だと周期は4096しか確保できないにょ。
これだとあっと言う間に同じ値を繰り返すため256x192ドットの画面をランダムに表示された
ドットで埋めるなんてことは不可能であり実用性は低くなってしまうにょ。
したがって、別途変数Yによるカウンタを用いて周期を長くしたものが上記の疑似乱数にょ。
変数Yは4095回で元に戻るため4096回周期のXとは異なる周期であり、4096と4095は互いに素で
あるため周期は4096×4095＝16773120に達するにょ。

ここで変数Yに注目すると単に長い周期を繰り返せばY=(Y+1)%4095に拘る必要はないにょ。
A=(A+0.1)%1でAが4096回で初期値に戻るというのを利用してこれをカウンタに使えばいいの
だけど周期4096ではXと周期が同じであるため意味がないにょ。
したがって、4096とは素となる数（2の倍数ではない数）を4096で割ったものを設定する
必要があるにょ。
別に何でもいいのだけどここでは1.1（4096倍すれば4505）にしてみるにょ。
Y=(Y+0.1)%1.1でYは4505回周期となり、4096回周期のXと組み合わせると周期は18452480と
なるにょ。
そうすれば1.1ではなくもっと大きな数に設定すればさらに周期が伸びると考えるけど
周期が伸びてもXの取る値に変化はないため1より極端に大きな値を指定しても意味はないため
リスト短縮を考えて1.1がベターだと考えたにょ。（ちなみに4095回周期にしたければ0.9998に
すればよい）

出力するXの値が0〜1の範囲内であればXの方もX=(X*479232+Y)%4096/4096から短くできるため
次のようになるにょ。
Y=(Y+0.1)%1.1X=(X*117+Y)%1
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#rand
0〜1の値を返す疑似乱数は固定小数点の誤差を上手く活用することで10文字分短縮できたと
いうことが分かるにょ。

プチコンの固定小数点は一見すると簡単に誤差が出るため非常に使い勝手が悪いような気が
するけど浮動小数点とは異なり加減算で新たな誤差が生まれないというのは大きなメリット
だと思うにょ。
それがあるからこそ上記のようなことが可能になったのだからね。
固定小数点は内部に保存する段階で誤差が発生するというだけにょ。

32bit浮動小数点（float）では符号1bit、指数部8bit、仮数部23bitとなっているにょ。
そのためfloatでは絶対値が1.175494×10^-38〜3.402823×10^38の数を扱うことができるにょ。
こうしてみると同じ32bitでもプチコンの固定小数点よりも優れているように思えるかも
しれないけど問題なのは仮数部が23bitしかないということにょ。
23bitで扱える数は1〜8388607（＝2^23-1）となるにょ。
このため非常に大きい数と非常に小さい数を加算すると小さい数はちゃんと加算されないにょ。
これがプチコンの固定小数点の場合は525288以上の大きい数は事前に2のべき乗で割れば誤差
無しで加算できるにょ。
この方法によってプチコンで32bit整数演算は擬似的に可能となるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#int
小さい数字は整数倍することでこちらも誤差無しで加算可能にょ。
何せ整数部と小数部で31bitあるためfloatよりも事実上扱える範囲は大きいにょ。
floatがさらにやっかいなのは減算にょ。
桁落ちによって誤差が拡大されてしまうからね。

固定小数点は小数点を含む数を表記すると（小数部分が1/4096単位で正確に表せる数を除き）
表記の段階で誤差が発生してしまうものの加減算では整数演算と同じように演算誤差が発生
しないにょ。
そのため誤差を減らすさまざまな方法を工夫すれば誤差無しで演算可能だけどfloatは確実に
誤差が出てしまうため誤差が発生しても問題ないようなコードを書く必要があるにょ。
もしも32bit浮動小数点のみだと初心者向けではなく玄人向けになってしまうにょ。
そう考えると変数の型を選べないプチコンで固定小数点となったのは納得がいくにょ。
整数演算だと誤差の心配はないけど小数が扱えないとさすがに不便だからね。

ポケコンの場合はシャープのポケコンは8byteBCD演算という極めて精度の高いものを搭載
しているにょ。
そして、PC-1280およびPC-E500シリーズでは倍精度演算（有効桁数20桁）が可能になって
いるにょ。
BCD演算は内部で10進数演算が可能であり、誤差は極めて小さいし、さらに有効数字で20桁の
倍精度となるとこれに適うBASICを搭載したパソコンは存在しないにょ。
まさに電卓の進化系であるポケコンならではといえるにょ。
ここまでくると固定小数点より圧倒的に扱いやすいため初心者でも安心して使えるにょ。
したがって、「固定小数点は初心者向き」と書いたもののあくまで1つに型を絞るならば浮動
小数点よりも固定小数点の方が初心者に向いているというだけのことにょ。

1488：御茶目菜子：2013/02/28(木) 00:05:04
タブレット端末はポケコンになれるのか？
タブレット端末が多数発表されたにょ。

HP、Samsungが7〜8型タブレットを発表
http://pc.watch.impress.co.jp/docs/news/event/20130225_589230.html
ソニー、「Xperia Tablet Z」のWi-Fiモデル
http://pc.watch.impress.co.jp/docs/news/20130226_589341.html
オンキヨー、直販9,480円からのAndroidタブレット6機種
http://pc.watch.impress.co.jp/docs/news/20130226_589403.html
Lenovo、Androidタブレット「IdeaTab」3機種を発表
http://pc.watch.impress.co.jp/docs/news/event/20130226_589410.html
ASUS、通話機能付き7型タブレット「Fonepad」を249ドルで発売
http://pc.watch.impress.co.jp/docs/news/event/20130226_589345.html
8.9型WUXGA液晶の「Kindle Fire HD 8.9」を予約開始
http://pc.watch.impress.co.jp/docs/news/20130227_589604.html

今回の多数の製品を見て目立った点といえば下記の3つにょ。

　(1)7インチクラスの普及
　(2)低価格化
　(3)Atomの本格導入の期待

(1)タブレット端末といえば10インチクラスのiPad（正確には9.7インチ）が爆発的にヒット
したため各メーカーもそれに追従して10インチクラスの製品を主に投入していったにょ。
しかし、10インチクラスの製品は軽い物でも500〜600gであり、基本的に片手で持って使用
することになるタブレット端末としてはどうしても重量面で難があったにょ。
また家庭内で持ち運ぶには10インチクラスの製品が問題ないのだけどバッグに入れて電車や
バスの中で気軽に取り出して活用するには10インチクラスでは大きいにょ。

サイズや重量の面ではスマホを活用すればいいというが意見もあると思うにょ。
確かに、国内においてはスマホは携帯電話の出荷台数の7割以上を占め普及率も今年中には
5割を越えることが予想されているにょ。
そうすると、「10インチタブレットでカバーできない領域はスマホ」となるのは自然な流れ
だけどユーザーが選ぶのが10インチではなく7インチになる可能性もあるにょ。
ここで、スマホを持っていて7インチクラスのタブレット端末が必要かということになるの
だけどスマホの高解像度化は止まらずこの昨年まで1機種しか無かったフルHD液晶搭載機が
この春の新機種では一気に増えたにょ。
フルHDだとスマホとしては大画面となる5インチでも441ppiに達するため計算上は20cmまで
近づいてもドットを認識するのは困難にょ。（一般的な人だと30cmの距離で300ppi程度まで
認識できる）

300ppiくらいまでは情報量のアップに貢献できたけどそれを越えてしまうと文字のキレイさ
くらいしか高精細のメリットはなくなるにょ。
その高精細も15cmまで近づいてみても600ppiまでしか認識できないためそれで高精細も打ち
止めになるのではないかと思われるにょ。
これは逆に言えばスマホの実質的な文字情報量はいくら精細度を高めても5インチでもWXGA
クラスあるかどうかというレベルしかないことを意味するにょ。

これが7インチだとWXGAで213ppiであり、5インチのスマホだと少し前にはハイエンドだった
QHD（960x540）よりも精細度が若干低いため十分に文字が認識できるにょ。
そして、7インチフルHDだと314ppiだけどこれは5インチWXGAとほぼ同じにょ。
両方とも手に持って使う端末であるため精細度が同じであれば文字の見やすさはほぼ同じに
なるにょ。
「WXGAとフルHDで情報量が分からない」なんて言う人はほぼ居ないと思うけどこの情報量の
多さこそが7インチタブレット端末のメリットだと思うにょ。（それにサイズが大きいと
文字入力の際にソフトウェアキーボードの使い勝手も良くなるし）
それならば10インチクラスの方がさらに情報量が多くなるという意見もありそうにょ。
確かに10.1インチ2560x1600でも299ppiであるため7インチフルHDよりも文字が見やすい
からね。
しかし、これは10インチクラスが片手で長時間保持できて気軽に持ち歩くことが出来る
という人に限られるにょ。（もしくは、ほぼ家庭内でしか使用しないためそこまでの
携帯性には拘らない）

ただし、これはスマホが「5インチ」というサイズで打ち止めであるということを前提に
しているにょ。
もしも、今後スマホがさらなる大型化を続けることになれば7インチタブレットの領域まで
スマホが浸食することになるからね。
ただし、そのサイズになるとポケットに入れることがほぼ難しくなるにょ。
現在アニメでも放送中の「ROBOTICS;NOTES」の世界では7インチのスマホが主流になっており
このスマホは通称「ポケコン」と呼ばれているにょ。（おちゃめくらぶで普段使用している
ポケコンとは別物であるため注意）
3.5〜4インチクラスだったスマホが現在は4〜5インチであるため数年後には7インチにならない
という保証はないけどそれはそういう時代になってから考えればいいにょ。
現時点では上記のようにスマホと差別化は可能だし、本体が別であるということは当然ながら
バッテリが別であるためただでさえバッテリ容量が小さくバッテリ切れの心配によって思う
ように使えないスマホの変わりに自由に使える端末が別途あるというとそれだけで大きな
メリットがあると私は感じるにょ。（単純にバッテリだけの問題ならばスマホ1台で済ました
場合には別途モバイルバッテリを持ち歩けばわざわざ別端末を持ち歩く必要はないけど）

(2)7インチクラスのタブレットが脚光を浴びるようになったのはNexus 7の登場が大きいと
思われるにょ。
従来は10インチクラスが主流であり、7インチは品質があまり良いとは言えない中華パッドの
ような格安品しかなかった中にそこそこのスペックで19800円という低価格で登場したわけ
だからね。
そして、Appleも7インチよりは1周り大きいiPad mini（といっても4:3の液晶であるため
短辺は大きいけど長辺は7インチクラスと互角）を投入してさらにこのクラスの競争が激しく
なったにょ。
スペックのわりに（登場時には）割安感があったNexus 7とは異なりiPad miniは予想以上に
割高感があったにょ。
それでもやはり小型iPad2というべきスペックであり、多くの人にはそれほど不満を感じ
させるものではない（CPUやGPUの性能はそのままでRetina液晶を搭載してしまえばスペック
不足でもっさりしてしまうのでiPad miniはRetina液晶を搭載しなくて正解だと思う）という
こでもあり、そして、Appleのブランド力もあって高い人気を誇っているにょ。

そうなると後続がそれらに対抗するにはスペックやブランド力で上回る必要はあるけど
ブランド力で上回るのは無理であり、スペックで上回るとそれらより高価格になるのは
必至であるためブランド力の無いメーカーだとかなり苦戦をしてしまうにょ。
そこで選んだ道は低価格化にょ。
従来だと中華パッドがカバーしていたような1万円を切る製品まで発表されているにょ。
ただし、その最下位クラスの製品だと当然のことながら格安中華パッドと大差ない性能に
まで落ちているため注意が必要にょ。
個人的にはスマホと共存するためには7インチタブレットにはWXGA以上が必須であると
考えているので低価格化による選択の幅が広がるのは歓迎するけど私ならば数千円余分に
払ってでも必要なレベルのものを購入するにょ。

(3)Intelがスマホやタブレット端末用として満を持して一昨年に発表したOak Trailだけど
参考出品の製品こそいくつかあったものの実際の製品として販売されたものは皆無にょ。
それから1年余り経ち昨年秋にはその後継となるClover Trailを発表したにょ。
Window8タブレット端末の多くに搭載され従来のAtomでは難しかった10インチクラスで
ARM SoCを搭載したAndoroidタブレット端末とほぼ互角のサイズ、重量、駆動時間を実現
したにょ。

それが今回Clover Trail+としてさらなるバージョンアップをしたにょ。
http://pc.watch.impress.co.jp/docs/news/20130225_589280.html
このClover Trail+はGPUコアを変更しAndoroid OSへの最適化が図られているとのことにょ。
http://pc.watch.impress.co.jp/docs/column/ubiq/20130227_589550.html
つまり、Clover Trailと比べてさらに長時間駆動が可能になるということにょ。
参考展示レベルだけどこれを採用しているタブレット端末も発表されたにょ。
Oak TrailではAtomを採用する意味はほぼ無かったけどClover Trail+がハイエンドなARM SoC
と比べて割高でないならば採用する意味は出てくるにょ。
というのも、それはIntelの今後のロードマップを見た場合に非常に見通しが明るいためにょ。

各ファウンドリは昨年28nmによる製造プロセスを立ち上げたものの依然として十分な供給が
できているとは言えないにょ。
特にGFは28nmの大幅な立ち上がりの遅れがありAMDの今後のCPUのロードマップが白紙状態に
までなってしまったくらいにょ。
PS4に採用のCPUがJaguarに決定したのはこれが一番の理由だろうからね。
その点Intelは昨年の段階で22nmプロセスの量産化が可能になっているにょ。
そして、来年には14nmプロセスの立ち上がりはほぼ予定通りに行われると思われるにょ。
Atomは現状では旧世代の32nmプロセスが採用されているものの年内には22nmプロセスを
使った「Bay Trail」の登場が予定されていて来年には最先端の14nmプロセスを使用した
Atomも投入される見込みにょ。

この世界最先端の製造技術は他社にとっては脅威にょ。
基本的に製造プロセスが微細化すれば同一ダイ面積に搭載できるトランジスタ数が増えるため
性能の向上に繋がるし、最先端の省電力化テクノロジも採用されているため低消費電力も
期待ができるにょ。（従来であれば駆動電圧を下げることでピーク時の省電力化が可能に
なっていたけど昨今は駆動電圧を下げるのが難しくなっているけどそれでも40nm→28nmでは
大幅な省電力化が行われた）
性能面と省電力面のアドバンテージがAtomにあるならばよほどコスト面で問題がない限りは
採用はこれからどんどん進むと思われるにょ。
Oak Trail登場時と現在では状況が全く異なっているということにょ。


さて、こうしてみると7インチのタブレット端末の普及はこれから加速するのは確実にょ。
当初は10インチばかりだったのは(1)で書いたようにiPadが市場を牽引したためであり
ユーザーが10インチを選んだわけではないにょ。
これからは10インチと7インチとラインナップの幅が広がり「10インチが良い」という人を
除けば低価格な製品が多い7インチクラスが選ぶだろうからね。
そうなるとあとは価格の問題にょ。
デフレによって15インチクラスのノートPCでさえ新品でも4万円以下で入手可能だし、11.6
インチクラスのUltrabookも安い製品ならば4万円台からあるにょ。
つまり、「とりあえずPCが欲しい」という人にとっては4万円くらいが主力品となっている
10インチタブレットは価格面でかなり苦しむのではないかと思われるにょ。

価格面の問題といえばかつて80年代前半、まだPC（というか当時はマイコンと呼んでいた）が
一般家庭にほとんど無かった時代はパソコン（マイコン）は高嶺の花だったにょ。
当然のことながら当時はノートPCなんてものは存在せず、機能が限定されたハンドヘルド
コンピュータやポケットコンピュータ（ポケコン）が携帯型のコンピュータとして用いられて
いたにょ。
特にポケコンは当時一般的な8bitパソコンが本体＋ディスプレイで10〜20万円していた時代に
1〜2万円で購入可能ということで多くの注目を集めていたにょ。
使用する用途が異なるため実際は比較対象にさえならならず別腹という感じだったのだけど
恐らくこの状況はPCとタブレット端末の間においても言えるのではないかと思われるにょ。
「PCより安価で携帯性に優れているもの」がタブレット端末が普及するためには必要に
なるにょ。

ポケコンは残念ながら電卓の延長線的な製品であるため当時の8bitパソコンががカバーする
領域はカバーできなかったにょ。（ただし、ポケコンは速度で劣っていても演算精度で
優れており、電池で数10時間〜100時間の連続使用が可能であった）
タブレット端末はポケコンがなし得なかった真にパーソナルなコンピュータになれる可能性を
持っているにょ。
まぁスマホがすでにそれをなし得ている（もしくはそれに近づいている）といえばそれまで
だけどスマホはあくまで携帯電話の役割として購入している人が多いということを考えると
タブレット端末は端末だけの魅力（もちろん、その端末を使ったサービスを込み）で普及
させていかなくてはならないため簡単ではないにょ。
かつてのポケコンやPDAは一般層に普及する前に形を変えて姿を消したけどタブレット端末は
それらと比べると今後の展望は非常に明るいといえるにょ。

1489：道産子の初心者：2013/03/02(土) 00:41:02
識別コード追加依頼
コードは「DS」です。お願いします。

http://www53.atwiki.jp/petctournament

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