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

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

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

さっきは結構降っていたにょ。
また詳しくは明日書くにょ。
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
1490：道産子の初心者：2013/03/02(土) 01:00:57: リンク申請
http://www53.atwiki.jp/petctournament
リンクお願いします。(相互リンク希望)

http://www53.atwiki.jp/petctournament
1491：進：2013/03/02(土) 15:28:57: リンク申請
前回お話ししたサイトのリンクをお願いします。
http://www48.atpages.jp/~kolang/pukiwiki/index.php?Petcです。
名前は、「幻想楽団プチコンのページ」
でおねがいします。
1492：御茶目菜子：2013/03/02(土) 23:59:46: レスにょ
道産子の初心者さんへ
＞リンクお願いします。(相互リンク希望)

相互リンクどうもにょ。
こちらもリンクページからリンクを張っておいたにょ。

進さんへ
＞前回お話ししたサイトのリンクをお願いします。

リンク申し込みどうもにょ。
こちらからもリンクを張っておいたにょ。
1493：御茶目菜子：2013/03/03(日) 23:54:42: 第2回　プチコンコンテスト開催
本日より第2回非公式プチコンコンテストが開催されたにょ。
http://wiki.hosiken.jp/ptcmcon/
半年前に開催された前回は公式のコンテストであるプチコン大喜利と時期が重なったと
いうこともありその影響もあったけど今回は問題ないにょ。
もっとも、大喜利に参加者を奪われるという面もあるけど大喜利はハードルが高そう
だから非公式のコンテストに参加するという動きが小中学生には多く見られたため相乗効果で
逆に増えたという可能性もあるため大喜利が同時期に開催された影響というのはプラスか
マイナスかは判断が難しいところにょ。

私もこのコンテストに新作1画面プログラム「PETIT DRUM + BASS」で参加してみたにょ。
http://wiki.hosiken.jp/ptcmcon/?Toukou%2FPETIT%20DRUM%2BBASS
おちゃめくらぶの方でも同時に公開したにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/2page.htm#drum_bass
http://www.youtube.com/watch?v=JgzexRXqsQE
その名の通り、ドラムとベースを演奏できるプログラムにょ。
1月に作った1画面プログラム「PETIT GUITAR」と同じく弦1本ごとに独立制御しているため
同時に音を鳴らすことも可能になっているにょ。
当然ながらドラムの方も同時ボタン入力で音を同時に鳴らせるにょ。
この辺は特に難しいこともなくドラムだけだと7行で済んだためベースと合わせても1画面に
十分に収めることができたにょ。

実をいうとこのプログラムはPETIT GUITARを作って1週間後（1月下旬）にはほぼ完成して
いたにょ。
今頃になって公開するというのはやはりプチコンコンテストに投稿するためにょ。
私の場合は1画面プログラムは数時間～20時間くらいかかっている（開発速度を優先して
コーディングしたら20～30分程度）のだけど直前になって作り始めてもネタがなかったら
できないからね。
というわけで、直前にネタが思い浮かばなかったことを考えて1月はすでにPETIT GUITARを
公開しており1ヶ月1本のノルマは果たしているためコンテスト用に公開を保留しておいた
わけにょ。

ただし、あくまでこれはいざというときのためのものであり本来ならば別のものを投稿
したかったにょ。
プログラム自体は前回のコンテストで投稿したPETIT RUN mkIIの方が上だし・・・。
まぁコンテストの締め切りは3月9日まであるためまだこれから作っても何とかなりそうな
気もしないでもないけど突貫工事で作っても完成度を高めるのは難しそうにょ。
ネタとしては1画面ではないけどGRPの2軸回転を使ったレースゲームとかを考えたにょ。
ただし、そのままレースゲームとして作るのは簡単だけど面白くするには何かもう一工夫
欲しいところにょ。
ライバル車を出さなければfpsは稼げるため速度重視で高速化してみるというのも1つの
方法としてはありかもしれないけどね。
現在はサンプルの段階で19fpsだけど汎用性を極限まで落として20fpsまでもっていくことが
できればいいかもしれないにょ。
恐らく2軸回転で2分の1画面の表示（32x12）でこの速度を出せている人は居ないと思うにょ。
というか、まともな2軸回転プログラムは私が作ったもの以外に見たことがないにょ。
Z軸回転＋プレイヤー視点というものならばいくつか見たことがあるけどね。（プレイヤーを
見下ろす視点とは異なり、プレイヤーから見たならば簡単な一次式で表せるため難易度は
かなり下がる）
その速度面で有利なプレイヤー視点のものよりも私が作った2軸回転の方が速いくらいにょ。

コンテストとは関係ないけど素数計算プログラムも作ってみたにょ。

INPUT M?"2,";:FOR I=2TO M:FOR J=2TO SQR(I)+1J=J+(J>2)+!(I%J)*999NEXT:?(STR$(I)+",")*(J<999);:NEXT
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#21

素数計算自体は簡単なんだけど1行でどこまで高速化できるかにチャレンジしてみたにょ。
素数は1とその数以外では割り切れない自然数なのだけどそれを単純に作ればNが素数か
どうかを調べるためにはN-1回のループが必要になるにょ。
しかし、実際はそうではなく√Nまで調べればいいにょ。
このプログラムでは√N+1になっているのだけどこれはリスト短縮の都合上にょ。
FOR～NEXTのループを使用しているけど初期値が2であり、終了値が√Nならば3以下の素数を
計算する場合に開始値よりも終了値の方が小さくなるためループ内を実行せず終了してしまう
ためそれを防ぐために1回分余分にループを回しているということにょ。（3以下の素数は
求めないならば+1する必要はない）

あと、高速化のためには1ずつ√Nまで増やすのも避けたいところにょ。
実際偶数で素数なのは2だけなので2以上のものは奇数のみ計算すればいいにょ。
つまり、2、3、5、7、・・・・√Nという感じで順番に割って割り切れるかを確かめていけば
いいというわけにょ。
ただし、これはIF文を使わずとも論理式で簡単に判断できるため何とか1画面に収まったにょ。
このプログラムは現時点で97文字でありあと2文字しか余裕がないためここからさらに高速化の
処理を導入するのは無理ではないかと思うにょ。
つまり、これが1行ではほぼ最速というわけにょ。
ちなみに1000以下の素数をすべて表示するのにかかる時間は28フレーム、10000以下の素数だと
430フレームだったにょ。
何の工夫もしていない場合には10000以下で25000フレームくらいかかったので約60倍の速度に
なっているにょ。

ところで、先日teacupのサーバトラブルがあり、その際にこのおちゃめくらぶ掲示板のログの
約3分の2が消えてしまったにょ。
現時点でもまだ復旧できてないところを見ると復旧できる見込みはかなり小さいのでは
ないかと思われるにょ。
teacupのログが無制限になってからはバックアップ（というか、単にテキストをコピペ
貼り付けしただけのものだけど）を取ってなかったにょ。
もっとも、投稿前のテキストファイルならば残っているけど私の場合は投降後に校正や細かい
修正をたくさんしているため手元のテキストファイルと実際の投稿内容はかなり異なるものに
なっているにょ。

まぁ、ネット上にあれば安心と思ってバックアップを取ってなかった私の責任だけどネット
上のサービスというのが安心ではないかというのは良く分かったにょ。（まぁバックアップを
とっておいてもブログやWebサイトとは異なり元の状態に復旧するのは不可能だけど）
これはteacupだけではなく他のWebサービス、クラウドサービスにおいても当てはまるのでは
ないかと思われるにょ。
ネット上のデータだからいざというときに安心ということは「絶対にない」といえるにょ。
実際、過去にはソフトバンクの子会社であるファーストサーバがデータをすべて消失させて
しまい復旧が不可能になったことがあるからね。
http://cloud.watch.impress.co.jp/docs/news/20120622_541897.html

スマホが普及し、クラウドだけで何でもできるようになるという時代になりつつあるけど
そのサービスの低価格化によって質の低下の懸念されるにょ。
サーバを扱うのは人間なのでその人間がミスをすればファーストサーバのような大惨事は
どこであっても考えられるにょ。（本来ならばバックアップも消去するなんて考えられない
けどそれはゼロではない）
したがって、基本的にはユーザー自身がバックアップを取り、そしてさらにクラウドでバック
アップというのが安心してクラウドサービスを利用できる使い方になると思われるにょ。
1494：御茶目菜子：2013/03/04(月) 23:56:41: プチコンでデータを圧縮しないことがユーザーに配慮していると言えるのか？
先日twitterのプチコンクラスタでプチコンにおけるデータ圧縮について盛り上がったにょ。
データを圧縮するメリットやデメリットは下記のようになると思われるにょ。

　◎メリット
　(1)保存するために必要な領域を減らせる
　(2)QRコード枚数を減らせる

　◎デメリット
　(3)展開にかかる時間
　(4)メインテナンス性が下がる（改造しにくい）

まずは(1)から書いていくにょ。

プチコンの保存領域は数MBしかなくとても小さいものにょ。
公開されているQRコードをどんどん取り込んでいたら間違いなくすぐに一杯になるにょ。
実際、私自身は昨年10月の段階でエラーメッセージが出たからね。
私の場合はmkIIが公開された当初はすべてのQRコードを読み込んでいたもののそれ以降は
せいぜい7～8割程度ということですべてではない（QR1～2枚のものは比較的高確率で読み
込み、QRコード枚数の多いものは厳選していた）ということでtwitterおよびまとめwikiに
投稿されているすべてのQRコードを読み込んでいるようなヘビーユーザーならば昨年の
夏の段階で保存領域が一杯になっていたのではないかと思われるにょ。
作品発表のペースは依然としてダウンしておらず（honoPさんによればお正月効果のあった
1月よりも2月の方が発表作品数が多いとのこと）、海外の方までチェックしている人
ならば「保存領域が全然足らない」というのが実情ではないかと思われるにょ。

これは私だけに限ったことではなくすでに一杯という人は大勢いるにょ。（私が知って
いるプチコンユーザーの中でも5、6人はいるため割合からすればかなりの比率になる）
保存領域の中から現在使っているもの（ディスクの空き容量を示すような関数）はない
ためエラーメッセージが出た経験のない人は「自分はまだ大丈夫」と思っているのでは
ないかと思われるけどリソースを大量に使っているプログラムを入れている場合には気が
付いてないだけですでに一杯近くにまで到達している可能性はあるにょ。
分散値が分からないから何ともいえないけど2～3割の人が100点を取っているテストに
おいて平均点が50点以下ということは考えにくいからね。（mkIIが発売当初から使って
いるユーザーにおいて空き容量が半分以上残っている人が大半ということは考えにくい）
よほど気に入ったもの以外はQRコードを読まない、もしくは1つ読み込むごとに1つ消去
するということを繰り返しているという人を除き保存領域の問題はいつかは自分自身に
やってくるにょ。

保存領域の大幅減少を招いている最大の原因はmkIIではQRコードによって簡単にデータを
取り込めるようになったことだけどそれ以外の原因にはGRPによるセーブを導入している
プログラムがどんどん増えているということもあるにょ。
プチコンではリソース単位でしかセーブができないけど基本的にセーブデータ用に用いられる
MEMリソースは256バイトまでしか入らないため大きなデータの保存には向かないにょ。
そこで目を付けられたのがGRPにょ。
プチコンではGRPは256色使えるため1ドット当たり1バイトの情報量となるにょ。
簡単なプログラムによってGRPを使ったセーブはできるようになるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/save.htm#grp

GRPによるセーブだとMEMリソースの192倍となる49152バイト（48KB）までのデータをセーブ
できるのはいいけどプチコンは保存する場合には非圧縮であるため1KBのセーブデータで
あってもGRPである限りは48KBの保存領域を必要とするにょ。
数MBの保存領域しかないプチコンにおいてGRPを使ったセーブばかりを行えばすぐに一杯に
なってしまうにょ。
そこで私が考えたのはGRPではなくCHRリソースを使う方法にょ。
CHRリソースは8KBであるため8KB以下のセーブデータであればCHRリソースを使うことで事実上
1/6に圧縮したのと同等の効果を得ることができるにょ。

ただし、CHRリソースは32バイト単位でしか読み書きできないという点がネックにょ。
これはリアルタイムでセーブデータの読み書きを行っているプログラム（何かを実行すれば
それをセーブデータに反映するプログラム）には使いにくいにょ。
それならば普段は扱いやすいGRPを使っておいてプチコンに内部に保存するときだけGRPから
CHRに変換して保存すればいいだけの話にょ。
その考えでできたのがCHRセーバー/CHRローダーにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#05
CHRへの変換は面倒くさそうと感じている人が多いかもしれないけどすでにGRPによるセーブを
導入している人ならばこの1行のプログラムを追加するだけでCHRセーブのシステムができる
ため非常に簡単にょ。

これだけを見ればデータを圧縮するということはかなり有意的なものであるということに
なりそうだけど実際はそうとは限らないにょ。
圧縮のメリットがあるかどうかを考える場合には下記の3通りについて考えなくてはならない
からにょ。

　(a)リソースデータを別のリソースに圧縮
　(b)リソースデータをPRGに組み込んで圧縮
　(c)非リソースデータを圧縮

(a)に関してはCHRセーバーのように大きな保存領域が必要なリソースを小さな保存領域で
収まるリソースに変換するということが求められるにょ。（といってCHRセーバーは単純に
小さなリソースに変換しているだけであって圧縮をしているわけではないけど）
GRPのデータを圧縮してGRPに保存するのは複数面のGRPを1枚に収めない限りは無意味なこと
というのは分かると思うにょ。

(b)に関してはまず考えないといけないのはリソースデータをPRGに組み込む意義にょ。
初代プチコンにおいてはQRコードによる読み込みができず、基本的に手打ちだったにょ。
あとは2台持ち寄って直接交換しか方法がなかったにょ。
手打ちができないCHRやGRPリソースにおいてはWeb上で公開してそれを入力してもらうため
には「PRGに組み込む」ということが必要不可欠だったにょ。
しかし、mkIIではQRコードによるやりとりが可能になったため必ずしも意味があることでは
ないにょ。

とはいえ、複数のCHRリソースデータを用意しているとデータの管理も面倒になるし、
ユーザーからしてみればそのプログラムをプチコン上から消したいときにどのCHRリソース
データを消していいのか分からないというのもあるにょ。
QRコードを読み取る場合にはファイル名が分かっていてもそれから後から削除する場合には
どのファイルかは分からないからね。
これはWindowsで動作するアプリに例えるとzipファイルを解凍してexeファイルはexe
フォルダ、bmpファイルはbmpフォルダに自動振り分けが行われると考えれば分かりやすいにょ。
同一フォルダに解凍されているならばフォルダごと削除すればいいのだけどファイル形式に
よって振り分けられている場合には単純にはいかずどれを消していいのかはユーザーによる
判断が必要になるにょ。
単純にタイムスタンプによる識別ができない場合もあるわけだし制作者がPRGとリソースを
同一ファイル名にしてない場合は探し出すのは困難にょ。
もしも、ファイル名が異なっている場合には1つずつ開いて確かめる必要があるけどそれは
ユーザーにとってはかなり大きな負担になるにょ。
したがって、制作者はPRGと同一ファイル名のリソースを使用していない限りはPRGに
アンインストールルーチンを組み込んで自己削除する旨をユーザーに伝えるのがベターだと
いえるにょ。

その点、PRGにリソースデータを組み込んでおけばその煩わしさは一気に解消されるにょ。
PRGに組み込むためにはリソースをファンクションキー経由で少しずつ組み込んでいく必要が
あるため制作者の負担があるというのがあるけど厄介なのは非圧縮だとデータが膨らんで
しまうということにょ。
これはどういうことがというと例えばCHRリソースは16進数（0～F）の64文字分のデータが
1キャラ分となっているのだけどこれは32バイトのデータにもかかわらず、PRGでそのまま
組み込んでしてしまえば64文字＝64バイトのデータとなってしまうためにょ。
つまり、8KBのCHRリソースはPRGに組み込めば単純計算では16KBのデータになるということにょ。

もっともこれはデータ圧縮によって改善が可能にょ。
16進数文字列を256進数に変換することで圧縮を行うプログラムも公開されているにょ。
http://wiki.hosiken.jp/petc/?Toukou%2F16%BF%CA%CA%B8%BB%FA%CE%F3%B0%B5%BD%CC%A5%D7%A5%ED%A5%B0%A5%E9%A5%E0
プチコンでは制御文字がないため256文字のうちのほとんどがPRGで使えるためこの圧縮に
よってほぼ半分までデータを圧縮することが可能になるにょ。
とはいえ、2倍に膨らんだものが半分になったところで元のリソースのサイズとあまり変わら
ないためサイズ面における圧縮のメリットはないにょ。（ランレングス圧縮によって半分より
さらに小さいサイズまで小さくできればサイズ面のメリットはあるけど）
ところが、GRPで1KBのセーブデータであっても48KBの保存領域を必要とするのと同じく少し
しか使われていないCHRリソースであっても8KBの保存領域が必要になるにょ。
「1つのリソースで256キャラのほぼすべてを書き換える必要性がある」というのでなければ
PRGに組み込む際に256進数に変換して圧縮すればサイズを小さくすることが可能になるにょ。

また、CHRリソースは使われている色がフォントなどのように単色であろうと16色フルに使って
いても同じ8KB必要となるにょ。
しかし、あらかじめ単色ということが分かっていればサイズはさらに1/4にサイズを小さくする
ことが可能にょ。（2進数→256進数となるためトータルで1/8のサイズになる）
これを使った圧縮プログラムも公開されているにょ。
http://wiki.hosiken.jp/petc/?Toukou%2F%A5%D5%A5%A9%A5%F3%A5%C8%A5%C7%A1%BC%A5%BF%B0%B5%BD%CC%A5%D7%A5%ED%A5%B0%A5%E9%A5%E0
これならば単純計算では256キャラ中64キャラを書き換えていればサイズを小さくすることが
可能となるにょ。
つまり、CHRリソースはそのままPRGに組み込めばサイズは大きくなることが多いけど圧縮を
すれば小さくなることが多くなるということにょ。

(c)に関しては無圧縮と圧縮済みのデータのサイズを天秤にかけて判断しなくてはならないにょ。
CHRリソースの場合はどれだけ小さいデータであっても8KBであるためその小さいデータを
PRGに組み込んだ際には無圧縮でもトータルではサイズが軽減可能になった（1KB分しか使って
ないCHRリソースだと圧縮をしなくても8KB→2KBで6KBのサイズ軽減となる）けどリソース
データでない場合は圧縮した分しかサイズは小さくならないからね。
例えば1KBのデータを400バイトに縮めても差分の600バイト分サイズが小さくなるだけにょ。

ここで考慮しなくてはならないのは展開プログラムのサイズとプチコンの保存領域の最小
単位にょ。
サイズが600バイト小さくなっても圧縮データを展開するプログラムが500バイトならば
事実上100バイトしか小さくなってないのと同じにょ。
つまり、「その100バイトが大きい」と感じる場合に初めて圧縮効果があるにょ。（展開
プログラムを合わせた場合に逆にサイズが大きくなるならばサイズにおいてはデメリット
しかない）
プチコンの保存領域の最小単位は私の検証だと4KB程度であるため4KB単位でファイルサイズが
変わらない場合はサイズを小さくしても実際の保存領域は変わらないにょ。
それを考えると保存領域を節約するために非リソースのPRGに組み込まれたデータを圧縮する
という場合にはそれなりのサイズが無いとあまり意味がないことが分かるにょ。
もっとも、古くからプログラムを作っている人だと無圧縮のデータの羅列がが嫌という人も
いるだろうし、圧縮アルゴリズムを勉強のために圧縮するという人もいるだろうから
保存領域の節約が出来なくても「圧縮する」ということそのものには十分な意味があると
私は思うにょ。（制作者自身の勉強用というだけではなく圧縮アルゴリズムを学びたいという
ユーザーにとっては実戦的な参考となるため非常に有意義なものとなる）

次に(2)について書いていくにょ。
QRコードは型番（サイズ）、誤り訂正レベルで記録できるデータ量が異なってくるにょ。
スマイルブームの公式変換ツールによって生成されるQRコードは型番20、誤り訂正レベルは
Mみたいなので1枚のQRコードには666バイトのデータが入ることになるにょ。
この誤り訂正によってQRコードは一部が欠損してもそのデータを読み込むことが可能になって
いるのだけど1枚のQRコードに666バイトしか入らないのであれば8KBのCHRリソースには13枚の
QRコードが必要になるにょ。
しかし、実際はCHRリソースの多くは2～4枚程度のQRコードで済んでいるにょ。
これはQRコードが生成される際にzip圧縮が行われているためにょ。

では、CHRリソースをPRGに組み込んだ場合にQRコード枚数は圧縮によってどうなるかというと
これは一概にはどうなるかは分からないにょ。
PRGのサイズが小さくなればその分だけQRコードが少なくなると思いがちだけどPRGに0～Fの
文字が多く含まれればその分だけQRコードに変換する際に圧縮効率が高くなるためQRコード
枚数が削減される可能性もあるためにょ。
したがって、ユーザーの手によってあらかじめデータ圧縮をしておけばQRコードが少なくなる
という単純なものではないためこの(2)はメリットとして書くにはかなり微妙な項目となって
いるにょ。

今までは圧縮についてもメリットばかりを書いてきたけどこれからはデメリットとなるにょ。
まずは(3)について考えていくにょ。

圧縮されたデータは基本的にはそのままでは使えずそれを解凍（展開）する必要があるにょ。
これは極めて当たり前のことだけどその影響も考える必要があるにょ。
(1)-(c)では展開ルーチンのサイズの問題については書いておいたけどここでは速度について
考えてみるにょ。
私が作ったプログラムCHRセーバー（8KB分のGRPをCHRに変換）は78フレーム、CHRローダー
（CHRをGRPに変換）は83フレームかかったにょ。
圧縮はしておらず単純な変換だけでこの時間がかかっている理由の1つとしてCHRSETがあまり
速い命令ではないというのがあるにょ。
例えば CHRSET "SPU",0,C$ という処理（C$にはあらかじめ64文字分のデータを入れてある）は
1回あたり16.5ミリフレームかかっているにょ。
無圧縮のデータを256キャラ分書き込むだけでこの256倍の時間である4.2フレーム＋αの時間が
かかるにょ。
CHRセーバーではその約18倍の時間かかっているのだけどそれは1ドットずつGSPOITで読み出し
ながら16進数へと変換しているためにょ。（CHRSETは256回だけどGSPOITと16進数変換は
8192回行われているため1回あたりではCHRSETの方が時間がかかるけどトータルではそれ以外の
部分の方が圧倒的に多くの時間がかかっている）
この作業があるため無圧縮にもかかわらず78フレームもの時間になっているにょ。

展開時間が大きいと感じるか小さいと感じるかは展開するデータ量やプログラム内で展開を
行う頻度によっても大きく変わってくるにょ。
ほんの数バイトであれば60fpsで動作するゲーム内で逐次展開を行ってもそれほど大きな影響は
出てこないにょ。
これが数KB単位になれば展開にかかる時間だけで数フレームとなるためフレームレートの
大幅な低下が起きてしまうにょ。
その場合もゲームならば開始時のみだけならば数秒間の展開時間があっても許容できるかも
しれないにょ。（タイトル画面に戻るたびに数秒の待ち時間があれば結構辛いけど）
CHRセーバーは変換にかかる時間が78フレームということでセーブの際に約1.3秒の待ち時間が
発生してしまうのだけどCHRセーバーはセーブするときのみ行うため1.3秒というのはそれほど
大きな負担にはならないと思うにょ。（そもそもプチコンはセーブの際にダイアログが必ず
出るためそれをクリックしたりなどの時間で数秒かかってしまいそれからさらに1.3秒増えても
大きな影響はない）

続いて(4)について考えていくにょ。

データを圧縮すればサイズを小さくすることが可能になるけどその代わりデータの可読性は
大幅に下がってしまうにょ。
データの書き換えを重視するとこれは望ましいものではないにょ。
では、ユーザーが簡単にデータを書き換えられることが重要ということを前提に書いていく
ことにするにょ。
さて、ここでは(1)と同じく下記の3つの場合について書いていくにょ。

　(a)リソースデータを別のリソースに圧縮
　(b)リソースデータをPRGに組み込んで圧縮
　(c)非リソースデータを圧縮

(a)に関してはデータのメインテナンス性を上げる（ユーザーがデータを改造しやすくする）
ためにはその逆変換ツール（圧縮ツール）を用意しておけばいいにょ。
要するにCHRセーバーだけではなくCHRローダーも合わせて公開するというようなものにょ。
元のリソースデータはCHREDなどで簡単に修正や改造が可能だから圧縮ツールさえちゃんと
用意されていれば誰でも簡単に扱うことができるにょ。

(b)に関してはそう簡単にはいかないにょ。
圧縮ツールを用意することでその問題は改善できそうだけど圧縮したデータを自動的にPRGに
組み込む方法はないにょ。（これがPC-E500系のポケコンならばKEY 0命令によってBASIC
プログラムの自己書き換えが可能なのでいくらでも方法はあるけどプチコンではそれは無理）
つまり、圧縮ルーチンを用意できてもファンクションキー経由でユーザーが手動で行う必要が
あるにょ。
そうなると「データの改造のしやすさ」を重視するならば最初からこの(b)の選択肢は無くなる
というわけにょ。
リソースデータはリソースとして扱うのが最も簡単であり、「PRGに組み込む」という時点で
一般ユーザーにとっては扱いにくいものになってしまうにょ。（これは改造のしやすさを
重視したためこの選択肢は無いという結論になってしまったけど(1)で書いたように
PRGに組み込むことでリソースファイルを別々に管理する手間が無くなるというメリットに
加えて圧縮を行えばサイズ軽減というメリットもあるため十分に意味がある）

(c)に関しては(a)とほぼ同じことがいえるにょ。
ただし、(b)で書いたように手動で書き換えることになるためそのデータ量によっては
データの改造が非常に大変になるにょ。
私の場合は最近作ったものだと1画面プログラムにおいて「PETIT GUITAR」では1つ6バイトの
ギターコードを2バイトに圧縮したり、昨日発表した1画面プログラム「PETIT DRUM＋BASS」
ではドラムセットの2バイトの音色データを1バイトに圧縮しているにょ。

私は1画面プログラムにおいても改造をする人に配慮して必要とされているであろう点に
おいては改造の補助を記しているにょ。
PETIT DRUM+BASSの圧縮アルゴリズムは非常にシンプルであるため簡単に言葉で説明と具体例
だけに止まっているけど言葉だけでは分かりにくいPETIT GUITARにおいてはコードデータを
追加したい人に配慮して圧縮プログラムを用意してその使い方も説明しているにょ。

http://ww5.tiki.ne.jp/~ochame/petitcom/2page.htm#guitar

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)

つまり、「圧縮するからユーザーが改造しにくくなる」というのではなく「改造をしやすい
配慮をしていないから改造しにくくなる」ということにょ。
したがって、「データを圧縮するから改造しにくくなる」というのは「改造をしやすくする
配慮を放棄している」というのとほぼ同じことにょ。
圧縮をしないことによるメリットはそういった配慮をする必要がないため制作者は楽をする
ことができるということにょ。（それ以外のメリットは全くない）
まぁ制作者も少しでも楽をしたいだろうし、私自身も開発速度を優先して楽なコーディングを
したい場合にはリスト短縮はそれほど考えない場合もあるため「制作者が楽をする」という
こと自体は問題ではないけどね。

長々とプチコンで圧縮することに関して様々な考えを書いてきたけど結局圧縮をすることに
対してはメリットやデメリットがあり、それはサイズ面だったり、速度面だったりユーザーや
制作者側のメリット（デメリット）であったりとさまざまにょ。
したがって、ケースバイケースで考えるべきことであり、一概にどうこうと言えるようなもの
ではないにょ。
上記の内容を見て分かるようにある人においてメリットと感じるようなことでも別のある人に
とってはデメリットに感じるような場合も多いにょ。
したがって、それに対して「間違いである」というようなことを言うのは「間違いである」と
私は思うにょ。
といっても無駄な処理をしているのに「プチコンの速度が遅い」とか「メモリが足らない」
とか言っている人がいればさすがにそれは「間違いである」と言いたくなってしまうのは
確かにょ。

そうなると手抜きではなくユーザーに配慮して頑なに「圧縮をしない」ということを
心がけている人ならばパッケージではなく、PRGに組み込むこともなくリソースを別に用意
する必要があるにょ。
その際にはリソース管理の問題もあるためファイル名はPRGと同じものを付けるというのは
当然としてアンインストールルーチンの組み込みや使用しているリソースをワンタッチで
別のプチコンに転送できるルーチンも組み込む必要があるにょ。（1つ1つバラで転送して
いたら転送漏れが出る可能性が極めて大きい）
そこまでのことを行わず、「圧縮しないからユーザーに配慮している」と言うのならば
片手落ちな配慮と言わざるを得ないにょ。（「圧縮をしていない＝改造しやすい＝ユーザーに
配慮している」という式が成立するほど単純なものではない）

私はかつてポケコンにおいて「PSS(ポケコンソフト統一規格)」というものを提案したにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/PSS.HTM
これはユーザーにいかに配慮したプログラムを作れるかということで考案したのだけど
これらの項目は長年掛けて多くの経験をすることでようやく完成に至ったにょ。
単なる自己満足で終わらないためにはそれによって生じるメリットとデメリットを天秤に
かけて少しずつ調整していく必要があるにょ。
そう考えると単に圧縮をしてないからユーザーに配慮しているなんてことにはならない
ことは自ずと分かってくるにょ。（私はまだプチコンにおいては経験不足であるためPSSと
同等のものをプチコンで作るのは難しい）
1495：御茶目菜子：2013/03/05(火) 23:54:50: ユーザーに配慮したプログラムを作ろう
昨日書いたようにプチコンでユーザーに配慮したプログラムを作るという意識が高まっている
みたいなのでPSS（プチコンソフト統一規格）を作ってみたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/pss.htm
これは18年前にポケコン（PC-E500系）用に考案したPSSを元にして作られているにょ。
ポケコン用のをベースにしてプチコン用にアレンジを加えたのがこの12個の項目にょ。

　◎ファイルに関する項目
　　(必須)ファイル名にはユーザー識別コードを入れる
　　(必須)リソースのファイル名はPRGと同じものにする
　　(必須)パッケージ使用時にはパッケージであることを明示してパッケージ文字列を
　　　　　必ず記載する
　　(推奨)リソースを使用時にはアンインストールルーチンを用意してそれが用意されて
　　　　　いることを明示する
　　(推奨)リソースを使用時にはリソースファイルを転送するルーチンを用意する
　　(推奨)セーブデータには必要でない限りはGRPは使用しない

　◎プログラムの実行に関する項目
　　(必須)キャラを書き換えている場合は終了時に元に戻す
　　(推奨)終了処理を入れる
　　(推奨)リトライ処理を入れる
　　(推奨)mkIIのホームメニューに対応する
　　(推奨)基本的な操作方法は画面上かリストで表記を行う
　　(推奨)改造をしやすくする

各項目の詳細やなぜその項目が入っているのかはリンク先にて説明を書いているため
それを参照して欲しいにょ。
12項目あるものの必須項目さえ確実に満たしていれば「PSS準拠」となるにょ。
つまり、推奨項目は満たすのが望ましいけど満たさないとダメというわけではないと
いうことにょ。
これくらい甘くしておかないと必須項目だらけだとあまりに窮屈すぎて普及は望めない
からね。

実はプチコン用のPSSは先日までは作る気が（まだ）無かったにょ。
というのも、私が経験不足だからにょ。
ポケコンにおいては1行プログラムから64KBをフルに使ったゲームまで作ったし、あらゆる
ジャンルを網羅しているということで制作者側の考えも把握しているし、雑誌に掲載された
プログラムの大半は入力して実際に試してみたからユーザー側の考えもちゃんとあるにょ。
しかし、プチコンにおいては1画面等の小規模プログラムばかりを作っていてリソースを
使いまくった大作は作ってないからね。
したがって、制作者側の考えは小規模なものがメインとなってしまうにょ。
QRコードが公開によってとりあえず多くのプログラムをダウンロードしているためユーザー
側の考えならば問題ないのでどうしてもそれがメインになってしまい意見が偏りがちに
なってしまうにょ。（昨日書いた圧縮しない方がユーザーのためという意見の人はほぼ
自分のプログラムしかプチコンに入れてない人なので大作を作っている制作側の意見と
してはいいけどユーザー側の意見としては不十分）

18年前だと私はネットをやっておらずリアルメールで意見交換をしていたため草案から
正式規格化まで2年の歳月を費やしたにょ。
しかし、今はネットで意見を募ればすぐに反応があるため草案さえ出しておけば規格化は
容易でありそれほど問題はないにょ。
というわけで、ポケコン用に作ったものに加えて今までtwitter等で出てきた意見を元に
してできたのが今回のPSSというわけにょ。
もちろん、これで完成というわけではなくさらに多くの意見を取り入れて必須項目や
推奨項目の追加が今後行われる可能性は十分にあるにょ。
私は（BASIC歴が10年を越えた）20年くらい前からユーザーに配慮したプログラムに
ついて考えてきたけどユーザーに配慮するためには自分自身にある程度の余裕が必要にょ。
「とりあえず動く」というプログラムを作るのが精一杯の人にユーザーに配慮したものを
作ろうというのはなかなか出来るものではないけどプチコンで初めてBASICに触れた人も
初代プチコンからなら約2年、mkIIから始めた人も約1年ということでそろそろある程度
（気持ちの面で）余裕が出てくる頃ではないかと思われるにょ。
その出てきた余裕をどのように使うかは人それぞれだけどプレイしてくれるユーザーの
ために使えるようになると良いのではないかと私は思うにょ。
1496：マリモーマ：2013/03/06(水) 01:02:01: 目の付け所が　オワコン
シャープ、韓国の「サムスン電子」と資本提携へ
http://potemkin.jp/archives/50808917.html
http://www3.nhk.or.jp/news/html/20130305/k10015978941000.html

シャープ、サムスンから３％出資受け入れ発表
http://www.nikkei.com/article/DGXNASHD0600N_W3A300C1000000/

ポケコンを　作ってた時代は　もう来ないね
もしかしたら　韓国で　G850が作られたりして

http://liv0.com
1497：御茶目菜子：2013/03/06(水) 23:59:41: レスにょ
マリモーマさんへ
＞シャープ、韓国の「サムスン電子」と資本提携へ

まぁシャープの経営状態を考えるとやむを得ないのではないかと思われるにょ。

＞ポケコンを　作ってた時代は　もう来ないね
＞もしかしたら　韓国で　G850が作られたりして

主に液晶パネル関係だからポケコンはあまり関係が無さそうにょ。
というか、G850VSは現時点で国内で作っているにょ？
1498：御茶目菜子：2013/03/08(金) 00:00:17: 魚眼レンズで地球を作る・・・？
ふと思って、プチコンで魚眼レンズフィルタを作ってみたにょ。
http://twitpic.com/c9c1sr
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#fisheye
これは原理的にはスクリーン座標を極座標に変換しているだけの簡単なものにょ。（一見
変数Cは無駄なことをやっているみたいだけど演算誤差の関係上こうするしかなかった）
極座標とは何かというと簡単に言えば時計の長針が長さと角度のパラメータさえあれば
長針の先の座標が分かるという感じにょ。
三角関数を使ってアナログ時計を作ったことがあれば極座標をイメージしやすいのでは
ないかと思われるにょ。
逆に画面上の座標（スクリーン座標）から極座標を求めるにはarc sinやarc cos が欲しい
けどプチコンにはarc tanのATANしかないためそれを使って求めなくてはならないにょ。
直角三角形において角度を求めることになるためATANを使うだけで簡単に求めることが
できるにょ。

3次元極座標であるため2つの角度を求める必要があるけど2つの角度は例えるならば緯度と
経度で地球表面上の座標を表すことができるのと同じにょ。
というわけで、まずは地球の表示・・・というか地球儀を作ることにしたにょ。
まぁ実際は地球儀の話題が出てから魚眼レンズフィルタを元にすればできそうということが
思いついたわけだけどね。

地球儀を作るならば必要なのは地図データにょ。
地図には計算がしやすい正距円筒図法を使うことにしたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/mercator/
当初は真っ先に頭に浮かんだメルカトル図法をテスト用に使用してみたけれどやっぱり
緯度を正確に計算するのが面倒くさい（速度が遅くなる）ということに加えて極が表示
できないというのがネックであるため計算が楽で極の表示も可能なこの図法に差し替える
ことにしたにょ。

では、この地図データを使ってどうやって地球儀の表示を行うかだけど実際にやっている
ことは上記の魚眼レンズフィルタとほぼ同じにょ。
平面上に投影された地図を元の球面の座標に表示するだけだからね。

まずは、画面に映っている円形の任意のドットから緯度と経度を求めなくてはならないにょ。
緯度は画面上の半径と現在の画面上の（円の中心を原点としたときの）Y座標が分かっている
ためATANで簡単に求めることができるにょ。
次に経度だけどその基準となるX座標があればそれと現在のX座標を元にATANで求めることが
できるにょ。
緯度と経度が分かれば見えている部分は半球であるため角度はπラジアン（180度）であり、
それが縦は192ドット、横は128ドット（2πで256ドットであるため）の地図データのどの
部分を参照しているかを計算するだけにょ。
そして、それをGSPOITで読み取ってGPSETで表示すればいいにょ。
そうやってできたのがこの簡易地球儀にょ。
http://twitpic.com/c94ahk
（※この地球儀の画面写真はメルカトル図法によるものなので上記の正距円筒図法のデータに
　　差し替えればもう少しまともになる）

1ドット単位でGSPOITで読み出して1ドット単位で表示するということで元のサイズより
大きいと空白が空きそうなイメージを持つ人がいるかもしれないけど画面上の座標を順番に
1ドットの抜けなく順番に表示しているため問題はないにょ。
これが地図データを1ドットずつ読み出してそれを画面に表示すると拡大時には抜けが出て
しまうだけではなく拡大率が1未満の場合には同じ場所に何度もドットを打つことになるため
ループ回数は地図を構成しているドット数分だけ必要になってくるためとてつもなく遅く
なってしまうにょ。
半球を表示するためには画面のドット数の半分となる128x192ドット分、つまり128ドット
必要となるためどれだけ小さい地球儀であってもループ回数は2476回となるにょ。
しかも、拡大率が1より大きいと上記のように抜けが出るし、1より小さいと正確には表示
できないということで事実上使いもののはならないにょ。

これが画面上のドットを元にすれば半径64の場合はループ回数は12844回で済むし、地球儀の
表示面積が半分になればループ回数は概ね半分になるにょ。
そして、ドットの抜けなく表示が可能にょ。
これは、簡単に言えばニアレストネイバー法と同じアルゴリズムであり拡大補間が行われて
いるけど中間色で補間を行うものと比べるとやはり綺麗さでは劣るにょ。
これはプチコンのGRPが256色のパレット発色であるため中間色で補間を行うと色数の問題で
対応しきれないし、仮にできても1ドット単位でCOLSETをするなんて大幅に遅くなるため
速度面でかなり厳しいにょ。

まぁ、ここまでシンプルなアルゴリズムの簡易的な地球儀でも実行速度はデフォ（半径64）の
場合で0.4fpsと非常に遅いにょ。
現在は64色だけどこれを16色x16階調くらいにしてシェーディング処理を行うという方法も
あるけどこれよりもさらに遅くなることを考えると微妙にょ。
まぁそれでもBASICでここまで出来るならば御の字といえるかもしれないにょ。
ATANによる角度計算、ドットの読み取り、表示を1秒間に約5000回行えているわけだしね。
魚眼フィルタの方は角度の計算にもう少し時間がかかっているけどこちらはそこまで高速性を
求めないので問題は無さそうにょ。
というか、地球儀以外で魚眼フィルタを何に使うかが問題かもしれないにょ（笑）
1499：ありふれた：2013/03/10(日) 11:40:25: プチＯＳを、のせて
ＰｕｔｉｔＣｏｍｐｕｔｅｒＯＳのＱＲコードを、のせて。
1500：御茶目菜子：2013/03/10(日) 23:58:05: レスにょ
ありふれたさんへ
＞ＰｕｔｉｔＣｏｍｐｕｔｅｒＯＳのＱＲコードを、のせて。

とりあえずCAVEだけが動くという未完成品なので公開はしていないにょ。
作りながら仕様を考えていったのでプログラムはぐちゃぐちゃだし考えた仕様もほとんどが
搭載されていないので使いものにならないしね。
未完成でもこれをベースに改造してみようと考えているのならばこれに使われているコードは
使用せずに一から作り直した方がいいくらいにょ（笑）
ぶっちゃけ私の未完成品よりプチコンコンテストに投稿されている「OTYAX」の方が遙かに
優れていると思うにょ。
http://wiki.hosiken.jp/ptcmcon/?Toukou%2FOTYAX
1501：御茶目菜子：2013/03/10(日) 23:59:18: 祝プチコン2周年
非公式プチコンコンテストは昨日でエントリーが締め切られたにょ。
私はエントリー開始日（3月3日）に1画面プログラム「PETIT DRUM+BASS」を投稿しているけど
どうも今回はエントリー数が少ないみたいなので先日作った「簡易地球儀」に少し手を加えた
簡易地球儀2を作って投稿してみたにょ。
http://wiki.hosiken.jp/ptcmcon/?Toukou%2F%B4%CA%B0%D7%C3%CF%B5%E5%B5%B72
http://www.youtube.com/watch?v=cUmHzYcWIPE

主な改良点はプログラムの書き換えによって行っていた地球儀の半径と回転量の設定をボタン
操作で行えるようにしたのとタッチ操作で地球儀を回転できるようにしたことにょ。
数値はBUTTON関数の返す値をそのまま使うことで多少はリスト短縮に貢献しているにょ。
もっともそこまでリスト短縮を行っているわけではないため単に作るのが楽だったという
だけのことなんだけどね。（リスト短縮というよりもBUTTON関数の値を知っていれば
ダイレクトで設定できるため分かりやすいというメリットの方が大きいと思う）
手動による回転だけどデフォの半径64ドットの場合は先日も書いたように0.4fpsということで
とても動きに追従はできないにょ。
ただし、描画面積に比例してフレームレートが変わるため半径を1/4にすれば単純計算で16倍の
高速化ができるにょ。
したがって、半径が16ドットならば何とかタッチで回転操作が可能にょ。
大きく表示したい場合は一旦小さくして任意の場所に回転させた後に大きくするといいかも
しれないにょ。

しかし、任意の場所を表示するのが目的ならばそれ専用の設定ができる方が使いやすいにょ。
というわけで下画面に表示されている地図をタッチすればそれを上画面の中心に表示できる
ようにしたにょ。
日本をタッチすれば上画面の中心に日本が表示されるということにょ。
ただし、この地球儀は横回転のみとなっているにょ。
縦回転に対応させることも可能だけど元々が極地方が拡大された地図であるため縦回転を
すると単純計算では座標が求まらないためプログラムが長くなり、速度も大幅に低下して
しまうし、画面サイズを大幅に超えるくらいの拡大表示を行うと地球儀っぽさが無くなって
しまうことを考えて縦回転は導入しなかったにょ。
そのため任意の場所を画面中心に置くためには地球儀を上下に移動する必要があるにょ。
そのお陰で極に近い場所を表示すれば超拡大時も地球儀っぽさが得られているのではないか
と思われるにょ。
あとシェーディング（陰影処理）も試してみたけど速度が大幅に遅くなったので削ったにょ。
というわけで、1日で作った簡易地球儀をさらに1日で改造したという超簡単なプログラム
となっているにょ。

では、今回の非公式プチコンコンテストにエントリーしている作品を見てみるにょ。

第2回非公式プチコンコンテスト　エントリー作品（敬称略）

【　Kinetic Slide Block Puzzle「杵部(きねぶ)」　】　三毛乱ジェロ
http://wiki.hosiken.jp/ptcmcon/?Toukou%2FKinetic%20Slide%20Block%20Puzzle%A1%D6%B5%CF%C9%F4%28%A4%AD%A4%CD%A4%D6%29%A1%D7
【　PETIT DRUM + BASS　】　おちゃめ
http://wiki.hosiken.jp/ptcmcon/?Toukou%2FPETIT%20DRUM%2BBASS
【　ステレオグラムでお絵かき　】　いったん
http://wiki.hosiken.jp/ptcmcon/?Toukou%2F%A5%B9%A5%C6%A5%EC%A5%AA%A5%B0%A5%E9%A5%E0%A4%C7%A4%AA%B3%A8%A4%AB%A4%AD
【　スマ村DX　】　SUMA
http://wiki.hosiken.jp/ptcmcon/?Toukou%2F%A5%B9%A5%DE%C2%BCDX
【　OTYAX　】　otya
http://wiki.hosiken.jp/ptcmcon/?Toukou%2FOTYAX
【　TopazOS Fusion　】　Topaz soft
http://wiki.hosiken.jp/ptcmcon/?Toukou%2FTopazOSFusion
【　モンスター育成ゲームG　】　ウイング
http://wiki.hosiken.jp/ptcmcon/?Toukou%2F%A5%E2%A5%F3%A5%B9%A5%BF%A1%BC%B0%E9%C0%AE%A5%B2%A1%BC%A5%E0G
【　Putix　　】　＠ななし
http://wiki.hosiken.jp/ptcmcon/?Toukou%2FPutix
【　簡易地球儀2　】　おちゃめ
http://wiki.hosiken.jp/ptcmcon/?Toukou%2F%B4%CA%B0%D7%C3%CF%B5%E5%B5%B72
【　自動パッケージプログラム「道産子パッケーザー」　】　道産子の初心者
http://wiki.hosiken.jp/ptcmcon/?Toukou%2F%BC%AB%C6%B0%A5%D1%A5%C3%A5%B1%A1%BC%A5%B8%A5%D7%A5%ED%A5%B0%A5%E9%A5%E0%A1%D6%C6%BB%BB%BA%BB%D2%A5%D1%A5%C3%A5%B1%A1%BC%A5%B6%A1%BC%A1%D7
【　弾ゲー　】　燻製
http://wiki.hosiken.jp/ptcmcon/?Toukou%2F%C3%C6%A5%B2%A1%BC
【　雷のようなもの　】　Lv100
http://wiki.hosiken.jp/ptcmcon/?Toukou%2F%CD%EB%A4%CE%A4%E8%A4%A6%A4%CA%A4%E2%A4%CE

今回のエントリー作品は全部で12作品となったにょ。
前回の21作品と比べるとずいぶん減ってしまったけど前回は公式のコンテストであるプチコン
大喜利と時期が重なったため相乗効果で盛り上がったというのが大きいし、今回は年度末と
いうことでいろいろ忙しい人が多かった（中高生ならば期末試験や受験など）というのが
ありそうにょ。
主催者のメルビルさんも体調不良によってエントリー作品が間に合わなかったみたいだしね。
これから1ヶ月（4月10日まで）かけてユーザーの皆さんのテストプレイを行いそれを元に
投票で争われるにょ。
結果発表は4月11日というわけでぜひ多くの皆さんが自分のプチコンで試してみて投票に
参加してみて欲しいにょ。

というわけで、昨日ちょうど発売から2周年を迎えたプチコン（mkIIも14日で1周年）だけど
まだまだユーザーの盛り上がりは衰えてないにょ。
いずれ登場するであろう3DS版のプチコンは現時点では詳細は全く出ていないため発売は
早くても半年以上先と思われるけどまだまだmkIIで十分いけそうな感じにょ。
ただし、何度も書いているように保存領域の問題だけは深刻なのでそれさえ何とかする
方法（例えば保存専用の追加DSiウェアを用意するとか）が欲しいところにょ。
一番いいのはプチコンからSDカードにセーブできるのだけどこれはDSiウェアでは対応が
可能とはいえプログラムのセーブが可能になって公式に自由に使えるようにするのは
任天堂の認可をもらうのが難しいのかもしれないにょ。（セーブしたプログラムは本体に
紐付けしていれば問題はないと個人的には思うけど）
1502：御茶目菜子：2013/03/14(木) 23:52:37: プチコンmkII発売1周年＆私の今後の予定
今日でプチコンmkIIが発売されてちょうど1年経ったにょ。
プチコンmkIIでは初代プチコンでは不満の1つだった自作プログラムのやりとりがQRコード
経由で可能になり、発表する側もそれを実行するユーザー側も非常にお手軽になったにょ。
しかし、それ故にここで何度も書いているように保存領域がすぐに一杯になるという問題を
生み出してしまったんだけどね。
それはおいといて、ここ1年の私の作品を振り返ってみるにょ。

mkIIが発売されて昨年の12月22日までは（小規模なサンプルプログラムを込みで）QRコードを
公開したもののみをカウントして全部で50作品（昨年末現在だとさらに3作品増えて53作品）
だったのでそれから今年になってからの分を合算すればmkIIが発売されてからの公開作品数は
分かるにょ。

ということで、まずは今年公開したものをカウントしてみたにょ。
1行プログラムは全部で10作品（別バージョン込みで13作品）、1画面プログラムは「SOUND
PAD」「PETIT GUITAR」「コンソールお絵かき」「音当てゲーム」「PETIT DRUM+BASS」の
5作品、1画面（＋外部ルーチンや外部データが必要なもの）は「簡易地球儀」「PIタッチ」の
2作品、ラスタースクロール系が「ノーマル」「テキストラスタースクロール」「旅の扉」
「神風の術」「似非スキャニメイト」の5作品、1画面超の作品が「簡易地球儀2」「2D→3D
RACE」「プロ生ちゃん100m走」の3作品、あとはサンプルプログラムが「マルチタッチ検出
ルーチン」「魚眼レンズ風フィルタ」「塗りつぶし三角形ルーチン」「塗りつぶし楕円
ルーチン」「色の重ね合わせ」「フェードイン/フェードアウト」「縦持ちフォント生成／
表示」「ドップラー効果：踏切」「ドップラー効果：救急車」などごく小規模のものを
含めて22作品（うちQRコードを公開分が13作品）でトータルでは今年になってから50作品が
リストもしくはQRコードを公開しているにょ。
昨年末までの分を合算すると1年間では103作品（QRコードを公開分のみで93作品）となるにょ。

これ以外にも動画でしか公開していない作品もあるにょ。
http://www.youtube.com/user/ochamenako
今年になってからだと「ポリゴン表示ルーチン」「2軸回転ルーチン」が動画のみの公開
となっているにょ。
これらはちゃんとしたサンプルとして公開できるレベルになったら公開する予定なので
楽しみに待っていてにょ。
2軸回転ルーチンは公開時に対応ゲームも用意する予定だけどこれらは次回のプチコン講座で
公開予定となっているにょ。

次回の講座の内容は「GRP面の拡大縮小回転」だけど単純なニアレストネイバー法による
拡大縮小から始まり、Z軸回転、X軸回転、2軸回転（X軸、Z軸）についても書く予定にょ。
X軸回転のサンプルゲームとしてはすでに「2D→3D RACE」を用意しているのであとはそれに
到達するまでの説明をするだけとはいえ過去最大となり前後編となった第7回の講座を
大幅に上回る分量になりそうにょ。
下手をするとテキストだけでも100KBを越える可能性さえあるにょ。（並のラノベ1冊分に
匹敵するテキスト量）
まぁ現時点ではまだ構想段階だからそれよりも多くなる可能性もあるし、少なくなる
可能性もあるけどね。

ポリゴン表示ルーチンの方もできるだけ早い段階で公開したいところだけどぶっちゃけ
現時点では回転して眺めるくらいしかできないためこれを使った公開時にはサンプルなども
用意したいところにょ。
次回のさらに次のプチコン講座でワイヤーフレーム、ポリゴン講座を書くという手もあるけど
プチコンの処理速度ではまともにゲームに使えるレベルでポリゴン表示をするのは不可能にょ。
私が作ったほぼ最速ルーチンでもあの動画のレベルだからね。

　◎私が作ったルーチンにおける座標計算込みの実行速度
　ポリゴン　・・・・・・・・・・　1秒間100～200ポリゴン
　ワイヤーフレーム　・・・・・・　1秒間1000～1200ライン
　単純な拡大縮小　・・・・・・・　1秒間GFILL2500～4000回
　X軸回転　・・・・・・・・・・　1秒間3500～4000ピクセル
　2軸（X軸、Z軸）回転・・・・・　1秒間3500ピクセル(GFILL)～7500ピクセル(BGPUT)

これを見れば大体の速度予想ができると思うにょ。
GFILLによる単純な拡大縮小を使った疑似3Dゲームを作る場合は60fpsを出すためには1フレーム
内に使えるGFILLの数は上記の1/60以下となるにょ。（表示や座標計算以外の部分もあるため
1/60ぴったりの数では処理落ちしてしまう）
2500～4000を60で割ると41～66となるけどこの範囲の差は拡大率（というか表示面積）に
よってGFILLの実行速度に差があるためにょ。
普通にゲームで使われるレベルのサイズだとこの範囲内に収まるにょ。
「PETIT RUN mkII」はメインルーチン1回で52回のGFILLを実行しているため60fpsで収まって
いるにょ。（ちなみに「PETIT RUN mkII」の場合は54回だと処理落ちする）

X軸回転のサンプルとして用意している「2D→3D RACE」は100頂点分の座標を求めてそれを
元にGFILL表示を行っているにょ。

　2D→3D RACE
　http://www.youtube.com/watch?v=k6vrMHPMO8I
　http://twitpic.com/byq6ew

式の簡略化を行い行列による回転処理を高速に行うことで単純なGFILLとほぼ同じ速度で
可能になっているにょ。
100個の座標を計算しているわけだけどそれを実行時でも36fps程度の速度が出ているにょ。
真上からの視点だと描画量が増えるため遅くなるけどそれでも32fpsを確保しており何とか
常時30fpsは維持できているにょ。
これが2軸回転なら劇的に重くなるにょ。
そもそも計算しなければいけない座標の量がX軸回転より劇的に増えるからね。
必要最小限に抑えても表示ドット数分の座標を求めなくてはならないにょ。
画面の半分となる32x12x8倍拡大では384個の座標を計算することになるにょ。
これに2回の逆行列演算を行うことで2軸回転は可能になるけどこの行列演算部分の計算式も
簡略化することで単純な拡大縮小とそれほど変わらないレベルの速度を実現可能にょ。
しかし、384個の座標を計算しなくてはらなないためゲーム要素のないサンプルレベルで
10fpsしか出すことはできないにょ。（これがBGPUTを使い限界まで最適化を行えば19fpsが
可能になっている）

さて、これを元にワイヤーフレームやポリゴンでゲームを作るとどの程度のフレームレートに
なるのかもある程度予想ができるのではないかと思うにょ。
ポリゴンだと表示サイズによって差が出るけど上記のように概ね100～200ポリゴン/秒と
なっているからね。
画面内に自分キャラの玉を4発、敵キャラが4発でそれぞれ1ポリゴンで描画したとして
全部で8ポリゴン、敵キャラは4面体（陰面消去によって表示は最大3ポリゴン）を2体出す
とすれば全部で14ポリゴンとなるにょ。
100～200を14で割ればおおざっぱなフレームレートは出るけど7～14fps程度となるにょ。
当たり判定など表示や座標計算以外の処理を考慮すれば6～10fps程度になりそうにょ。

これがワイヤーフレームならばかなり改善できるにょ。
上記と同じものをワイヤーフレームで作れば弾は1つ3ラインで合計8発で24ライン、
4面体は1つ6ラインなので2キャラで12ラインとなる合計36ラインになるにょ。
これを1000～1200ライン/秒を36で割るとフレームレートは27～33fpsとなるにょ。
当たり判定を込みでも20fps程度の速度は出せそうにょ。
このワイヤーフレームは回転処理を行ったものであるためプレイヤーからの視点で
敵は回転をしないという設定にするならばジオメトリ処理が簡略化できるため30fps程度は
可能かもしれないにょ。
こう考えるとポリゴンを使ったアクションやシューティングゲームは厳しいけどワイヤー
フレーム程度ならばギリギリなんとかなりそうな感じにょ。
使い物にならなければ講座を開く意味はないため実用レベルの速度が得られるならば
講座として公開するかもしれないにょ。

ということで、mkIIが発売されて1年間を振り返り、今後の私の予定も書き記したのだけど
公式twitterでは明日なにやら発表があるらしいにょ。
mkIIの後継が発表か・・・とも思えなくもないけどそこまでハードルを上げるなという
公式ツイートにもあるように追加データの配信かもしれないにょ。
使えそうなデータの配信ならばそれを使って何かプログラムを作ってみることにするにょ。
1503：天郷思音：2013/03/15(金) 17:12:56: (無題)
プチコン新作ならず。残念。
1504：御茶目菜子：2013/03/15(金) 23:17:50: レスにょ
天郷思音さんへ
＞プチコン新作ならず。残念。

mkII後継が発表されないのは想定内だったにょ。
大喜利を今開催するということは後継はもうしばらくかかるのかもしれないにょ。
年内に発売されるかどうかという感じかも・・・。
それまでは保存領域不足が深刻化しているプチコンmkIIで何とかやりすごすしかなさ
そうにょ。（まぁそれ以外は大きな不満もないけど）
1505：御茶目菜子：2013/03/15(金) 23:19:16: 第2回プチコン大喜利開催！
昨年8～9月にプチコンの公式コンテスト「プチコン大喜利」が開催されたのだけどついに本日
第2回プチコン大喜利が開催されることが告知されたにょ。
http://smileboom.com/special/ptcm2/co_contest/index.php
昨日公式twitterでツイートされていた「明日のお楽しみ」はこれだったにょ。
mkII後継は厳しそうだから新しいプレゼント素材の配信程度だろうと予想していたけどまさか
第2回プチコン大喜利とは思わなかったにょ。
この手の公式のコンテストは販促効果もあるため新発売後は行うことが非常に高いのだけど
半年前にすでに実施していてここにきて第2回を実施するということは逆に言えば「mkII後継は
まだもうしばらく時間がかかる」ということを意味するにょ。（数ヶ月以内にリリースできる
ならばそれに合わせて大喜利を行うのがベストであるため）

さて、前回は3つのテーマからいくつかを選択してそれに沿った内容のプログラムを作るという
大喜利方式を採用していたのだけど今回はそれは健在にょ。
しかし、前回は解釈の仕方にもよるけど「事実上なんでもあり」だったのと比べると今回の
テーマである「1分間で十分（ばっちり）エンジョイ」というのはある程度絞られてくるにょ。
逆に言えばテーマがはっきりしている分だけそのテーマに沿ったものが作りやすいとも言える
のではないかと思われるにょ。

「1分」というのが重要な部分だけどテーマが限られているとはいえ実際に作るとなると
難しい面もあるにょ。
それは1分間で何をするのかが様々考えられるからにょ。
これは「1分＋動詞」で考えると内容を考えやすいにょ。
「1分で出す」「1分で抜く」「1分で走る」「1分で止める」「1分で逃げる」・・など実際に
言葉で表すとどんなものにするのかイメージしやすいのではないかと思われるにょ。
例えば「1分で止める」ならば「5秒止め」の1分バージョンなどが考えられるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1line.htm#16

もちろんジャンルを先に考えて「1分で遊べるRPG」「1分で遊べるシューティング」などを
元にそれからどんな内容にするかを考えてもいいわけだけど1分という時間を有効活用する
ためにはその1分で何を行うかということが非常に重要となるためゲームデザインをよく
考える必要があるにょ。
プレイに制限時間があるものといえばアクションゲームやパズルゲームでは珍しくないにょ。
私がプチコンで作ったものでは「JUMPING ISLAND」がプレイ時間に制限があるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/jumping_m.htm
1ステージ30秒でその間のスコア稼ぎがゲームのポイントになっているにょ。
もちろん、アクション、パズルだけに拘らずさまざまなジャンルで可能であり、実際に市販
ゲームではPSP用ソフトの「勇者30」のように30秒間で遊ぶRPGも存在するにょ。
面白いものになるかどうかは結局はそのゲームデザインやバランス調整次第で大きく変わって
くるにょ。（まぁ1分の使い方は自由みたいなのでゲームに拘る必要さえないけど）

すでに第2回プチコン大喜利は本日から受け付けを開始しており、4月30日までエントリーを
行っているにょ。
私も当然参加予定にょ。
可能ならば1画面プログラムを1本、1画面超のプログラムを1本作る予定にょ。
前回の第1回プチコン大喜利ではPETIT RUN mkIIで技術賞を戴いたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#prun2
今回もやはり参加するならば入賞を狙いたいところにょ。
まぁ「参加するなら大賞を狙う」と大きく出たいたいところだけど大賞になるためには並の
アイデアでは難しいからね。（誰も作らないものにあえて挑まないと・・・）
あと今回は大賞とは別にMVPという賞もあるみたいにょ。（Most Valuable Programmerの
略らしい）
こちらの賞も何だか気になるところにょ（笑）
1506：松田：2013/03/18(月) 10:34:01: ELGIN WATCH
人気の高額腕時計ロレックスやオメガなど欲しかったあのブランドが
お手頃価格で見つかるかも
ELGIN WATCH

http://www.elygine.com
1507：御茶目菜子：2013/03/20(水) 23:59:39: プチコンカタログ vol.3
プチコンユーザーのhonoPさんが作っているプチコンソフト紹介動画「プチコンカタログ
vol.3」が公開されたにょ。
http://www.nicovideo.jp/watch/sm20373062
http://www.youtube.com/watch?v=Im7JTVSGSSc

今回は先月（2月）の1ヶ月間にtwitter上で紹介されたプチコンプログラムが対象となって
いるにょ。
今回の動画は前回よりも紹介作品数が増えたため時間はさらに増えて50分というかなり
ボリューム感のある動画となっているにょ。
このプチコンカタログは前号までは1バージョンのみだったけど今回からは「全年齢のみ」と
「年齢指定のあるものを含むもの」の2種類が公開されているにょ。
全年齢の方は「CERO A指定（全年齢）」レベルだけど上記の年齢指定を含むものは「CERO B
（12歳以上）～CERO C（15歳以上）」レベルの作品も含んでいるにょ。

全年齢版
http://www.youtube.com/watch?v=Z_YX3Ujj2sw

プチコンユーザーは年齢が高い人（30～40代）が多いということを考えれば年齢指定がある
ものが作られるのは当然なのだけど逆に小中学生も多いためその配慮が必要ということで
わざわざ別バージョンを作ったものと思われるにょ。（プチコンユーザーは大学生～20代
くらいの人がかなり少ないイメージ）
実は私が作ったプログラムもいくつか全年齢版の動画では削られているにょ（笑）

先日、公式コンテストであるプチコン大喜利が発表されそれに向けて多くの人がプチコン
プログラムを作っていると思うにょ。
前回は応募総数は64作品だったけど今回はそれを大幅に上回りそうにょ。
そうなると大喜利投稿作品が掲載される号（5月号？）は1時間を超える動画になることが
予想されるにょ。
honoPさんも大変だけど頑張って欲しいところにょ。

さて、その大喜利だけどなかなかいいアイデアが浮かばないにょ。
ということで、条件を課して絞ってみることにしたにょ。
これはポケコンでは良くやっていたことだけど新しく作ったシステムを使って何かできそうな
ものはないかということを考えるというものにょ。
そこで候補に挙がったのが以前作ったGRP2軸回転プログラムにょ。
このプログラムは回転処理によってリアルタイムで平面を3D化可能であり、カメラアングル
とかカメラ距離も自由自在に調整が可能になっているにょ。

http://twitpic.com/ccwmpf
　※この画面写真では先日作った地球儀に使った地図データの上を走ってみたものであり
　　制作中のゲームの写真ではない。
　　この写真では見栄えを良くするため128x72ドットx2倍拡大としているけどこれだと
　　1fpsも出ないため実際に使用するときは32x12（～18）ドットx8倍拡大となると
　　思われる。
　　その場合は、GFILLで10fps、BGPUTを使って最適化を施せば19fpsとなる。

私が知る限りでは2軸回転プログラムをプチコンで作っているのは私だけなのでこれならば
インパクトのあるものが作れそうだけどそれを活かしたものとなると結構難しいにょ。
マリオカートのようなレースゲームならば（敵車を出さなければ）簡単に作れるけど
「1分」というテーマを考えるとレースゲームはあまりに単純過ぎて面白みがないにょ。
（普通にプレイすれば1分でゴールできるくらいのコースにすればいいだけのことだし）
やはり、作るならば何かひねりが欲しいところにょ。
前回の大喜利は何とか「技術賞」をいただけたけど次は競争率が高いだけに大賞どころか
入賞さえもかなり厳しそうだからね。
1508：hatena：2013/03/21(木) 20:58:44: おちゃめくらぶ誤字報告
誤字があったページはこちらです。
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm

・プチコン50m走
100m走ゲーム（2011/11/1）

作品「プチコン50m走」なのに、「100m走ゲーム（2011/11/1）」と書かれています。
おそらく、コピペして日付だけ変えたのでしょう。

ちなみに、「プチコン50m走」も「プチコン100m走」もかなりのプログラム短縮の余地がありますねー。
1509：御茶目菜子：2013/03/22(金) 01:06:12: レスにょ
hatenaさんへ
＞作品「プチコン50m走」なのに、「100m走ゲーム（2011/11/1）」と書かれています。
＞おそらく、コピペして日付だけ変えたのでしょう。

報告どうもにょ。

＞ちなみに、「プチコン50m走」も「プチコン100m走」もかなりのプログラム短縮の余地がありますねー。

初期の頃の作品はどれもリスト短縮の余地がありまくりにょ。
プチコン100m走はプチコン100m走mkIIとして、PETIT RUNはPETIT RUN mkIIとしてリスト短縮
してその短縮した分を画面表示をアップさせたり、ゲーム性をアップさせたりしているにょ。
他のも短縮できる余地はたくさんあるけど今のところ保留にょ（笑）
リスト短縮テクニックはどんどん新しいものが見つかっているためmkII発売以降に作ったものでさえ
リスト短縮が可能なものが多いにょ。
1510：御茶目菜子：2013/03/23(土) 23:59:52: EOS Kiss X7はミラーレス対抗のデジタル一眼なのか・・・？
キヤノンからデジタル一眼レフEOS Kiss X7とEOS Kiss X7iが発表されたにょ。
http://dc.watch.impress.co.jp/docs/news/20130321_592405.html
http://dc.watch.impress.co.jp/docs/news/20130321_592445.html

入門機を一気に2機種発表したわけだけどこれは過去にはEOS kiss X5とEOS kiss X50が同時
発表となったこともあるため初めてのことではないにょ。
X7i、X7と型番こそ似ているけどスペック表を比較するとかなり異なるものであることが
分かるにょ。

　　　　　　　　　　　EOS Kiss X7 　　　　EOS Kiss X7i　　　　EOS Kiss X6i
　センサー　　　　　　APS-C　　　　　　　 APS-C　　　　　　　 APS-C
　　　　　　　　　　　1800万画素　　　　　1800万画素　　　　　1800万画素
　バリアングル　　　　無し　　　　　　　　あり　　　　　　　　あり
　タッチパネル　　　　無し　　　　　　　　あり　　　　　　　　あり
　最高シャッター速度　1/4000秒　　　　　　1/4000秒　　　　　　1/4000秒
　静音撮影　　　　　　あり　　　　　　　　無し　　　　　　　　無し
　連写速度　　　　　　4コマ/秒　　　　　　5コマ/秒　　　　　　5コマ/秒
　サイズ　　　　　　　116.8x90.7x69.4　　 133.1x99.8x78.8　　 133.1x99.8x78.8
　重量（バッテリ込）　407g　　　　　　　　580g　　　　　　　　575g

まず、Kiss X7iの方からみていくとX6iと比べてその差は極めて小さいことが分かるにょ。
スペック表を見てみると唯一の違いはクリエイティブフィルタの仕様が変わった程度にょ。
あとはサイズは同一で筐体デザインが少し変わったため重量が5g減っている程度にょ。
それと本体ではないけどレンズキット付属レンズが動画サーボAFに対応したEF-S 18-55mm
F3.5-5.6 IS STMに変わった程度にょ。
クリエイティブフィルタの仕様変更程度ならばファームウェアの更新でいくらでも対応可能で
あるためわざわざ新機種を出す必要はないのだけどあえて出す理由としてはやはり値崩れ防止
というのが大きいと思われるにょ。
ほぼ同一仕様であっても新機種として投入することで再び適正な価格を維持可能になるため
十分な利益が確保可能になるにょ。
確かにレンズキットで付属するレンズが異なるため同一型番では分かりにくいというのも
あるにょ。
kissを買う層がそこまでレンズに拘るかどうかは分からないけど動画に強いというのを
メーカーがアピールしやすくなるためメリットは大きいと思われるにょ。
それと近日発表されるであろうEOS 70Dとの差別化を可能にするためKiss X7iの性能を
意図的に上げなかったということも考えられるにょ。（これはキヤノンだけに限ったことでは
ないけど下克上が極力起きないようにするというのはよくあること）

ということで、Kiss X7iはKiss X5がX50と同時発表であったためX4のマイナーバージョン
アップに止まっていたのと同じくマイナーバージョンアップでしかないのだけどX7の方は
正真正銘の新機種にょ。
そして、やはりウリとなるのはAPS-Cセンサー搭載のデジタル一眼の中で世界最小最軽量と
いうことにょ。
本体だけだと370g、バッテリと記録メディアを込みでも407gしかないわけだからね。
他社のエントリーモデルが500g程度であることを考えるとこれは驚異的にょ。
重量だけではなくサイズも明確にKiss X7iとは異なり意図的に差別化を行っていることが
分かるにょ。

さて、このKiss X7だけどやはりこれを出す根底にあるのがレンズ交換式のミラーレスの
需要増大だと思われるにょ。
数年前まで驚異的な拡大をしていたデジタル一眼もここ2、3年は国内では伸び悩んでいて
その代わりに売れているのがミラーレスにょ。
この根底にあるのはコンデジからのステップアップとしてより高画質で撮影可能なものを
望んでいるユーザーが多いというのもあるにょ。
その役割は従来はデジタル一眼が担っていたにょ。
当初は非常に高価だったデジタル一眼も2000年代半ばからいわゆる入門機と呼ばれる10万円
以下の機種が投入されるようになり普及が大幅に進んだにょ。
確かにデジタル一眼は今では下位モデルでは新機種でさえ7～8万円程度から購入可能であり
入門機は1年ごとに新機種が投入されるため値下げ率も大きいため1年後には半値近くまで
下がっていることも珍しくはないにょ。
そのためコンデジからのステップアップを求めるユーザーは昔（10年くらい前）と比べて
買いやすい価格になったデジタル一眼を買い求めたというわけにょ。

しかし、いくら安くなったとはいえやはり問題はそのサイズや重量にょ。
センサーサイズは銀塩カメラでは主流だった35mmサイズ（いわゆるフルサイズ）と比べて
1/2.3のサイズしかないAPS-Cセンサーを搭載機であっても入門機で本体重量は500～600g
程度、中級機ならば700～800g程度あったわけだからね。
それに別途レンズの分が加算されるにょ。（APS-Cならば標準ズームでも200g以上）
すでに一眼レフを使っている人が買うのならば全く問題はないとはいえ、一眼レフをあまり
使ったことがない人にとってはこれは大きく重いと言わざるを得ないにょ。

そこで注目を浴びたのがミラーレスにょ。
ミラーレスは一眼レフで筐体サイズや重量増の原因となっているクイックリターンミラーや
ファインダーに用いられているペンタプリズムを搭載しないことで小型（薄型）、軽量化が
可能になっているからね。（デジタル一眼でも入門機はコスト削減と軽量化のためペンタ
プリズムではなくペンタミラーが採用されている）
当初はデジタル一眼のサブ的な存在であったミラーレスもコンデジからのステップアップ
ユーザーが増えたためラインナップが増して入門用の機種が多く登場したにょ。
ミラーレスはコンデジと同じく液晶画面を見ながら撮影できるという点もコンデジからの
ステップアップには向いているのだけどこれを可能にしているのがライブビュー撮影にょ。
ライブビューは今ではデジタル一眼でも搭載していない機種が珍しいくらいだけどデジタル
一眼ではAFは位相差検出方式に特化しているためライブビューで主に使われているコント
ラスト検出方式では遅いという点がネックになっているにょ。

キヤノンのデジタル一眼においては位相差検出方式においては業界トップレベルであるものの
コントラスト検出方式によるAFは他社と比べてかなり見劣りしていたにょ。
それを改善したのがEOS Kiss X6iによるハイブリッドAFにょ。
Nikon 1などと同じく像面位相差検出方式に対応したセンサーを搭載しているものの位相差
検出方式だけではなくコントラスト検出方式と組み合わせることで速度と精度を維持して
いるにょ。
このハイブリッドAFによってキヤノンはミラーレスのEOS Mを立ち上げることができたにょ。

今回のEOS Kiss X7はこのハイブリッドAFをさらに高めたものとなっているにょ。（X7iは
従来のX6iと同等なものが搭載されている）
そうなるとこのKiss X7はEOS Mと競合してしまう可能性があるにょ。
ミラーレスとデジタル一眼は別物とはいえ、ユーザーからすればサイズ、重量の問題が緩和
すればミラーレスである必要はなくデジタル一眼でも問題ないという人も大勢いるだろう
からね。（むしろ、ファインダーを見ながら撮影できるということをメリットとして捉えて
いる人も少なくない）
なぜキヤノンがあえて競合する可能性の高いモデルを投入したかというとやはりEOS Mが
現時点では不完全なものであるためだと思われるにょ。

まずは、先ほども書いたようにAFの速さはキヤノンのデジタル一眼においては大きなアドバン
テージだったけどこれはハイブリッドAFによって従来よりも高速化されたとはいえまだ他社と
比べて十分に速いとは言い難いレベルだからにょ。
そして、まだ発売からの期間が短いとはいえ依然として標準ズームとパンケーキレンズの
2本しか交換レンズがない状態では苦戦はやむを得ないにょ。
キヤノンのデジタル一眼の大きなアドバンテージはAFだけではなくその豊富なレンズ資産も
あるからね。
確かにアダプタ経由でEF-Sマウントのレンズも使用可能になるとはいえ、マウントが嵩張る
だけではなくAFもさらに遅くなってしまうというのがネックとなるにょ。
したがって、EOS Mを主軸に据えるには今後さらにハイブリッドAFが高速化されてなおかつ
レンズもそれなりにラインナップが揃う必要性があるにょ。

現時点ではEOS Mを中心にした場合には（アダプタを経由すればEF-Sマウントのレンズが
使えるとはいえ）別マウントになってしまうためあえてEOS Mを買う必要性というのは
「キヤノンブランド」が必要な人に止まると思われるにょ。
そうなると豊富なレンズ資産や高速なAFが活かせるデジタル一眼で小型化した方が他社と
比べて有利に立てるというのがキヤノンの考えではないかと私は思うにょ。
デジタル一眼の中では最小、最軽量とはいえミラーレスと戦えるレベルのサイズ、重量かと
言われたら微妙だけど現実的な面を見るとミラーレスがヒットしても量販店の販売台数
ベースでは依然としてEOS Kissは高いシェアとなっているわけだからね。
他社のミラーレスに流れるユーザーを少しでも食い止められるだけでもかなり恩恵がある
と思われるにょ。
その間にEOS M用のレンズのラインナップを増やしハイブリッドAFを高速化して他社の
ミラーレスと十分に戦えるようになったときにKissを縮小させれば問題ないわけだからね。
つまり、キヤノンにとってはまだそこまでミラーレスに注力するほどではないという判断の
結果がEOS Kiss X7と言えそうにょ。（EOS Kiss 7が7iの下位機種だと考えるとAFの
性能向上や静音撮影が可能になっていたりと上位機種を上回る面が見られるため単純に
下位だからすべての面でスペックが劣っているとはいえないことが分かる）
1511：道産子の初心者：2013/03/26(火) 15:13:27: リンクの説明の書き換え申請
プチコントーナメントのエントリーは締め切ったので説明を書き換えお願いします。

http://www53.atwiki.jp/petctournament
1512：御茶目菜子：2013/03/27(水) 00:31:09: レスにょ
道産子の初心者さんへ
＞プチコントーナメントのエントリーは締め切ったので説明を書き換えお願いします。

リンクの説明文を書き換えておいたにょ。
1513：道産子の初心者：2013/03/27(水) 21:54:04: レス
=おちゃめさんへ=
確認しました。ありがとうございます。

http://www53.atwiki.jp/petctournament
1514：御茶目菜子：2013/03/27(水) 23:59:41: レスにょ
道産子の初心者さんへ
＞確認しました。ありがとうございます。

いえいえ、また何かあったら言ってにょ。
1515：御茶目菜子：2013/03/28(木) 00:00:53: 何fpsくらいあればゲームは快適にプレイできるのか・・・？
さて、第2回プチコン大喜利の締め切りまで1ヶ月余りとなったわけだけどいいアイデアが
ないため3月20日に書いたようにレースゲームを作ることにしたにょ。
ただし、前回の大喜利ではレースゲームのPETIT RUN mkIIで技術賞を戴いたのにまたレース
ゲームでは芸が無さ過ぎるためプチコンでは例のない自由視点のレースゲームにすることに
したにょ。
これは行列演算を行えば簡単にできるにょ。
ここで問題なのが処理速度にょ。
コースは2軸回転で32x18ドットの8倍拡大とすれば1152回の回転処理を行う必要があるにょ。
http://web11.twitpic.com/ccwmpf　（2軸回転のイメージ写真）
このコースにマッチさせる自機をどうするかだけどこれはポリゴンにすることにしたにょ。
サンプルとして簡単にモデリングしてみたにょ。（モデリングソフトは作ってないので脳内で
モデルをイメージしてその脳内座標を直接データ化した）
http://web11.twitpic.com/cdp7b9

F-ZEROを意識した機体だけどあまりカッコイイものではないもののこれでも34ポリゴンも
使われているにょ。（ポリゴンならば自由な角度から描画できるためカメラアングルを1度
単位で変えても問題なく表示が可能になる）
頂点数は20個なので40回の回転処理をする必要があるにょ。
つまり、敵が全く出ない状態のタイムアタック専用であっても1192回の回転処理が必要と
いうことにょ。
プチコンでは概ね1フレームあたり60回の回転処理が行えるにょ。（といってもポリゴンと
2軸回転では速度が全然異なるので3月14日に書いたプチコンにおける実行速度を参照）
単純に考えれば1回の表示で20フレーム以上かかるため普通に作れば3fps以下という速度に
なってしまうにょ。
やはり、これではあまりに辛すぎるため高速化を行う必要があるにょ。
2軸回転においてはすでにある程度の高速化の目処はたっているとはいえ厳しいことが
予想されるにょ。

プチコンはかつての8bitパソコンと比べて数10倍という高速であり、ポケコンの中では
高速なPC-E650と比べても100倍くらいの速度にょ。（グラフィック表示に至ってはE650の
1万倍くらいの速度）
http://ww5.tiki.ne.jp/~ochame/petitcom/what.htm
このためよほど重い処理をしなければ60fpsの速度を出すことが可能にょ。
私が作ったゲームも大半が60fps（もしくはそれ以上）となっており、それよりも遅いものと
なるとGCOPYによるスクロールを行っている「JUMPING ISLAND」やリアルタイムでX軸回転を
行っている疑似3Dレースゲーム「2D→3D RACE」の30fpsなどがあるにょ。
しかし、今回作ろうとしているゲームは30fps以上の速度を出すのは不可能にょ。

では、最低でもどの程度の速度ならば問題ないかというとこれはなかなか結論を出すのは
難しいにょ。
しかし、私のポケコンの経験からある程度は判断が可能にょ。
一般的なゲームだと最低30fps、できれば60fps欲しいところだけどポケコンBASICという
ことを考慮すれば以下のようになるにょ。
http://ww5.tiki.ne.jp/~ochame/E500/LECTURE/making_3.htm

　◎リアルタイム系のゲームの必要速度
　　一般的な操作のゲーム　　 5～10fps
　　連射を要求するゲーム　　10～20fps

この理由については上記のリンク先に詳細を書いているので読んでもらいたいにょ。
つまり、一般的な操作のゲームの場合は5fpsあればそのメインルーチンのキー入力判定に
合わせて入力することで問題なくプレイできるレベルであり、10fpsならば（キーを押している
時間が全体の半分と仮定した場合）普通に押して概ね追従できるレベルの速度といえるにょ。
プチコンでBASICを始めた人ならばこれは「すごく基準が甘い」と感じるかもしれないけど
古くからBASICを使っている人だと大体同意してもらえるのではないかと思われるにょ。

上記のようにポケコンでは高速なPC-E650でさえプチコンと比べたら100倍くらい遅いわけ
だから一見簡単そうに見える5fpsでもプチコンでは500fps相当（グラフィックを使うもので
あればそのさらに1桁上の速度）のプログラムを作るようなものと考えれば分かりやすいにょ。
コンソールで作られた50m走でさえ45fps、8x8ドットのキャラを動かすだけで11fpsしか出ない
わけだからね。
http://ww5.tiki.ne.jp/~ochame/E500/LECTURE/making_3_2.htm
それでも、私が実際に雑誌等に掲載した作品では高速化を駆使したり、OPAS（プチコンで
いえばPCGを駆使してアニメーションやスクロールを可能にしたもの）を用いて何とか7～8
fpsという速度を得ているにょ。

というわけでプチコンならば容易に見える5fpsもポケコンBASICだとかなり難しいことが
分かるにょ。
その場合はゲーム性でカバーできていれば問題ないにょ。
5fpsあればタイミングよくキーを押せば何とかなるため格闘ゲームならば波動拳コマンドを
入力（テンキーで2→3→6）する場合に1フレームのずれもなく正確に入力することで必殺技が
出るようにすれば「タイミングよく押さないと動作しない」ということを有効活用が可能に
なるにょ。
これが10fpsであればタイミングよく1フレームのずれもなく押すというのは極めて困難に
なるにょ。

しかし、現実的にはオールBASICのポケコンゲームならば5fpsにも満たないものも少なくなくて
ゲーム性でカバーできているかと言われたら微妙なものも多いにょ。
その場合は高速化が重要になってくるにょ。
高速化は上記の必須ラインである5fpsより遅ければそれだけ高速化の効果は大きくなり、
推奨ラインとなる10fpsを大きく越えるものだと高速化の効果は小さくなるにょ。
つまり、同じ「3倍の高速化」が可能であっても15fps→45fpsよりも3fps→9fpsの方が
高速化をより大きく体感することが可能になるということにょ。（前者はスピード感や
なめらかさが増すくらいだけど後者はゲームとして成立するのが難しかったのが普通にプレイ
できるレベルになる）
そのため5fpsに満たないものが多いポケコンBASICでは高速化の恩恵が極めて大きいのだけど
遅いのをBASICのせいにしている場合も少なくないにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/basic9.htm
「高速化しようとしない限りは速くならない」というのは紛れもない事実であり、これは
ポケコンよりも100倍程度高速なプチコンにおいてもいえることにょ。

もっともプチコンの場合は上記のように簡単なアクションゲームならば60fpsは余裕で出す
ことができるにょ。
では、実際に60fpsのゲームと30fpsのゲームを比較するとどちらがスピード感を得られるか
というとこれはゲームの作り方によっても変わってくるにょ。
60fpsの方が30fpsよりもなめらかさでは上回るけどスピード感では必ずしも上回るわけでは
ないということにょ。
オブジェクトなどの移動量によって「スピード感がある」と判断してしまうことが多いと
いうのが理由にょ。（もちろん、60fpsより30fpsの方がスピード感があるというのではなく
作り方によっては逆転もあり得るというだけの話だけど）
その場合も30fpsではなく15fpsになって移動量を2倍にしたらスピード感はさらに増すのか
というとそんなことはなくやはり30fpsくらいがスピード感を得られるボーダーラインに
なるのではないかと思われるにょ。（この辺は人によって感覚も違うだろうけど反応速度が
遅いモノクロSTN液晶のポケコンならば15fpsと30fpsでは表示においてはほとんど差がない
ため連射時の入力判定の漏れがあるかないかの違い程度になる）

さて、そうなると「10fpsあればボタン入力判定漏れ」は緩和できるとはいえ可能な限り
30fpsに近づけるようにするのがベターだといえるにょ。
それにボタン入力判定も「秒5回」で「半分の時間押している」という仮定において10fps
ならば問題ないというだけであって連射をしなくても秒7～8回の入力は十分行えるわけ
なのでそうなるとスピード感はともかくとして快適にプレイできる最低のボーダーラインは
15fpsくらいになると思われるにょ。
したがって、私が大喜利用に作るゲームもそれを目標に高速化を行う予定にょ。
1516：天郷思音：2013/03/30(土) 19:05:07: (無題)
今使ってるカメラはカインズのトイデジで131万画素で1980円。
「カインズ　トイカメラ」と検索したら出てきたのでそれなり知名度があるようなのでカメラに詳しいおちゃめさんのところに今使ってるカメラの報告に来た。
モニターがない。動画も撮れる。静止画は1280*1024で保存されるけど半分くらいにリサイズしないと質が悪い。
青系の色が変なのはなぜだろうと思ったがほかの人の持ってる同機種でも同じようなことが起こるとのこと。
1517：御茶目菜子：2013/03/30(土) 21:55:08: レスにょ
天郷思音さんへ
＞今使ってるカメラはカインズのトイデジで131万画素で1980円。
＞「カインズ　トイカメラ」と検索したら出てきたのでそれなり知名度があるようなのでカメラに詳しいおちゃめさんのところに今使ってるカメラの報告に来た。

90年代末～2000年代初頭はまだデジカメが高価で普及クラスのものでも3～5万円していた
ため1万円以下で買えるトイデジカメの需要は大きかったにょ。
昨今はケータイやスマホのカメラ性能のアップや普及クラスのデジカメならば1万円台で
購入可能（型落ち品ならば5～6000円で売られていることもある）ということもありトイ
デジカメ需要は減ったかのように思えるけど普通のデジカメではあまり見られないような
奇抜なデザイン、大胆な省略化（ファインダーや液晶モニタがない）などでファッションの
一部として購入する人も結構多いにょ。
また、昨今のデジカメはシャッターを押せば普通に映るのに対してトイデジカメはどんな
写真になるのか画像を開くまで分からないという楽しさがあるにょ。
それ故、トイデジカメ特有の描写を求めて使用している人もいるにょ。
デジカメによってはわざわざ画質を落としてトイデジカメ風にするという撮影モードを内蔵
している機種もあるくらいだしね。
私は天郷さんが購入したトイデジカメは使ったことがないもののその価格ならば使用方法に
マッチしているならばお買い得ではないかと思われるにょ。

＞モニターがない。動画も撮れる。静止画は1280*1024で保存されるけど半分くらいにリサイズしないと質が悪い。
＞青系の色が変なのはなぜだろうと思ったがほかの人の持ってる同機種でも同じようなことが起こるとのこと。

トイデジカメは上記のように普通のデジカメと比べたら画質の面では劣るにょ。
デジカメの画質を決めている主な要因としてはセンサー性能、レンズ性能、画像処理エンジン
性能が挙げられるけどセンサーそのものがそんなに低品質なものが使用されているという
わけではなくやはりレンズ性能や画像処理エンジン性能が通常のデジカメと比べて劣っている
ためだと思われるにょ。
そのため単純に画素数だけで画質は比較ができないにょ。
半分くらいにリサイズしないとキレイに見えないというのは理由としてはレンズ性能が低いと
いうのと画像処理エンジン性能が低いというのが理由となるにょ。

このレンズ性能に関しては普通のコンデジでも最近は顕著になってきているにょ。
普及クラスでも1000万画素以上が当たり前で主流は1600～1800万画素となっているにょ。
普及クラスのコンデジのセンサーサイズは10年前から1/2.3～1/2.5インチ程度の大きさを
維持しているのだけど10年前は200～300万画素が主流だったにょ。
画素数が8倍くらい増えてセンサーサイズが変わらないというのはそれだけレンズ性能が
要求されるようになっているにょ。
しかし、普及クラスのコンデジでそこまで高性能（高解像力）なレンズを搭載するのは
難しいにょ。
また、レンズの解像力が上がっても回折限界という物理限界は避けることができないにょ。
1/2.3インチ、1600万画素ならば開放F値がF2程度でないと解像は無理であり、この条件を
満たしている機種は一部の機種に限られるにょ。
したがって、昨今の高画素のデジカメではセンサーの画素数と同じ画素数の画像を出力
したものを等倍で鑑賞した場合には細部の描写はあまり行われないにょ。
実際、私が使っているCyberShot WX100（昨年発売された1800万画素モデル）は1800万画素
では鑑賞には堪えられないけど500万画素で撮影すれば十分キレイに見えるにょ。

また、ほとんどのデジカメではベイヤー配列のセンサーが搭載されており、センサーの
1画素ではRGBの各成分の情報しかないにょ。
それでなぜフルカラーの画像ができるのかというとそれは画像処理エンジンによって隣の
センサーの情報を元に演算されているからにょ。
とはいえ、それでは幾何学的な細かい模様を撮影した場合には偽色が発生してしまうため
多くのデジカメではローパスフィルタによって低周波部分のみカットしているにょ。
ごく簡単にいえば少しぼかしてアンチエイリアスをかけた状態にするということにょ。
そのため等倍ではどうしてもキレイには見えないにょ。

こうしてみるとレンズ性能や画像処理エンジンで劣っているトイデジカメが等倍では
キレイに見えないことは容易に説明ができるにょ。
昨今のコンデジのように1000万画素が当たり前というものとは異なり、トイデジカメは
100～500万画素程度であり、レンズに要求されるハードルは幾分低くなっているものの
それでもコスト面を考えるとレンズがボトルネックになっているのは否めないにょ。
また画像処理エンジン性能が低いためRGBの各成分からフルカラーの画像を生成する際は
発色が芳しくなかったり、ノイズが残ってしまうことがあるにょ。
JPEGが2x2単位になるというのは、ベイヤー配列センサーの情報をフルカラー画像に生成する
際には内部では2x2単位で処理をしている（ベイヤー配列の場合は任意の2x2の画素を取り
出した場合にはRx1、Gx2、Bx1となっているため単純にRGBの情報を得られる）けど処理を
簡略化している（要するに画像処理エンジンの性能が低い）ために起きている現象と考え
られるにょ。
緑の発色が悪いのは補色フィルタを使用している影響というのも考えられるにょ。
デジカメのセンサーはRGBの各成分の情報を得るためにカラーフィルタを使っているのだけど
昨今は原色フィルタによってRGBの情報を得ているものが大半にょ。
しかし、かつては感度で有利な補色フィルタを用いてイエロー、マゼンダ、シアンの情報を
得てそれからRGBの情報を演算で求めるというものが主流だったにょ。
画像処理エンジンが優れていれば「補色フィルタだから色が悪い」と単純には言えないけど
トイデジカメに搭載されている画像処理エンジンではそこまで望むのは難しいにょ。

というわけで、「トイデジカメ」ということを考えると納得できる範疇だと思うにょ。
もしも、画質に不満があるならば昨今の国内の大手メーカー製のデジカメを買うのが良いの
ではないかと思われるにょ。
1年前の機種でも大きく性能が落ちるなんてことはないため半値以下に下がった型落ち品の
セール品を狙うのが良いのではないかと思われるにょ。
あまり安価な機種だと光学式の手ぶれ補正がないため室内や暗所などではフラッシュ撮影が
不可欠になるにょ。（フラッシュを使ったら描写が不自然になったり、反射で撮影対象が
映らなかったりという問題もあるため個人的にはフラッシュはほとんど使わない）
あと室内や暗所などでの撮影が多いならば高感度設定で使う頻度が高いのでそれを重視して
いる機種を買うのがベターだと思われるにょ。
1518：御茶目菜子：2013/03/30(土) 21:56:41: やっぱりゲームはUIが重要
ゲームでは重要なものの1つにUIがあるにょ。
プチコンはDSiウェアということでDSiのハードウェアボタンやタッチパネルを使用することが
できるにょ。
3DSでもDSiウェアとして動作するため3DS専用のデバイスにはプチコンは対応していないにょ。
画面解像度や立体視はまぁ仕方ないとしてアナログ入力が可能なスライドパッドは対応して
いるとゲームの幅が広がるだけに残念に感じている人も多いのではないかと思われるにょ。
それならば作ればいい・・・ということで「アナログPAD」ルーチンを作ってみたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#pad

仕組みはあえて説明するまでもないくらい単純なもので単純にタッチした座標を元に判断を
しているだけにょ。
一般的な手法だとATANでパッドの中心を原点として考えた場合の角度を求めてそれから
SIN、COSを使って求めるというものが考えられるにょ。
これはシューティングゲームでは誘導弾などでは常套手段だけどここで必要な角度は原点を
基準としたタッチ座標の角度であるためATANからSIN、COSを使って求めるのは二度手間に
なってしまうにょ。
そのためタッチした座標からそのままX、Yの移動量を求めているにょ。
この座標を一定数倍すればゲームのキャラの移動に使えるにょ。
ゲームに使用する場合はベクトルの向きと大きさを示すものよりもX、Yに分解したものの
方が圧倒的に多いためこの方が処理速度の面でも有利になるにょ。
角度がどうしても欲しい場合はATAN(X,Y)で求められるからね。

さて、こういったアナログ風の操作はレースゲームのハンドル操作でも使用できそうだけど
それならば最初からハンドル型のコントローラーを用意した方がいいにょ。
というわけで、「ハンドルコントローラ」ルーチンも作ってみたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#handle
ハンドルコントローラルーチンはアナログPADルーチンで代用できそうだけど両者には
決定的な違いがあるにょ。
それは絶対座標による入力と相対座標による入力の違いにょ。

絶対座標は原点を定めてそれからの距離で決まる座標系だけどこれはアナログPADの場合は
タッチした座標とX、Yの値は1対1で対応しているにょ。
そのため前回どこにタッチしたのか関係なく現在タッチしている座標ですべて決まるにょ。
しかし、ハンドルコントローラの方は前回タッチした座標との差分をとって相対的な値を
元に演算されているにょ。
例えばPCで絵を描く場合にはマウスは相対座標なのに対して一般的なペンタブレットは
デフォで絶対座標の設定（相対座標にも変更はできる）となっており、ペンタブ上でタッチ
した座標がそのままPC画面に反映されるにょ。
「どこを示すか」が分かりやすいのが絶対座標で「どれだけ動かしたか」が分かりやすいのが
相対座標にょ。
そのためポインティングデバイスやお絵かきでは絶対座標の方が都合がいいにょ。

ただし、ポインティングデバイスとして使用する場合には画面とポインティングデバイスの
サイズ差が非常に大きいため絶対座標の方がいいとは言えないにょ。
ドット単位の緻密な操作するためには相対座標によるものの方が都合がいいにょ。
ただし、アナログPADもハンドルコントローラも座標を出力するものではなく移動量を出力
するものなのでこのPCにおけるポインティングデバイスとは異なるものの相対座標と絶対
座標は操作感が異なるものであるということは分かるのではないかと思われるにょ。
ハンドルコントローラはどれだけ移動したかが分かりやすいためレースゲームに向いた
直感的な操作が可能になるというメリットがあるわけにょ。
ちなみにIF ABS(A)>1.57THEN～の前の行にA=AN*T:SA=SGN(A)を入れると相対座標入力
から絶対座標入力へと変わるにょ。
これを実行すれば相対座標入力の方が操作しやすくてハンドルコントローラールーチンに
絶対座標入力をを行うならば上記のアナログPADの方が直線的で分かりやすいと感じるのでは
ないかと思われるにょ。

ただし、いくら相対座標入力で感覚的に操作しやすくなったとはいえタッチパネルを使って
擬似的に実現しているため実物のハンドル型コントローラと比べたら操作感では劣ってしまう
のはやむを得ないにょ。
それでも、一般的なハンドルのように回した際には元に戻ろうとする力が働くようなものを
再現しているにょ。
実際に力が加わるわけではないのだけどそのままの角度を維持しているとまっすぐ進むため
「0度の角度に戻す」という余分な操作が必要になるにょ。
かといって、離した瞬間に角度が0に戻ってしまうと操作ミスが頻発してしまうためその戻る
速度も適度と感じるものに調整してみたにょ。（最大角から100フレームで0に戻るように設定
しているけどこれは60fpsでの動作を元に作っているためそれより遅いゲームに使用する場合は
ハンドルが戻る角度はそれに比例した速度にした方がいいかも）
あと、ハンドルは隅（円周上）をタッチ操作しなくても円内であればどこであってもタッチ
操作は可能であるため見た目（線1本分の幅）ほどは操作性は悪くはないにょ。
しかし、あまり行わない操作であるためこれを使ったゲームは難易度がどうしても高くなって
しまいそうにょ。
試しにPETIT RUN mkIIに組み込んでみたのでどんなものかはそれをプレイして判断して
みて欲しいにょ。
http://twitpic.com/cfdchr

とりあえず、このハンドルコントローラールーチンは大喜利に投稿予定のレースゲームに
採用予定にょ。
まぁまだこのレースゲームは仕様を考えている段階であるため今後大幅な変更があり得るし
まだ採用すると決まったわけではないけどやはり一番の問題は処理速度にょ。
ボタン入力ならば15fpsあれば入力漏れはほとんど無くなるけどタッチパネルによる操作
だと15fpsではどうしてももたつき感が出てしまうにょ。
これは表示速度が遅いためなめらかさに欠けるというのも要因の1つだろうけど今後の
高速化がどこまでできるかが操作性に大きな影響を与えることになりそうにょ。
実はこのハンドルコントローラールーチンは先日「沈没ゲーム」の試作品を作ったときに
思いついたものにょ。
http://twitpic.com/cce1uj
まぁこれを作ったときはそんなことを全く考えてなかったのだけど・・・（笑）

DSや3DSではレースゲームがたくさんあるけどタッチパネルをハンドルに見立てて操作する
ゲームというのは私が知る限りではリッジレーサー（北米版）くらいしかないにょ。
これはハンドルは直感的な操作が可能とはいえタッチパネルとボタン操作の両立が難しい
というのが一番の原因ではないかと思われるにょ。
そうなると私が作ろうとしているレースゲームもその辺が重要になってくるかもしれないにょ。
1519：マリモーマ：2013/03/31(日) 00:45:56: ネジコンも　昔あったな
ハンドルコントローラーで使いにくいのは wiiのマリオカートのやつかも
あれは　慣れないと難しい気がする

http://liv0.com
1520：御茶目菜子：2013/03/31(日) 23:33:47: レスにょ
マリモーマさんへ
＞ネジコンも　昔あったな

ネジコンは初代プレステで使ったけど回転角をつかむまでは操作をするのはなかなか難し
かったにょ。

＞ハンドルコントローラーで使いにくいのは wiiのマリオカートのやつかも
＞あれは　慣れないと難しい気がする

WiiのマリカーはプレイしていないけどWiiリモコンの加速度センサーを利用しているだけで
ハンドルコントローラーはただの外枠だからやっぱりコツをつかむまでは難しそうにょ。
どんなコントローラでもやはり重要なのは慣れなので十字ボタンでの操作に慣れている以上は
初見だとそれが一番簡単に感じてしまうにょ。
1521：道産子の初心者：2013/04/01(月) 12:04:03: リンク説明書き換え申請
プチコントーナメントが開催されたので説明の書き換えをお願いします。
何度もお願いして申し訳ございません。お願いします。

http://www53.atwiki.jp/petctournament
1522：御茶目菜子：2013/04/01(月) 22:21:51: レスにょ
道産子の初心者さんへ
＞プチコントーナメントが開催されたので説明の書き換えをお願いします。

説明を書き換えておいたにょ。
せっかく開催させるわけだからぜひ成功させてにょ。
1523：御茶目菜子：2013/04/01(月) 22:23:04: 真実はいつもひとつ・・・？
さて、4月1日ということで恒例のエイプリルフールネタが今年も健在にょ。
http://nlab.itmedia.co.jp/nl/articles/1303/29/news077.html
http://www.kotaku.jp/2013/04/april_fools_day.html

企業によってはこの日のために綿密な準備をいているようなところもあるわけであって
手の込んだネタを仕込んでいるサイトも多くあるにょ。
エイプリルフールを逃すと公開はできず、しかも旬ネタだったら来年流用するというのも
難しいだけに遅れて公開するというわけにはいかないからね。
とはいえ、100％すべてがウソというわけではなく中にはエイプリルフールに便乗して本当の
ネタ（ネタではなく事実か）を仕込んでいる場合もあるためその見極めも必要にょ。
まぁエイプリルフールネタが好評だったから前向きに健闘した結果実現という場合もあるため
その時点ではネタでも結果として真実になる場合もなきにしもあらずだけどね。
もっとも、100％ネタとわかるネタが大半なのでそんなに悩む必要もないんだけど・・・。

さて、私はプチコン大喜利用のゲームを考えている間にプチコンにアーケードゲームである
「ソルバルウ」を移植してみたにょ。
ソルバルウといえば昨年のエイプリルフールでTINY野郎さんがプチコンで再現ということで
話題になったにょ。
http://www.youtube.com/watch?v=6chAcvkzWYg
しかし、これは動画を見ての通り明らかにプチコン上で動作していないのだけどそれでも
だまされる人が数多く現れたにょ。

それから1年・・・。
少し簡略化すればいくらでもプチコンで動作するだろうということで作ったのがこれにょ。
http://twitpic.com/cg4zbm
これは紛れもなく実際にプチコン上で動いているにょ。
以前から作っていた高速ポリゴンルーチンが役に立ったにょ。
まぁ、まだ完成度は低いけどプチコンの性能があればここまでのことは簡単にできるにょ。

《　4月2日追記　》

エイプリルフールのネタばらし

これはプチコン上で動作しているものの単にポリゴンのアンドアジェネシスが動くだけの
ゲーム性が全くないものにょ。
しかも、152ポリゴンも使っているため1～2fpsしか出ないのでここからさらに開発を続ける
気は全くないにょ（笑）
ちなみにモデリングはすべて脳内で行ったにょ。
そのため微妙な計算違いがあってポリゴンに隙間が出来てしまう場合があるけどこれは
まぁ気にしてはダメにょ（笑）
一晩で即興的に作ったためやむを得ないにょ。

このアンドアジェネシスのポリゴンデータはポリゴン表示ルーチンを正式公開時に配布予定
となっているのでお楽しみに！
まぁ速度面の問題もあるので実用性があるかは微妙なデータだけどとりあえずグリグリ
動かして楽しむといいにょ。
ワイヤーフレームならば18fps出ているので結構スムーズに動かせるにょ。

ちなみに動いている様子の動画を撮影したのはこんな感じにょ。
ポリゴンだと1～2fpsということで拡大縮小や回転のペン操作もまともに受け付けてくれない
けどワイヤーフレームならばそこそこ反応はいいというのは分かると思うにょ。
http://www.youtube.com/watch?v=XmvYJA1iuz0
1524：gamekool.net：2013/04/04(木) 15:57:17: R4i sdhc rtsが3DS V5.0.0-11に運行できるため、更新方法の指導
3DSの新バージョンV5.0.0-11で運行できるように、R4i SDHC 3DS V4.5とR4i SDHC RTSを更新する必要があります。
　実は違ったカードの更新方法はそんなに大きな差別が’ありません、こちらはR4i SDHC 3DS

V4.5を例として、論じます。更新必要のある方はみなこの方法をも参考できます。
このブログをご参考ください。http://blog.livedoor.jp/gamekool/archives/6416690.html

http://blog.livedoor.jp/
1525：gamekool.net：2013/04/04(木) 15:58:46: ニンテンドーの3DS/LL本体は更新できない症状と解決方法
先日、ニンテンドーは3DS本体を更新しました。今回の更新は主にeshopの性能を向上しました。eshop起動中のスリープモードでも、インコンシャス通信情報も取れるようになりました。そして、パッチ更新もバックステージでダウンロードできます。そのうえ、eshopはファイル移転ツールも増加して、プレーヤーはダウンロードできます。

　　それと同時に、一部のプレーヤーは新バージョンv5.0.0-11に更新した後、eshopに入れなくなってしまい、本体設置、ゲームノートにも入ることができなく、電子説明書といった悪質バグが出てくるなんて、プレーヤーは次々とニンテンドー公式のtwitterとfacebookへ苦情を言いに行きました。これに対して、とニンテンドーの公式サイトは今回のバグを解決する緊急な公告を発布しました。

　　その解決方法の分からない方はこちらのブログをご参考ください。　http://blog.livedoor.jp/gamekool/archives/6418338.html

http://blog.livedoor.jp/
1526：天郷思音：2013/04/06(土) 09:33:09: (無題)
攻撃の威力は「攻撃力/防御力」と「攻撃力-防御力」どっちの式がいいだろうか。
ちなみに公式素材の戦車を使ったゲームです。
1527：御茶目菜子：2013/04/06(土) 23:30:57: レスにょ
gamekool.netさんへ
＞ニンテンドーの3DS/LL本体は更新できない症状と解決方法

私は不具合が起きたことはないけど参考にしておくにょ。

天郷思音さんへ
＞攻撃の威力は「攻撃力/防御力」と「攻撃力-防御力」どっちの式がいいだろうか。
＞ちなみに公式素材の戦車を使ったゲームです。

攻撃力、防御力のパラメータの取り得る範囲やレベルアップ等での上昇量を調整すれば
どちらも同じような値を取ることができるものの後者の方が簡単で扱いやすいと思うにょ。
というのも前者だと例えば攻撃力100、防御力10だとダメージが10だけど防御力が1ならば
ダメージが100になってしまうからにょ。
つまり、防御力の変化によってダメージの範囲が大きく変わるためパラメータの調整が
非常に難しくなるにょ。
その反面、後者はただの減算なのでどの程度のダメージになるかが容易に予想ができる
からにょ。
そのため攻撃力や防御力のパラメータ調整は簡単にできるにょ。

また、乱数でダメージにバラツキを持たせる場合にも後者は単純に乱数で単純に加減算を
行えば良いけど前者は単純加算ではダメな分だけ難しくなるにょ。
別の言い方をすれば攻撃力や防御力が2倍、3倍と増えていく場合に後者はダメージが
1次関数的な増え方をするのに対して前者は2次関数的になるにょ。
したがって、簡単（1次関数的）かそうでないかではなく自分にとってどちらのダメージ
関数が望ましいかで決めたらいいと思うにょ。（実際のダメージ量が1次関数になるわけ
ではなくあくまでバランス調整時に1次関数のように考えで調整すればいいということ）

ちなみにドラクエの場合は基本的には攻撃力/2－守備力/4にょ。
はぐれメタルの守備力が1023ならば攻撃力が512以上あってようやく普通にダメージを
与えることが可能になるのと同時に攻撃力が600あれば平均的に40少々のダメージを与える
ことができるようになるにょ。
その辺を考慮すれば攻撃力が512を大きく越えるまでパラメータが上昇しないということも
分かるにょ。
1528：マリモーマ：2013/04/09(火) 13:31:17: win
Windows XPはサポート終了後も使われ続ける? その数は少なくとも数千万台規模か【デジ通】
http://itlifehack.jp/archives/7820893.html

win8は　入れたくないから　どうするか迷うな
win7でも　十分なのかな？

http://liv0.com
1529：御茶目菜子：2013/04/10(水) 00:19:13: レスにょ
マリモーマさんへ
＞Windows XPはサポート終了後も使われ続ける? その数は少なくとも数千万台規模か

XPのサポート終了まであと1年となったわけだけどやはりXPはサポート期間が長かったという
ことで出回っている数量そのものが多いし、互換性等の問題によりVistaへの移行もあまり
進まなかったということもあって未だにXPを使っているユーザーも多いからね。
実際私も現在使っているPCはVistaが1台あるだけで残りは全部XPにょ。
とりあえず、Win8pro発売記念価格終了前に1本買っておいたからそれをそのうち自作PCに
入れる予定にょ。

＞win8は　入れたくないから　どうするか迷うな
＞win7でも　十分なのかな？

セキュリティ面ではWin8の方がWin7より優れているのは確かだけど7もXPよりは遙かに優れて
いるし何よりWin8はタブレット端末での使い勝手向上のためにタッチパネルのないPCでは
使い勝手がダウンしているというデメリットがあるからね。
自作PCに入れるならばWin8で使いたい機能がない限りWin7をオススメするにょ。
とりあえず、Win7が入手できるうちに1本確保しておくといいかもしれないにょ。
1530：御茶目菜子：2013/04/11(木) 23:53:16: 第2回プチコンコンテスト結果発表
1ヶ月前に行われた非公式の第2回プチコンコンテストの結果が発表されたにょ。
今回のエントリー作品数は12作品で投票者数は42人となっているにょ。
結果は以下の通りにょ。

http://wiki.hosiken.jp/ptcmcon/?Award

　各賞の受賞作品一覧（敬称略）

　総合
　◎最優秀賞金賞
　　「OTYAX」　　　　　　　　　　　 otya
　◎銀賞
　　「スマ村DX」　　　　　　　　　　SUMA
　◎銅賞
　　「TopazOS Fusion【OSもどき】」　Topaz Soft.

　各部門賞
　◎アイデア賞
　　「OTYAX」　　　　　　　　　　　 otya
　◎シンプルで賞
　　「簡易地球儀2」　　　　　　　　おちゃめ
　◎音楽賞
　　「PETIT DRUM + BASS」　　　　　おちゃめ
　◎プログラムが見やすいで賞
　　「TopazOS Fusion【OSもどき】」　Topaz Soft.
　◎飽きないで賞
　　「スマ村DX」　　　　　　　　　　SUMA
　◎機能がたくさんあるで賞
　　「OTYAX」　　　　　　　　　　　 otya
　◎グラフィックが神で賞
　　「簡易地球儀2」　　　　　　　　おちゃめ

総合4位以下、各部門2位以下などの詳細はこちらを見るといいにょ。
http://enq-maker.com/result/caMwt0Y

私が投稿した作品「簡易地球儀2」「PETIT DRUM + BASS」は総合では12作品中4位と8位に
なっているにょ。
トップ3（金銀銅賞）がどれも力作だからトップ3に割り込むことができないのはやむを得ない
といった感じにょ。
むしろ、「簡易地球儀2」は1日で作った「簡易地球儀」を1日で改良したため実質2日の開発
期間ということを考えれば健闘ではないかと思われるにょ。

ちなみにその2作品の結果はこんな感じにょ。

◎簡易地球儀2
　総合　　　　　　　　　　　　　　4位（得票率35.7％）
　シンプルで賞　　　　　　　　　　1位（得票率50％）
　プログラムリストが見やすいで賞　2位（得票率35.7％）
　グラフィックが神で賞　　　　　　1位（得票率78.6％）
◎PETIT DRUM + BASS
　総合　　　　　　　　　　　　　　8位（得票率19.0％）
　アイデア賞　　　　　　　　　　　5位（得票率26.2％）
　シンプルで賞　　　　　　　　　　3位（得票率28.6％）
　音楽賞　　　　　　　　　　　　　1位（得票率50.0％）
　（※投票は複数回答あり）

今回は第1回である前回と変わった部分は各部門賞は自己申告制になったということにょ。
あらかじめ狙える賞を3つまでに絞ることで部門賞を狙いやすくなっているにょ。
そのいい例は「簡易地球儀2」のグラフィックが神で賞にょ。
これは78.6％という驚異的な得票率でダントツ1位か・・・のように見えるけど実際はこの
部門を申告したのはこのプログラム1本だったので投票前に1位が決まっていたにょ（笑）
したがって、得票率がいくらかということだけが注目だったけど78.6％ということは該当者
無し（無回答）が21.4％もいるわけだからね。
無回答率はプログラムリストが見やすいで賞などのように判断が難しいものは増える傾向が
あるけどグラフィックは見た目ですぐに分かるからね。
とはいえ、このグラフィックは神で賞は前回も21.4％の無回答があったので1作品ということで
選択肢が狭まったにもかかわらず投票率が前回と同じになったということを考えると健闘と
いえるかもしれないにょ。

半年に1回開催されるみたいなので次回は今年の9月の予定にょ。
その前に公式コンテストであるプチコン大喜利の締め切りが今月末に控えているにょ。
しかし、現時点では何もできてないにょ。
未だに大喜利の投稿予定ゲームに使うポリゴン表示プログラムの最適化を図っている状態
だからね。
このプログラムが完成しないと大喜利用のプログラムのコーディングができないためまだ
ゼロどころかマイナスかもしれないにょ（笑）
1531：御茶目菜子：2013/04/13(土) 22:14:04: プチコン用ポリゴン表示プログラムがついに完成
2ヶ月前から作っていたプチコン用ポリゴン表示プログラムがついに完成したにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/polygon.htm
http://www.youtube.com/watch?v=4OkGjWAIGt8

2ヶ月前から作っていたとはいえベースとなった1日で作ったプログラムを3月末まで放置して
いたので実質的には2週間程度の開発期間にょ。

ポリゴン表示プログラムを作ろうというきっかけになったのはやはり高速な塗りつぶし三角形
描画ルーチンを作ったことにあるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#triangle
塗りつぶし三角形が最も有効活用できるのはポリゴン表示であるためそれならばポリゴン表示
ルーチンを作ってこの三角形の描画ルーチンがどのくらい使えるのかという実験的な内容から
始まったにょ。
私はワイヤーフレームプログラムならば何度も作ったことがあるためそれが線から三角形に
変わっただけだからすぐにできるだろうと思っていたにょ。
しかし、Direct3DもOpenGLも実際に使ったことが無かったせいか作ったプログラムは正常動作
しなかったにょ。
何が足りなかったかというとZソートとポリゴンの裏表判断にょ。
何せ一番最初に組んだプログラムはワイヤーフレームと同じようにインデックスデータ順に
表示していたたし、インデックスデータの並び順は時計回りと反時計回りがバラバラになって
いたからね。

インデックスデータの並び順は統一すれば良いため簡単な問題だけどやはり一番悩んだのが
Zソートにょ。
一般的には3頂点の座標のもしくは平均を求めてそれから判断するのだけどそれだと少し
入り組んだモデルは正確に表現できなくなるという問題を抱えているにょ。
例えばサンプルに含まれるトライフォースのようなものだと内側の切り抜かれた三角形の
面が外周面よりも近くに表示される（つまり外周ポリゴンの一部が欠ける）ということが
頻繁に起きてしまうにょ。
これは理由は簡単で四角形は三角形を2つ組み合わせて作られるけど頂点0～頂点3で構成
されていると考えた場合には下記の三角形A、三角形Bを合わせたものと言えるにょ。

　0----------1　4
　|＼　　　　|　|＼　Ｃ
　|　＼　Ａ　|　|　＼　　カメラから遠い　　三角形A、B、Cにおいて
　|　　＼　　|　6----5　　　↑　　　　　　カメラから遠い順に並べると
　|　Ｂ　＼　|　　　　　　　↓　　　　　　どうなる？
　|　　　　＼|　　　　　カメラから近い
　3----------2

この三角形が（これを見ている）モニタの上部がワールド座標においてカメラより遠くに
あると想定した場合には三角形A、三角形Bのどちらが近いかというと単純に3点の平均を
求めた場合にはBの方が近くなるにょ。
これが立方体のように凹凸のない立体ならば問題ないのだけど少し変則的になるだけで
ボロが出てしまうにょ。
それではA、Bの他にZ座標が頂点、1、2の中央に位置する頂点5と6を持つ三角形Cがある
場合（図の関係から便宜上変えているけど実際は頂点1＝頂点4と考えて欲しい）にそれら
位置関係を考えてみるにょ。
例えば頂点0、1が、Z座標30、頂点2がZ座標0とした場合には三角形Aの平均Z座標は、20に
なるけど三角形Cの頂点4は30、頂点5、6は15であるため、5、6の平均Z座標は20であるため
三角形AとCは同じ位置にあると判断されるにょ。
ここで頂点1（頂点4）を基準に少しだけ（モニタ正面から見て）左右どちらかに回転させた
場合にはZ座標の平均はCの方が小さくなり、三角形Cは三角形Aの手前に表示されることに
なるにょ。の平均でトライフォースを表示した場合には外側の面が欠けて内側の面が表示
される理由になっているにょ。

この三角形AとBにおいて本来ならば同一平面上にある四角形を2つに分断しただけなので
「両者が同じ位置関係にある」と考えた方が表示の間違いは少なくできるにょ。
そこで考えたのは3つの頂点のZ座標を並べ替えて真ん中を取り除いて2点の座標から求める
というものにょ。
これならばAとBの位置関係は等しくなるにょ。
それと同時に（Cが手前に来るような回転をさせない限り）CはAより奥になるにょ。
単純に2点の座標の合計（もしくは平均）を求めてもいいけど少しでもポリゴン欠けを軽減
するため重み付けをすることにしたにょ。
いろいろ試した結果最も大きい座標を2倍した場合に最もポリゴン欠けが少なくなったため
このプログラムでは「3頂点の最も小さい座標＋最も大きい座標×2」をZソートの基準に
おくことにしたにょ。
これでポリゴン表示プログラムの初期バージョン（β1）はできたにょ。
http://www.youtube.com/watch?v=NUZD6W5qw2M

ただ、このプログラムは「既存のポリゴンルーチンより速い」ということをアピールする
ために最小限の機能のみとなっているにょ。
光源設定やシェーディングもないため光と陰の表現ははポリゴンの面の色をデータ上で
あらかじめ変えておくことで擬似的に行っているにょ。
そして、法線ベクトルを簡略化するためパースはOFFの状態のみの表示サポートとなって
いるにょ。（こうすることで法線ベクトルのZ成分のみを求めれば済むため高速化ができて
いる）

この状態では完成までほど遠いためもう少し改良して正式公開しよう・・・と思いつつ
大幅な改修が必要であるためしばらく放置の日々が続いたにょ。
そこに第2回大喜利の開催の情報が入ってきたにょ。
いいネタがないのでこのポリゴンルーチンを使ったレースゲームを作ろうと考えたにょ。
そして、3月末にまずは改善点としてシェーディングを搭載したにょ。
多少重くなったけど「光源は正面からのみ」とすることで高速化して何とかβ1と同レベルの
速度を維持してシェーディングが搭載したβ2ができたにょ。
それを使ってアンドアジェネシスもどきを表示たのがこの動画にょ。
http://www.youtube.com/watch?v=XmvYJA1iuz0

このβ2で完成・・・としても良かったけど速度面ではまだ不満があるためさらなる高速化を
行うことにしたにょ。
そして、やはり光源の自由な設定が欲しいと感じたにょ。
光源の色や環境光の設定は実行前にパレットを書き換えておけば良いだけなので速度的な
マイナスはゼロで実装できたにょ。
問題は光源の場所の指定にょ。
3次元座標を入力もしくはプログラム上で変数の初期値を書き換えることで実装という手段も
あるけどそれだとインパクトに欠けるし、何よりユーザーに座標を入力すると言われても
全くピンと来ないからね。（例えばユーザーを中心に前方100m、右に150m、上に50mと言った
場合にどの方向を示しているのかは瞬間的に比例計算できるか長さや距離の目安になる
ガイドとなる物体が別にない限りは難しい）
やはり、X、Y、Zの座標ではなく極座標の方が分かりやすいと思ったにょ。
要するに緯度経度のように右（左）○度、仰角△度のような感じでの指定にょ。
これをタッチパネルでリアルタイムで変化させることができればインパクトはあるにょ。

そのUIとして考えたのがプチコンコンテストで発表した簡易地球儀2で用いている世界地図
からの入力にょ。
http://wiki.hosiken.jp/ptcmcon/?Toukou%2F%B4%CA%B0%D7%C3%CF%B5%E5%B5%B72
これを使えば球面の極座標を2次元の直交座標と同じ感覚で指定できるにょ。
上画面の太陽マークが球面上を動いている関係で下画面は先日作ったアナログPADルーチンの
ような円形の入力画面の方が上下の座標が一致して分かりやすいという考えもあるかも
しれないけど実際に試してみたら上画面の太陽マークはスムーズに動かせる反面で座標の
指定は分かりにくくなってしまったにょ。
アナログPADルーチンを使ってキャラを動かす場合にはキャラの動きに合わせて微調整する
ためあまり気にならないけれどここでは座標を1対1に対応させる必要があるにょ。
これは相対座標入力が絶対座標入力かということの違いにょ。
アナログPADルーチンは相対座標入力に特化しているため特定の座標を直接指定する絶対
座標入力用には向かないにょ。

ちなみにこのプログラムでは光源の指定は絶対座標入力が用いられているけど拡大縮小や
回転には相対座標入力が用いられているにょ。
これはその方が使いやすいからにょ。
光源の指定は絶対座標入力が相対座標入力よりも良いということは上記の通りだけど
回転に関してはどちらでも良いという考えがありそうにょ。
回転を絶対座標入力で行う場合には画面中央をタッチしたら0度で横方向への回転ならば
256ドットを360度で置き換えて1ドットあたり1.4度回転させればいいにょ。
縦方向だとドット数の関係からそれが4/3倍になってしまうけど厳密な操作が要求される
ようなゲームではないので問題ないにょ。（ゲームに使う場合に縦横の回転量が異なると
いうのはアナログPADルーチンが円形ではなく楕円形だったことを考えると分かりやすい）

このように考えると回転を相対座標入力ではなく絶対座標入力で行うことに何ら問題は
ないように感じるけどこれは光源の指定と組み合わせると変わってくるにょ。
絶対座標入力を行った際に例えば何もボタンを押していない場合に画面タッチをした場合に
どのような挙動になるかというと当然ながらそのタッチした座標に応じて回転となるにょ。
では、回転をしないで光源だけを移動させたい場合はどうするのかというと最後にタッチ
した場所と同じ座標を再びタッチして[L]ボタンを押す必要があるにょ。
そんなことは無理なので[L]ボタンを押すしかないにょ。
しかし、[L]ボタンを単独で押したら光源が初期化（正面向き）されてしまうにょ。

つまり、両方が絶対座標入力の場合には「その機能専用ボタン」による操作が別途必要に
なってくるということにょ。
例えば回転ならばタッチで座標が変わらないようにするためには回転用のボタンを押しながら
タッチさせる必要があるにょ。
回転をタッチのみでまかなうためには光源設定ボタンで光源モードに入り（この時点で
光源の位置は初期化されない）確定ボタンで光源を確定させる必要があるにょ。（確定
ボタンを押さずにモードを終了した場合には位置が初期化されるという感じ）
要するに現状よりワンクッション動作が増えてしまうということにょ。
たかが、ワンクッションだけどこの差は大きいと思うにょ。
これが、相対座標入力による回転と絶対座標入力による光源指定だとシームレスで非常に
直感的な操作が可能になるにょ。

さて、UIもいろいろ考えたけどやはり重要なのは処理速度にょ。
プチコンがいくら高性能とはいえCPUパワーのみでポリゴン表示を行うならばかなり非力
だからね。
これに関してはβ2でかなり高速化はしたもののやはり時間を掛ければまだまだ高速化
できる余地が見つかってきたにょ。
プチコンは演算そのものは速いけど代入処理が相対的に見てかなり遅いからね。

　　　　1000回あたりの実行時間
　　　　　プチコンmkII　　　　ポケコン（PC-E650）
　加算　　　0.004秒　　　　　　　0.8秒　　　　　　　　約200倍
　乗算　　　0.0037秒　　　　　　 1.6秒　　　　　　　　約432倍
　代入　　　0.0098秒　　　　　　 0.8秒　　　　　　　　約81倍
　（加算、乗算は代入処理を含まない実時間）

プチコンはポケコン（PC-E650）と比べて200～400倍の演算速度になっているにも関わらず
実際に演算速度のベンチを実行した場合には100倍程度の速度にしかならないのはこの代入
処理がボトルネックになっているためにょ。（あとプチコンのFOR～NEXTは終了値の値を毎回
チェックされているため遅いのでここは固定数にした方が高速化に繋がる）
つまり、代入処理を減らし、ループ処理を工夫すれば普通に作った場合にはポケコン比で
100倍程度にしかならないものがポケコン比で200～400倍の速度に近いものが得られるため
高速化できるということにょ。
したがって、多少リストの長さに無駄が出ても速度を重視することにしたにょ。

これによって、立方体の表示ならば17～20fps、24面体で13～14fpsと高速になったにょ。
これは最も処理が軽かったβ1と比べて1割程度の高速化になっているにょ。
1割程度だと大したことはないと感じるかもしれないけど実際はポリゴン面の法線ベクトルは
β1ではZ成分しか求めておらず、裏表を判断するための内積もZ成分のみで済んでいた（視線
ベクトルのZ成分は1であるため内積を計算する必要性さえなかった）けれどパースON、OFFで
きちんと表示されるようにZ成分だけではなくX、Y成分の計算に単位ベクトル化処理や各成分の
内積もちゃんと行っているにょ。
それに加えて光源の位置も自由に変えられるようになったためそのベクトルの内積も計算して
いるにょ。
おおざっぱに見て2～3割は処理が増えているにも関わらず、1割程度の高速化ができていると
言えば実際は3～4割程度の高速化ができているといっても過言ではないにょ。
これは処理の高速化だけではなく場合分けを行い不要な処理を行わないことで高速化も行って
いるためにょ。（2～3割は処理が増えても条件でふるい落としをして実質処理増を1～2割
程度の増へと軽減し、それで2～3割の高速化が行えればトータルで1割程度の高速化となる）
一見して無駄に見えるIF文も高速化のためというわけにょ。
これによって、ポリゴンの速度が速くなったというだけではなくワイヤーフレームに関しても
β1と比べて2～3割速くなっているにょ。

　　　　　　　　　β1　　　　　　　　正式公開版
　立方体　　　　　96～97fps　　→　　122～123fps
　24面体　　　　　56～57fps　　→　　　65～66fps
　トライフォース　65～66fps　　→　　　81～82fps
　　　　　　　（※正式公開版はタッチしていない場合の速度）

これだけ高速化を駆使してもβ1の2倍とか3倍とかの速度にならないのはβ1の段階である程度
高速化されているためにょ。
要するにβ1の段階で2～3倍の高速化をやっていて今回さらにそこから2～3割の高速化を行った
ということにょ。
リストの可読性を下げてリストの長さを捨てて限界まで高速化すればさらに高速化できるにょ。
といってもその数字は微々たるものでせいぜい1～2％だと思われるにょ。
あと三角関数をテーブル化して高速化などの方法もあるけどプチコンの三角関数は非常に速く
例えばA=SIN(X)は配列変数を使ってテーブル化してA=S(X)と配列変数を使った方が遅くなる
といった感じにょ。（テーブル化をしたらRADを使わなくていい分だけわずかに速くなるけど
テーブル化のリスト増を考えると微妙すぎるくらいの速度向上であるためこのプログラムでは
テーブル化は使用していない）
それよりはZソートにおいて上記のようにポリゴン欠けが起きにくくする措置をとるのをやめて
単純加算で行えば簡単に5～6％高速化可能にょ。
それならば光源位置もβ2の段階までのように固定化すればさらに高速化できる要素があるため
これ以上高速化できる余地が全くないというわけではないけど可読性と機能性とリストの
長さを考慮した場合にはこれがほぼ限界の速度だと思われるにょ。

もっとも、これだけ高速化してもわずか24面体で13～14fpsであるため（陰面消去をしている
ため単純に計算はできないものの）300ポリゴン/秒くらいの演算、描画速度となっているにょ。
実際152ポリゴンのアンドアジェネシスで2fps弱だからね。
この速度ではゲームに利用するのはかなり厳しそうだけど工夫次第では活用の用途はいろいろ
見つかるのではないかと思われるにょ。