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

おちゃめくらぶ掲示板

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


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

さっきは結構降っていたにょ。
また詳しくは明日書くにょ。
1032：orirakkusu：2012/05/22(火) 12:54:38
3dsを雨の中ちゃんと対策をして新聞を取りにいったら
こうなった。
http://www.geocities.jp/orirakkusu/twitter/000001.html
あと、Twitterのプロフィール画像変更してみた。

1033：御茶目菜子：2012/05/22(火) 20:25:18
レスにょ
orirakkusuさんへ
＞[自分]-[3DS])←レンズ-[日食グラス]です。

変な写り込みがあったからてっきり何かに反射させて撮影したと思ったにょ。

＞子供の科学のピンホールカメラもありましたが、使いませんでした。

ピンホールカメラは拡大撮影に便利にょ。
私も昔フィルムカメラで日食撮影をした時に当時望遠レンズを持ってなかったから自作の
ピンホールレンズ（といってもただの穴だからレンズというのも変だけど）をレンズの
代わりにカメラの先に付けて撮影したにょ。
特別なものではなくチップスターの容器の底に穴を開けただけにょ。
これで、300mmの望遠レンズに匹敵するサイズで撮影できるだけではなく露出倍数を稼げる
（要するに暗く写せる）ため減光フィルタも不要になるにょ。（筒の長さが焦点距離になる
ために長い筒を用意すればいくらでも倍率の高い望遠レンズを作れる）
有害な赤外線はカットできないからそれを直接肉眼で見てはだめだけどね。

＞後で父の方にたのんで望遠鏡(!?)でとった写真をお見せします！！

楽しみにしているにょ。

＞3dsを雨の中ちゃんと対策をして新聞を取りにいったらこうなった。

防水仕様にしたにょ？
どこまで耐えれるか実験のためお風呂で・・・（ただし壊れても責任もてません）



マリモーマさんへ
＞ゲームラボに載ってた　black casて　全チャンネル見れるらしいね

まだ今月のゲームラボは見てないけどどうやら怪しげなカードみたいにょ。

1034：orirakkusu：2012/05/23(水) 16:31:09
3DSの防水に使っている袋の防水テストをしてみました.
http://www.geocities.jp/orirakkusu/twitter/000002.html
1は水を貯めてそこに入れました。
2はお湯(わたしがはいっている風呂程度)を貯めてそこにいれました.
気持ちよくなってしまってずっとやってしまったorz
3は雨をイメージしたようにシャワーにしてじゃーっ。
これも
|　　　　　|
|-----------|
|　　　　　|
|　　　　　|
|　　　　　|
|__________|
を
|　　 |
|-----|
|　　 |
|　 　|
|　　 |
|_____|
の状態でやるとイオ○のドライアイスの音がするのではまり。
という感じで検証したけっか！
水粒1もはいってませんぜした！
???????? ＿＿＿
(°-°)＜な？！\______
?? |????\なんだと？！/
＼|／　΄΄΄΄΄΄΄΄΄΄΄΄΄΄΄΄
　|
／＼

1035：御茶目菜子：2012/05/23(水) 22:06:25
レスにょ
orirakkusuさんへ
＞3DSの防水に使っている袋の防水テストをしてみました.

実験どうもにょ。
結構な防水性能がありそうにょ。
さすがに実機を入れての実験は恐くてできなかったにょ？
でも、ネット上ではスマホをジップロックに入れてお風呂で使っている人も結構いるにょ。

1036：orirakkusu：2012/05/24(木) 18:41:22
DSiLLきたー
http://www.geocities.jp/orirakkusu/twitter/000003.html
土日にプチコン入れます。
これでえーと、
800*3=2400円
スマブにプレゼントしているということですね。

1037：御茶目菜子：2012/05/24(木) 23:37:33
レスにょ
orirakkusuさんへ
＞DSiLLきたー

3DSを所持しているのにDSiLLの買い増しとは・・・。
私も資金に余裕があればプチコンのためにDSiLLが欲しいところにょ。
やはり、大きな画面の方がタイピングしやすいし、3DSの画面ではぼけてしまうからね。
ぼけずに等倍表示も可能だけどその場合はただでさえ小さな液晶の一部しか使わなく
なってしまうためさらに操作性が悪くなってしまうにょ。

＞土日にプチコン入れます。
＞これでえーと、
＞800*3=2400円

というと、DSi、3DS、DSiLLの3台持ちにょ？
すばらいことにょ。
これで本体同士でファイルをやりとりすればバックアップもとれてしまうにょ。
SDカードにPTCファイルとしてバックアップは1台しか持ってなくても可能だけどQRコード
経由でないとプチコンでは読み込めないからね。

1038：御茶目菜子：2012/05/24(木) 23:40:48
デジタル一眼がこの先生き残るためには
ペンタックスが防塵防滴ボディのデジタル一眼レフ「K-30」を発表したにょ。
http://dc.watch.impress.co.jp/docs/news/20120522_534384.html
このカメラの特色は価格にあるにょ。
米国での価格はボディのみで849.95ドル、標準ズーム付きのレンズキットが899.95ドルと
なっているにょ。
日本での発売は未定であるもののこの価格を考えると単純計算ではレンズキットで7万円台
1ドル100円計算でも8万円台になるからね。
実際はこれより安価なデジタル一眼はあるけどそれはどれもが入門機であり中級機の開始
価格でこの価格は異例の安さにょ。

それでは、入門機、中級機に具体的な定義があるのかと言われたらそれはないにょ。
実際はメーカーの主観（その製品が対象となるユーザー）で決まってしまうわけだけど
それに関してはそれほどメーカー間に認識の違いがあるわけではないためある程度機能面で
判別が可能になっているにょ。
それをまとめると下記のような感じにょ。

　《デジタル一眼の入門機と中級機の違い》
　　　　　　　　　　　　　　入門機　　　　　　中級機
　(1)　ファインダー　　　　ペンタミラー　　　ペンタプリズム
　(2)　ボディの防塵防滴　　　なし　　　　　　　あり
　(3)　操作ダイヤル　　　　　1つ　　　　　　　 2つ
　(4)　サブ液晶　　　　　　　なし　　　　　　　あり

(1)やはり、一番の違いはファインダーにあるにょ。
一眼レフはレンズから入ってきた像を（光学的に）直接ファインダーで見ることができると
いうのが最大の特色となっているけどそのためにはクイックリターンミラーが必要不可欠と
なっているにょ。
これの有無が最近急速にシェアを伸ばしているミラーレスとの最大の違いになっているにょ。
その中間的存在としてソニーが発売しているTRM（トランスルーセントミラー）を搭載した
αシリーズがあるにょ。

α55から始まったTRMの搭載はソニーのデジタル一眼レフの方向性を大きく変えるものになって
いるにょ。
TRMによってクイックリターンミラーのようにミラーそのものを高速に動作させてセンサーと
ファインダーへの光の進路を変える必要性は無くなったため安価な機種でも高速連射が
可能になったのだけどその代償としてOVF（光学ファインダー）を失ってしまったにょ。
昨今はEVFの進化は著しく「EVFはOVFと比べて劣る」という単純なものではなく拡大して
ピント合わせができたりホワイトバランスや各種フィルタをかけた状態を確認しながら撮影が
可能ということでOVFには真似できない部分もあるもののOVFが不要ならばミラーは必要なく
ミラーレズでも十分となってしまうからね。
実際、TRM搭載のαシリーズは位相差検出方式のためだけにわざわざミラーを搭載している
わけなので像面位相差検出方式のセンサーが主流になればTRMを搭載する意義はほぼ無くなって
しまうと考えるとデジタル一眼とミラーレスとの過渡期の製品と私は感じてしまうにょ。
レンズとセンサーとの間にTRMという余分な光学系があるため解像面でも不利になってしまうと
いうことを考えると現時点でEVF＋位相差検出方式に価値を見いだせる人のみに大きな
メリットがあると思われるにょ。

さて、一眼レフの最大の特徴となっているOVFだけどこれもペンタミラーとペンタプリズムと
2種類あるにょ。
ペンタミラーは単純にミラーを繋ぎ合わせてクイックリターンミラーから導かれた像を
ファインダーへと導いているため構造が単純であり低価格が実現可能でさらに中が空洞である
ために軽量化も可能となっているにょ。
しかし、その反面構造上どうしてもファインダー倍率や視野率を上げることが難しいにょ。
そして、MFでのピント合わせも難しくなっているにょ。
実際、手元にあるPENTAX K200D、ニコンD50ともにファインダーで得られたものと実際に
絞り開放で撮影したものとを比較するとまるで異なるものになっているからね。
これがペンタプリズムだとファインダーと実際に撮影されたものとのギャップがかなり
縮まるし、ファインダー倍率や視野率も高められるにょ。
その代わり高い加工精度が要求されるため高コストであり、ガラスの固まりであるため
重量面でもペンタミラーと比べると不利になるにょ。
そういうことから低コスト、軽量化が求められる入門機ではペンタミラーが採用されており
ある程度こだわりを持った人が買うであろう中級機にはペンタプリズムが採用されているにょ。

(2)ボディの防塵防滴はかつてはプロ機や上級機の仕様だったにょ。
というのもやはりコストや重量面で不利になってくるからにょ。
最近は中級機でもほとんどの機種が防塵防滴（ただし、JIS防水規格であるJIS IPXでどの
程度なのかというのを謳っている機種はほぼないため具体的にどの程度まで耐えられると
いうのはメーカーや機種によって異なっていると思われる）機構を採用しているにょ。
中には2008年に発売されたK200Dのように入門機で採用されたという事例もあるにょ。
とはいえ、やはりコスト面や重量面で不利になるため入門機で採用されることはほぼ無くて
中級機の証ともいえるにょ。

(3)(4)ダイヤルや（本体上部にある）サブ液晶だけどこれもコスト面の問題が絡んでいると
思われるにょ。
かつてデジタル一眼レフが高価だった時代（初代EOS Kiss Digitalが登場前）はボディにも
それなりにコストが掛けられていたためにサブ液晶（銀塩一眼ではこれが唯一の液晶表示
パネルだったのでこの本体上部の液晶モニタを「サブ液晶」と呼ぶようになったのは
デジタル一眼が普及してからだと思われる）が省略されることは無かったし電子ダイヤルが
2つの機種が主流だったにょ。
デジタル一眼において廉価な入門機が登場してきてからはコストの制約が大きくなりこれは
真っ先に削られてしまったにょ。（とはいえ、私が所持しているK200DとD50はいずれも
入門機にもかかわらずサブ液晶を搭載しているためサブ液晶の廃止は入門機の登場と同時
ではなくコスト面の制約とともに徐々に行われてきたのが分かる）
もちろん、コストだけではなく入門機で小型、軽量を実現するために省略したというのも
1つの理由にょ。

これらを見てのように中級機と入門機の仕様の違いは低コストや小型軽量化のためという
のと上位モデル（中級機）との差別化をするためという2面の理由によるものといえるにょ。
ニコンのデジタル一眼においてはD40以降は入門機はボディに内蔵のAF駆動用モーターを
省略しているにょ。
これは小型軽量化が主な目的だろうけど中級機との差別化とも言えそうにょ。
もっとも、昨今はレンズ内にAF駆動用モーターを内蔵したAF-Sレンズが主流となっているため
一般ユーザーがこれを不利な差別化と感じることはなく従来のレンズ資産や旧モデルの
レンズを中古などで購入する場合のみにその問題点があるというだけにょ。
とはいえ、まだAF-S化してないモデルも現役レンズの中にあるし、サードパーティ製の
レンズにはAF駆動用モーターを内蔵していないものも現役としてラインナップされている
ということも事実にょ。（旧製品だとAFだけではなくAEも使えないモデルもある）
そのため旧製品だけではなく現在発売されているレンズの一部でAFが使用できないという
ことを考えると個人的にはあまり積極的にニコンの入門機を買おうとは思えないにょ。
その点、ペンタックスならば入門機と中級機でニコンのような差別化はしていないにょ。

あと入門機と中級機との違いには連写速度もあるにょ。
ただし、これは2〜3コマ/秒だった入門機で5〜6コマ/秒の機種が登場してきた現在となっては
中級機では差別化はかなり難しくなっているにょ。
差別化をするならば8〜10コマ/秒程度の速度が必要だけどそのためにはシャッターユニットを
一新する必要があるからね。（EOS 7Dの後継機種となるAPS-Cフラッグシップ機は10コマ/秒
になるというウワサがある）
それに上級機であるD800も（DXにクロップ時を除き）4コマ/秒程度の速度しかないため
そのグレードと連写速度との関連性はほぼ無くなってしまっているにょ。（単純に連写速度
だけを見たらD800は入門機以下になってしまうけどD800を入門機と考える人はほぼ居ない
と思う）


さて、こうやって見てみるとK-30はサブ液晶以外はすべて中級機の条件を満たしているため
これを中級機と呼んでもそれほど抵抗はないにょ。
とはいえ、これはあくまで絶対的な基準ではないためこれをハイグレードな入門機とメーカー
側が言えば防塵防滴のK200Dという前例があるためそれはそれで納得してしまうにょ。
キヤノンのEOS 60Dも作りが安っぽい中級機という認識だったけどメーカー側がKissの上位と
なる入門機と言ってからはその認識が変わったからね。（ただし、入門機というには当初の
価格が高すぎたのが今度は問題となったけど）

K-30のスペックを見ると廉価K-5という感じだけど最新のセンサーで1600万画素という点も
魅力になるにょ。
画素数においては、昨今はニコンD3200やソニーα65のように入門機でも2400万画素という
時代になってきているので中級機とは画素数で逆転現象が起きているのだけどレンズキットで
ほぼ完結するであろう入門機ではいくらコンデジと比べて1桁大きなAPS-Cセンサーとはいえ
2400万画素はオーバースペック（レンズが解像しきれない）となっており、ファイルサイズが
大きくなったり暗所性能がダウンすることを考えるとあまり好ましい状況ではないにょ。
そういう面では現在のレンズ性能やセンサー性能を考えるとAPS-Cで1600万画素というのは
ベストチョイスではないかと思われるにょ。（個人的には1000〜1200万画素でもいいくらい
だけど多くのレンズは1600万画素程度ならば十分に解像できるし1200万画素に下げたからと
いって明確に暗所性能に差が出るとは限らない）
あとAFも新開発のSAFOX IXi+が採用されているためペンタックスがニコンやキャノンと大きく
劣っている動体のAF性能がどの程度向上しているかも気になるところにょ。

ニコンD4 vs EOS 1DXやニコンD800 vs EOS 5D MarkIIIを見てのようにプロ機や上級機での
2強対決が最近話題となっており、中級機は両社ともずいぶんご無沙汰だけどやはり
デジタル一眼の需要を大きく左右するのはこれからは中級機になるのではないかと私は
思うにょ。
恐らく入門機はどんどんミラーレスへとシフトしていくため現在は数量面で圧倒的なシェア
となっている入門機のデジタル一眼はシェアを失うことになりそうにょ。
そのためには中級機を広くユーザーにアピールしておく必要があるにょ。
そうすれば、いくらミラーレスがシェアを獲得しても一眼レフの時代が終わる（現在の銀塩
一眼のように一部の愛好家のみが支持して事実上市場からは姿を消す）ということはないの
ではないかと思うにょ。

その大きな役目を担っている中級機だけどとりわけ重要なのが(1)に書いたペンタプリズム
搭載による光学ファインダーにょ。
今後どれだけEVFが進化してもこのペンタプリズム搭載のファインダーがある限りデジタル
一眼のシェアは完全にミラーレスに奪われることはないと思われるにょ。
逆に言えばデジタル一眼の入門機のシェアはほとんどミラーレスに奪われてしまうという
恐れがあるということにょ。
したがって、今後の長いスパンで考えるとメーカー側はデジタル一眼のメリットをユーザーに
アピールしそのメリットが最大限に生かせる中級機がミラーレスの浸食の防波堤になるのでは
ないかと思われるにょ。
そのためにはペンタプリズムファインダーを搭載した廉価な中級機が登場することは良いこと
だと思われるにょ。

また、1インチ〜APS-Cという大型のセンサーを搭載したミラーレスに対してAPS-Cセンサーを
搭載したデジタル一眼はいくら中級機といっても画質面のアドバンテージはそれほど多くは
ないため「デジタル一眼はミラーレスより画質面で優れる」とアピールするならばフルサイズ
センサーを搭載した機種が必要になるにょ。
とはいえ、現行ではプロ機を除けば各社ともに実質1モデルしかないにょ。
しかし、先日D800を発売したニコンは廉価版フルサイズとなるD600（？）を用意している
らしいし、キヤノンもそれに対抗する機種を用意しているというウワサがあるにょ。
そして、ソニーもα99（？）を廉価フルサイズとして発売するみたいにょ。
数量面では多いデジタル一眼の入門機は今後ミラーレスにシェアを奪われていき将来的には
デジタル一眼で生き残るのは現行の中級機以上になるのではないかと思われるにょ。
したがって、それらをより買いやすい価格にしていくことが今後は重要になっていくため
今回発表された廉価中級機となるK-30やニコンやキヤノンが発売を予定している廉価フル
サイズ機はかなり、今後、重要な存在になりそうにょ。

いくらミラーレスが普及しようともデジタル一眼のプロ機が簡単に消滅することはないため
「デジタル一眼が終わる」なんてことはないけどある程度の市場規模がないと個人が購入
可能なレベルの価格帯にはならないためその市場を失わないためにもミラーレスに負けない
ようなものであり、かつ個人に手が届く範囲内でデジタル一眼のメリットをアピールできる
ような機種を出し続ける必要があるにょ。

1039：orirakkusu：2012/05/25(金) 05:29:11
dsillから投稿です、
3は、
3dsが初代プチコンとmK2
DSiLLがmK2
ということです。
p.s.
手書きモード使いやすい。

1040：御茶目菜子：2012/05/25(金) 23:06:24
レスにょ
orirakkusuさんへ
＞3は、3dsが初代プチコンとmK2
＞DSiLLがmK2ということです。

確かに初代を入れたら私も2つだしね。
しかし、本体が1台だからバックアップには使えないにょ。
手持ちの残りのDSは旧DSとDS LiteなのでDSiウェアは使用できないし・・・。

＞手書きモード使いやすい。

画面が大きいだけあってうごメモも使いやすそうにょ。

1041：orirakkusu：2012/05/26(土) 10:36:50
うごメモデビューしました!
うごメモデビューしました!
字は汚いしひらがなばっかりですが、
よければごらんください。

1042：orirakkusu：2012/05/26(土) 10:39:28
(無題)
↓コマンドは
↓AR→BXLL
です。

1043：わぁぃ@：2012/05/26(土) 20:14:03
電車ゲーム仕様変更
座標を従来の描画位置基準から車両の先頭基準に変更する工事をしてみたにゅ。
そしたら、また「突然ホームが現れる」バグが復活したにゅ。
左端<5m>停車位置<205m>右端
で210mのはずなのに、220m分くらい描画しているにゃああぁああぁ。
どこの値を間違えたのかしら？

1044：御茶目菜子：2012/05/27(日) 00:32:19
レスにょ
orirakkusuさんへ
＞うごメモデビューしました!
＞字は汚いしひらがなばっかりですが、
＞よければごらんください。

私はうごメモは買ってないので買ったときに見てみることにするにょ。


わぁぃ@ さんへ
＞座標を従来の描画位置基準から車両の先頭基準に変更する工事をしてみたにゅ。
＞そしたら、また「突然ホームが現れる」バグが復活したにゅ。

TRAIN6のリストをざっと見ただけだと163行と164行のX+I+1376はX-I+1376の間違いだと
思うにょ。
あと上記の駅のホームの座標が正しいならば147行のIF文はIF SZL<1376になるはずにょ。

＞左端<5m>停車位置<205m>右端
＞で210mのはずなのに、220m分くらい描画しているにゃああぁああぁ。
＞どこの値を間違えたのかしら？

上記の符号を修正すればリストを見る限りホームの幅は1376-32=1344、1344÷6.4=210と
なるため210mであっていると思うにょ。

1045：orirakkusu：2012/05/27(日) 07:36:07
プチコン大好きクラブから
画面左上のHatenaをクリック→うごメモクリック
で見れますよ！

1046：御茶目菜子：2012/05/27(日) 16:20:01
レスにょ
orirakkusuさんへ
＞プチコン大好きクラブから画面左上のHatenaをクリック→うごメモクリック
＞で見れますよ！

これは知らなかったにょ。
お陰で無事に見れたにょ。
うごメモの低機能ツールでも結構すごい絵を描いている人が居て驚きにょ。

1047：御茶目菜子：2012/05/27(日) 16:22:29
プチコンオリンピック　イン　ロンドン
プチコン1画面プログラムの新作を作ったにょ。
タイトルは「プチコン100m走 mkII」にょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/petit_olympic.htm#100m

すでにプチコン100m走は半年前に作っているのでまた100m走というのも何だけど半年前に
作った時は不慣れなスプライト、BG画面ということでプログラムにすごく無駄があるし
この半年間の間に身につけたリスト短縮テクニックやmkIIの専用命令によるテクニックを
使えば大幅にリスト短縮が可能だからね。
それが、どの程度のものなのかは同じゲームで試すのが一番にょ。
しかし、24行のプログラムリストが仮に3分の2の16行になったとしてもそれのすごさは
1画面プログラムを作り慣れている人にしか分からないにょ。
ということで、リスト短縮によって得られた余裕を誰でもすぐに分かる見た目に費やす
ことにしたにょ。

問題はどのように見た目で分かるようにするかだけどこれは前作の見た目があまりに
チープだからこれを越えることは余裕で可能にょ。
何せ当時はBG画面で横幅512ドット（64キャラ）を越えるスクロールの仕方がよく分から
なかったわけだし、GCLSで背景色を設定できるということさえ知らなかったからね。
やはり、スクロールならばリスト短縮に有用なGCOPYを使用するとしてそのGCOPYを使って
2重スクロールを考えたにょ。
ということで、どのように変わったかは動画で比較して見れば一目瞭然にょ。

◎プチコン100m走
　http://www.youtube.com/watch?v=LtUrtuonBJQ
◎プチコン100m走mkII
　http://www.youtube.com/watch?v=p0E8grjA6gk

この無駄に2重スクロールしている背景だけどこれは仕組みは実に簡単にょ。
このようなデータを予め用意しておいてそれを左右でつなげることで無限スクロールを
可能にしているにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/image/100m_data.png
問題はこのデータをどうやって作るかだけどこれは行数制限がなければ誰でも簡単に
行うことができるにょ。
BG画面をBGPUTでキャラを並べるのとは異なり見た目で簡単に分かるわけだからね。
しかし、いくらリスト短縮が可能といっても普通に作ったらこのデータ作成だけで12行
（もちろんマルチステートメントで記述して）かかってしまったにょ。
別途GCOPYだけで最低4行かかるということを考えるとこれでは1画面（29文字x24行）に
抑えることはできないにょ。（これでもBG画面で同じデータを用意するのと比べたら
確実に行数を短縮できているわけだけど）

ここでリスト短縮に役立ったのが前作のJUMPING ISLAND（1画面版）でも使った1組の
FOR〜NEXTで設定をすべてまかなうということにょ。
普通に考えたらコースにランダムなドットを打つのに1組、スタジアムの観客を描画
するのに2〜3組、フェンスのスポンサー名（OCHAME）を表示するのに1組で計4〜5組の
FOR〜NEXTを使うことになるのが1つで収まっているにょ。
スタジアムの観客はGPUTCHRを使ってスプライトキャラをグラフィック面に表示している
のだけどキャラは8x8ドットであり、16x16ドットのスプライトキャラを表示するためには
縦横2キャラ分並べないといけないにょ。

　１２　←　16x16ドットのスプライトは8x8ドット単位でこのような配置で表示する
　３４　　　必要があるため普通に作れば1体表示するのに1〜2組のFOR〜NEXTが必要になる

実際はそんなことをする必要はなく斜めに8x8ドットのキャラを8ドットずつずらしながら
順番に置いているにょ。（PNLTYPE "OFF"にしてGPUTCHRの描画部分にWAIT 3くらい
のウェイトを入れれば一目瞭然）
これでトータルで見れば16x16ドットのキャラが8ドットずつずれた状態で並ぶことに
なるにょ。
あとOCHAMEの文字もMID$を使えばGPUTCHRで簡単に描画できるのだけどここでもリスト
短縮のため剰余を使っているにょ。
28912%(J+13)+!J*14

このデータができたらあとは簡単にょ。
スクロールは上記のようにこのデータを左右つなげた状態で使用するだけにょ。
X座標部分で切って左右を逆にしてGCOPYで転送すればこの無限スクロールは完了するにょ。
遠景はスクロール速度を半分にすればそれっぽくなるにょ。
具体的な方法は近いうちにGCOPYを使ったスクロール方法をまとめるのでそちらの方に
詳しく描くことにするにょ。
本当にここまで楽にスクロールができるのはGCOPYのお陰にょ。

肝心のゲーム内容は前作とほぼ同じにょ。（1秒が正確な1秒ではなく「なんちゃって1秒」
となっている部分も変えてない）
実際はスクロール量が変わっているため速度計算式を変えたのだけどその程度の変更に
すぎないからね。（あとはリスト短縮できる部分は短縮している）
とはいえ、この速度計算式も前作で10秒が簡単に切れるため少々難易度を高めているにょ。
難易度はこのmkIIのCランク（11秒台）のタイムが前作のBランク（10秒台）のタイム
くらいに相当するにょ。

さて、このゲームは「プチコンオリンピック　イン　ロンドン」のシリーズ第1弾として
作ったにょ。
実はポケコンではこのようなオリンピックに合わせたゲーム（オリンピック開催前、
開催後に作ったゲーム）は多くあるにょ。
まぁ100m走だけでもたくさんのバリエーションがあるわけだけどそれ以外にも陸上競技は
短距離からマラソンまで作ったし、投擲競技は砲丸投げ、やり投げ、ハンマー投げを
作ったり、走り幅跳び、高跳び、三段跳びなども作ったにょ。
冬季オリンピックではスピードスケートやカーリングなどを作ったにょ。

ただし、今回のプチコン版はすべて1画面の予定なので結構厳しそうにょ。（ただ作るだけ
ならば簡単にできてしまう）
それを考えると作れる競技には限界があるし、競技内容もかなりの簡略化が迫られる場合も
あるにょ。（簡単に組んだ状態で1KBを越えるようだと1画面化はかなり難しい）
それが1画面プログラムの醍醐味であり、1画面だからこそ多少見た目が寂しくても妥協が
可能になるからね。
これは別に手を抜くという意味ではなく1画面にすることで完成までにかかる時間は何倍も
かかってしまう場合も多いにょ。（リスト短縮も最後の数バイトの短縮で数日かかって
しまうこともあるし実際JUMPING ISLANDの1画面版はなかなか1画面に収まらず非常に
苦労した）
しかし、その苦労の過程を含めて楽しめるのが1画面プログラムにょ。（このパズル的な
プログラミングが楽しいかどうかで1画面プログラムにハマれるかどうかが決まると思う）
自作のキャラに拘る人、フォントに拘る人、音楽に拘る人、それらすべてどれもが良くて
どれかが駄目というわけではなくみんながみんな違うから面白いにょ。

1048：orirakkusu：2012/05/28(月) 07:53:51
(無題)
DSiLLを撮影する練習もかねて
http://www.geocities.jp/orirakkusu/twitter/000005.html
リンク先は見てからのお楽しみ♪♪

1049：御茶目菜子：2012/05/29(火) 00:03:10
レスにょ
orirakkusuさんへ
＞DSiLLを撮影する練習もかねて

意図的に顔が映り込むように撮影したにょ？
写り込みを減らすためには部屋の中を暗くするか、背景を暗くするといいにょ。
それでも顔などの明るいものが正面にあったら角度を付けて撮影しない限り、画面内に顔が
映り込んでしまうのでそれを避けるためには黒いマスクを被るといいにょ（笑）

1050：プログラマー入門：2012/05/29(火) 12:50:51
プログラマー入門
http://1c-job.net
このサイトにはプログラマーとして必要だと思うことが載っています。
これをとっかかりにしてプログラムに興味が出てくること間違いないです。

http://1c-job.net

1051：orirakkusu：2012/05/30(水) 08:20:21
DSiLLのこと
暇つぶしにプチコンでロンドンオリンピック版100m走をやっていたらいきなり電源がぶつぎれた。
どうやらタッチペンを入れる所に衝撃を加えると切れるっぽい。
ただAB連打してただけなのに...

1052：御茶目菜子：2012/05/30(水) 15:11:11
レスにょ
プログラマー入門さんへ
＞このサイトにはプログラマーとして必要だと思うことが載っています。

まだ、初歩の初歩しか記載されていないのでこれからに期待にょ。


orirakkusuさんへ
＞暇つぶしにプチコンでロンドンオリンピック版100m走をやっていたらいきなり電源がぶつぎれた。
＞どうやらタッチペンを入れる所に衝撃を加えると切れるっぽい。

これは明らかにおかしな挙動なので新品で買ったのならば購入店に持って行って初期不良を
訴えるという方法もあるにょ。
もちろん、うっかり電源ボタンを触っていたというオチがない場合だけどね。
とはいうものの通販で購入の場合にはそれが難しいのでどうしても気になるならば保証期間
のうちに修理に出すしかないにょ。

1053：御茶目菜子：2012/05/30(水) 15:16:07
各キャリアの夏モデル
ケータイの各キャリアが今年度の夏モデルの発表を行ったにょ。

ドコモ
http://k-tai.impress.co.jp/docs/news/20120516_532738.html
au
http://k-tai.impress.co.jp/docs/news/20120515_532727.html
ソフトバンク、ウイルコム
http://k-tai.impress.co.jp/docs/news/20120529_536080.html

この中で一際目を引くのはドコモの新モデルにょ。
何しろ、通常のケータイ（ガラケーやフィーチャーフォンと呼ばれているもの）はキッズ
ケータイ1機種のみであり従来主力であったiモード端末はゼロとなったにょ。
高年齢向けの「らくらくホン」もスマートフォンに移行して「らくらくスマートフォン」に
なったくらいにょ。

らくらくホンのスマホ化に関しては賛否両論意見が出ているけど私は個人的にはタッチ
パネルによって直感的操作が可能になるというのはプラスになっていると感じるにょ。
タッチパネルはスマホでなくてもガラケーであっても実現可能とはいえOSがタッチパネルに
最適化されているAndroidだからこそ操作性の向上が望めるにょ。
しかし、直感的操作が可能といってもやはりボタンを押した時のクリック感がないため不安に
感じる人もいるのではないかと思われるにょ。
ドコモもそう言うユーザー層を想定して画面上のボタンを押したら振動によるフィードバック
によって擬似的にクリック感を実現しているにょ。
それにDSの普及でタッチパネルに抵抗のない人も増えているだろうからタッチパネル化という
のはプラス要素の方が大きいと思うにょ。

さて、らくらくホンのスマホ化において一番の問題は料金システムにょ。
Androidの場合はただでさえバックグラウンド通信によって月に数MBの通信が行われている
だけではなくスマホはガラケーと比べて通信の機会が多いからにょ。
らくらくホンに加入しているユーザーはネットやメールを積極的に使うという人はほとんど
居ないためかパケホーダイに加入している人もあまり居ないのではないかと思われるにょ。
しかし、仮に月1MBのバックグラウンド通信が行われたとしても1パケット0.2円で計算すれば
1600円、10MBの通信ならば16000円ものパケット料金が発生するにょ。
そのためスマホにはパケット定額料金プランであるパケホーダイが事実上必須になるにょ。
しかし、パケホーダイの料金もガラケー（iモード端末）用が上限4410円なのに対してスマホ
用は5985円（フラット型でも5460円）と割高になっているにょ。
今までは不要だったそんな高価なオプションが必要になるならば加入しないという層も多い
ことが予想されるためらくらくスマートフォン専用のパケホーダイプランも用意されたにょ。
http://k-tai.impress.co.jp/docs/news/20120516_533087.html

この「らくらくパケホーダイ」は上限2980円のフラットプランということで定額プランの
中では極めて安価なものとなっているにょ。
月間500MBを越えたら128Kbpsの帯域制限となるわけだけどこのらくらくスマートフォンの
対象ユーザーを考えると500MBあればそれほど困ることはないのではないかと思われるにょ。
しかし、それでも現在タイプSSバリューのファミ割もしくはひとりでも割に入っている人で
あれば月々の費用は980円で済んでいるにょ。（1050円の無料通話の範疇に収まる場合）
それが別途2980円かかるとなると一気に負担は約4倍に上がるため相対的に考えると決して
小さなものではないにょ。
そういう意味ではあまり積極的に通信をしないユーザー向けで従来のらくらくホンもしばらく
併売する必要がありそうにょ。

ドコモの全面スマホへの移行はやはり極端であり否定的なユーザーも少なくないにょ。
このアンケート結果を見る限り4分の3が否定的となっているにょ。
http://k-tai.impress.co.jp/docs/readers/odaibeya/20120525_535023.html

　　ドコモ夏モデルでiモード端末ゼロ、どう思う？
　　　当たり前　　　・・・・　24.7％
　　　ありえない　　・・・・　75.3％

各キャリアともに一昨年よりスマホに力を入れており今年度はさらなる需要が拡大するのは
確実であるためスマホの割合を増やすのは当然だけど上記のような料金面の問題もあるし
スマホでは対応していないケータイ向けサービスを利用するためスマホには移行できない
という人も居るのではないかと思われるにょ。
ドコモがこの度の新モデルでiモード端末を無くしすべてスマホに移行したのはやはり他の
キャリアに遅れをとっている部分があるというのに加えて「iPhoneがない」というのが
大きいのではないかと思われるにょ。
何だかんだでiPhonenのシェアは決して小さくはないし、知名度においては全スマホの中で
ダントツの1位だからね。
そういう中で「ドコモはスマホに強い」というイメージを付けるために今回のような極端な
ことを行ったと考えられるにょ。
しかし、そのためにはトラフィック面の改善が必要になってくるにょ。
ただでさえ、昨年12月22日に書いたように「予想外の負荷」によってSPモードにおいて
差出人が異なるメールが送られるというトラブルが発生してしまったわけだからね。
それに昨今はスマホの普及によって通信トラフィックの増大も懸念材料となっているにょ。
そういうことを考えると一気に全面移行するというのはキャリアにとっても不安材料を
増加させるだけであり、そういう意味では今回ドコモがとった戦略はあまり良いものとは
いえないのではないかと思われるにょ。

では、他のキャリアを見てみるとソフトバンクは全体的にみるとインパクトに欠けるにょ。
とはいえ、放射線測定機能を内蔵した「PANTONE 5 107SH」のような機種もあるにょ。
やはり、未だに不安要素の多い放射線についてだけどこれはセシウム137の半減期を考えると
やむを得ないにょ。
それに雨水が溜まるなどによって局所的に線量が多くなっているという場面も少なくない
ので原発からの距離に比例して線量が小さくなるという単純なものではないからね。
個人的に欲しいと思うのはハイエンド端末である「AQUOS PHONE Xx 106SH」くらいにょ。
やや大柄なのがネックだけどAndroid4.0に加えて1280x720のHD液晶が魅力にょ。
液晶むき出しのスマホは液晶破損の心配が高いけどGorillaガラス採用によってそれは
いくらか軽減できるし、ガラケーではおなじみのワンセグ、おサイフなどの機能も一通り
搭載しているからね。
さらに防水・防塵仕様となっている点も魅力にょ。

とはいえ、問題は価格にょ。
端末価格だけではなくガラケーからだと現在パケット定額プランの下限に収まっていると
いうことを考えると月々のコスト増から考えてなかなかスマホへの移行ができないにょ。
どうしても、スマホが必要というわけでもないわけだしね。
「新モデルが出て端末価格が下がったら買おう」なんて考えているうちは新モデルが発表
されるごとに同じことを言って終わりなのでそのコストを払ってまで必要ではないから
買わないというだけかもしれないにょ。

ソフトバンクは電波の繋がりやすさなどの問題点はある（これは900MHz帯のプラチナ
バンド獲得によって一気に解消が見込めそう）けれど料金プランや端末だけを見れば他と
比較しても優れている部分も多いにょ。（ソフトバンクに経営が移ったウィルコムの
新製品はぱっとしないのは難点だけど）
107SHは半年前ならばすごいハイスペックだけど今となっては個々のスペックを見ると
ミドル〜ハイスエンド端末レベルに止まっているにょ。
http://k-tai.impress.co.jp/docs/news/20120528_536007.html
http://k-tai.impress.co.jp/docs/news/20120525_535473.html
このリストを見る限りこの夏モデルはデュアルコア1.5GHz程度が普通（というかそれに
該当するクアルコムMSM8960を採用している機種が非常に多い）であり、中にはTegra3の
クアッドコア1.5GHzモデルを搭載している機種さえあるにょ。
もはやシングルコアCPUを搭載しているのはローエンド端末だけになっているにょ。
メインメモリは1GBに横一線であり、これがもはや普通といった感じにょ。
画面解像度の拡大やマルチタスクへの対応を考えると現状で512MBではやや不安が残ると
いった感じになっているにょ。
画面解像度は昨年まではWVGA（FWVGA）が主流でハイエンドがQHD（960x540）といった
感じだったけどこの夏モデルは1280x720のHD液晶を搭載した機種が非常に増えているにょ。
スマホの液晶画面は高解像度化に伴い大画面化が進んでおり、4.5〜5インチの液晶を搭載
している割合は昨年と比べて大幅に増えているにょ。
そして、それに対して3インチ台でWVGAも一定数存在しており、これらが消えることも
なさそうにょ。
したがって、スマホはハイスペック、大画面とそこそこスペックで比較的小型なものとの
二極化が進んでいる感じにょ。

1054：　：2012/05/30(水) 17:21:39
(無題)
＞暇つぶしにプチコンでロンドンオリンピック版100m走をやっていたらいきなり電源がぶつぎれた。
＞どうやらタッチペンを入れる所に衝撃を加えると切れるっぽい。
そういや自分のDSiLLも衝撃を加えると切れる。
プログラム中椅子でぐるぐる回ってたらDSに当たって…ああああああああ

1055：御茶目菜子：2012/06/01(金) 00:09:53
レスにょ
名無しさんへ
＞そういや自分のDSiLLも衝撃を加えると切れる。
＞プログラム中椅子でぐるぐる回ってたらDSに当たって…ああああああああ

さすがのDSも衝撃が加えられてしまえば壊れてしまうからね。
今のところ私の3DSは大丈夫だけど私の部屋の中では何が起きてもおかしくないので
果たしていつまで無事で居られるやら・・・。

1056：orirakkusu ：2012/06/01(金) 12:03:16
それからのこと
ぶちきれなくなった。
外の石の上でやってたから？

1057：otyaken：2012/06/01(金) 22:09:26
MML
http://www.youtube.com/watch?v=GIoF-95VlqM&amp;feature=player_embedded
これのMMLが欲しい。

http://putikonclub.g.hatena.ne.jp/otyakenrabu/

1058：御茶目菜子：2012/06/02(土) 00:33:50
レスにょ
orirakkusuさんへ
＞ぶちきれなくなった。
＞外の石の上でやってたから？

たまたまその時だけ調子が悪かっただけなのかも・・・。

otyakenさんへ
＞これのMMLが欲しい。

著作権の関係でMMLデータをあげることはできないのでこのGRPで我慢してにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/qr/dorakue.png

1059：orirakkusu：2012/06/02(土) 07:10:00
暗号化ぎぢゅつ
clear
input "アンゴウカスモジハ";an$
@anstart
k=0 xor rnd(256)
ke$=chr$(k)
for i=0 to len(an$)-1
ke$=ke$+chr$(asc(mid$(an$,i,1)) xor k
next
?ke$
@kastart
k=asc(mid$(ke$,0,1))
for i=1 to len(ke$)-1
ka$=ka$+chr$(asc(mid$(ke$,i,1)) xor k)
next
?ka$
clear
おちゃめさんはソースを見ればわかるとおもうけど、わからない人のために説明。
アンゴウカスルモジハ？と聞いてきますので、適当に入れてください。
そうすると暗号化された文字と復号？された文字がでてきます。
これはソースを見なければ(普通はね)破れないのですが、
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
なんていうのを暗号化すると、
◇チチチチチチチチチチチチチチチチチチチチチチチチチチチチチチチチ
とかになって暗号化が意味なくなります。

1060：　：2012/06/02(土) 16:25:41
(無題)
http://putikonclub.g.hatena.ne.jp/otyakenrabu/20120317
これと似てるw
1061：御茶目菜子：2012/06/02(土) 16:41:08
レスにょ
orirakkusuさんへ
＞aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
＞なんていうのを暗号化すると、
＞◇チチチチチチチチチチチチチチチチチチチチチチチチチチチチチチチチ
＞とかになって暗号化が意味なくなります。

この点に関しては1文字ずつKの値を変えていけば改善されるにょ。
問題はどのように変えるかだけど解読しにくいものといえば私が考えた疑似乱数を
使うというのも1つの手にょ。
0〜1の乱数を0〜255になるように256倍してIのカウンタを使えばいいにょ。
もっとも、これは1対1に対応していていればいいのでK=0OR (ABS(SIN(K+I))*256)とかでも
問題ないにょ。（例えば「AAAAA」を暗号化すると「サセセモクソ」などになる）
元がシンプルな分だけいろいろ応用させやすいと思われるにょ。

といっても、プチコンでは入力できない文字が生成されたり、256通りの鍵しかないため
鍵が分からなくても総当たりで解読可能だったりするけどまぁその辺は用途に応じて変更
すればいいだけの話だしね。


名無しさんへ
＞これと似てるw

まぁXORを使った暗号化はポピュラーだから似たようなものができてしまうのはやむを得ない
と思うにょ。

1062：御茶目菜子：2012/06/02(土) 16:42:22
プチコンオリンピック第2弾
1画面「プチコンオリンピック　イン　ロンドン」の第2弾の「プチコンハンマー投げ」が
できたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/petit_olympic.htm#hammer
http://www.youtube.com/watch?v=zXB4_X-aoAc
このゲームの元は昨年の世界陸上の時にポケコンで作ったものにょ。
ただし、ポケコンではテンキーを使って[1][2][3][6][9][8][7][4]を順番に押して回転させて
いる感覚を味わうという操作性だったけど実際にプレイしてみるととてもまともにプレイは
できなかったのでそのままお蔵入りとなったにょ。
このプチコン版はその没になったポケコン版と基本的なゲーム内容と画面構成は同一となって
いるにょ。
一端没になったものがプチコン版で再び採用されたのはやはりポケコンと違ってゲームに
適したUIが搭載されているためにょ。
やはり、テンキーで擬似的に回転させるのは無謀すぎたけど十字キーならば何とか回転操作は
可能だからね。

とはいうもののやはり回転操作は簡単ではないのはザンギエフのスクリューが簡単に出せない
のを見ても明らかにょ。
「回転開始場所はどこでも良い」「入力ミスがあってもパワーが溜まりにくくなるだけであり
多少ミスしても問題ない」「時間制限がない」などによって十分に使えるレベルにはなって
いるけどそれでもやはり回転入力は大変にょ。
というのも十字ボタンは斜め入力が入りにくいからにょ。
しかし、3DSならばスライドパッド搭載によって斜め入力が非常に簡単にできるにょ。
何せ普通に回転するだけで意識せずに斜めにはいるからね。
これによって、このゲームは普通に遊べるレベルの難易度になっていると思われるにょ。
とはいえ、スライドパッド使用時にバランス調整しているため十字ボタンでプレイ時には
記録を出すのが極端に難しくなるためパワーの計算式を変える必要があるにょ。
その辺は上記の改造点にも書いているにょ。

大幅なリスト短縮が可能であったためひたすら見栄えを重視した「プチコン100m走mkII」
と比べてこの「プチコンハンマー投げ」は1画面に収めるのがやっとであり、そこまで
見栄えに拘ることはできなかったにょ。
というのも100m走は作り慣れているのに加えて基本的に「初期設定→走る→結果表示」だけ
なので事実上メイン部分は「走る」という動作しかないためにょ。
その点このハンマー投げは「初期設定→パワーためる→角度決める→投げる→結果表示」
ということでメイン部分は3段階に分かれているにょ。
1画面プログラムでそれを実現するためにはFOR〜NEXTを3組使えば良いのだけど前回100m走の
データ生成部分で書いたように1画面プログラムにおいてはFOR〜NEXTを1組でも減らすことが
リスト短縮においては重要になってくるのにそれが3組必須となると短縮が難しくなって
しまうということにょ。（これは、1画面でなければラベルジャンプを使うことでリスト
短縮ができるため1画面化の際にリストが逆に長くなる部分といえる）
あと1画面プログラムを作る際には1行が29文字を越える場合にそれを分割処理するために
逆に長くなる部分があるということもあるため「リスト短縮をすれば1画面化は簡単に
できる」という単純なものではないにょ。

プログラムをもう少し見ていくと回転入力の判定処理は9行目のINSTR関数で行っているにょ。
これは1行（29文字）で収めるにはこれが限界だったにょ。
剰余によるパターン化も試してみたけど同じく29文字にするのが精一杯だったのでリストを
見て分かりやすいINSTR関数を使用したものを採用したにょ。
このゲームで1画面化の1番の障壁になったのは実は上記のFOR〜NEXTではなくスプライトの
キャラ変更部分にょ。
キャラ変更はSPCHRで簡単にできるのだけど1つの方向に1パターンを割り当てて8パターンで
1回転するように見せるという方法を考えたのだけど問題は1画面で行うためにはどうするのか
ということにょ。
スプライト番号64、68、72、76の4パターンを2セットという方法もあるけどこれを実際に
行った場合には棒立ち状態でそのまま回転しているように見えるためダイナミックさを感じる
ことができなかったので剣を振る動作（スプライト番号84〜87）を採用したにょ。
これに左右反転を行い8パターンで表示すれば回転しているように見えなくはないし何と
いっても上記の棒立ち回転より遙かにいい感じにょ。
肝心のハンマーはスプライト番号28〜31のキャラをグレーで表示させればそれっぽく見える
ためにそれを採用したにょ。

これでほぼゲームの骨格部分はできたのだけど1画面化をする際にはどうしてもどこかを
削らなければ収まらないため投げる瞬間のSPCHRを削ることにしたにょ。
それを行った場合には基本的にはボタン入力がないデフォのキャラが表示されるわけだけど
それはスプライト番号84のキャラになっていたにょ。（プログラム内では0番のキャラ）
このデフォのキャラは上記動画を見てのようにハンマーが地面に付いた状態で個人的には
ハンマー投げのスタート時としては何となくそれっぽいポーズということで気に入っていた
けれどこれが投げる瞬間のポーズになってしまうと話は別にょ。
さすがにうしろ向きで投げるというのは・・・（笑）
ということでキャラの回転方向を逆にして0番のキャラを7番、1番のキャラを6番・・・と
言う感じで変えていき元の7番のキャラを0番（ボタン入力をしていない状態のキャラ）に
したにょ。
これでボタン入力をしていない時はちゃんと正面を向くようになったのだけど問題は
それがデフォであるため何もしていない時はハンマーが宙に浮いた状態であるという
ことにょ。
投げる瞬間のSPCHRを省略せざるを得ないという状況であるためこの部分はこのゲームで
唯一妥協を許してしまった部分といえるにょ。
それ以外は初期のプログラム（900バイト弱）をほぼ1画面化できたにょ

さて、次の第3弾は全く趣向の異なるものになると思うにょ。
オリンピックの競技の中で1画面化を行えばどうしても簡略化のためにゲーム内容に偏りが
できてしまうためにょ。
それが異なる操作性であれば同じようなゲームでも全然別ものになるため例えば5つ作れば
5通り楽しむことができるにょ。（これがどれも連射重視のゲームだと見た目が異なる
だけでどれも同じになってしまい連射が不得意ならばどれも楽しむことができない）
連射重視の競技は最初に100m走を作ったから連射重視の競技は現在は作る予定がないにょ。
そうでもしないと100m走のループ回数を変えただけの200m走とか400m走とかを作っても面白く
ないからね。
1画面という制約に加えて操作性が被らないようにするという別の制約でゲーム作りは難航
しそうだけど反射神経重視のゲーム、ボタンを押すタイミング重視のゲーム、繊細な操作を
要求するゲームなどいろいろなパターンが考えられるので問題はないにょ。

1063：otyaken：2012/07/01(日) 01:54:32
どら焼き食えスト
＞著作権の関係でMMLデータをあげることはできないのでこのGRPで我慢してにょ。
＞http://ww5.tiki.ne.jp/~ochame/petitcom/qr/dorakue.png
今日OMPにプログラム使って取り込んでみたけどこの曲ドラ食え何のどこの曲だったっけ?

1064：御茶目菜子：2012/07/01(日) 09:23:25
TALKのお得な知識
最近twitterでTALK命令に関する質問が良く出ているのでTALK命令で歌わせる方法について
まとめてみたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/talk.htm
これは棒歌ロイドOSPを作ったときに私が試行錯誤で会得したものを書いたものだけど
これらの多くはすでにこの掲示板で書いているようなことばかりにょ。
とはいえ、情報がバラバラだし追記の追記みたいになっていて分かりにくい部分もあるため
Tipsとして利用できるようにすべて書き直してみたにょ。

実際、これはOSPを作った当時（2ヶ月半前）に書こうと思っていたけど書いても需要が
無さそうと感じたので書くのをやめてしまったにょ。
しかし、冒頭のように以外にTALKで困っている人はいるみたいなのでせっかく試行錯誤で
会得した知識を一人でも多くの人に活用してもらうべくまとめることにしたにょ。
といっても、実際はTALK命令全般ではなく「TALKで歌わせる」ということに限定したもの
だけどね。
それでも、分かりやすくしようと書いたらこの文字数になってしまったにょ。

ぶっちゃけプログラムでも「分かりやすく書こう」とすればどんどん長くなってしまうため
プチコンでは可読性を落としてでも1画面に拘ることで短くまとめているにょ。
これは1画面のプログラムサイズだからこそできることであり、数10KBのプログラムを
1画面レベルのリスト短縮技術を使ってプログラムを作ったらさすがに死ねるにょ（笑）
長いプログラムほど可読性を重視しないとバグや仕様変更に対応できなくなってしまうからね。
その辺は臨機応変に行うべきことにょ。



otyakenさんへ
＞今日OMPにプログラム使って取り込んでみたけどこの曲ドラ食え何のどこの曲だったっけ?

あの動画の曲のことだったらIIIのフィールドの曲にょ。

1065：otyaken：2012/07/01(日) 09:58:22
どら食え2
はてなのMMLで演奏したら変な音楽になったw

http://putikonclub.g.hatena.ne.jp/otyakenrabu/20120603

1066：orirakkusu：2012/06/04(月) 17:23:25
いえーい！部分月食だぜー！
こんどはでかくとれるぜ！

1067：御茶目菜子：2012/06/04(月) 23:25:04
レスにょ
otyakenさんへ
＞はてなのMMLで演奏したら変な音楽になったw

はてなにそんな機能があることを初めて知ったにょ（笑）
正しく鳴らないのはプチコン用のMMLと仕様が異なるせいだと思うにょ。
オクターブの上げ下げも逆みたいだしね。



orirakkusuさんへ
＞いえーい！部分月食だぜー！
＞こんどはでかくとれるぜ！

天体望遠鏡で撮影するにょ？
サイトで公開するのを楽しみにしてるにょ。

1068：御茶目菜子：2012/06/04(月) 23:26:46
飛んでる写真は難しい
先日航空祭を撮影に行ってきたにょ。
昨年は震災のため自粛で開催されず、今年もブルーインパルスはないということで盛り
上がりにはやや欠けるけどせっかくなので行ってみたにょ。
こういう機会でもないと望遠レンズを使うことがないからね。
何せ普段のほとんどの撮影は換算200mmで足りているわけだし・・・。

ということで、使用した機材を紹介するとペンタックスK200D＋シグマ400mmF5.6と
ニコンD50＋タムロン70-300mm F4.5-5.6にょ。
APS-Cなので400mmのレンズは換算600mm、70-300mmのズームレンズは換算105-450mmに
なるにょ。
（私にとっては）普段であればまず使うことのない焦点域にょ。
特に400mmF5.6なんて普段はバッグの中にしまいっぱなしで持ち出すことはまずないわけ
だしね。

ただし、これも戦闘機の撮影においては望遠すぎることはまったくないにょ。
低空飛行を行う航空祭であっても戦闘機を画面いっぱいに撮るならば換算500〜800mmの
レンズが必要だからね。
したがって、500mF4とか600mmF4とかの普段は私が目にすることが全くない大砲を抱えて
撮影している人もいるにょ。
APS-Cであれば600mm（換算900mm）の単焦点はやや長目であり使い勝手がそれほど良くない
のでやはりレンズの抜き差しが要らないズームレンズが便利にょ。
普段の撮影ならば「撮影者の方が動いて撮影する」というのが基本だけどこういう撮影
場所を自由に移動できないイベントの場合は撮影者が動いて撮影するなんてできないにょ。
というのがあるためか、私の両サイドで撮影している人はシグマ50-500mmF5.6-6.3のズーム
レンズを使っていたにょ。
まさに航空写真のためのズームレンズにょ。

私が使っているシグマ400mmF5.6のレンズはかつては超望遠入門レンズとしては人気のあった
焦点域ということで各社からも「ヨンゴーロク」が発売されていたけどその初期の頃に出た
MFレンズにょ。
したがって、画質はあまり良くはないにょ。（その代わり安かったけど）
しかも、MFレンズということで当然AFは使えないのだけどペンタミラーだとペンタプリズムと
比べてピントの山をつかみにくいのでピント合わせはかなり厳しいにょ。
同じくMFの50mmF1.8のレンズも使っているけどこちらのレンズは最短撮影距離付近では
被写界深度はわずか数mmとなっているけどファインダー内では数cmある感じだからね。
したがって、絞り開放で撮影時には運でピント合わせをしないといけないにょ。
F4〜5.6まで絞ってピント合わせのずれがなんとかギリギリ被写界深度に収まる感じにょ。

それと同じで400mmF5.6もピントの歩留まりが極めて低いにょ。
戦闘機なんだから数100m離れているため無限遠にピントを合わせておけば良いのでは？
という人もいるかもしれないけど400mmともなると無限遠にピントを合わせても数100mの
地点は被写界深度内に収まらないにょ。
それに超望遠レンズということでピントリングには余裕が設けられているため肉眼で
無限遠にピント合わせをした状態が真の無限遠になるにょ。（ピントリングの無限遠は
無限遠ではない）
ということで、今回は数100m先に置きピンをしてそれで撮影することにしたにょ。

しかし、撮影された写真はどれもピンぼけだらけにょ。
まぁ縮小すれば何とか使えそうだけどデジカメの場合はピクセル等倍での鑑賞の機会が多い
けど銀塩写真をルーペで鑑賞するのと同じようなものであり厳しいピント精度が要求されて
しまうにょ。
ということを考えると昔は「ピントが合っていたように感じていただけ」かもしれない
けどね。

そういうこともあり、今回もD50を併用しておいて良かったにょ。
こちらはAFは遅いけど一応何とかAFによって見れる程度にはピントが合っているからね。
航空祭とは全く関係ないけど以前撮影したこんな写真も私はMFでは撮影できないにょ。

「鳩のえさをくわえて逃亡するカラス」D50＋タムロン70-300mm
http://ww5.tiki.ne.jp/~ochame/test/karasu.jpg

とはいえ両者入門機ということあり、K200Dは2008年の機種、D50は2005年の機種ということも
あって連射は最大3コマ/秒でしか撮影できず、しかもRAWだと3コマでバッファフルになって
しまうという情けない仕様にょ。
それでもK200DとD50を交互に構えれば何とかなるにょ。

D50＋タムロン70-300mm　1/500 F10
http://ww5.tiki.ne.jp/~ochame/test/koukuusai1.jpg
離陸の瞬間の流し取り（ちょっとぶれてしまったけど）D50＋タムロン70-300mm　1/60 F18
http://ww5.tiki.ne.jp/~ochame/test/koukuusai2.jpg

でも、やっぱりこういうのを撮影しているとD7000とかK-5とかの中級機が欲しくなるにょ。
普段の撮影ならば入門機で（ファインダー以外は）全く不満はないんだけどね。（たまに
高感度の画質に不満を感じるけど）
本来ならば今年D7000かK-5を買う予定だったけど金銭的な都合で難しそうにょ。
ミラーレスも欲しいし・・・。

1069：otyaken：2012/06/05(火) 21:15:36
(無題)
＞はてなにそんな機能があることを初めて知ったにょ（笑）
＞正しく鳴らないのはプチコン用のMMLと仕様が異なるせいだと思うにょ。
＞オクターブの上げ下げも逆みたいだしね。

今試したら逆じゃなくなってた。
ループは
[MML]nが
/:nMML:/だった。
http://putikonclub.g.hatena.ne.jp/otyakenrabu/20120605

1070：御茶目菜子：2012/06/05(火) 23:46:44
レスにょ
otyakenさんへ
＞今試したら逆じゃなくなってた。

私の勘違いだったのかも・・・。
だとすると例のどら食えのMMLも上げ下げは逆にしないと正しく鳴らないにょ。

1071：御茶目菜子：2012/06/05(火) 23:49:54
新型VAIO Tは「Tenuki」のT・・・？
IvyBridgeのULV版が正式発表されたにょ。
http://pc.watch.impress.co.jp/docs/news/20120605_537050.html
これによってそれを搭載したUltrabookも次々発表されているにょ。
そんな中、SONYもVAIO TをUltrabookとして発表したにょ。
VAIO Tシリーズ（T、TX、TZ、TT）は10.6〜11.1インチの液晶を搭載して光学ドライブを内蔵
しながらも薄型軽量であることが特徴となっていた機種にょ。
しかし、2009年発売のTTを最後に新モデルの登場がなくなり今回久々にTシリーズが登場という
ことで一部ではかなり注目されたもののリーク情報でがっかりした人も多かったにょ。
というのも、特徴的な部分が無くなり平凡なUltrabookになったためにょ。

今回発表されたVAIO Tの店頭モデルのスペックを見ると次のようになっているにょ。

　　　　　　　　11インチモデル　　　　13インチモデル
　CPU 　　　　　Core i5-3317U　　　　 Core i5-3317U
　メモリ　　　　4GB　　　　　　　　　 4GB
　ドライブ　　　HDD500GB＋SSD32GB　　 HDD500GB＋SSD32GB
　画面解像度　　1366x768　　　　　　　1366x768
　バッテリ駆動　6.5時間　　　　　　　 6.5時間
　サイズ　　　　297x214.5x17.8　　　　323x226x17.8
　重量　　　　　1.42kg　　　　　　　　1.6kg
　予価　　　　　11万円前後　　　　　　12万円前後

VAIO TTの店頭モデル（VGN-TT50B）が光学ドライブ内蔵で1.27kgであったことを考えると
11インチモデルの1.42kgというのはさすがに重いにょ。
13インチモデルの1.6kgというのは今まで発表されたUltrabookの中で重い方から数えた方が
早いくらいのレベルだからね。
さすがに厚さは最大21mmの制限があるUltrabookだけあって17.8mmのスリムなものになって
いるもののこれも15mm前後の機種が多く発表されているということを考えるとUltrabookの
中では薄いものには属さず平均、もしくは平均よりやや厚めといった感じにょ。

重量においては重要なのはバッテリ駆動時間との兼ね合いにょ。
たとえば1.2kgで4時間駆動の機種（機種A）と1.3kgで12時間駆動の機種（機種B）があり、
それぞれのバッテリの重量が100gと300gであった場合には機種Aの方を12時間駆動する場合
にはプラス200gしなくてはならないため1.4kgになり、「デフォでは軽いけど実際は重い」と
いう逆転現象が起きることになるにょ。
この2機種の重さが同じになるのは8時間駆動の場合であり、その時の重量は両者ともに1.3kgに
なるにょ。
JEITA測定法における公称駆動時間はWeb閲覧程度の負荷で概ね6〜7割程度の実駆動になる
場合が多いため（新品時に）2、3時間駆動すれば十分という人は機種Aの方が軽くなり、
4、5時間駆動すれば十分という人は機種A、機種Bはほぼ同等になり、それ以上必要という
人は機種Bの方が軽くなるというわけにょ。

それでは、その必要駆動時間あたりの重量を見てみるとVAIT TTは店頭モデル（HDD搭載）で
さえ駆動時間10時間であるため「軽いTTの方が駆動時間も長い」ということで必要駆動時間
あたりの重量はスペック上の重量よりもさらに差が開いてしまうにょ。
つまり、この新型のTが「重い代わりにバッテリ駆動時間がすごく長い」のでない限りは
「単に重くなっただけ」ということになるにょ。
仮にこの新型Tのバッテリが200gとすればTTと同等以上の駆動時間にするためにはデフォの
重量に200gプラスする必要があるため11インチモデルは1.62kgになるので1.27kgのTTと
比べると350g重いといえるにょ。
4時間動作すれば十分という人でもデフォ重量との差になるので150g重いにょ。

Ultrabookと比較されることの多いMacBook Air（以下MBA）だけど今年はまだ発表されてない
ため昨年に発売されたMBAとVAIO Tのサイズ、重量を比べた場合は下記のようになるにょ。

　　　　　　　　VAIO T　　　MBA
　厚さ　　　　　17.8mm　　　17mm　　　　0.8mm　MBAの勝利
　重さ11インチ　1.42kg　　　1.08kg　　　340g　MBAの勝利
　　　13インチ　1.6kg　　　 1.35kg　　　240g　MBAの勝利

厚さは0.8mm差ということで大差というほどではないけど重さに関してはMBAの圧勝にょ。
実際各社のUltrabookもMBAに勝つべく薄型というだけではなく軽量化も進めておりMBA
よりも軽いUltrabookはすでにいくつも存在するにょ。
国内メーカーだとNECから発表されているLaVie Zは13インチながら「999g以下」（正式
重量は現時点では非公開）という極めて軽量なものになっているにょ。
http://pc.watch.impress.co.jp/docs/news/20120605_537833.html
海外メーカーでもマザーボードメーカーのGIGABYTEが11.6インチで975gという軽量な
Ultrabookを公開しているにょ。
http://www.gigabyte.com/press-center/news-page.aspx?nid=1130
確かにMBAは現時点でも比較的軽い部類だけど国内メーカーは12インチクラスで1kg前後の
モバイルノートは古くから作っているため軽量化は国内メーカーのお家芸ともいえるにょ。

全部入り（光学ドライブ、独立GPU搭載など）のハイスペックモバイルノートでユーザーから
高い支持を得ていたVAIO Zだけど昨年のモデルチェンジで光学ドライブ、GPUが外付けになり
多くのユーザーから不満の声が上がったにょ。
この度、そのZもIvyBridgeを搭載した新モデルが発表されたにょ。
http://pc.watch.impress.co.jp/docs/news/20120604_537059.html
そのZだけど昨年9月28日に書いたようにUltrabookとして考えると極めて優れたものである
ことが分かるにょ。
何せ高性能な通常電圧版のCPUを搭載しているにもかかわらずMBAより薄くて軽くて駆動時間も
長いわけだからね。
その代わり価格も高価だったにょ。
とはいえ、従来のユーザーからの不支持が多く販売店によっては発売から3ヶ月後には当初の
半値程度まで値下がりしていたため当時発表されたいた第1世代のUltrabookと同レベルの
価格帯であり、実売価格は決して高価ではなかったにょ。

VAIO Tの13インチモデルはVAIO Zと競合することになるにょ。
そうなるとZはTより格上であるため価格が高価な分だけすべての面において優れているにょ。
つまり、TはZがあるためモバイル性（サイズ、重量、駆動時間）を高めることができなかった
ということにょ。
これは言い換えるとTは手を抜いて作る必要があったといえるにょ。
確かにコスト削減のためといえば聞こえはいいけど同一メーカー内で上位モデルを越える存在
になってはならないという考えが優先してしまっているのは明らかにょ。（これは別にVAIOに
限ったことではなく全く異なるジャンルにおいて、キヤノンもEOS 60Dを7Dの下位と位置づけて
明確にスペックで差を付けたことがユーザーからの批判対象になっている）
高解像度がソニーのモバイルノートのウリの1つになっている部分だけど13インチモデルは
WXGAという非常につまらないものになっているにょ。
同じ13インチのVAIO Zは店頭モデルでWXGA++（1600x900）となっており、ソニーストアで
カスタマイズを行えばフルHDも可能であることを考えると明確に格下扱いになっているにょ。
11インチモデルはVAIOにはZのようなハイスペックモバイルは存在しないけど結局13インチ
モデルと同様に廉価モバイル扱いになっているにょ。（Tよりさらに下となるEもあるけど）

要するに価格だけがウリといえそうだけどVAIOの場合は店頭モデルは無駄に高価になっている
ためあまりオススメできないにょ。
やはり、本命はソニーストアによるカスタマイズモデルにょ。
最小構成ならば11インチモデルは59800円、13インチモデルは69800円となっているにょ。
ただし、最小構成だとCPUはCore i3になり、メモリは2GBになるにょ。
CPUはi3で困ることはそれほどないけどメモリ2GBはやや不足にょ。
自分で後から増設してもいいけど買ってすぐに使えるレベルとなると4GBが最低ラインである
ためにそれだと11インチモデルは63800円になるにょ。
これでも十分に安いにょ。（長期保証がデフォだし、オプションでワイドにすれば落下や
水没の保証もあるため保証については下手なメーカーよりもいい）
スペックはつまらないけど価格を重視して買うのならば悪くない選択肢といえるにょ。
ただし、ベースモデルに近い状態で購入しないとそのメリットも失われるにょ。
カスタマイズでハイスペック指向にしていくとどんどんコストパフォーマンスが悪くなる
からね。
特に13インチモデルはTの上位にZがあるだけにTをハイスペックにカスタマイズするくらい
ならばZを購入する方がコストパフォーマンスは高くなるにょ。

1072：御茶目菜子：2012/06/06(水) 21:43:55
Wii Uの勝利の鍵は・・・？
E3でWii Uの概要が発表されたにょ。
http://game.watch.impress.co.jp/docs/news/20120606_538192.html
といっても、前日のプリカンファですでに言われていたように発売日や価格の発表は無かった
わけだしWii Uの詳細スペックは発表されず、専用コントローラとなる「Wii U Game Pad」の
詳細発表と発売予定のタイトルの一部が発表されただけに止まったにょ。

やはり、Wii Uで気になるのは基本性能だと思うにょ。
何せ現行のWiiはPS3やXbox360と比べて大幅に性能が劣るためマルチ対象から外れがちであり
昨今は開発コスト高騰によって少しでもパイを大きくするためマルチが普通になっていると
いう状況下であるためマルチ対象外というのはゲームのタイトル不足を招いてしまうことに
繋がりこれは事実上Wiiが任天堂ソフト専用機になっていることを意味するにょ。
Wii Uにはこれを打開してもらう必要があるため必然的にそれなりの高性能化が求められて
いたにょ。
もっとも、PS3に搭載されているGPUはGeForce 7800GTXの帯域半減カスタムバージョンという
ことで実質7600GTレベルの性能しかないためこれを越えること自体は容易にょ。
Wii Uでは28nmのGPUの搭載があり得ると昨年後藤氏が予想されていたのを見てそれを元に
考えた場合にはメモリ帯域がボトルネックになったとしてもWii UのGPU性能はPS3の3〜5倍に
達するのではないかと予想したにょ。
したがって、昨年7月27日に書いたように「28nmプロセスならばWii Uは勝てる」という結論に
至ったにょ。

これは、PS3の次世代機PS4（？）がWii Uと比べて大幅な性能差をアピールするために5倍の
性能にしようとしても28nm世代では実現が困難であり次の20nmプロセスでようやく実現が
可能になるためにょ。
そうなると早くても2014年以降になってしまうだけではなく従来のPS3 vs Wiiのように
HD vs SDに加えてシェーダ有り vs シェーダ無しという大きな差と比べると5倍の差では
高性能を謳うには十分なレベルではないため先行するWii Uに大きなアドバンテージが
出てくるからにょ。
それに現行のPS3もフルHDで全く問題がない性能かというとそうではなくゲームによっては
解像度やフレームレートを落とす必要があるし、3D立体視でプレイするためには120fpsで
表示する必要があるのだけど現行のPS3にはその性能がないにょ。
しかし、Wii UがPS3の3〜5倍ならばそれらにおいても何とか及第点レベルに達するため
PS4が高性能化を行っても有意的な差にはならないためにょ。
一般家庭のTVがフルHDより高解像度化されるのは当分先のことだしDX10とDX11の描画の差
なんてほとんどの一般人には区別が付かないからね。

しかし、Wii Uで28nmプロセスのGPUを搭載するのは各ファウンドリの28nmの量産化の
立ち上がりの遅れなどによって怪しくなったにょ。
最新の製造プロセスで製造が可能なファウンドリは限られておりどれもが28nmでは十分に
製造できる状況下にないためWii UのGPUは28nmではなく40nmになるというのが濃厚になって
しまったからね。
これは当初の予想よりも一世代劣るものになるということにょ。
AMDやnVidiaが発表しているGPUを見る限り、40nmから28nmへの進化は非常に大きく従来より
性能を上げながら省電力が行われておりワットパフォーマンスは2倍くらいに変わっている
感じにょ。
上限TDPを固定して考えるならばこの世代の移行で性能は2倍変わることを意味するにょ。
28nmならばPS3と比べて実性能で3〜5倍の確保が可能であっても40nmならば1.5〜2.5倍に
とどまるということにょ。（28nmならばRADEON HD4870レベルの800spを搭載可能だったけど
40nmだと半分の400spになると予想するけどシェーダのみの性能ならばこれでもPS3と比べて
3倍以上になると思われる）
これならば仮にPS4が現在開発中であってもWii Uと比べて高性能化を謳う余地を与えることに
なり、Wii Uの絶対的な勝利は無くなってしまうにょ。

実際のところ今回はWii Uに搭載しているCPU、GPUに関してはノーコメントであるため何とも
言い難いのだけど実際にプレイしているデモ映像を見る限りではPS3と同レベルといった
感じになっているにょ。
確かにWiiと比べると別格の進化となっているにょ。
WiiはGCの2倍程度の性能であり、初代Xboxと同レベルの性能であったためGC→Wiiではあまり
見た目の進化は無かったから当然のことだけどね。
この性能であれば次世代機とのマルチ対象になり得るかは微妙だけど少なくとも現行機との
マルチ対象には十分だと感じるにょ。

あとは、本体の記憶容量も気になるにょ。
Wiiはフラッシュメモリが512MBしかなくて当初はSDカードからは起動ができなかったから
SDカードに移したアプリは一端本体に書き戻さないとプレイできないという問題があった
ために本体フラッシュメモリのやりくりが大変だったにょ。
Wii UはSDXCにもたぶん対応しているだろうからデフォでそれにすべてのアプリとセーブ
データが対応していることを願うにょ。
何だかんだでWiiはSDカードに書き出せないデータやアプリも少なくないからね。
すべてのデータがSDHC/SDXCに保存できるわけではないのならば本体フラッシュの容量は
重要になってくるにょ。

それとやっぱり気になるのは価格にょ。
今回はまだ明かされてないもののWii U Game Padのコストを考えると従来の任天堂の
ゲーム機の上限価格である25000円は超えそうな感じにょ。
本体はスペックを抑えることで製造原価は2万円を切るだろうけどこのコントローラだけで
1万円以上のコストがかかってそうなので定価は3万円前後が濃厚かも・・・。
私の予想では29800円〜34800円といった感じにょ。

ゲーム機なんだからやっぱり一番重要なのはソフトだけどほぼ任天堂専用機状態だったWiiの
時よりは軽減されそうにょ。
現行発表されているタイトルだとNewスーパーマリオU」と「ピクミン3」がローンチで発売
されるらしいので安泰とはいえサードの協力がないと後が続かないにょ。
「HDゲームがプレイできる」というだけならばPS3やXbox360が十分普及しているしそれらは
現時点で25000円以下で買えるからね。
したがって、それら現行機と勝負するならば多少逆ざやになっても「25000円」という
今までの任天堂の上限価格を貫くことが求められるけど3DSの大幅値下げによる赤字計上も
あるわけだし、それは難しいのではないかと思われるにょ。

本体はこれ以上考えてもただの予想の域を脱しないため今回唯一詳細が発表された
「Wii U Game Pad」についてもう少し見ていくことにするにょ。
http://game.watch.impress.co.jp/docs/news/20120604_537520.html
私も当初は「こんな高価で重そうなコントローラはあり得ない」と感じていたけれど
マルチモニタ＋ポインティングデバイスと考えると悪くないコントローラにょ。
DSも2画面を有効に使っているソフトは結構出ているし、下画面がタッチパネルだからこそ
実現できたゲームも少なくないからね。
それと同じことが据え置き機でも可能になるということにょ。

しかし、コントローラとして考えると500gという重量はかなりの懸念材料になるにょ。
この重量で私が真っ先に思いつくのはVAIO UXにょ。
私はUXを使っており、Wii U Game Padと同じく両手持ちスタイルでの操作が基本となって
いるもののやはり約500gの重量はずっしり感があるにょ。
ただし、しっかりとしたグリップがあれば両手で500gというのは長時間（2、3時間）連続で
使用していてもそれほど大きな負担にはならないにょ。
週刊少年ジャンプが700g程度であり、それよりも軽いわけだしね。
もっとも、これはある程度の筋力がある大人というのが前提になっており、任天堂ハードの
対象の多くを占めている若年層（小学生、もしくはそれ以下）において考えると少々重い
かもしれないにょ。

確かに500gという重量は両手で支えている状態ならばそれほど重さは感じないとはいえ
液晶パネルをポインティングデバイスとして使用する場合には片手で支えることになるにょ。
これが一時的なものならばいいけど片手持ちスタイルがメインになる場合には上限重量は
500gではなく300gになると私は感じているにょ。
3DSやPS Vistaは300gを切っているので片手で持った状態でポインティング操作するのに
それほど問題がないけど一般的なタブレット端末の場合は10インチクラスで600〜700g、
7インチクラスで300〜400gとなっているにょ。
新型iPadは652gの重量となっておりこれを片手で長時間支え続けるにはかなりの筋力が
必要になってくるため長時間のゲームのプレイには向いていないにょ。
もっともタブレット端末の場合は長時間使う場合は専用の台を使ってテーブルに置いて
使うという方法もあるし、その大きさから手でつかむのではなく腕に乗せることで重さを
軽減可能だけどゲームコントローラの場合はボタン操作の関係上手でつかむ以外の持ち方は
難しいためポインティング操作がメインのゲームは長時間のプレイが厳しそうにょ。
これがある程度サイズが小さい端末ならば両手で支えつつ親指でポインティング操作する
ことも可能だけどそれが可能なのは横幅が17〜18cm程度が限界であり、まともに操作する
ならば最大でも横幅15cm程度が望ましいのだけど横幅が25.5cmもあり一般的な週刊誌の
長辺と同程度のサイズWii U Game Padでは両手に持ったままポインティング操作することは
極めて困難といえるにょ。（Wii U Game Padのスペック上のサイズを簡単に言えば
週刊少年ジャンプの短辺を3分の2にしたものと考えると分かりやすいと思う）

タッチパネル付きの液晶画面を用いてマルチモニタとポインティングデバイスとして使用
するのが特徴のWii U Game Padだけどその考えはすでに競合他社も行おうとしているにょ。
http://game.watch.impress.co.jp/docs/series/3dcg/20120605_537847.html
マイクロソフトは既存のタブレット端末やスマホをXbox360と組み合わせて行うにょ。
この「Xbox SmartGlass」はWindowsもしくはWindows PhoneのようなMS製のOS搭載機だけに
止まらずAndroidやiOS機（iPhone、iPad）でも専用のソフトをインストールすることで
可能にするにょ。
つまり、これらタブレット端末やスマホが普及さえしてくれたらユーザーは別途高価な
オプションを買いそろえる必要はないということにょ。
ただし、それでも専用のコントローラが標準で付属するWii Uと比べるとやや不利になると
思われるにょ。
コントローラが付属するならばユーザーの100％が所持することになり、それを前提とした
ゲームを作ることは可能になるけど別途スマホやタブレット端末が必要となるとその分だけ
ユーザー層が狭くなり、その分サードも対応を渋ることになるにょ。

それにスマホやタブレット端末は機種によってスペックがまちまちであり液晶サイズや
解像度が異なるだけでなくゲーム機のコントローラとして使うにはハードウェアボタンが
ない（ボタンもせいぜい3つ程度だし、機種によって配置が異なるため利用しにくい）と
いうことで、おまけ機能を脱しないのではないかと予想しているにょ。
スマホやタブレット端末が普及していくのは明白であり、将来的にはおもしろい存在に
なるけど実用性を考えるとやはりWii U Game Padのようなゲームのために作られたものとは
比較にならないと思うにょ。

SCEはPS VitaをPS3を組み合わせて使う「Cross-Controller」を発表したにょ。
確かにVitaはゲーム機であり操作性については申し分ないけどVitaそのものが普及して
いないという問題があるにょ。
「Cross-Controller」のためにVitaを購入する人はほぼ居ないと思われるためVitaの
売れ行きがすべてを左右するにょ。
普及しないと上記のようにサードの対応は難しいにょ。
それを使ったソフトは登場するかもしれないけどそれ専用（つまり「Cross-Controller」が
必須となるソフト）がラインナップされることはほぼないのではと思われるにょ。
したがって、対応しても「あれば便利」というおまけ程度に止まりそうな感じにょ。
任天堂もGCにおいてGBAをコントローラ代わりに使うという提案をして、一部ソフトはそれに
対応していたけど結局おまけ機能を脱することはできなかったからね。（サードの対応は
ほとんど無かった）

こうして見るとWii U Game Padというのは決して目新しい機能を持ったものではないけど
やはり標準で付属しているというのが最大の武器になっていると思われるにょ。
標準だからこそソフトの対応も進むわけだしね。
過去のゲームの歴史においてオプション機器が必要なゲームは最初はもてはやされても
すぐに廃れているからね。
WiiもWiiリモコンとヌンチャクがオプションでクラコンが標準の付属品だったらWiiの
歴史は変わっていたと思われるにょ。
サードも特殊なWiiリモコンやヌンチャクに積極対応しようとは思わないだろうからね。

あと専用だからこその使い勝手も大きいにょ。
タブレット端末やスマホが使える「Xbox SmartGlass」は普及台数の面ではVitaを使う
「Cross-Controller」と比べて将来的には有用になってくるにょ。
それでも上記のように専用機とは異なり操作性で劣るからね。
それだけではなく無線の遅延問題があるにょ。
Wii Uでは対応ゲームにおいてはTV無しでコントローラのみでも本編のゲームをプレイ可能
となっているけど「Xbox SmartGlass」は端末側のアプリで描画する仕組みになっている
ためゲーム本編をプレイするのが難しい（というか実質できない）だけではなく
リアルタイム操作を要求する場面でも使用ができないとのことにょ。（そもそもタブレット
端末とコントローラを持ち替えて操作するのが頻発するようでは実用レベルにならないため
「Xbox SmartGlass」の対応は極めて限定的なものになりそう）
そう考えると似たようなシステムといってもWii Uのアドバンテージは揺るがないと
いえるにょ。

SCEの「Cross-Controller」は「Xbox SmartGlass」よりもWii Uに近い使い勝手を実現できる
とはいえ、やはり無線LANによる通信だと遅延の影響でリアルタイムでゲームをプレイする
のはかなり厳しそうにょ。
もしも、SCEがPS3とVitaにが直接通信可能な高速無線通信アダプタを用意すればWii Uの
アドバンテージは失われそうだけどVitaだけではなくそんなアダプタまで買ってまでWii U
ライクなことをしたいという人はかなり限られるだろうから恐らくデフォで搭載されない
限りは普及はしないと思われるにょ。
ということで、Wii Uが成功するためにはWii U Game Padのアドバンテージを生かしそれを
いかに上手く活用できるかで大きく変わってくると思われるにょ。

1073：御茶目菜子：2012/06/07(木) 21:26:37
RX100はS100のライバルになる・・・？
ソニーから1インチセンサーを搭載した高級コンデジ「サイバーショットDSC-RX100」が
発表されたにょ。
http://dc.watch.impress.co.jp/docs/news/20120606_538091.html
サイバーショットRシリーズはR1以来7年ぶりとなるけどR1は21.5x14.4mmというAPS-Cに
迫る大型センサーを搭載しており一眼レフに匹敵する描写力で話題になったにょ。
しかし、価格の問題やサイズの問題があったせいか後継機種は登場せず今日に至るにょ。
RX100はR1とは全く似てない風貌だけど（R1のセンサーよりは小さいものの）1インチと
いう大型センサーのセンサーを搭載しているという点のみは共通にょ。

1インチセンサーといえばNikon 1が真っ先に思い浮かぶけどそのセンサーサイズは昨年の
9月22日に書いたけどそれを改めて書いてみると次のような感じになるにょ。

　　　　　　　　　　　　面積比
　フルサイズ　　　　　　7.44倍
　APS-C 　　　　　　　　3.17倍
　1.5インチセンサー 　　2.25倍　※G1Xに搭載のセンサー
　フォーサーズ（4/3） 　1.94倍
◎1インチセンサー 　　　1.00倍
　2/3インチセンサー　 　1/2倍
　1/1.7インチセンサー　 1/2.8倍
　1/2.3インチセンサー　 1/4倍

　※センサーサイズはメーカーや機種によって微妙に差がある
　　1/1.7インチセンサーの1/2.8倍という数字はRX100の公式サイト参照

見ての通り、一眼レフ用のセンサーとコンデジ用のセンサーのちょうど中央に位置するのが
1インチセンサーといえるにょ。
同一世代のセンサーで画像処理エンジンやレンズの性能が同レベルならば基本的に画素数
ではなくセンサーサイズで主に画質が決まってくるにょ。
しかし、大型センサーを搭載すれば本体が大型化してしまうだけではなくレンズまで大型化
してしまうという問題があるにょ。
一般的なコンデジに搭載されている1/2.3インチセンサーはわずか、6.2x4.6mmという米粒
レベルの小さなセンサーだけどそのお陰で高倍率ズームを搭載しながらポケットに余裕で
収まるコンパクトサイズが実現できているにょ。
したがって、小さいセンサーには小さいセンサーなりのメリットはあるけどレンズから入る
光を受ける絶対量が小さいため画質面においては不利になってしまうにょ。

画質とサイズの両立をする場合には1インチセンサーというのは程よいサイズだと思うにょ。
しかし、Nikon 1は1インチセンサーを搭載している割に本体サイズもレンズのサイズも大きい
というのがやや気になったにょ。
特別大きいというわけではないもののセンサーの面積はフォーサーズの半分しかないのに
フォーサーズ（4/3インチ）センサー搭載機とあまり変わらないサイズだったからね。
フォーサーズセンサー搭載機も小型化が進んでおり、パンケーキズームのような薄型軽量
ズームが出ているということを考えるとNikon 1の方がセンサーサイズが小さいのに大型
といっても過言ではないかもしれないにょ。

では、1インチセンサーを搭載したRX100のサイズはどうなのかということでそのサイズや
重量を他の高級コンデジと比較してみたにょ。

　　　　　　　　　　ソニー　　　キヤノン　　ニコン　　　オリンパス　 キヤノン
　　　　　　　　　　RX100 　　　S100　　　　P310　　　　XZ-1　　　　 G1X
センサーサイズ　　　1インチ　　 1/1.7インチ 1/2.3インチ 1/1.63インチ 1.5インチ
画素数　　　　　　　2020万　　　1210万　　　1610万　　　1000万　　　 1420万
レンズ（35mm換算）　28-100mm　　24-120mm　　24-100mm　　28-112mm　　 28-112mm
　　　　　　　　　　F1.8-4.9　　F2.0-5.9　　F1.8-4.9　　F1.8-2.5　　 F2.8-5.8
最短撮影距離　広角　5cm　　　　 3cm　　　　 2cm　　　　 1cm　　　　　20cm
　　　　　　　望遠　55cm　　　　30cm　　　　60cm　　　　30cm　　　　 85cm
本体サイズ　幅　　　101.6mm　　 98.9mm　　　103mm　　　 110.6mm　　　116.7mm
　　　　　　高さ　　58.1mm　　　59.8mm　　　58.3mm　　　64.8mm　　　 80.5mm
　　　　　　厚さ　　35.9mm　　　26.7mm　　　32mm　　　　42.3mm　　　 64.7mm
本体重量　　　　　　213g　　　　173g　　　　----　　　　----　　　　 492g
使用時重量　　　　　240g　　　　198g　　　　194g　　　　275g　　　　 534g
　　　　　※本体重量　＝メディア、バッテリ無しの重量
　　　　　　使用時重量＝メディア、バッテリ込みの重量

これを見ると高級コンデジとしては小振りとなっているS100と比べても幅と高さに関しては
ほぼ同レベルであることが分かるにょ。
S100は高級コンデジとしては一般的な1/1.7インチセンサーを搭載しているけれどこの
サイズは1インチセンサーの1/2.8の面積しかないためRX100はセンサーサイズの割にかなり
小型軽量であることが分かると思うにょ。
厚さはS100と比べてやや厚いもののそれでもP310と比べても3.9mmに止まっており、XZ-1と
比べたら厚さだけではなくすべての面において小型、軽量となっているにょ。
この中で唯一RX100よりも大きなセンサーを搭載しているG1Xだけどそのサイズ、重量は
他を圧倒するレベルであり、これらと同レベルに考えるのが難しいレベルにょ。

RX100で注目すべきはやはりレンズにょ。
センサーサイズが大きくなれば基本的に本体が大きくなるけど本体は小型化の余地が
あるもののレンズは小型化が難しいからね。
RX100に搭載されているレンズは換算28-100mm相当の3.5倍ズームレンズであり、明るさも
広角側においてはF1.8を実現しているにょ。
これはの明るさだけを見るとP310と互角となっているにょ。
P310に搭載のセンサーは1インチセンサーのわずか1/4しかない1/2.3インチセンサーである
にも関わらずその本体のサイズ差はわずがになっているにょ。
こうしてみるとRX100のサイズの小ささは異常といえるレベルにょ。

それでは参考程度に1インチ〜APS-Cセンサーを搭載したミラーレスとも比較してみるにょ。

　　　　　　　　　　ニコン　　　Panasonic　 ソニー
　　　　　　　　　　Nikon1 J1　 GF5　　　　 NEX-F3
センサーサイズ　　　1インチ　　 4/3インチ　 APS-C
画素数　　　　　　　1010万　　　1210万　　　1610万
本体サイズ　幅　　　106mm　　 　107.7mm　　 117.3mm
　　　　　　高さ　　61mm　　　　66.6mm　　　66.6mm
　　　　　　厚さ　　29.8mm　　　36.8mm　　　41.3mm
本体重量　　　　　　234g　　　　225g　　　　255g
使用時重量　　　　　277g　　　　267g　　　　314g
標準ズーム(35mm換算)27-81mm　　 28-84mm　　 27mm-82mm
　　　　　　　　　　F3.5-5.6　　F3.5-5.6　　F3.5-5.6
マウント面からの長さ42mm　　　　26.8mm　　　60mm
レンズ重量　　　　　115g　　　　95g　　　　 194g
最短撮影距離　広角　20cm　　　　20cm　　　　25cm
　　　　　　　望遠　20cm　　　　30cm　　　　25cm
本体＋レンズ重量　　392g　　　　362g　　　　449g
本体＋レンズ厚さ　　71.8mm　　　63.6mm　　　101.3mm
　　　　　　　　　※本体＋レンズ重量＝使用時重量にレンズ重量を単純加算したもの
　　　　　　　　　　本体＋レンズ厚さ＝本体の厚さにレンズの長さを単純加算したもの

上記のコンデジとの比較では別格の大きさ、重さであったG1Xもこのミラーレスの中に
加わればそれほど大きく、重いものではなくなるにょ。
それでも「重い」ということには変わりはないけどレンズ内蔵で厚さ64.7mmというのは
パンケーキズームを搭載したGF5と同レベルでありミラーレスとして考えればかなり
薄型の部類になるにょ。（GF5は本体とレンズの厚さを単純加算したものなので実際は
上記の表と比べて数mmの誤差があると思われる）
何せAPS-Cセンサーを搭載したNEX-F3は標準ズームを装着したら厚さが約10cmにまで達して
しまうわけだからね。
NEX-F3も本体だけを見れば決して大きく重いものではないけどセンサーサイズが大きく
なればレンズの大きさや重さに大きな影響を与えるというのはこれで分かると思うにょ。

それを踏まえて同じ1インチセンサーを搭載したRX100とJ1を比較してみるにょ。
本体だけのサイズにおいてはJ1の方が若干薄型だけどレンズを装着した状態で比較すれば
一気に逆転してRX1の方が圧倒的に薄型になるにょ。
これはレンズ一体型というのが大きく影響しているけどNikon 1用のレンズが明るさの
割に大きいというのが影響しているにょ。
何せ広角側F1.8という明るさを実現しているのにも関わらずRX1のレンズはコンパクトに
なっているからね。（とはいえ、センサーサイズが大きい分だけ鏡胴は他のコンデジより
太くなっている）
そして、重量においてはレンズを装着していないJ1よりもレンズ込みのRX100の方が軽い
ためレンズ装着時にはRX100の方が圧倒的に軽くなるにょ。
これもJ1がセンサーサイズの割に本体が軽くないためにょ。

サイズ、重量の話ばかりしても面白くないので他の面を見ていくにょ。
G1Xはセンサーサイズの大きなコンデジ（1月10日にはセンサーサイズの大きなコンデジは
別の名称で呼ぼうということで「レンズ一体型デジカメ」というのを提案したけどやはり
分かりにくいと感じたので今後は「大型センサー搭載コンデジ」と呼ぶことにする）と
いうことで、画質面に非常に優れていたにょ。（開放では周辺部の描写力は今ひとつ
だけど絞ればかなり改善される）
特に高感度画質においては最新のAPS-Cセンサー搭載のデジタル一眼レフと比べても遜色
ないすばらしいものだったにょ。

では、RX100がどうなのか・・・というとまだレビューがないもののメーカーサイトによる
サンプルなどを元に判断すると画素ピッチから考えたものよりはかなり解像感が高く
感じたにょ。
1インチで2020万画素ということはAPS-Cで6000万画素以上に相当する画素ピッチであるため
レンズの解像力が追いつかないと考えていたけど思った以上に悪くないにょ。
高感度時の撮影サンプルがメーカーサイトになかったので海外サイトを見てみたけどこれも
悪くない感じにょ。

（ISO3200）
http://www.imaging-resource.com/PRODS/sony-rx100/FULLRES/RX100hSLI3200NR2D.HTM

詳しくは製品版のレビューが行われて判断する予定だけどこの撮影サンプルを見る限りでは
画素数が多い割には高感度画質も悪くはないにょ。
やはり、センサーサイズが大きいというのもあるけどセンサーそのものの性能が高いのと
画像処理エンジンによってうまくノイズ除去している影響もありそうにょ。
さすがに高感度時の画質はG1Xと比べたらやや劣る感じだけどね。
とはいえ、2000万画素でこれなんだからこれが1000〜1200万画素だったら下手をすると
G1Xに近いレベルの高感度画質を実現できた可能性はあるにょ。

高感度画質においてはG1Xは非常に優れているけどG1Xの弱点は「寄れない」ということにょ。
基本的にセンサーサイズが小さい方が接写しやすいのだけどそれを考慮しても上記のミラー
レスの標準ズームを見てのようにG1Xの最短撮影距離が大きく劣っているのは一目瞭然と
いえるにょ。
RX100はどうなのかというと広角側で5cm、望遠側で50cmとなっているにょ。
これは一般的なコンデジの中では平均よりやや下といった感じだけどセンサーサイズを
考えるとすごく健闘しているにょ。
もっとも、G1Xは接写時の画質低下を防ぐため意図的に最短撮影距離を大きくしたという
ことも考えられるし、RX100は接写時の画質低下よりもユーザーの利便性を重視したとも
考えられるためこれで単純にRX100の方が上と言えるものではないけど多少画質が低下しても
撮影できないよりはできた方がずっといいからね。（もちろん、使い物にならないレベル
だったらあまり意味がないけど）
いくらISO100における描写力が高くても最大感度ISO100では使える場面が制限されるのと
同じにょ。
感度だったらまだRAWから増感処理を行えばいいけどピントが合ってない写真をあとから
ピントを合わせるなんて昨年10月25日に書いたようなライトフィールドカメラでない
限りは不可能だからね。

RX100は高感度時の画質はG1Xほどは期待できないとはいえG1Xと比べてレンズが明るいと
いうアドバンテージがあるにょ。
望遠側は1/3段程度の差とはいえ広角側は1段以上明るいにょ。
これは言い換えると高感度時の画質がRX100の方が1段劣っていてもレンズの明るさで
逆転ができるということにょ。
RX100のレビューがないため何ともいえないけどG1Xの方が少なくとも1段分以上は優れて
いると思われるためレンズの明るさを考慮してもG1Xに暗所画質（高感度時の画質＋レンズの
明るさ）ではやや劣っていると考えられそうにょ。
それでも、RX100と同等クラスのサイズ、重量のデジカメの中ではほぼ間違いなく暗所画質は
トップになりそうにょ。

センサーサイズの割にレンズが明るいためボケに期待している人もいるかもしれないにょ。
G1Xを除くコンデジの中でボケ量においてはトップレベルとなっているXZ-1だけどそれと
比べて広角側においてはレンズの明るさが同等でセンサーサイズが大きいからRX100は
かなり有利になりそうだけど実はXZ-1が本当に優れているのは望遠側でさえF2.5という
明るさにあるにょ。
このためXZ-1はセンサーサイズで圧倒的に格上の存在であるフォーサーズの標準ズームと
互角のボケ量となっているにょ。
RX100はフォーサーズ換算だと14-50mm F2.4-6.5となっているにょ。（このF値は
ボケ量を換算したものであり、明るさそのものは換算してもF1.8-4.9で変わらない）
これから考えると一般的なフォーサーズ用の標準ズーム（14-42mm F3.5-5.6）と比べて
広角側はぼけ量で勝っているけど望遠側はほぼ互角といった感じにょ。（明るさは若干
暗いけど焦点距離が若干長いのでほぼ相殺されている感じ）

もっとも、フォーサーズの標準ズームと互角というレベルではそこまでボケ量は期待
できないもののコンデジとして考えるとかなり優秀といえそうにょ。（問題はボケ量
だけではなくボケ味も重要だけど）
広角側がF1.8と明るいのはいいけど問題は日中屋外だと最高1/2000秒というシャッター
速度だと屋外でF1.8は使えない場合も多いにょ。
風景とかだと絞ることが多いのだけどせっかくのF1.8を使いたい時に使えないというのは
やや残念にょ。
1/4000秒の高速シャッターを搭載するか、NDフィルターを搭載してくれると良かったにょ。

こうしてみるとRX100は私の理想の高級コンデジにかなり近い存在といえるにょ。
私が高級コンデジに求めているものは毎日の持ち歩きに苦にならないサイズ重量と
普及クラスのコンデジと比べて別格な描写力を持つということだからね。
あとは、室内での撮影を考慮して高感度時の画質（というかレンズの明るさを加味した
暗所性能）で優れているということとそれなりに接写ができるということと操作性に
優れているということにょ。
操作性においてはRX100はS90/95/100のようなリングダイヤルを装備しており、使い勝手は
悪く無さそうにょ。（実際に使ってみないとその感触が自分に合うかどうかは分から
ないけど）

ということで、RX100の唯一の懸念材料は「画素数が多すぎる」ということくらいにょ。
あとは、小型化の影響でレンズの描写力（特に周辺画質）もやや不安なところにょ。
これらは製品版のレビューが行われた時に改めて見ていこうと思うにょ。
そして、やっぱり一番気になる価格だけど予価7万円で価格comの最安値（ただし、発売
前ということであくまで参考価格）は、62800円となっているにょ。
スペックを考えると決して高価ではないけどやはり気軽に手を出せる価格ではないにょ。
RX100は価格的にはライバルはG1Xという感じにょ。
しかし、G1Xはサイズや重量を考えるとライバルはミラーレスであり、高級コンデジの代わりに
買うには少々厳しいにょ。（「コンデジ」と思って買った場合にはサイズ面の問題だけでは
なく上記の「寄れない」という問題点も大きくなってしまう）
それに対してRX100は高級コンデジの代わりに買っても全く問題がないレベルのサイズ、重量
となっているにょ。（レンズバリアが付いている点も重要）
サイズの上限（ポケットに収まるサイズ）がある人ならば予算がそれなりならばS100、
十分に予算があればRX100がベストな選択になりそうにょ。

1074：御茶目菜子：2012/06/09(土) 21:46:21
これが最後のKissになるのか・・・？
キヤノンがデジタル一眼レフ「EOS KissX6i」を発表したにょ。
http://dc.watch.impress.co.jp/docs/news/20120608_538522.html
EOS KissX5の後継機となる入門機だけどまずはX5との違いを見てみるにょ。

　　　　　　　　　　　EOS KissX6i 　　　　　EOS KissX5
センサーサイズ　　　　APS-C　　　　　　　　 APS-C
画素数　　　　　　　　1800万　　　　　　　　1800万
画像処理エンジン　　　DIGIC5　　　　　　　　DISIC4
ISO感度　　　　　　　 100-25600　　　　　　 100-12800
液晶モニタ　　　　　　タッチ対応　　　　　　タッチ非対応
連写速度　　　　　　　5コマ/秒　　　　　　　3.7コマ/秒
ライブビュー時のAF　　ハイブリッドAF　　　　コントラストAF
GPS　　　　　　　　　 有り　　　　　　　　　無し

画素数は1800万画素据え置きとなっているにょ。
前々モデルのX4で1800万画素になってから据え置きとなっているけどこれは良いことだと
私は思うにょ。
ソニーにしろニコンにしろ入門機が2400万画素という画素数に達しているけど入門機を買う
人の大半はキットレンズで済ませると思うので2400万画素という画素数を生かせず無駄に
画素数が多いだけだからね。
そして、画素数が多ければ多いほどブレに対してシビアになるにょ。
この辺の問題についてはそれを熟知しているベテランの人にとっては全く問題のないかと
だけどそういう層が入門機を購入することはあまりないだろうからね。（確かに軽量で安価
というメリットがあるからそういう層が買わないというわけではないけど）

デジカメは等倍鑑賞の機会が多いためせっかく画素数が多くなっても「解像していない」
「ぶれている」ということでせっかくの高画素の意味が全く無くなるどころか、データが
重くなりPCに要求するスペックが高くなり、無駄にカードの容量を使いレスポンスが悪く
なるとデメリットしかないにょ。
高価な単焦点レンズなど高解像力のレンズを用いて、ぶれないようにしっかり構えて撮影
することを心がければ高画素のメリットを生かすことはできるけどそれが出来る人は小数派
であり、入門機を購入する人の中に限って言えばほとんど居ないと予想されるためこれ以上の
高画素化は不要と私は考えているにょ。
一般家庭で行うであろう最大のプリントサイズであるA3であっても1200万画素あれば十分な
わけだしね。（まぁレンズの解像力が足らなくてもオーバーサンプリングを考えれば画素数が
多いことは無駄とはいえないけどそれならばせめてスモールRAWを搭載して欲しい）

ということで、X4から2世代画素数が増えてないため進化が止まっているというわけではなく
新型センサー搭載にょ。
そして、DIGIC5搭載も大きいにょ。
キヤノンのデジカメが高感度画質に優れているのはこの画像処理エンジンのお陰にょ。
DIGIC5はすでに多くの機種に搭載されているのを見てのように高感度時のノイズ低減効果は
絶大となっているにょ。
このセンサーと画像処理エンジンの変更によってEOS KissX6iの常用感度はISO12800、拡張感度
にいたってはISO25600となっており従来よりも1段分増えているにょ。
高感度設定ができるようになったからといって高感度画質が上がったとは限らないけど上記の
変更を考慮すれば1段分くらいの画質向上は期待できそうにょ。

このEOS KissX6iの最大の進化はAFにあるにょ。
キヤノン初の像面位相差検出AF方式を搭載しているにょ。
これはニコンにおいてはミラーレスであるNikon 1に搭載されたけど要するに撮像センサー上に
AF測距センサーを置いているということにょ。
像面位相差検出AF方式は特にミラーレスにおいては効果が絶大なのだけどほとんど採用されて
いないのは1つは特許の問題があるだろうし、もう1つは撮像センサーの一部をAFセンサーと
して使用しているためドット欠けが起きてしまうということにょ。
ドット欠けにおいてはベイヤー方式の場合はそれほど深刻なものではなく周辺画素からの補完
によって画像生成が可能になるのだけど写ってない部分を補完するわけなので解像感の低下を
招いてしまうにょ。
私もNikon 1のレビューの写真を見ると高感度画質においてはセンサーが（ミラーレスの中
では）小さい割に健闘していると思ったのだけど低感度はどうも解像感が物足りなく感じて
しまったにょ。
これはレンズのせいかもしれないけど像面位相差検出方式による画素補完の影響も少なくない
かもしれないにょ。

さて、そうなるとこのEOS KissX6iも心配になってくるかもしれないけどこのEOS KissX6iに
使われているセンサーは撮像センサーとAFセンサーを兼ねたセンサーを使用しておりドット
欠けがないため理論上は画質の低下の心配は要らないにょ。
問題はその画素ピッチでそんなことをすれば撮像センサーに入る光とAFセンサーに入る光が
分断して「二兎を追う者は一兎をも得ず」の状態になるのではという考えの人もいるかも
しれないにょ。
この辺は過去に前例のないセンサーだけに実際のレビューを見るまでは何とも言えないにょ。

像面位相差検出方式は一眼レフの場合は位相差検出方式AFセンサーを別途搭載しているため
本来ならば不要にょ。
それをあえて採用したのは近い将来ミラーレスカメラを販売するための布石というのもある
けどEOS KissX6iにおいてはライブビューにおけるAF速度を向上させるためにょ。
キヤノンのデジカメは位相差検出方式においては業界トップの性能を誇っているけど
コントラストAFにおいては決して優れているとは言い難い状況にあるにょ。
当初は背面液晶をファインダー代わりにしての撮影のために使われたライブビューだけど
近年はデジタル一眼でも動画撮影が当たり前となったためにその使用頻度は急増していると
思われるにょ。
しかし、ライブビュー時はミラーアップが行われており位相差検出方式AFが使えないため
必然的にコントラストAFを行う必要があったにょ。
その場合、コントラストAFの遅さがアキレス腱になってしまっていたにょ。

ただし、この像面位相差検出方式センサーも精度の問題があるのかコントラストAFとの
併用となっているにょ。
確かに顔認識等はコントラストAFは必要だけどそうではなく像面位相差検出方式によって
ある程度ピントを合わせていて最後にコントラストAFで微調整を行うみたいにょ。
キヤノンはこの像面位相差検出方式とコントラストAFのハイブリッド方式のAFを
「ハイブリッドCMOS AF」と呼んでいるにょ。
これによって従来はできなかったライブビューや動画撮影時のサーボAF（コンティニュアス
AF）ができるようになったにょ。
コントラストAFは静止物を撮影するのには問題ないけど動体撮影は途端に弱くなるからね。

キヤノンが動画に力を入れているのはEOS KissX6iと同時に発表されたEF40mm F2.8STMと
EF-S18-135mm F3.5-5.6IS STMの2本のレンズを見ても明らかにょ。
これらのレンズはステッピングモーターが採用されており、動画撮影時にAFがスムーズに
なる模様にょ。
動画は重視しないという人もEF40mm F2.8STMはフルサイズ対応であり、キヤノン初の
パンケーキレンズであるためにその存在価値は高いと思われるにょ。
定価2.4万円と安価であるためズームレンズ付きのレンズキットを買った人が2本目の
レンズとして最初に買うのに適しているかもしれないにょ。
AFが強化されたのはライブビューや動画撮影時だけではないにょ。
通常時においても9点の測距点がすべてクロス対応となったためどの測距点で撮影しても
中央と同レベルの速度や精度を得られるようになるにょ。

これらに比べたら些細となる液晶のタッチパネル対応やGPS搭載だけどこれにおいても
ニーズはあるため搭載することによるプラス点はあってもマイナス点はないのではないか
と思われるにょ。（タッチパネルオンリーの操作になってしまうと確かに弊害が出てくる
のでマイナス要素に感じるかもしれないけど〜
あと細かい点においては連写速度が3.7コマ/秒から5コマ/秒に引き上げられたにょ。
これは他社の入門機も5コマ/秒が普通になってきている状況を考えると当然といえるにょ。
ただし、入門機ということでバッファが削られている関係かRAWで6コマ、RAW＋JPEGだと
3コマしか撮影ができないにょ。
これは他社においても入門機はこんなものなのでEOS KissX6iの問題ということではない
けど1800万画素、14bitRAWならば非圧縮でも1枚31.5MBなんだからバッファメモリを1GB
くらい搭載してくれれば何ら不満が無くなるけどこれはコストの問題というより上位
モデルとの差別化の役割もあるためなかなか望むのは難しそうにょ。

EOS KissX5はEOS KissX4からの進化が少なくて「1回休み」のようなイメージだったけど
このEOS KissX6iは久々に大きな進化が行われて入門機としては最強クラスに返り咲く
ことになりそうにょ。
ただし、5月24日にも書いたように今後はミラーレスの普及によってデジタル一眼の入門機は
かなり厳しい立場に立たされることになるにょ。
ライブビューや動画撮影のウエイトが大きくなればなるほどデジタル一眼のミラーレスに
対するアドバンテージはどんどん小さくなってくるにょ。
ミラーレスはデジタル一眼と比べて小型軽量だし、ミラーや光学ファインダーがない分だけ
低コスト化が可能だからね。
そうなると近い将来には光学ファインダーを重視する中級機以上しか生き残れないと予想
しているにょ。（10年以上先を考えるとAPS-C搭載の中級機もその存続が危うくなり残るのは
フルサイズセンサー搭載機だけになるかもしれない）

確かにミラーレスのコントラストAFにはめざましいものがあるにょ。
コントラストAFを高速化するためにはレンズの対応が必要不可欠だけどミラーレスにおいては
コントラストAFでの使用を前提としているレンズの対応については全く問題ないにょ。
ただし、それでも現状では静止物では問題なくても動体においてはまだまだ不十分であり
最低でも運動会の徒競走にAFが追尾するレベルでないとデジタル一眼の入門機が絶滅するには
至らないと思われるにょ。
しかし、それも像面位相差検出方式によって解決可能にょ。
これがミラーレスにおいてデフォになる頃にはデジタル一眼の入門機は絶滅していると言う
ことが十分に考えられるにょ。
1インチセンサーを採用することでデジタル一眼との共存を行う選択肢をとったニコンに
対してキヤノンがどう出るかで今後大きく変わってくるにょ。
キヤノンのミラーレスがAPS-CセンサーやG1Xに採用されている1.5インチセンサーであれば
Kissとの差別化が難しくなりKissの役割は終了するかもしれないにょ。

1075：御茶目菜子：2012/06/10(日) 22:06:04
プチコン講座　第7回
久々にプチコン講座の続きを書いたにょ。

第7回　グラフィック面（GRP）をスクロールさせよう
http://ww5.tiki.ne.jp/~ochame/petitcom/p007.htm

GCOPYによってスクロールさせる方法について書いたわけだけどmkIIが発売されてから
GCOPYによるプログラムはたくさん作ったけどそれの1つのまとめとなるにょ。
今までだとGSPOITで画面全体を1ドットずつ読み出す必要があったのがGCOPYでは一発で
グラフィック画面に描いたキャラを他所にコピーできるようになり、アクションゲーム
にも耐え得る速度になったにょ。
それだけではなく画面全体コピーをしても1.6フレームの時間で済むため画面全体を
スクロールさせるようなゲームもGCOPYによって作れるようになったにょ。

スクロールそのものはプチコンにおいてはBG画面があるからそれを使えばいいのだけど
グラフィック面をスクロールさせるメリットとしてはキャラ単位である必要はないことと
お手軽であるということにょ。
どれくらいお手軽かというと2分の1画面に収まっているCAVEのリストを見れば分かるにょ。
キャラ単位であってもBG画面だとここまで短く記述することはできないからね。

それとやっぱり大きいのはドット単位で配置できるということにょ。
BG画面でも1ドットずつずらしたキャラを大量に定義することで擬似的にドット単位で
配置することはできるけどそれだとGCOPYより大幅に複雑になる上に当たり判定を行うのは
非常に大変になるにょ。
あくまでBG画面はキャラ単位なので当たり判定はキャラ単位でしかできないからね。
そういう意味では1ドット単位で簡単に当たり判定ができるグラフィック面がドット単位で
構成されたステージをスクロールさせるゲームを作るのに非常に都合が良いことが分かると
思うにょ。
というのを具体例を交えて書いているのが、上記の講座となっているにょ。

しかし、今回の講座はテキストサイズ60KBを越える量になってしまったにょ。
これは、第4回、5回、6回の講座の合計よりも多いにょ。
さすがに次回書くときはもっとコンパクトにしたいけどGCOPYは書きたいことがたくさん
あったからこれでもかなり厳選してい書いているくらいにょ（笑）
サンプルプログラムやサンプルゲームは40本くらいつくったけどこの講座で使用している
のはわずか10本くらいだからね。

さて、次の講座は何にしようか・・・。
「BG画面でスクロールさせる」ではありきたりだし、コンソール画面でドット単位で
スクロールさせるというのはあまりに需要が無さすぎるにょ。
スクロールから離れてBG画面を回転させるというのもいいかもしれないにょ。
いろいろな候補があるけどまずはある程度自分でプログラムを作って確かめないと講座は
書けないからね。
講座を書くことで「何が分かって何が分からないのか」ということが分かるため自分自身に
とってもいい勉強になるにょ。

1076：御茶目菜子：2012/06/12(火) 21:35:58
2880x1800の液晶に価値はあるのか・・・？
アップルから新型のMacBook Air（以下MBA）が発売されたにょ。
http://pc.watch.impress.co.jp/docs/news/20120612_539523.html

この新型MBAの従来モデルとの主な違いは以下の2点にょ。
(1)IvyBridge搭載
(2)USB3.0対応

(1)第3世代Core iとなるコードネームIvyBridgeだけどCPU性能そのものを見ると同一
クロックにおいては第2世代となるSandyBridgeとそれほど差はないにょ。
プロセスルールの進化によって高クロックのSKUが選択できるようになったというだけで
あるためCPUの性能強化はそれほど大きくはないにょ。
とはいえ、メモリは従来はDDR3-1333だったのがDDR3-1600に高速化されているためその
分だけ高速になっているにょ。

やはり、IvyBridgeの性能面におけるSandyBridgeに対するアドバンテージは5月14日にも
書いたように内蔵GPUの性能向上と製造プロセスの進化による省電力化にょ。
GPU性能は使用するソフトやベンチによっても変わってくるけど従来よりも1.3〜1.6倍ほど
高速化されているにょ。
ゲームをするのに十分な速度とは言えないものの筐体のサイズやコスト的に独立GPUの搭載が
難しいノートPCなどではその恩恵は大きいにょ。

(2)昨年のモデルですでに高速なThunderboltに対応しているためUSB3.0の必要性は薄かった
もののやはり普及率を考えるとUSBの方が圧倒的に高いので利用頻度も高いわけだしPCにおいて
USB3.0は急速に普及つつあるため対応する製品も多くなっているためメリットは大きいにょ。
Thunderboltは昨年2月27日に書いたようにUSB3.0よりも実効速度が速いという点だけでなく
やさまざまなプロコトルに対応し柔軟性の高さ（DisplayPortとしても使える汎用性の高さ）が
アドバンテージになっているにょ。
したがって、ThunderboltとUSB3.0の2つのIFはFireWireとUSB2.0のように共存していくと
考えられるにょ。
そうすれば今回のUSB3.0の対応は前世代のIFにおいてFireWire＆USB1.1からFireWire＆USB2.0
へと変わったようなものにすぎないと言えそうにょ。

とはいえ、これは単にIvyBridgeのチップセットがUSB3.0に対応しただけであってUSB3.0用の
コントローラを内蔵したわけではないにょ。
要するにIvyBridgeに対応する時点でUSB3.0に対応することが確定したというわけにょ。
USB2.0も当初は別途コントローラを搭載することによって対応していたけどIntel用のCPUの
チップセットにおいてはサウスブリッジは2002年に登場したICH4にてようやくUSB2.0に対応
しており、それ以降USB2.0が急速に普及したにょ。（ノートPCにおいてはPenM世代以降）
それと同じくIvyBridgeにおいてチップセットでUSB3.0が標準サポートされることによって
USB3.0が今後急速に普及することはほぼ確実であり、USB3.0に対応した製品も増えると
考えるため新型MBAがUSB3.0に対応した恩恵は大きいと思われるにょ。

というわけで、新型MBAは逆に言えばIvyBridgeが採用されただけであってUSB3.0もその
影響だし、あとの目新しい部分は何もない・・・と言えなくもないにょ。
11インチMBAにおいて2011年モデルと2012年モデルを比較すると以下のようになるにょ。

　◎2011年モデル
　　　　　　11インチ下位モデル　　　11インチ上位モデル
　CPU 　　　　Core i5 1.6GHz　　　　　　同左
　　　　　　　（SandyBridge）
　メモリ　　　　2GB　　　　　　　　　　 4GB
　SSD　　　　　64GB　　　　　　　　　 128GB
　拡張　　　　USB2.0x2、TBx1　　　　　　同左
　駆動時間　　　5時間　　　　　　　　　 同左
　サイズ　　　300x192x17mm　　　　　　　同左
　重量　　　　　1.08kg　　　　　　　　　同左
　価格　　　　84800円　　　　　　　　102800円

　◎2012年モデル
　　　　　　11インチ下位モデル　　　11インチ上位モデル
　CPU 　　　　Core i5 1.7GHz　　　　　　同左
　　　　　　　（IvyBridge）
　メモリ　　　　4GB　　　　　　　　　　 同左
　SSD　　　　　64GB　　　　　　　　　 128GB
　拡張　　　　USB3.0x2、TBx1　　　　　　同左
　駆動時間　　　5時間　　　　　　　　　 同左
　サイズ　　　300x192x17mm　　　　　　　同左
　重量　　　　　1.08kg　　　　　　　　　同左
　価格　　　　84800円　　　　　　　　 94800円

これを見てのようにCPUがIvyBridgeに代わりクロックが0.1GHzアップし、USB3.0に対応した
ということくらいの違いしかないにょ。（サイズ、重量もまったく同一だし）
とはいえ、下位モデルの方は2GBというかなり心許ないメモリだったのがようやく実用的となる
4GBのメモリが搭載されたわけだし、上位モデルに至っては何の変化もないけどその代わり
価格が従来よりも8000円引き下げられているにょ。
この価格引き下げはSSDの価格下落の影響が大きいと思われるにょ。
一時期は下げ止まった感があったSSDだけどここ最近は再び大幅な下落があり120GBで1万円を
切って販売されることも珍しくなくなったからね。

マイナーチェンジ的なMBAに対して大きく変わったのがMacBook Pro（以下MBP）にょ。
MBPもただのマイナーチェンジに止まっているのだけどRetinaディスプレイに対応した
モデルが用意されているからね。
http://pc.watch.impress.co.jp/docs/news/20120612_539501.html
このRetinaディスプレイに対応した新型MBPは光学ドライブを排除し薄型軽量化を図っており、
従来のMBPとは異なる性質を持つ新製品と言えそうにょ。
やはり、最大の注目ポイントは2880x1800という超高解像度に対応しているという点にょ。
これは220ppiにまで達しており15インチ液晶を搭載したPCとしては過去に例のない最も
高精細なものといえるにょ。

個人的には液晶モニタの解像度は高ければ高いほどいいと感じているにょ。
それは単純に作業領域が増えるだけではなく文字も読みやすくなるからね。
しかし、Windows PCにおいてはWXGAが主流となっているにょ。
これは10インチクラスの液晶ならば特に問題はないのだけど15インチクラスの機種においては
単に粗いドットが見えてしまうだけであって大きな液晶画面を全く生かすことはできない
ためあまり喜ばしいことではないにょ。
高解像度化の弊害で「文字が小さくなり読みにくくなる」ということを考えている人もいる
だろうけどそれならばDPI設定を変えれば済むことにょ。
Vista以降はXPまでとは異なり、柔軟なスケーリングに対応しているためDPI設定を変えても
レイアウトが崩れることは非常に少なくなったにょ。
個人的には昨年の10月4日に書いたように標準のDPI設定（96dpi）での使用時であっても
120〜150ppi程度が使いやすいと感じているにょ。
つまり、15インチクラスならばフルHDもしくはWUXGAくらいはあっても良いということにょ。
もちろん、DPI設定を変えればさらなる高解像度も問題ないにょ。

MBPは従来WXGA＋（1440x900）もしくはWAXGA+（1680x1050）の解像度のモデルが選択でき
（今回は発表されなかった）17インチモデルでようやくWUXGA（1920x1200）という解像度に
なっていたにょ。
これは一定のDPI設定において文字やアイコンサイズが極端に変わるのを避けるためにょ。
昨今のMacは120dpi程度を基準に文字サイズやアイコンサイズが定められているためそれを
大きく変わるような環境では使い勝手に影響してしまうからそれを避けていると考えるのが
妥当にょ。
そこで今回は縦横2倍のピクセル数にすることで高解像度でも同じ使い勝手を実現しているにょ。
15インチWXGA+と15インチQuad XGA+（2880x1800）で文字やアイコンサイズを縦横2倍にした
ものとでは同等になり、アイコンや文字は精細感が出て読みやすくなるにょ。

この考えはiPhoneやiPadと同じものにょ。
iPhone 4は従来の3GSの320x480という解像度を縦横2倍に高めて640x960という解像度に
なったにょ。
今年登場した新型iPadは2048x1536というQuad XGA液晶を搭載して話題になったけどこれも
従来のiPad2のXGA液晶の解像度を縦横2倍に高めたものにょ。
こうすることで従来アプリとの高い互換性を得ることができ使い勝手も損ねることがなく
なるというメリットがあるだけではなく単に解像度を落としているわけではないために
アイコンや文字は高精細を保つことが可能になっているというメリットがあるにょ。
これがAndroidだと異なる解像度用のアプリだと高解像度の機種で使用した際には
液晶の一部だけに表示された状態になってしまうにょ。
もっともAndroidはマルチスケーリングに対応しているためアプリが対応していれば
問題ないのだけどそれは言い換えればアプリの対応がないとその高解像度の液晶は
生かすことができないということにょ。
そういう面ではiPhone、iPadはアップル社のみによる垂直統合のメリットを生かし画面
解像度を一気に縦横2倍に高めたのはAndroidと比べて有利に働いているにょ。（水平
分散型のAndroidだと各社の意向によって端末スペックを統一化するのは難しい）

Retinaディスプレイ搭載の新型MBPに話を戻すと上記だと「従来の解像度で使用して文字や
アイコンが高精細になる」ということだけがメリットになっているけどOS Xはマルチ
スケーリングに対応しているため当然のことながらWXGA+相当のDPI設定以外にも変更が
可能になっているにょ。
設定変更が可能な解像度は1024x640（WSVGA）、1280x800（WXGA）、1440x900（WXGA+、
デフォ）、1680x1050（WAXGA+）、1920x1200（WUXGA）の5種類となっているにょ。
デフォ設定よりも作業領域を広げたいという場合には1680x1050や1920x1200を選択すれば
良いということになるにょ。

さて、ここですでに気づいているかもしれないけど設定には2880x1800（Quad XGA+）と
いうものが存在していないにょ。
これはアップル社の英断だと思われるにょ。
普通に考えれば「液晶モニタでドットバイドット表示はできて当たり前」なのだけど
それができないことになっているからね。
では、なぜ液晶モニタではドットバイドットが当たり前なのかというと液晶モニタの
場合はCRTとは異なりドットがはっきり見えるからにょ。

「Retinaディスプレイ」の名称のその所以は「肉眼でドットが確認できない高精細」な
ものであるためにょ。
iPhone4では326ppiであり、一般的な人の目は30cm離れた場所における分解能はおよそ
300dpiであるためほぼ肉眼では見えないものになっているにょ。
この「30cmで300dpiという分解能」は私自身の実験データから言ってもだいたい合って
いるため問題ないにょ。
まぁ見えるか見えないかギリギリのラインだから人によっては30cmの距離でも見えると
いう人もいるだろうし、30cmではなく20cmまで近づけたら大抵の人は見えると思うので
「肉眼ではドットが見えにくい」というレベルであって「肉眼でドットが確認できない」
と言うのならば過剰表現に思えなくもないにょ。

仮に「300ppiを越えるものはRetinaディスプレイ」であると妥協したとしてもRetina
ディスプレイ搭載のMBPは220ppiとなっているにょ。
これを「Retinaディスプレイ」と呼んで本当に良いのか疑問に残るにょ。
確かに一般的にノートPCを使用する際には画面から50〜60cm離れるため200ppiを越えた
場合には肉眼ではほぼ見えなくなるとはいえ完全に見えないわけではないにょ。
実際私は264ppiという高精細液晶のVAIO UXを使っているけどドットが見えないと
感じたことはほとんどないからね。
手に持って使うVAIO UXとテーブルに置いて使う一般的なノートPCを同列に比較することは
できないものの220ppiでRetinaディスプレイと呼ぶのはやや過剰な気がするにょ。
あくまで「30cmで300dpiという分解能」はフルカラーにおけるものであるためモノクロ
2階調だとそれよりもずっと高いものになる（400〜500dpi程度）わけだからね。
したがって、個人的には220ppiというRetinaディスプレイ搭載MBPでドットが見えない
とは到底思えないにょ。

これが、もしも本当にドットが見えないレベル（最低でも300ppi以上、できれば
600ppi以上）というのならば液晶モニタにおけるドットバイドットには意味が無くなって
くるにょ。
上記のように「ドットがはっきり見える」からこそドットバイドットの重要性が高い
ものになってくるわけだからね。
そう考えるとドットバイドット（2880x1800）の設定ができないRetinaディスプレイ搭載
MBPは英断すぎると思われるにょ。
OS X上で設定できないのならばWindowsで使用するいう選択肢もあるにょ。
発売日に速攻で購入したライターが試したところWin8で2880x1800という超高解像度が
設定できるということが確認できた模様にょ。
http://weekly.ascii.jp/elem/000/000/093/93360/
まぁ15インチクラスならば実用的レベルはWUXGA程度と感じているためDPI設定を変え
ないと実用的に使えないかもしれないけどそれでも作業領域が少しでも広くなることに
恩恵が得られる人には良さそうにょ。

2880x1800という解像度が一人歩きをしているけどOS X上でその解像度が設定できない
以上はその解像度分の価値はないと言えるかもしれないにょ。
それでも高解像度でも文字が読みやすいというメリットがあるにょ。
それに、高解像度化の流れは良いことだし近い将来にはMBAにもRetinaディスプレイが
搭載されると予想しているのでそれが楽しみにょ。

1077：orirakkusu@3DS：2012/06/14(木) 07:54:53
マイクロ切り番踏んだよっ
0372212
理由:下2桁が自分の誕生日だからw

1078：御茶目菜子：2012/06/14(木) 21:41:49
レスにょ
orirakkusuさんへ
＞0372212
＞理由:下2桁が自分の誕生日だからw

おめでとうにょ！
といっても、キリ番コーナーはずいぶん前から更新停止しているけど（笑）

1079：orirakkusu@3DS：2012/06/15(金) 11:52:10
久しぶりに
自分のブログにログインしてみたら、
プチコン　講座
でググってくる人が多くてえっ？
て思ったのでトップにでものってるのかと思いきや、検索。
Top　プチコン講座(おちゃめさんのページ)
2.公式
.
.
.

1p目の一番下に自分のブログが来てたw

1080：みっぴゅ：2012/06/15(金) 20:21:33
今日は18日…じゃぁなかった。。。
今朝、ポケコンジャーナルの夢を見てしまったがために、今日は何度も18日と間違えそうになってしまいました。
いまだに18日は特別な日になっているようです。。。

ていうか、、、スマホに機種変してから、2chのポケコンスレに書き込めなくなってしまって、現在実質ポケコンのお話しができる場所がそこだけですから…淋しいです。。。

一日でも早くお茶目さんがポケコンの世界に戻ってくることを心待ちにしております (´Д｀)??????????????????????
1081：御茶目菜子：2012/06/15(金) 21:13:28
レスにょ
orirakkusuさんへ
＞1p目の一番下に自分のブログが来てたw

おめでとうにょ。
それにしても、私のサイトが公式を越えてついにトップとは・・・。
次は「プチコン」でぐぐってトップを狙えるように頑張るとするにょ（無理だって）


みっぴゅさんへ
＞いまだに18日は特別な日になっているようです。。。

私の所では2日遅れだからPJ＝20日発売のイメージにょ（笑）
しかし、PJは投稿してから掲載までのサイクルが不安定だけど早いときには私が最新号を
買ってそれについてレスをしたらその次の号にそれが掲載された（月末投稿したものが翌月
18日発売号に掲載）こともあるにょ。
いったいどんなスケジュールで作っていたのか気になっていたにょ（笑）

＞ていうか、、、スマホに機種変してから、2chのポケコンスレに書き込めなくなってしまって、現在実質ポケコンのお話しができる場所がそこだけですから…淋しいです。。。

ここで話題を振ってもいいし、twitterのアカウントをお持ちならば私にリプライを送って
くれたらいつでも会話はできるにょ。
http://twitter.com/ochame_nako

＞一日でも早くお茶目さんがポケコンの世界に戻ってくることを心待ちにしております (´Д

まぁ卒業したわけではなく一時休学みたいな感じなのでいつか必ずまたポケコンを手に入れて
復活するにょ。

1082：orirakkusu@3DS：2012/06/17(日) 14:58:07
(無題)
おうちゃくもののりすと
FOR I=0 TO 19
.
.
.

BGPAGE I/19:CHRSET ...
NEXT

1083：御茶目菜子：2012/06/17(日) 23:17:41
レスにょ
orirakkusuさんへ
＞おうちゃくもののりすと
＞FOR I=0 TO 19
＞.
＞.
＞.
＞
＞BGPAGE I/19:CHRSET ...
＞NEXT

私には普通のプログラムに見えてしまうにょ（笑）

1084：御茶目菜子：2012/06/17(日) 23:19:32
プチコンオリンピック　第3弾
プチコンオリンピック第3弾「プチコンクレー射撃」を作ったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/petit_olympic.htm#clay
http://www.youtube.com/watch?v=OH4eoP9hWA4

100m走、ハンマー投げときてクレー射撃というのは何ら関連性もないけど元々そんなものは
考えておらず思いついたものを作っているだけなので問題ないにょ（笑）

さて、このクレー射撃においてはmkIIではGM音源相当の音色が鳴らせるようになったことが
非常に大きいにょ。
127番のgunshotがあれば銃で撃つタイプのゲームを作った時に雰囲気が出るからね。
このGM音源だけどこれはBGMPLAY命令用に追加されたわけではなくBEEP命令でもその音が
出せるようになっているにょ。
つまり、BEEP 197がGunshotというわけにょ。
もしも、BGMPLAYでないと出せないというのならばリストが長くなってしまい、1画面には
収まらなかったにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/p003.htm#beep

ゲームそのものはプチコンでよく作られているガンシューティングゲームと同じくタッチ
パネルをポインティングデバイス代わりにしているため作るのもプレイするのも非常に
簡単になっているにょ。
これがDSの液晶画面が2つではなく1つであればただのモグラたたき系のゲームになって
しまうのだけど画面が2つあることが、「照準を意図通りに動かす」というスキルが必要に
なっているため反射神経だけではなく「画面を見ながら素早く正確に動かす」という
必要が出てくるので「照準をつけて狙う」という雰囲気も出せるようになるにょ。

1画面に収めるためいつものようにスプライトはデフォキャラを使いそれぽっく見せている
だけにょ。
弾倉のキャラなんてものは当然ないためスプライト番号170のキャラのパレット15番を
弾倉に見せかけているだけにょ。
照準やクレーはそのままでもそれっぽいキャラがあったので非常に楽だったにょ。
リスト短縮も前回のハンマー投げと比べると遙かにスムーズにいったため非常に楽に完成
させることができたにょ。

少し悩んだのは当たり判定の大きさとバランスくらいにょ。
当たり判定については1画面プログラムにおいてはプチコンmkIIで新たに導入された
スプライト同士の衝突判定を行う命令SPHITを使うとリストが長くなるため私は使用しない
ことにしているのでいつものごとくそれに適したものを使っているにょ。
直線、矩形、円のどれかなんだけど今回はクレーの形状からどう見ても円が妥当という
ことで円の当たり判定の式を使っているにょ。
まぁ中心からのX座標の差の2乗とY座標の差の2乗を足したものの平方根と当たり判定の
大きさとの差をとるだけという非常に簡単なものだけどね。
このゲームはクレーがどんどん小さくなっている関係上当たり判定も変えていく必要が
あるにょ。

ここで問題なのはクレーの大きさが1ドットならば当たり判定も1ドットにすべきか否か
ということにょ。
「自分のミス判定は小さく」「自分の攻撃判定は大きく」というのが基本と考えている
ために当たり判定は見た目より大きくすることにしたにょ。
どのくらい大きくするかだけど当たり判定で距離の2乗の平方根をとるというところを
平方根をとらずにそのままクレーのサイズ（ドット数ではなく16ドットを100とした
拡大率の数値）で比較することで小さいクレーの当たり判定を大きくすると同時にリスト
短縮も行えるため一石二鳥となっているにょ。
例えばかなり遠ざかり見た目の半径が1ドットのクレーの場合はスプライトの拡大率は
12.5となるけどこの場合は√12.5≒3.5であるため3.5ドット分の当たり判定があると
いうことにょ。
これによってすぐに反応できない人であっても比較的容易に遠ざかるクレーを撃ち落とす
ことが可能になっているにょ。

このゲームは上記の当たり判定の大きさやクレーの動きがパターン化されているなどの
要因によってクレーの動きさえつかめれば満点、もしくはそれに近い点数を出すのは容易と
なっているにょ。
だから、最初にちょうどいいと思った難易度ではなくクレーのサイズを小さくすることで
難易度を高めることも考えたけど初プレイやこういったゲームが苦手な人だとあまり撃ち
落とせず「当たり判定の大きさもよく分からない」という状況に陥るだろうと予想した
ためデフォのサイズは大きめ（当初の想定通り）にしたにょ。
自分でゲームを作る場合はそのゲームに慣れてしまい適切な難易度を見失いがちなので
テストプレイもできることならば第三者に意見をもらうことが重要となるけどそれが
できない場合は当初に感じた自分（まだそのゲームに慣れてない自分）のイメージは
非常に有用といえるにょ。
http://ww5.tiki.ne.jp/~ochame/E500/LECTURE/making_5.htm

そして、慣れて簡単に感じたら小さくすればいいということで改造点においてはそれを
記述することにしたにょ。
これが100m走の場合はボタン連射ですべてが決まるため改造のしようがない（加速を早く
してもそれによってタイムそのものが良くなるけどゲームのコツをつかめるようになって
上達に繋がるわけではないため無意味）ので連射が苦手という人には諦めてもらうしか
ないにょ。

次の第4弾は何にするかは決まってないもののまたフィーリングで競技を選ぶことにする
のでお楽しみにょ。
今回も冒頭で描いたようにフィーリングで競技を決定しており最初から「クレー射撃を
作ろう」と考えていたわけではなくてmkIIで搭載されたGM音源相当の音色がBEEPで使える
ため「BEEP 197でGunshotの音が出る」というのが制作の発端になっているにょ。
私の場合は「この命令を使ってみよう」「こういう操作のゲームがあったら面白そう」
などによってゲームを作ることが多いため今回は特別なものではなくいつも通りといっても
過言ではないにょ（笑）
といっても、1画面で作れるとなるとよほどシンプルにできない限りは競技自体は限られて
しまうけど・・・。

1085：御茶目菜子：2012/06/19(火) 21:55:54
プチコンでリソースを使う是非
昨日twitter上でプチコンのリソースについて盛り上がったにょ。
プチコン開発元のスマイルブーム社長の小林氏も加わりリソースを使用する意味について
みんなで語り合ったにょ。（ハッシュタグ #petitcom で検索すればそのログが読める）
プチコンではプログラム本体（PRG）とは別にさまざまなデータをリソースファイルとして
管理可能になっているにょ。

　PRGリソース・・・プログラム本体
　CHRリソース・・・スプライトキャラ（SPU）、BGキャラ（BGU）、コンソールキャラ（BGF）
　SCRリソース・・・BGスクリーン
　GRPリソース・・・グラフィック（GRP）
　COLリソース・・・カラーパレット
　MEMリソース・・・メモリ（MEM$に保存されているデータ）

　初代プチコンにおいてはネット上で不特定多数に公開する手段が用意されていなかったにょ。
確かにプチコンが入っている2台のDS本体を持ち寄れば上記のリソースファイルの受け渡しが
すべて可能であり全く問題は無かったのだけど直接受け渡しができない他人に実行してもらう
ためにはプログラムリスト（PRG）をテキストファイルとして書き下ろすか、編集画面を
写真撮影してそれを繋ぎ合わせて公開するという手段しかなかったにょ。
当然ながらその場合はPRGのみで動作するプログラムならば問題ないけど他のリソースが
必要な場合は、そのキャラやグラフィックを写真に撮って「これと同じものを自分で用意
してください」と言うしか方法は無かったにょ。

これがmkIIによってQRコード経由で公開できるようになって事態は一転したにょ。
自分でプログラムリストを手入力する必要が無くなったというだけではなく従来は不特定
多数に公開が不可能だった他のリソースファイルもQRコード経由で公開できるようになった
からね。
そのためmkIIが発売されてからはリソースファイルを使う人はかなり増えたのではないかと
思われるにょ。
ただし、QRコードはリソースごとに分かれていたら読み込むのが面倒とか、フォルダ管理が
できないプチコンではあまりファイル数を増やすと管理が大変になるとかいう問題も発生
してしまうにょ。
しかし、それもパッケージ化によって解決されているにょ。
パッケージ化されたプログラムは必要なリソースを読み込んだ状態で保存されているため
QRコードはそのプログラムだけで済むし、管理も1ファイルで済むにょ。
そして、そのプログラムをLOADする場合も必要なリソースファイルをプログラム内で別途
LOADする必要もないにょ。（ただし、パッケージ化されたプログラムはLOAD時にリソース
ファイルが自動読み込みされるためキャラの初期化などを行った場合には再度その
プログラムをLOADしなおす必要がある）

　◎リソースを使うメリット
　　(1)データのメインテナンス性が高い
　　(2)データの再利用が容易
　　(3)QRコードの枚数を減らせる

(1)プログラム本体でキャラデータを扱う場合には下記のようにDATA文の羅列によって表記
する必要があるにょ。

　DATA "0000F000"
　DATA "000FFF00"
　DATA "00FFFFF0"
　DATA "0FFFFFFF"
　DATA "000FF000"
　DATA "000FF000"
　DATA "000FF000"

このようにDATA文の羅列で表記する場合には少しでもメインテナンス性を高めようとする
ならば非圧縮になってしまうのだけどそれだとデータ数が増えた場合にはデータ量も行数も
非常に多くなってしまうにょ。
データ圧縮をすることでデータ量や行数は軽減できるもののその場合はメインテナンス性が
大幅に低下してしまうにょ。
そのデータはそれで完成だから弄らないというのならばそれでもいいのだけどそうでない
場合は厄介にょ。

またデータを変更する場合には、上記のメインテナンス性を高めた非圧縮のデータであっても
別途CHREDなどのエディタを使って編集する場合にはリソースデータをDATA文の形式に書き出す
という必要性が出てくるにょ。
したがって、メインテナンス性の面で見るとリソースデータをそのまま活用した方が遙かに
有利なのは言うまでもないことにょ。

(2)初代プチコンではDATA文で羅列されたデータを再利用する方法は無かったにょ。
そのため、そのデータを利用するためにはそのプログラムリストを元にDATA文を手入力する
必要があったにょ。
しかし、mkIIではAPPEND命令の追加によってそれは変わったにょ。
データごとに別のPRGファイルを用意すればそれをAPPENDして繋ぎ合わせるだけで再利用が
可能になったからね。

ただし、再利用性を高める場合にはDATA文によるデータは非圧縮であることが求められて
くるにょ。
データを圧縮した場合は同じ圧縮、展開ルーチンを使う必要があるにょ。
そうでないとデータごとに圧縮、展開ルーチンを別途用意する必要があるため圧縮する意味が
薄れてしまうからね。
自分しか使わないデータならば最初に考えた圧縮展開ルーチンを使い続ければいいだけの
話だけど他人にデータを使ってもらう場合には共通の圧縮展開ルーチンを求めるのも難しい
ために非圧縮である必要性があるにょ。

またプチコンの編集機能が今時のエディタと比べると大幅に貧弱であり、削除は1文字もしくは
1行ごとしか行えないのに加えて行単位での挿入もコピー＆ペーストで1行単位で行うしかない
ためにAPPEND命令を使用した場合には基本的にデータを順番に追加しかできないにょ。
そういう面を考えるとAPPEND命令によってPRGでのデータの再利用が可能になったとはいえ
再利用するならばファイルをそのまま読み込むだけのリソースと比べたら完全に劣っていると
思われるにょ。
もっともリソースファイルの最小単位はCHRリソースの場合は256キャラ分となっており
SPUならば1バンク単位となっているため再利用を前提として考えるならば1つのバンクに
利用したいキャラが集結していることが求められてくるにょ。
もっともエディタを使えばコピー＆ペーストによってその都度1つのバンクに集結させれば
済むとはいえそれなりの手間がかかってしまうため、「リソースファイルだから再利用性が
高い」という単純なものではないではないということにょ。（あくまでPRGと比べてたら
再利用性が高くなる場合が多いというだけ）

(3)上記のようにリソースを使わずDATAで表記した場合には1ドットが8bit（1バイト）の
GRPデータではどうなるかを考えてみるにょ。
プチコンでは制御文字がない（実質改行マークとタブのみ）であるため256文字のほとんどが
プログラム内で使用可能となっており、それを生かして256進数で表記してみるにょ。
その場合はプチコンの1行の最大が100文字であるためDATA文1つに付き64バイトのデータを
並べるとすれば1行当たり71バイトとなるにょ。
これで256x192ドット分、49152バイトのGRPデータをDATA文で表記した場合には54528バイト
となるためDATA文で表記した場合は256進数であっても4KB分多くなってしまうにょ。
ただし、これはGRPをフルに使ったデータである場合に限られるにょ。
RPGなどで大量のデータが必要であってもそれがフルに使用しているとは限らないのだけど
全体の9割未満の消費であればDATA文での表記の方が短くなるためリソースファイルの
方が短くなるとはいえないにょ。
何せリソースファイルを用いた場合には例え1KB分しか使用していなくてもGRPは1つで
49152バイト（プチコン内部に保存する場合はヘッダ込みで49164バイト）の記録領域が
必要になってくるからね。
したがって、「記録領域を少しでも減らしたい」という場合はリソースを使うよりも
使わない場合の方が有利になると思われるにょ。（もちろん非圧縮だとDATA文を使用した
場合にはデータ量が多くなるため256進数を使用するなどのデータ圧縮の方法を講じた
場合に限る）

しかし、これはQRコードにおいてはまた別にょ。
というのもQRコードの場合はzip圧縮がかかるからにょ。
これはLZ77符号化ととハフマン符号化アルゴリズムを組み合わせて圧縮しているのだけど
ハフマン符号化においては出現頻度の高いデータを短いbitを割り当てることで圧縮を
行っているにょ。
これがGRPによる1枚絵ならば使用している色に偏りがあるためハフマン符号化が有効に
働いているにょ。（均等に256色使われている場合にはほとんど効果がないためランダムで
描かれたドットを保存する場合にはあまり圧縮は期待できない）
またパターン化している部分があればLZ77のスライド辞書によって圧縮が可能になるため
特定パターンを繰り返して塗られているような絵ならば高い圧縮が期待できるにょ。
SPUのようなドット絵だとパターン化はそれほどないとはいえ、パレットが16色であるため
高い圧縮率となっているにょ。

これならばPRGにDATA文で表記しても高い圧縮率が期待できそうだけど実際はプログラム
内で使用されている文字とDATAで使用されている文字を合わせて頻度やパターンを考慮
して圧縮が行われているためDATAで出現頻度が高くてもプログラム内全体でそこまで
高い文字でなければ短いbitは割り当てられずハフマン符号化による高い圧縮効果は
期待できないにょ。
これは256色のBMP画像をzip圧縮した場合にはグラフィックならば1/2〜1/10の極めて高い
圧縮が期待できるけどテキストの場合はせいぜい1/2程度の圧縮しかできないのを見れば
一目瞭然だと思われるにょ。
出現頻度やパターンが異なるため圧縮するファイルは別々に用意した方が圧縮率が高く
なるということでプチコンにおいてはプログラム本体（PRG）とは別にリソースを用意
もしくはパッケージ化を行った方がより多くの圧縮が期待できるためQRコードの枚数の
削減に繋がるというわけにょ。
1枚絵より圧縮が効きにくいフォントデータにおいてもプチコンまとめwikiに投稿されている
美咲フォントはGRP版でQRコード30枚となっているけれどこれのプログラムリスト版を
PetitEditorを用いてQRコード化した場合には65枚になっており、リソースを別途用意する
方が少ないQRコードになるという意味がはっきり分かると思われるにょ。
http://wiki.hosiken.jp/petc/?Toukou%2F%B4%C1%BB%FA%A5%C7%A1%BC%A5%BF

プチコンで使っているQRコードは97x97のサイズであり、誤り訂正が最大の場合は1枚に
600バイト程度のデータが記録可能になっているにょ。
もちろん、これは上記のように圧縮後のデータであり、1/10に圧縮ができるならば1バンク
8192バイト（プチコン内部記録時で8204バイト）のCHRリソースでもQRコード1枚になる
可能性があるというわけにょ。
しかし、PRGの場合は圧縮率はせいぜい1/2程度であるため6KBのプログラムならばQRコードは
5枚前後になるにょ。
これがリスト短縮を行って6KBのプログラムを5KBに減らした場合にはzip圧縮による圧縮率も
低下してしまうのでQRコードの枚数はほとんど変わらない（5枚前後）になってしまうにょ。
私の経験ではリスト短縮をフルに行った場合にはQRコード1枚あたり800バイト程度しか
入らないためzip圧縮の効果はほとんどないものといえるにょ。（つまり、リスト短縮を行い
リストは短くなってもQRコードの枚数は減らない）


では、次にリソースを使わないメリットにはどのようなものがあるのかを考えてみることに
するにょ。

　◎リソースを使わないメリット
　　(1)使う必要がない
　　(2)PRGだけで完結できる

(1)80年代にBASICでのプログラミングを行っていてしばらくプログラミングから遠ざかり
プチコンによって再びプログラミングを始めたという人にとってはリソースは謎の存在
かもしれないにょ。
実際は上記のように単にそれぞれのデータを別ファイルとして管理されているというだけの
話なので難しいことは何もないにょ。
とはいえ、それを使うか使わないかはそれを生かせる使い方をするか否かというのも重要に
なってからね。
別途リソースファイルを使わなくてもプチコンはデフォで様々なデータが内蔵されているし
自前のキャラが必要な場合でもその時だけDATA文でキャラ定義をすれば済む話だしね。
したがって、リソースを使わない人の多くは「リソースと使う必要性に迫られていない」
「リソースファイルを使わなくても特に困っていない」というのが理由だと思われるにょ。

(2)は(1)と似ているようだけど根本的に(1)が消去法でリソースを使わない選択をしたのに
対してリソースを使わないという選択を積極的に行っているということにょ。
これは人によっては「謎のこだわり」と感じられる部分かもしれないにょ。
それはPRGで完結させるというのは初代プチコンならば上記のように不特定多数に向けて公開
するためには必要不可欠といっても良かったけどmkIIではQRコード経由の公開が可能になった
ためにPRGで完結させる必要性が無くなったためにょ。

それではなぜPRGで完結するような選択肢をとっているのかというとやはり古くからBASICで
プログラミングをしている人にとってはそれが馴染みが深いためにょ。
80年代はベーマガ、I/O、Pio、プログラムポシェット、ポプコム、The BASICなど読者からの
投稿プログラムを募集している雑誌がたくさんあったにょ。
そんな中でポケコンも専門誌「ポケコンジャーナル」が88年に創刊されたにょ。
当時は雑誌掲載のプログラムリストを手入力を行うというのが普通だったにょ。
中には工学社のように雑誌掲載のプログラムをカセットテープやFDに入れたものを販売する
という方法をとっているものもあり、手間をかけて雑誌のリストを手入力するか手間を
惜しんでお金で解決するかという二択があったにょ。

最近（というかWindows普及後）だったらCD-ROMやDVD-ROMにフリーウェアを詰め込んだ雑誌は
多数存在するけど当時はそれができなかった理由としては記録媒体の価格が高価であった
ことと記録媒体が統一化されてなかったことが挙げられるにょ。
80年代初頭だとまずFDDは高値だった（外付けFDDが10〜20万円していた）上に記録媒体である
FDそのものの価格も高価であったために雑誌の付録にFDを付けるなんてことはまず現実的な
選択としてはあり得なかったにょ。
FDDが一般的なパソコンに内蔵されるようになった80年代半ばにはある程度価格が下がったとは
いえ記録媒体は5インチに加えて3.5インチが登場したし、記録面も片面、両面があるだけでは
なく記録密度も標準、倍密度、高密度と様々だったからね。
当然のことながらFDDを搭載していない機種（オプションの機種）も多かったためそういう
機種においてはカセットテープに記録していたにょ。
ならば、複数のメディアを雑誌に付ければ良いと考えるかもしれないけど空のメディアでも
1枚数100円もするようなメディア（2〜3年前のBD-Rレベルの価格）のものを複数付録で付ける
というのはかなり難しい問題だったにょ。（というか、雑誌の付録の規制緩和が行われた
のは2001年であり、それまでは材質などの規制があった）
したがって、80年代半ばだとPioのようにソノシートを付けるのが精一杯だったにょ。
これが90年代に入ると国内ではPC-98が圧倒的なシェアとなり記録媒体も5インチから3.5インチ
への移行が進んできたために雑誌の付録もPC-98用のフリーウェアを入れたFDを付けたものが
増えてきたけれどこれはBASICの話とは離れていくので割愛するにょ。

90年代になり、8ビットパソコンは市場からほとんど姿を消した後でもベーマガなどの雑誌では
BASICによるプログラム投稿が盛んに行われていたにょ。
これは根強いユーザーがいるというのも理由だけど基本的に旧世代のBASICはプログラムリスト
の形で完結しているため雑誌掲載がしやすいためだと思われるにょ。
93年のWin3.1、95年のWin95の発売によってWindowsが急速に普及しはじめたけどそのためVB
などのGUIによるプログラミング環境が増えることになったにょ。
そうすると雑誌の紙面では完結できないという問題点が浮上することになるにょ。
Win95以降のCD-ROM搭載率の大幅な増加とCD-ROMのプレスコストの低下によって2000年代に
入ってからはCD-ROMを雑誌に搭載することが容易になってきたけどそうなったときには
ベーマガのように読者投稿プログラムを集めた雑誌とTECH WINのようにユーザーの投稿
ソフトを集めた雑誌の差別化が難しくなってきたにょ。

ベーマガの最大の特徴としては多くの投稿プログラムを掲載しているという点ではないかと
思われるにょ。
80年代は○○機種××本掲載というようにそれを煽り文句にしていたくらいだからね。
それも90年代から徐々に減っていき上記のようにWindows普及後はGUIによるプログラミング
環境が普及したために「超大作プログラム」と称してプログラムリストが誌面に掲載されない
ものが増えてきたにょ。（当初はCD-ROMの付録は無かったのでWebサイトにて公開）
これは誌面だけでは完結できないためやむを得ないとはいえこれによってプログラムリスト
公開の雑誌の限界が見え始めたにょ。
ということで、ベーマガ休刊の最大の理由は一世風靡した旧世代BASICの衰退にあると
思われるにょ。
したがって、もしも旧世代BASICが栄えており高い需要があれば未だにベーマガは健在
だったと確信しているにょ。（あり得ない仮定を持ち出しても仕方ないけど）

以上の流れを踏まえて考えるとやはり旧世代BASICを名乗るならばプログラムリストの
形で完結することが必要不可欠だと思われるにょ。（確かに旧世代BASICの中には別途
スプライトデータが必要なリストも掲載されていたけどそれは一部の例外に止まった）
だから個人的には「プログラムリストで完結する」というのは非常に大きな意味を持つ
ことになるにょ。
しかし、これは現行のプログラミング言語を否定するようなものではなく古き良き文化の
維持という感じのものだと受け止めて欲しいにょ。

確かにグラフィックを使いまくったプログラムを作るならば上記のようにリソースには
メインテナンス性と再利用に優れているというメリットがあるためプログラム単体で
完結するように作るよりも遙かに楽だけど個人的にはそこまで使いまくったものは
作らないし、いかに短いリスト（小さいファイルサイズ）で面白いものを作るかという
ことを考えているため必要性に迫られない限りはデフォキャラをいかに使うかということを
考えてしまうので結果的にリソースを使う機会もほとんどないことになるにょ。（まぁ
セーブデータ用でMEMリソースを使うくらいか）
小さいリストサイズ（ファイルサイズ）に拘っているのは面白さを天秤に掛けた場合に長い
リストだから面白くできるというわけではないからにょ。
その長いリストや大きなファイルサイズに似合った面白さが用意できるならば別だけど
私の場合はそれが難しいので自分に向いている選択肢をとっているというだけのことにょ。
この辺の融通が利くのが趣味によるプログラムの醍醐味といえるにょ。

1086：御茶目菜子：2012/06/20(水) 22:23:58
DVDのリッピングがついに違法に！
本日改正著作権法が成立したにょ。
http://internet.watch.impress.co.jp/docs/news/20120620_541251.html
3年前の改正では著作権者の認可のない違法ファイルのダウンロード（以下「違法
ダウンロード」と略）が違法となったのだけど今回の改正の主な改正ポイントとなって
いるのは以下の2つにょ。

　(1) 違法ダウンロードの刑事罰化
　(2) DVDリッピングの違法化

(1)3年前に成立し、一昨年の1月1日より施行されている違法ダウンロードにおいては
あくまで「違法」扱いというだけであって処罰対象にはなっていないにょ。
それが今回の改正で懲役2年以下、罰金200万円以下の刑事罰対象となっているにょ。
元々著作権者に無断でアップロードする行為そのものが違法であり、きちんと取り締まって
いればそれで問題ないのだけど取り締まる方にも限界があるし、ユーザーにおいてはそれが
「違法行為である」と認知しているか否かの差は非常に大きいためこのダウンロードの
違法化はやむを得ないと私も感じていたにょ。

ただし、これが刑事罰対象になるとなれば話は別にょ。
「ダウンロード」なのでストリーミングは対象外になっているのだけどYouTubeやニコニコ
動画のように一時ファイルとして保存して再生するものは「プログレッシブダウンロード」
と呼ばれており厳密にいえばストリーミング再生とは異なるものにょ。
一時ファイルをダウンロード扱いにするか否かという点においては条文からでは判断できず
弁護士の間でも意見が分かれているにょ。
言い変えれば「YouTubeやニコニコ動画で違法ファイルを視聴すれば、今回の改正によって
刑事罰対象の可能性がある」ということにょ。
では、「違法ファイルをを視聴しなければいい」となるのだけど現実問題からいってそれは
「動画共有サイトを利用しない」というのとほぼ等しいにょ。
というのも、どの動画が著作権者に認可されているのか分からないわけだからね。
「許可を得ています」と書かれていてもそれが正しい保証は何もないにょ。

YouTubeやニコニコ動画はJASRACと包括契約を結んでいるためJASRAC管理曲をBGMとして
使い「歌ってみた」や「踊ってみた」として投稿することは問題ないにょ。
ただし、この場合でもCDなどの原曲を使うのは著作権法違反であり、あくまで耳コピした
楽譜を元に生演奏やMIDIなどで演奏したものを使う必要があるにょ。
この条件を満たしていれば視聴する側も問題ないのだけどもしもアップロード者がCDから
リッピングした音源を利用していたり、JASRAC管理曲以外（ただし、アップロード者の
自作曲を除く）を使用している場合はこの限りではないにょ。
つまり、安全なものは音楽のない映像に限るにょ。
ただし、映像部分もアップロード者に著作権があるかどうかは分からないにょ。
したがって、「閲覧する側」にとっては「どれが違法でどれが合法か分からない」というのは
理解できるのではないかと思われるにょ。

適法サイトマークとかを作ってそのサイトの動画ならば100％安心というのがあればユーザーも
そのサイトを利用する限りは問題ないのだろうけど実際はそんなマークを付けても個人が投稿
可能な動画サイトの場合はサイトの管理者がすべてをチェックするのは不可能にょ。
それが合法か違法かというのは著作権者でない限りは判断ができないわけだからね。
それに適法サイトマークが本当に正規の適法サイトマークかどうか（正規認可されているか
どうか）というのもユーザーからは分からないにょ。
つまり、疑い出したらきりがないということにょ。
（疑いだしたらきりがないから）開き直って視聴するか、視聴しないかという二択になって
しまうにょ。
まぁネット上で動画や音楽を見ない（それが張ってあるページのリンクも踏まない）ように
すれば100％安心できるけどそれはPCでネットを利用するなというのに等しいにょ（笑）

刑事罰化で問題となるのは恣意的な逮捕が可能になるということにょ。
上記のように普通にネットを利用しているユーザーならば誰もが違法行為をしている可能性が
あるわけだからこれは脅威となるのはやむを得ないにょ。
これに関しては現時点ではそれほどおびえる心配はないにょ。
というのも、あくまで親告罪となっているからにょ。
とはいえ何らかの理由で家宅捜索を食らうことになった場合には別件逮捕として利用されて
しまうため安心はできないにょ。
自分に何の罪が無くても誰かのとばっちりで家宅捜索の対象になってしまうこともあるため
その時になってようやくこれが大きな問題に気づくことになるにょ。
まぁそういう可能性はほぼないから大丈夫と思っていてもいつまで親告罪の状態が続くかは
分からないにょ。
前回の著作権法改正時に次は違法ダウンロード刑事罰導入を予想していた人が多かったけど
実際にそうなったからね。
海外では著作権法違反の非親告罪化を導入している国もありもしも日本がTPPに参加したならば
非親告罪化を懸念している人も大勢いるにょ。
もしも、非親告罪化となってしまった場合には本当に誰しも逮捕される危険性があるという
ことにょ。
それは自分には関係ないかもしれないと思ってもたまたま見た1回の動画によって人生を
狂わせることになるという可能性はゼロではないにょ。

違法ダウンロードが音楽業界に大きなダメージを与えたのは確かだけどそれがどの程度なのか
というのは実際のところ誰にも分からないにょ。
というのも、実際は違法アップロードが無ければ「CDを買う」もしくは「正規ダウンロードを
行う」という人はごく限られるからにょ。
違法ダウンロードする人の大半は「最初から買うつもりはない」もしくは「正規品が入手
できなかった」というのが理由だと思われるからにょ。
3年前の著作権法改正で「違法ファイルのダウンロードが違法化」されてもなお今でも
違法ダウンロードを使用している人たちが刑事罰対象になったらダウンロードを控えるかも
しれないけどほとんど購買には繋がらないと思うにょ。
つまり、刑事罰対象になって変わるのは「違法ダウンロードが減る」というだけにょ。
プラスになることは何もないにょ。（ダウンロード販売が少しは増えるかもしれないけど
ダウンロードに対する萎縮のマイナス影響を考えると相殺されそうな感じ）
音楽業界の低迷が「違法ダウンロード」を理由にできなくなってしまうだろうけけどこれを
プラスと考える人がいるとしたらどのような業界の人なのやら・・・。

(2)今回の著作権法改正で違法ダウンロードの刑事罰化と同じくらい問題視されているのが
DVDのリッピング行為の違法化にょ。
これはあくまで一例であり、実際はアクセスコントロールを回避してコピーする行為が違法
となっているにょ。
この辺をもう少し詳しく書くと著作権法第30条においては私的複製（個人または家庭内などの
限られた範囲内での複製行為）は認められているのだけどその場合でも例外として第二項に
おいて「技術的保護手段の回避（技術的保護手段に用いられている信号の除去又は改変
（記録又は送信の方式の変換に伴う技術的な制約による除去又は改変を除く。）を行うこと
により、当該技術的保護手段によつて防止される行為を可能とし、又は当該技術的保護手段に
よつて抑止される行為の結果に障害を生じないようにすることをいう。」と記されているにょ。
簡単に言うと「コピーガードがかかっているものをはずしてコピーしては駄目」という
ことにょ。

ここで、DVDのリッピングに話を戻すとDVDに使われているCSSは著作権保護手段の1つだけど
日本においては「アクセスコントロール」と見なされており上記の著作権法における
コピーガードとは異なるものになっているにょ。
アクセスコントロールは特定の機器、ユーザーのみが使用できるように制限しているもので
あり、著作権法におけるコピーガードは世代コントロールを目的としたものなので異なる
ものになっているというわけにょ。
従来はこのアクセスコントロールを回避する機器やソフトの販売行為は違法となっていたの
だけど今回は個人がそれを行うことも違法になったというわけにょ。

これは「レンタルDVDが駄目で買ってきたDVDならば大丈夫」なんてことはなく現在市販
されているDVDならばCSSによるアクセスコントロールはほぼすべてのものに行われている
ため自分が購入したDVDを自分が使用するのを目的でリッピングする場合であっても
今回の改正著作権法が施行された後は違法となっているにょ。
遡逆性はないため現在すでにリッピング済みのものにおいては施行後に違法扱いになる
ことはないにょ。
レンタルDVDならまだしも、個人が購入したDVDのリッピングが今まで合法であったのに
それが急に違法になるというのは解せないにょ。
リッピングには動画データの一元管理とバックアップの2面のメリットがあるからね。
「刑事罰対象ではないのだからやりたければやればいい」という人もいるかもしれない
けれど「違法である」と分かっていて行うなんて私にはなかなかできないにょ。

今回の改正は上記のようにアクセスコントロールを回避してコピー行うことが違法となって
いるため通常の音楽CDのリッピングにおいては今までと変わらず私的複製の範囲内で
あれば合法となっているにょ。
ただし、コピーコントロールCDにおいてはアクセスコントロールが導入されているため
それをコピーする行為は違法となるにょ。
DSにおけるマジコンもアクセスコントロールによる著作権保護の回避手段の1つと考え
られているためマジコンを使った吸い出し行為も違法となるにょ。


以上のように今回の著作権法改正は誰も得をしないマイナス面ばかりが目立つものと
なっているにょ。
「火事が起きても自分に火の粉が飛んでこない限りは無関係」という人が多いだろうから
実際に問題視している人は少ないだろうけど違法ダウンロードにおいては上記のように
誰しも行っている可能性があることだし、下手をするとそれを悪用した振り込め詐欺の
登場も十分に考えられるにょ。（刑事罰と振り込みの二択ならば振り込みを選ぶ人も
いるだろうし、警察に相談もできないため振り込まざるを得なくなってしまう）
変な規制が新しい犯罪を生むというわけにょ。
DVDのリッピングも規制を行ったところで違法アップロードする人が減るわけでもないし
いままで合法として楽しんでいた人たちの楽しみを奪うだけでしかないにょ。
特にバックアップ目的として利用していた人にとってはこれは致命的にょ。

1087：orirakkusu@3DS：2012/06/21(木) 18:24:45
(無題)
>PCでネットを使うな
Adobe Flash Playerをアンインストールすればぶつぶつ
しかもPS3でもm(gs

1088：わぁぃ@：2012/06/21(木) 20:19:22
(無題)
QRから取り込むのはダウンロードに該当するだろうか？

1089：御茶目菜子：2012/06/21(木) 21:54:32
レスにょ
orirakkusuさんへ
＞Adobe Flash Playerをアンインストールすればぶつぶつ
＞しかもPS3でもm(gs

現時点で対象となっているのは音楽と動画だけなのでそれが再生できないようなWebブラウザ
ならば問題ないにょ。
ページを開いたら音楽が鳴るようなサイトにおいてその音楽が著作権者に許可を得てない
場合はそのページを開いた瞬間著作権法違反になってしまうにょ。（あくまで厳密に考えた
場合であり「違法と知らずに再生した場合」は考慮されるためこれによって即著作権法違反と
して罪を問われるわけではないけど）
というわけでPCで100％の安全性を求めるならばテキストベースのWebブラウザを使用するしか
ないにょ（笑）


わぁぃ@さんへ
＞QRから取り込むのはダウンロードに該当するだろうか？

QRコード経由とはいえダウンロードには変わりないと思うにょ。
プチコンで違法動画の再生に使用するのは難しいけど音楽の方はやばいかも・・・。
QRコードによるMMLデータの公開は現時点においても著作権法違反だし、それは10月1日からは
そのQRコードを読み取った方も著作権法違反になってしまうにょ。（JASRACと包括契約を
しているYouTubeやニコ動などで動画のBGMとして用いるならば問題ない）
もっとも、親告罪であるため著作権者が訴えなければ罪に問われる心配はないけどね。

1090：御茶目菜子：2012/06/21(木) 23:20:56
違法ダウンロードの刑事罰化がプチコンに与える影響
昨日は著作権法が改正されDVDのリッピングが違法になったり、違法ダウンロードの刑事罰化
について詳しく書いていったにょ。
プチコンではQRコード経由しかファイルをやりとりできないもののそのファイルを内部に
保存する関係上「ダウンロード」として扱われると思われるにょ。
今回の改正で対象となっているのは動画と音楽のみとなっているけどプチコンでそういった
ファイルが再生できるのかをまず考える必要があるにょ。

まず、動画に関しては、プチコンでは動画再生機能はないもののGRPを連続表示した
アニメーションが可能になっているにょ。
しかし、「絵」に関しては今回の改正では変わってないのでダウンロードする側は特に
気にする必要はないにょ。
とはいえ、TVキャプチャしてPC上で変換したGRPを大量公開すればQRコードを公開する側が
著作権法違反に問われる可能性があるにょ。（引用ならば問題ないけどそれを越える場合は
気を付けなくてはならない）
二次創作であれば問題ないのでアニメを参考に自分で描けば著作権法違反で訴えられることは
ほぼ無くなると思われるにょ。
二次創作に関しては1月19日に詳しく書いているのでそれを参照して欲しいにょ。
http://6407.teacup.com/ochame/bbs/3063

さて、プチコンで問題になるとすれば音楽の方にょ。
プチコンmkIIではMMLに対応したためネット上でも自作MMLデータを公開する機会が増えている
もののMMLデータといはいえ音楽ファイルであるため著作権法違反に問われる可能性が極めて
高いにょ。
CDなどの生音源やそれをエンコードしたMP3においては原盤権があるため著作権法違反に
問われてもやむを得ないけどそれは2000年に大きく変わったにょ。
それはネット上でMIDIデータを公開する場合においても著作権料を支払わなくてもならなく
なってしまったからにょ。
著作権法違反は親告罪であるため著作権者が訴えを起こさなければ問題ないわけであって
MP3は問題であるとしてもMIDIデータは特に問題とは思えないと個人的には思うけどね。

そうなるとプチコンによって著作権者に無認可でMMLデータを公開するということは
違法ファイルのアップロードと変わりなくなってしまうにょ。
これが、YouTubeやニコ動のようにJASRACと包括契約をしている動画サイトにおける動画の
BGMなどで使用する場合であれば問題ないのだけどこの場合においても原盤権が著作権者に
あるためにCDから抜き出した音源を使用してはならないにょ。
ニコ動やYouTubeで動画として公開する場合はいいのだけどこれがそこを離れてファイル
単体（MMLデータのQRコード）を公開してしまえば上記のように問題となるにょ。

とはいうものの、著作権法違反は親告罪であるため違反をしたら刑罰が確定というわけでは
ないにょ。
これは、自動車を運転する場合に法定速度60km/hの道路を100km/hで走行しても捕まらない
こともあるし、65km/hで捕まることがあるということを考えれば分かると思うにょ。
つまり、運とさじ加減次第ということにょ。
とはいえ、運悪く罪に問われるのが嫌ならばそれを出来るだけ避けるのがベターにょ。
厄介なのは今回の改正でダウンロード側も刑罰対象となってしまったために著作権法違反が
問われてしまうようなファイルをダウンロードした側も刑罰（最大で懲役2年、罰金200万円）
対象になってしまうにょ。
要するに怪しいファイルを落とすな（QRコードを読み込むな）ということになるにょ。
まぁ現実問題からいってプチコンのQRコードを読み込んだだけで逮捕・・・なんてあり得ない
けれどその可能性がゼロではないというのが今回の著作権法の改正の問題点となるにょ。
「刑事罰化」というのはこういうことにょ。（一般的な著作権法違反のように民事訴訟ではなく
刑事訴訟となるため容易に告訴できるので著作権者に目を付けられたファイルをたまたま
ダウンロードしただけでアウトになる可能性がある）

1091：わぁぃ＠：2012/06/22(金) 13:43:19
(無題)
>>一般的な著作権法違反のように民事訴訟ではなく刑事訴訟となるため容易に告訴できる
社会の先生が「訴訟社会」の話をしたの思い出した。
日本もそーなったらどーしよどーしよ。

1092：orirakkusu@3DS：2012/06/22(金) 17:06:03
(無題)
耳コピならいいんだろか。

1093：御茶目菜子：2012/06/22(金) 23:49:03
レスにょ
わぁぃ＠さんへ
＞社会の先生が「訴訟社会」の話をしたの思い出した。
＞日本もそーなったらどーしよどーしよ。

米国では何かあったら真っ先に救急車よりも弁護士が先に駆けつけるレベルだからね。
まぁこれはものの例えとはいえ日本とは比べ物にならないくらいの訴訟が行われているにょ。
現在の著作権法違反は親告罪であるのと同時に民事であるために訴訟相手を自前で探す
必要があるし、賠償金額も算出しないといけないにょ。
これが警察が介入する刑事事件になればプロバイダ経由で本人を特定するのは容易だし
少額賠償もしやすくなるにょ。


orirakkusuさんへ
＞耳コピならいいんだろか。

耳コピでも不可にょ。
個人が非営利で合法的に音楽データを公開するためにはJASRACに10曲まで公開ならば
毎月1200円支払う必要があるにょ。
1曲単位ならば毎月150円必要にょ。
もちろん、これは音楽のデータ（MIDIやMMLファイルなど）だけであり、歌詞データ
などの料金は含まれておらず、原曲を使ったデータ配信は個人では不可となっているにょ。
10月以降は無許可で公開されているデータをダウンロードするだけで先日書いたように
刑事罰の対象となってしまうにょ。
まぁプチコンのMMLをダウンロードしただけで逮捕なんて確率的にはほぼゼロだろうけどね。

1094：御茶目菜子：2012/06/22(金) 23:50:05
ニンテンドー3DS LL発表
ニンテンドー3DS LLが発表されたにょ。
http://game.watch.impress.co.jp/docs/news/20120622_541924.html
E3前に日経にリーク情報が記載された際には断固として否定したけどこれは正式発表前
だったため「近日中に発表する」と言うわけにも行かずあのような否定行為を行ったの
だと思われるにょ。
否定はしたものの3DS LLはそのうち（秋〜年末辺り）出るとは思っていたけど予想以上に
早い発表だったにょ。

現行の3DSとの違いは何と言ってもサイズにょ。
DSiLLがDSiと比べて大きいということ以外に大きな違いがないようにこの3DS LLもサイズ
以外にはスペック面で大きな違いはないにょ。

　　　　折りたたみ時サイズ　重量　上画面　　　下画面　　　価格
　3DS　　　　74x134x21mm　　235g　3.53インチ　3.02インチ　15000円
　3DS LL　　 93x156x22mm　　336g　4.88インチ　4.18インチ　18900円
　　　　　　（注）3DS LLはACアダプタ同梱ではないためDSi/3DSを持ってない場合は
　　　　　　　　　別途購入しなくてはならない。

DSiLLが91.4x161x161mm、314gだからそれと比べると本体サイズはわずかに小柄になり重量は
少し重くなっている感じにょ。
画面サイズはというと現行のDSiLLは4.2インチなのでそれと比べると下画面はほぼ同じサイズ
となり上画面はそれを横長にしたものとなっているにょ。
画面サイズはほぼ同じサイズということはドット数の関係上DSiLLよりも高精細になっており
3.25インチのDSiの95ppiとほぼ同レベルの98ppiになっているにょ。
そのためDSiLLほど文字サイズは大きくはないもののDSi以上の見やすさは確保されているため
年配の方も安心に使えるにょ。

DSiLLは文字サイズが大きいというのもあるけどやはり大きいのは画面サイズが大きい分だけ
タッチ操作がしやすくなっているということにょ。
アイコンサイズが小さいソフトだと3DSでは結構シビアな操作が要求されるからね。
まぁタッチペンで慎重に操作すれば何の問題もないことだけど大きければ多少ラフな操作も
できるし、指を使ってタッチしても誤動作の可能性はかなり減るにょ。

やはり、大きいのはプチコンでの利用だと思うにょ。
プチコンで文字入力をする場合は速度を考えると指で入力したいところだけど指による入力
では3DSのサイズではミスタイプが非常に多くなってしまうにょ。
そのため3DSの価格引き下げ後もプチコン目的でDSiLLを購入する人は結構見られたにょ。
そういう人はこれからは3DS LLを買うといいかもしれないにょ。
もっとも、プチコンの場合はDSiウェアであるため3DSでプレイ時にはドットがぼやけてしまう
という問題があるけどね。
3DSではDS用ソフトをドットバイドットでプレイすることは可能だけどその場合はかなり
小さく表示されてしまうにょ。
3DS LLならばドットバイドットの表示時でもDSiと同レベルの画面サイズを確保可能となって
いるため3DSと比べるとその操作性は雲泥の差にょ。
私も予算に都合が付けば1台欲しいところにょ。

1095：orirakkusu@3DS：2012/06/23(土) 15:57:22
(無題)
WindowsってMicrosoft Windowsで登録ひょうしきだっけ？

1096：マイクソフト：2012/06/23(土) 21:56:51
(無題)
Microsoft Windowsは、米国Microsoft Corporationの米国およびその他の 国 における登録商標です。

1097：御茶目菜子：2012/06/23(土) 22:28:11
レスにょ
orirakkusuさんへ
＞WindowsってMicrosoft Windowsで登録ひょうしきだっけ？

「Microsoft」「Windows」で別々の登録商標となっているにょ。
そのためWindowsみたいなOSもどきのプログラムを作るならば「Windows」という名称は避けて
「Windous」などの適当に文字を変えた名称にした方が無難にょ。

1098：御茶目菜子：2012/06/23(土) 22:30:30
プチコン公式追加素材
6月19日にプチコンでリソースファイルを使うことについて書いたのだけどその翌日に
プチコンの制作元であるスマイルブームのプチコンmkII公式サイトにて「プレゼント素材」
なる追加リソースファイルが公開されたにょ。
http://smileboom.com/special/ptcm2/co_present/html_present01.php
議論があった翌日であるため1日で作った・・・というわけではなくあらかじめ用意していた
から前日の議論にスマイルブーム社長である小林氏（ノトホホ氏）がユーザーの議論に参加
したのかもしれないにょ。
リソースを「使う」「使わない」は別にしてこういったフリーで使える素材が用意される
ことによって「自分でデータを作れない」「自分で作るのは面倒」という人の選択肢が
増えることになるので喜ばしいことにょ。
それに、リソースの共用という面においてもメリットがあるしね。

さて、この追加素材は公式サイトの講座等ではおなじみの4人の面々であり、ハカセや
ワンパク君はベーマガのDr.Dと影さんをオマージュしたようなキャラとなっているにょ。
あとのインテリ君と神崎君はツッコミ役ということでバランスはとれているけどやはり
つぐみさん成分が足りないというのがやや難点かもしれないにょ（笑）
この追加素材は同ページのサンプルプログラムのようにコントを作るならば特に問題ないけど
ゲームで使用する場合はパターン数が少ないということで使いどころがなかなか難しいにょ。

せっかく、公式が用意してくれた素材だから活用しようということで早速それを使った
ゲームを作ってみたにょ。
といっても、新規作成ではなくて、すでに作ったゲームのデータを差し替えてプラスαした
だけのものだけどね。

まず、最初に作ったのは「ハカセ射撃」にょ。
http://twitpic.com/9ym2ck
これは「プチコンクレー射撃」のデータを差し替えたものとなっているにょ。
まぁクレーの代わりにハカセの顔を撃ち落とすというゲーム内容だけど元が1画面プログラム
ということもあり、必要最小限のものしか搭載されてなかったので「1画面」という縛りを
解くことで適当にいろいろ追加してみたにょ。
まずはTALK命令による音声にょ。
やっぱり、ゲームに音声が付くだけでも盛り上がり方が変わってくるからね。（もっとも
そのキャラに合わないようなセリフだとマイナス効果になる場合もあるけど）

そして、プチコンクレー射撃の問題点だった「デフォ状態では簡単すぎる」という問題に
関してはスコアを稼ぐごとにどんどん的を小さくすることで上手い人も簡単に感じさせない
ようにしてみたにょ。
あと、遠くの的（要するにより小さい的）を撃ち落とした方が高得点になっているのでスコア
アタックもプチコンクレー射撃と比べたら熱くなっていると思われるにょ。
といっても、わざわざここで言うようなたいしたものではないのだけど・・・。

そして、次に作ったのは「ハカセジャンプ」にょ。
http://twitpic.com/9zk3ak
このゲームはプチコン講座第7回で使用しているサンプルゲーム「JUMP ACTION GAME2」の
データを差し変えたものになっているにょ。
とはいえ、この「JUMP ACTION GAME2」は講座内で詳しく書いているようにゲームとしては
やや問題点もあるためそれを改善した内容になっているにょ。
具体的に言うと全く有効活用されていなかった「狭い隙間」の扱いが大きく変わったにょ。

このゲームでは狭い隙間は「JUMPING ISLAND」と同様にジャンプせずに渡ることができるため
BG画面とは異なり、キャラ単位ではなくドット単位でのマップ配置が容易にできるGRP面を使い
GCOPYを使用してスクロールさせているのだけど「JUMP ACTION GAME2」ではその狭い隙間を
うまく活用されてなかったにょ。
このハカセジャンプではライフのパラメータを取り入れジャンプするごとにライフが減って
いくため無駄にジャンプしすぎるとクリア不能に陥ることになり、ペース配分が求められて
いるにょ。
ジャンプの消費ライフ4だと私の実力だと全9ステージをクリアできず消費ライフ3に減らした
のだけどこのゲームが楽勝でクリアできる人は以下の変更で消費ライフ4にしてチャレンジ
してみてにょ。（これが当初想定していた難易度であり、ペース配分を考えないと序盤の
ステージでさえクリア不能になる）

　59行　Y>=3　→　Y>=4　および　Y=Y-3　→　Y=Y-4
　64行　"　　　　"　→　"　　　　　"　（””で囲まれたスペースを4つから5つへ変更）

もっとも消費ライフ3に減らしたため序盤のステージだと適当にジャンプしまくってもライフは
余るにょ。（残りライフはボーナス得点に加算されるためスコア競争をするならば有用）
ライフをたくさん消費させるため狭い隙間をある程度たくさん出すようにする必要があり、
騙しとしてギリギリ渡れない（ジャンプが必要な）隙間も出すように計算式を変えたにょ。

あと大ジャンプと小ジャンプは飛距離が違うけど使用ライフは3であるため大ジャンプでないと
飛べないような隙間以外ならば「とりあえず小ジャンプしておけばOK」という「JUMP ACTION
GAME2」の単調になりがちとなっていた部分を改善しているにょ。
したがって、ライフを節約するためには「小ジャンプで飛べる隙間でも早めにジャンプして
大ジャンプで飛ぶ」「隙間2つ分を大ジャンプで飛ぶ」ということが終盤のステージをクリア
したり、序盤においてもスコア競争をする場合には求められているにょ。
ただ、この「ハカセジャンプ」はただでさえ重いGCOPYを使用しているため30fpsギリギリで
あるためTALKで発声するときには処理落ちしてしまうにょ。（この辺は愛嬌ということで）

これらのプログラムは特にリスト短縮を行っておらず、かといって、可読性が高くなって
いるかというとそこまで可読性を高めるように作ってないためプログラムそのものは非常に
中途半端な出来となっているにょ。
これは、可読性やリストの長さではなく開発速度を最優先して作ったためにょ。
可読性を高めようとするならば最初からそのように作る必要があるので私はリスト短縮重視
してばかりであるため開発速度重視で「普通に動くプログラム」をまず作りそれを元に
リスト短縮しているにょ。

さて、これらのプログラムはサイトの方でわざわざページを作って公開するかどうかは微妙で
あるためプチコンプログラムコーナー上で外部リンクを張って公開という形にすることに
したにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/soft.htm#twitter
twitter上で発表したけどサイトでは公開していないプログラム、この掲示板で発表したけど
サイトでは公開していないプログラムも多くあるからね。
そういう物の中から残す価値があると判断したもののみこのページでリンクで公開という形に
しようと思うにょ。

1099：orirakkusu@3DS：2012/06/24(日) 06:26:20
Windowsもどきの正式名称は
みごとWindous DSにきまりましたー！(ぱちぱち？
さて、とうろく商(無理だってw
というか今のところ60fpsでぬるぬる動いてるぜ！
なんかもう簡易マルチタスクでけてる。
だって時計と時刻とスタートメニューが開けるんだもーん！
ところでWindowsって名前だけだっけ？ロゴはだいじょぶだっけ？(パクるぐらいなら、ということです

1100：　：2012/06/24(日) 12:50:24
(無題)
＞なんかもう簡易マルチタスクでけてる。
ふと思いついたけど全部変数を配列変数にすれば沢山開ける…

1101：わぁぃ@：2012/06/24(日) 16:36:37
>配列変数にすれば沢山開ける
重ね表示の処理に難。

1102：orirakkusu@3DS：2012/06/24(日) 18:20:27
(無題)
おちゃめさんへ
博士だけでなくほかのk(gs)aもだしてほs(gs

1103：御茶目菜子：2012/06/24(日) 19:30:49
レスにょ
orirakkusuさんへ
＞みごとWindous DSにきまりましたー！(ぱちぱち？
＞さて、とうろく商(無理だってw

他の人にその名称を使わせないようにするためにはちゃんと商標登録しないと（笑）

＞というか今のところ60fpsでぬるぬる動いてるぜ！

ということはBG画面でウインドウを描画しているにょ？
そのウインドウ内でGRPやスプライトを使ったゲームが高速に動いてそのウインドウをドット
単位でぐりぐり動かせるならば見た目がすごそうに感じられるようになるにょ。

＞ところでWindowsって名前だけだっけ？ロゴはだいじょぶだっけ？(パクるぐらいなら、とい＞うことです

ロゴも商標登録、もしくは意匠登録していると思われるのでそのまま使うのはさすがに
まずいと思われるにょ。
ただし、完全一致でない限り問題ない（1文字変えれば逃れることができる）商標名とは
異なり意匠登録してある場合は類似品も提訴可能になっているにょ。
もっとも、個人が趣味で作ったプログラムで損害が生じることはないためそれで訴える
なんてことはほぼありえないのでロゴは多少変えておけば問題ないと思うにょ。

＞博士だけでなくほかのk(gs)aもだしてほs(gs

ハカセジャンプでキャラをワンパク君に変えるためには以下の変更をすればいいにょ。

　20行　SPSET 1,0,11　 →　SPSET 1,32,12
　21行　SPSET 1,16,11　→　SPSET 1,48,12
　22行　SPSET 1,12,11　→　SPSET 1,44,12
　23行　SPSET 1,24,11　→　SPSET 1,56,12
　58行、59行、73行のTALK文によるセリフをワンパク君っぽいものに変更

これで、キャラは変わるけどこのライフを消費してジャンプというシステムは年配である
ハカセをモチーフにしたからこそのものなのでキャラを変えたら別のシステムを導入するか
パラメータを調整して個性を出せるようにしないとハカセからキャラを変える意味があまり
ないにょ。

　ハカセ　　ジャンプA　体力E
　ワンパク　ジャンプE　体力A

こんな感じでキャラに差別化をしていってステージによってキャラチェンジが可能になれば
さらに楽しいゲームになりそうだけどね。


名無しさんへ
＞ふと思いついたけど全部変数を配列変数にすれば沢山開ける…

わぁぃ@さんも言っているように重ね合わせ処理が必要だから簡単にはいかないにょ。


わぁぃ@さんへ
＞重ね表示の処理に難。

BG画面を使えばウインドウ表示は簡単にできるけど普通に作れば2つしかウインドウを開く
ことができないにょ。
そのウインドウ内のデータをバッファに入れておけばいいけど3つ以上のウインドウを
BG画面によって開くためにはキャラ単位でしか実現できないのが厄介にょ。
GRPが8面くらいあればマルチウインドウでウインドウ内の描画を行いつつドット単位で
ドラッグも可能になるんだけどね。

1104：orirakkusu@3DS：2012/06/24(日) 20:19:27
(無題)
BGじゃなくGRPだお！
なんかこの勢いだとわぁぃ@さんのGGKシリーズと敵同士になりそうw
MacとWindows的な。

1105：otyaken：2012/06/25(月) 00:14:24
osもどき
OSもどきなら前作った事がある。
ー応ダイアログサイズのウインドウを重ねることが出来た。
1.FPS表示
2.文字とボタン
3.%表示バーの表示と変数表示
で120FPSくらいで、何も実行していない時で600FPSだった。
初代から開発しててmk2で実行したら割と速かった。
でも最初はWindowsもどきを作ろうとしていたら全然違うものになり、
面影はコントロールパネルのアイコンとコマンドプロンプトのアイコンだけ…

1106：otyaken：2012/06/25(月) 00:23:57
なまえ
FILENAME:WIN21V
NARU OS/V VER0.51
WINDOWシステムVER0.21

ちなみにNARUという名前はペットの名前から。
/VはVGAのV(VGA対応)
名前がDOSに似ているw

1107：orirakkusu@3DS：2012/06/25(月) 10:01:03
Windous
SSはTwitterで#windous ハッシュタグをつけてツイートしてます。

1108：orirakkusu@3DS：2012/06/25(月) 10:27:57
(無題)
あと、日付と時刻を開いてる時にTALK+BGMPLAYを実行すると上画面のG面にノイズいっぱいイヤー！

1109：御茶目菜子：2012/06/25(月) 22:19:05
レスにょ
orirakkusuさんへ
＞BGじゃなくGRPだお！

GRPだと自由度は高いけど処理が重くなりがちだし、GRPは全部で4面しかないのがネックにょ。

＞SSはTwitterで#windous ハッシュタグをつけてツイートしてます。

Windousなんてハッシュタグを付けているのは他にないので一発で見つかるにょ。

＞あと、日付と時刻を開いてる時にTALK+BGMPLAYを実行すると上画面のG面にノイズいっぱいイヤー！

それってただの処理落ちでは・・・？
GRPでの描画は重いけどTALKもめちゃくちゃ重いからね。
専用DSPでの再生ではなくCPUによる再生であるため処理に1フレーム以上に時間がかかっており
確実に処理落ちしてしまうにょ。
これがGRPの描画途中であれば表示のちらつきを生んでしまうにょ。



otyakenさんへ
＞OSもどきなら前作った事がある。
＞ー応ダイアログサイズのウインドウを重ねることが出来た。

OSもどきを作るのが流行ってるにょ！？
ということで、私も試しに作ってみたにょ。
まぁOSというのはほど遠いレベルだけど・・・（笑）

＞初代から開発しててmk2で実行したら割と速かった。
＞でも最初はWindowsもどきを作ろうとしていたら全然違うものになり、
＞面影はコントロールパネルのアイコンとコマンドプロンプトのアイコンだけ…

初代で作ってその速度ということはGRPだとあり得ないのでBG面でウインドウ表示をして
いるにょ？

1110：御茶目菜子：2012/06/25(月) 22:20:29
プチコンでマルチタスクOSを作る
なんだかプチコンでOSもどきを作るのが流行っているみたいなので私も試しに作ってみたにょ。
名付けて「Petitcom OS」にょ。（また、ストレートなネーミング・・・）
http://ww5.tiki.ne.jp/~ochame/petitcom/image/Petitcom_OS.jpg
http://www.youtube.com/watch?v=_zzCVJQwKsY
（ちなみにこの動画ではアプリの起動、ウインドウのドラッグ、アプリの実行、アプリを
無敵モードにしてアプリ動作中のウインドウのドラッグの様子を記録している）

とりあえず、一晩で作ったということでまだ機能は最低限しかないにょ。
現時点でできることとはアプリケーションの起動（ただし、現在の対応アプリは横スクロール
ゲーム「CAVE」のみ）、終了、ウインドウのドラッグのみにょ。（通常版の「CAVE」は
プチコン講座の第7回のサンプルプログラムとして公開しているのでそれを参照）
ウインドウはGRPで描画されているので1ドット単位で自由に移動することができるにょ。
一応マルチタスクに対応しているためアプリ動作中でもウインドウを自由に動かすことは
可能になっているにょ。
現時点ではアプリが1つのみということでマルチウインドウには対応していないものの
重ね合った部分をバッファに入れておけばマルチウインドウに対応させるのは簡単にょ。

マルチタスクに対応させるためにはアプリ側の対応も必要になってくるにょ。
これがシングルタスクならばタスク終了スイッチさえ用意すれば簡単に実現できるけど
マルチタスク対応にするならばアプリ実行中に一定のタイミングでOS側に処理を移し、
そして再びそのアプリの続きの処理を実行するように作る必要があるにょ。（アプリの方で
OSに移す処理を忘れたらアプリでCPUが占有されるためWin9xでは頻繁に見られたフリーズ
状態になってしまう）
このPetitcom OSでは1/60秒単位でアプリとOSを切り替えているためアプリを3つ同時実行
させる場合には1つ平均180fpsで動作させる必要があるにょ。
それより遅い場合は処理落ちをしてしまうので、いくら高速なプチコンとはいえ現実的に
考えるとバックグラウンドに回ったアプリは自動停止させる方が無難かもしれないにょ。
自動停止したら困るアプリもあるから「デフォでは停止」にしてバックグラウンドに回った
時も動作し続けるアプリも作れるようにした方がいいかもしれないにょ。

　《　3本のアプリをマルチタスク動作させる場合　》
　　　アプリ→アプリ→アプリ→OS
　　　↑--- この間が1/60秒 ---↑

ただ、問題となるのはmkIIでもGRPが4面しかないということにょ。
表示用、表示バッファ用、記録用で3面必要になるためウインドウの重ね合わせのバッファ
用にはGRPが1面しか余ってないにょ。
つまり、マルチウインドウに対応といってもウインドウは1つしか開けないことになるにょ。
もっとも1つのGRPが256x192なので128x96のウインドウならば4つまで確保できるものの
それを越えるサイズが1つでもあったらその時点で1つ分しかバッファが確保できなくなって
しまうためにょ。
記録用のGRPを諦めてウインドウのバッファ用に回せば2〜8つのウインドウを開くことが
できるものの保存するデータが大きくなるからMEM$ではかなり細切れ保存が必要になるし
唯一余っているSPUだけどこれも32バイト単位でしか読み書きできないため使い勝手を
考えると厳しいにょ。

このPetitcom OSで難点となるのはマルチタスク対応アプリを作るのが非常に難しいと
いう点にょ。
まず、ローカル変数が使えず、すべてグローバル変数となるBASICでは変数名やラベル名の
のバッティングを避けることができないにょ。
それはアプリ名（8文字）＋変数名という長い変数名を用いれば何とか解決可能だし、
このOS用の簡易言語＋コンパイラを作り変数名の管理はすべてOS側で行うという方法もある
（この方法だとHSPのAWAIT命令のようなものを用意すればOSへの処理の受け渡しとアプリ内
でのウエイト処理を手軽に行えるようになる）のだけどやはり最大の問題となるのはGRP面の
少なさにょ。
すべてのアプリでGRP面1つを共用しているためCAVEのようなGCOPYを使ったスクロールゲームを
作る場合には一部の領域を常時占有してしまうことになるにょ。
これが128x96以下のサイズであれば使用していない領域を使用すればいいだけの話だけど
このCAVEはウインドウサイズが160x120であるためその時点で残り横幅が96もしくは縦幅が
72というのが他のアプリで使用できる最大サイズとなってしまうにょ。
これが常時占有しない（常に画面全体を新規描画する）アプリであれば問題ないのだけど
CAVEのようなアプリが1つでもあったらその時点でGRPの面数の関係でマルチタスクで
動作させるのが難しくなってくるにょ。（ちなみに1/60秒単位でアプリとOSを切り替える
ためにアプリ内でVSYNCやWAIT命令を使用するのは不可でOSの動作用にVSYNC 1を使って
いるのみ）

というわけで、即興で作ったものの何か画期的な方法が思い浮かばない限りは先に進む
ことができないためこれで一端開発終了とするにょ（笑）
まぁ思いつきで作っただけだから問題はないけどね。
思いつきといえばレイヤー対応のお絵かきソフトも結局GRPの面数不足で開発凍結状態と
なっているにょ。
GRPが8面あればこのPetitcom OSも表示用、記録用を除いても6面余るためアプリ1つあたり
アプリ動作用で1面、ウインドウの表示バッファ用で1面の合計2面分使ってもアプリ3つを
同時に動かすことができるためようやくマルチタスクOSの意味が出てくるにょ。
現状でもウインドウの最大サイズを128x96に制限すれば4つ以上のアプリを同時に動かす
ことは可能だし、フル画面専用にすれば重ね合わせ処理用のバッファが要らなくなるため
2つ以上のアプリを同時に動かすことは可能なので何かを妥協すれば現状のGRP4面であっても
マルチウインドウ対応に作れないわけではないけどね。

1111：わぁぃ@：2012/06/26(火) 14:59:38
GGKDreamStar
ローマ字入力、ひらがな表示対応。
漢字(小1-2)も導入予定。
ウィンドウシステムも随時改修中。

1112：orirakkusu@3DS：2012/06/26(火) 16:41:35
(無題)
YsのPSG番エンディング(FLY ME うんたらかんたら)とスーパーマリオブラザーズのBGMを同梱いやっふううううううう！

1113：otyaken：2012/06/26(火) 17:11:41
SS
http://cdn-ak.f.st-hatena.com/images/fotolife/o/otyakenrabu/20120626/20120626171024.jpg
若干高速化

1114：otyaken：2012/06/26(火) 17:19:47
(無題)
＞漢字(小1-2)も導入予定。http://ugomemo.hatena.ne.jp/05763C20AA3C5510@DSi/movie/3C5510_0B1BDAAD71C03_006

この漢字フォントなら7*7で1ドット相手、習った順に並んでいるから使いやすそう。
もちろん許可取らないといけませんが。

http://d.hatena.ne.jp/TTT0918/20110704/1309708418

1115：御茶目菜子：2012/06/26(火) 23:37:04
レスにょ
わぁぃ@さんへ
＞ローマ字入力、ひらがな表示対応。
＞漢字(小1-2)も導入予定。
＞ウィンドウシステムも随時改修中

どんどんパワーアップしているにょ。
私は脳内にあったマルチタスクOSがプチコンで実現可能かを試しただけなので今のところ
バージョンアップ予定はないにょ。（気が向いたら9月のコンテストに向けて無理矢理完成
させるかも）

orirakkusuさんへ
＞YsのPSG番エンディング(FLY ME うんたらかんたら)とスーパーマリオブラザーズのBGMを同梱いやっふううううううう！

Windousに同梱するにょ！？


otyakenさんへ
＞若干高速化

150fpsとはなかなか速いにょ。
私が作ったものはOSにVSYNC 1を入れているため60fpsが上限にょ。
これを取り除いてCAVEのゲームオーバー画面を表示させた場合には73fpsだったにょ。
アクティブウインドウは常時描画しているのでGRPではこれが限界か・・・。
ちなみにCAVEの動作中にウインドウをドラッグすると30fps台まで落ちるため処理落ちが
酷いにょ（笑）

1116：御茶目菜子：2012/06/26(火) 23:41:11
1インチセンサーが今後の高級コンデジのスタンダードになる！？
1インチセンサーを搭載した高級コンデジ「DSC-RX100」のレビューが行われているので
見てみることにするにょ。
http://dc.watch.impress.co.jp/docs/review/newproduct/20120622_541398.html
やはり、気になるのは操作感と描写力にょ。
操作感については発売開始前のファーストインプレッションにも記されているためそれも
見てみるといいかもしれないにょ。
http://dc.watch.impress.co.jp/docs/review/impression/20120614_540132.html

やはり、RX100の操作面の特徴は背面のダイヤルに加えて前面に設けられたリングダイヤルを
使った操作にあると思われるにょ。
このダイヤルはキヤノンのPowershot S90系（S95/S100を含む）を彷彿させるものだけど
このRX100の場合はそれと比べるとクリック感が無く無段階での回転となっているにょ。
そのため感覚で1段分や2段分変えるというわけにはいかず液晶画面を見る必要があるのだけど
あえてクリック感を無くしているのは動画にそのクリック音が入らないためにょ。
とはいえ、適度な重みがあるので操作感は悪くなさそうにょ。（まだ私も実機を触ってない
ため何とも言えないけど）

描写力で気になる部分といえばやはりレンズ性能と1インチセンサーの実力にょ。
一般的な1/2.3インチセンサーのコンデジと比べたら4倍、1/1.7インチセンサーの高級コンデジ
と比較しても2.8倍のセンサーサイズとなっており、あえて比べるまでもなくそれらとはランク
違いになることが予想されるけど懸念材料となるのはやはり2000万画素もあるということにょ。
いくらセンサーサイズが大きくても画素ピッチは1/1.7インチ、1000万画素の高級コンデジと
比べるとあまり差がないからね。
この辺はフルサイズで3630万画素のニコンD800がAPS-Cで1600万画素クラスの機種と比べると
画素ピッチではあまり差はなくても総合性能では格上となっていることを考えると画素ピッチ
だけで語ることはできないためやはり実機での描写性能こそがすべてとなるにょ。

まずは広角端の絞り開放（F1.8）の描写を見てみるにょ。
http://dc.watch.impress.co.jp/img/dcw/docs/541/398/03.jpg　（ISO125）
http://dc.watch.impress.co.jp/img/dcw/docs/541/398/05.jpg　（ISO125）
さすがにこのサイズで絞り開放から高い解像力を求めるのは無理があるけどこれをもって
判断を下すのも危険にょ。
F5.6まで絞るとかなりの解像感を得られるにょ。
ISO400でもこのレベルだからね。
http://dc.watch.impress.co.jp/img/dcw/docs/541/398/05.jpg　（ISO400）
ボケに関してはややうるさいのがネックだけどこの辺は個人差もあるから置いておくにょ。

望遠端においてはこのレベルの描写力となっているにょ。
http://dc.watch.impress.co.jp/img/dcw/docs/541/398/90.jpg　（ISO125）
大半のコンデジは広角〜標準域ではそこそこの描写力であっても望遠側においてはイマイチと
なっていることを考えるとやはり高画素かつコンパクトな割にレンズは頑張っているといえる
かもしれないにょ。
1/2.3インチセンサーのコンデジで1000万画素超になるとレンズの解像力がセンサーの画素
ピッチに対して明らかに不足しているというのに加えて回折現象による解像力の低下もある
からね。
1/2.3インチで1600万画素になるとF2.5で解像するレンズを作る必要があるのだけどその
明るさは一部のコンデジの広角端でようやく達成できているレベルにょ。（明るくてもその
絞りで解像できなければ意味はないけど）

しかし、望遠端でF2.5なんてコンデジは1/2.3インチセンサー搭載機の中には存在しないにょ。
比較的明るい機種でF4程度で最近の高倍率ズーム搭載機だとF5.6より暗い機種は少なくない
からね。
回折限界を超えたからといってすぐに明確な影響が出るわけではないけどその画素数では
物理的に解像しないわけであって大半のコンデジは等倍では見るに堪えられない縮小前提の
描写力となっているにょ。
その点1インチセンサーのRX100ならばF5.6までならば回折の影響はあまりないためちゃんと
解像力のあるレンズさえ搭載していれば等倍でも十分に見れるレベルの描写力となるにょ。
まぁ描写力といっても解像感だけではなくダイナミックレンジや色再現性も重要になって
くるのだけどさすがにこの辺は画素ピッチの広いAPS-Cやフルサイズと比べるとやや劣る
もののサイズから考えて一般的なコンデジと比較した場合には十分なレベルあると
思われるにょ。

続いて感度別の描写力を見てみるにょ。

　ISO125　http://dc.watch.impress.co.jp/img/dcw/docs/541/398/75.jpg
　ISO200　http://dc.watch.impress.co.jp/img/dcw/docs/541/398/76.jpg
　ISO400　http://dc.watch.impress.co.jp/img/dcw/docs/541/398/77.jpg
　ISO800　http://dc.watch.impress.co.jp/img/dcw/docs/541/398/78.jpg
　ISO1600 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/79.jpg
　ISO3200 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/80.jpg
　ISO6400 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/81.jpg
　（マルチショットNR）
　ISO6400 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/82.jpg

ISO125、ISO200は全く問題ないもののISO400からはやや目立ったノイズが出てくるように
なっているにょ。
これは昨今のAPS-Cセンサーを搭載したデジタル一眼と比べるとISO125ではそれほど差は
ないけど400くらいになるとその差が出てくるといえそうにょ。
とはいえ、ISO800、ISO1600でも等倍で見なければ十分に実用レベルにょ。
等倍ではたいしたことはないけれど1/2の1000万画素にリサイズすれば1/1.7インチ、
1000万画素の高級コンデジと比べたら明確なアドバンテージがあるように見えるにょ。
とはいえ、常用として使えるのはISO1600までにょ。
ISO3200では明らかにノイズリダクションによるディティール低下が目立ってきている
ため縮小前提画質となってしまっているにょ。
ISO3200でも常用可能なレベルにあるAPS-Cセンサー搭載のデジタル一眼レフと比べると
1〜2段分劣っている感じにょ。（等倍ではなく同一サイズへリサイズした場合の比較）
しかし、これはセンサーサイズを考えるとAPS-Cの方が3.16倍大きいのと妥当なものと
いえるにょ。
つまり、2000万画素と画素数は多いものの高画素による目に見えるデメリットはなくて
センサーサイズなりの性能はあるということにょ。（DIGIC5を搭載したS100はコンデジ
として見ればかなり高感度画質に優れていたけれどRX100と比べるとセンサーサイズの差は
大きいと感じる）

さすがにISO6400は厳しいけどそれはマルチショットNRで解決にょ。
これはソニーのコンデジでは「手持ち夜景モード」として数年前から使用されている
ものであり、高速連射を生かして複数枚（6枚程度）の写真を撮影してそれを重ね合わせ
処理を行うことで最大2段分程度のノイズ軽減を行えるというものにょ。
これは私が普段使っているコンデジTX1でも採用されているけどISO1600でも通常のISO400
クラスの低ノイズの写真が撮れているため非常に実用性の高い機能にょ。
もちろん動体撮影には不向きだし、手ぶれをしてしまうと解像感の低下を招いてしまう
ため万能なものではないけどね。

こうしてみるとやはり「センサーサイズ」が極めて偉大であることが改めてよく分かった
感じにょ。
1/2.3インチセンサーでもF0.9-2.4のズームレンズを搭載すればRX100と計算上は対等に
なれるけれど現実的に考えるとその明るさで1/2.3インチの極小ピッチセンサーでまともに
解像できるレンズを作ることはほぼ不可能だからね。
Nikon 1を見ると1インチセンサーで2000万画素は厳しいという先入観があったものの
RX100はレンズ一体型であり、デジタル補正がフルに使えるからこそ2000万画素でも実用
レベルの描写力となっていると思われるにょ。
画素ピッチからいえば上記のように一般的な高級コンデジよりも広いため決して無茶な
ものではないといえるにょ。

さて、スマホに搭載されるデジカメの性能は年々アップしており、1月31日にも書いた
ようにスマホと差別化や共存が狙える機種でないと今後生き残ることが難しいと考えて
いるにょ。
したがって、安いだけのコンデジではもう生き残ることができないにょ。
これはすでにメーカー側も気づいていることであり、各社とも生き残りを考えた機種を
発表しているにょ。
スマホのデジカメがいくら良くなってもあくまでローエンドコンデジと同レベルのもの
であり、高倍率ズーム搭載機や画質重視のモデルは十分に生き残ることができるにょ。

ただ、画質重視する場合には昨今はミラーレスが小型化、低価格化しておりコンデジから
ステップアップ用としてメーカー側も入門者的な位置づけの機種を積極的にラインナップ
しているにょ。
確かにフォーサーズセンサー搭載機でも一般的なコンデジと比べると別格の描写力となって
いる（ただし、高感度に関してはそれほど強くない機種が多い）もののコンデジの代わり
にはならないにょ。（コンデジの代わりというよりもデジタル一眼の入門機が大きく重い
という人の代わりであるためミラーレスの普及でシェアを失うのはコンデジではなくて
デジタル一眼の方）
確かにセンサーサイズが大きくなれば画質に与える影響は極めて大きくなるのだけど
今度は筐体サイズだけではなくレンズも大型化してしまうという問題が発生してしまう
ことになるため「センサーサイズを大きくすれば解決」という単純な問題ではないという
ことにょ。

そういう面では1インチセンサーというのは落としどころとしてはベストだと思うし
そのセンサーサイズでこの筐体サイズを実現しているからこそRX100の魅力は大きいと
思われるにょ。
ミラーレスのサイズを受け入れられないユーザーの受け入れ先としては高級コンデジは
非常に有用な存在であり、廉価コンデジの将来はないため恐らくRX100を発端として
各社の高級コンデジに1/1.7インチを越える大型センサーを搭載するものをラインナップ
してくるのではないかと予想されるにょ。

1117：orirakkusu@3DS：2012/06/27(水) 17:22:37
(無題)
Ysのほうは@tiny_yarouにリプライ飛ばす
マリオの方はneko8000さんに聞く
----
現在背景実装中！全部内蔵してやるへへへ

1118：御茶目菜子：2012/06/27(水) 22:14:41
レスにょ
orirakkusuさんへ
＞現在背景実装中！全部内蔵してやるへへへ

気を付けないとQRコード100枚越えの超大作になってしまうにょ。
配布を行うならばほどほどにしないとね。

1119：orirakkusu@3DS：2012/06/28(木) 20:36:36
(無題)
いまのところSIZEはSixRockChainより小さい16720。
さてFPSは(事実CPSだが)
アドオン時725fps
日付と時刻起動時300fps
上+TALK125fps
どうだ素晴らしいだろう。Win9x系によく見られたアプリによるフリーズは対策の仕様がOS側ではないな。

1120：御茶目菜子：2012/06/28(木) 21:44:49
レスにょ
orirakkusuさんへ
＞??いまのところSIZEはSixRockChainより小さい16720。

私の方は最小限の機能のみなので2130バイトにょ。
完成時にはこの数10倍になりそうだけどね。
あとは、アプリをどれだけ入れるのかでもサイズが変わってきそうにょ。

＞さてFPSは(事実CPSだが)
＞アドオン時725fps
＞日付と時刻起動時300fps
＞上+TALK125fps
＞どうだ素晴らしいだろう。

私の方はOSの起動時（画面表示はデスクトップ、マウスカーソル、タスクバー、時計のみ）
で790fpsだったにょ。
ただし、唯一のアプリであるCAVEを起動時には73fpsまで低下してしまうにょ。
これはマルチタスク、マルチウインドウに対応できるように仮想画面に描画してそれを転送
している関係上どうしても遅くなってしまうにょ。
とはいえ、デフォの160x120のゲーム画面を128x96にすれば102fps、96x64にすれば160fpsに
なったにょ。（CAVEはウインドウサイズ可変に対応しているのでサイズを小さくしても普通に
遊べる）
96x64ならばCAVEの動作中にウインドウをドラッグしまくっても96fps出るけどさすがにこの
画面サイズだとやや寂しいにょ。

＞Win9x系によく見られたアプリによるフリーズは対策の仕様がOS側ではないな。

ちなみにorirakkusuさんはWindous DSではどうやってアプリを追加予定にょ？
やっぱり、APPENDで追加にょ？

1121：otyaken：2012/06/28(木) 22:40:42
(無題)
調べてみたら34352バイトだった。
けどほとんどが旧アプリ(windowシステム2.0)でそれを消したら多分半分以下になると思う。
そういやfpsとかってどうやって測定しているんですか?
自分はどっかのゲームからfpsカウンタだけ取り出して使っている。

1122：わぁぃ@：2012/06/28(木) 22:54:53
(無題)
私はfpsをGAME4のカウンタで計りますね。otyakenさんと同じかな？

1123：orirakkusu@3DS：2012/06/29(金) 06:31:24
(無題)
完成番では、特設DATA文コーナーにアイコンデータとラベル、常駐のラベル、プログラムNo.を書いて、その下にアプリケーションを書くという方法です。
FPSのはかり方(その時その時で違うけどね)
49.IF TIME$!=MT$ THEN (表示部):F=1 ELSE F=F+1
57.MT$=TIME$
あと、SPOFSをタッチ時しか実行しないようにしたら
アドオン時1250fps
日付と時刻起動650fps
上+TALK300fps
すごい上がった。
あと30fpsを切ったらブルースクリーンルーチンに飛ばすようにした。

1124：わぁぃ@：2012/06/29(金) 17:40:45
GGK DreamStar
追加の仕方はorirrakusuさんと同じ感じ。
速度はおちゃめさんと同じ60fps。
処理落ち防止用に、30fpsで同等の動作を確保する「30fpsモード」を搭載予定。

1125：御茶目菜子：2012/06/29(金) 21:19:18
レスにょ
otyakenさんへ
＞調べてみたら34352バイトだった。
＞けどほとんどが旧アプリ(windowシステム2.0)でそれを消したら多分半分以下になると思う。

それでも17KBか・・・。
どんな機能を持っていてどんなアプリを用意しているのか分からないので長いのか短いのか
判断するのが難しいところにょ。

＞そういやfpsとかってどうやって測定しているんですか?

1秒間（60フレーム）の描画回数をカウントしてそれを表示すればいいだけにょ。
私が普段使っているのはこんな感じにょ。

　FPS=FPS+1:IF !(MAINCNTL%60)THEN LOCATE 0,0:?FPS,:FPS=0

（余分なコロン、スペースを省略して）変数名に1文字変数を使えばfps表示プログラムと
しては最短になると思うにょ。（1文字変数を使わないのは普段はリスト短縮のため優先的に
使用しているため削ることが可能なfps表示に使用するのがもったいないため）
MAINCNTL%60の値が0になるのは60フレームごとなのでTHEN以下は60フレームごとに実行
されるにょ。（ただし、60fpsを越える場合は1フレームに2回以上実行される可能性がある）
特に初期設定無しでこの1行を追加するだけでOKでありお手軽なのだけどこの方法はVSYNCや
WAIT命令によって上限が60fpsになっている場合しか使えないにょ。（つまり1〜60fpsの
範囲内で測定可能）
60fps超を測定するには前回のMAINCNTLの値を変数に入れれば簡単に判定が可能にょ。

　FPS=FPS+1:IF MAINCNTL-CNT>=60THEN LOCATE 0,0:?FPS,:FPS=0:CNT=MAINCNTL

そうすれば前回から60フレーム以上経過しているかどうかというのを判定すれば済むにょ。
わざわざ前回のカウンタの値を変数に入れたりと無駄に変数を増やしたくないならば最初の
リストを改造すれば条件付きで測定可能にょ。

　FPS=FPS+1:IF (FPS>9)*!(MAINCNTL%60)THEN LOCATE 0,0:?FPS,:FPS=0

こうすることでデフォの10倍となる10〜600fpsで測定可能にょ。（「FPS>19」にすれば
デフォの20倍まで測定可能）
基本さえ抑えておけばあとは自分が使いやすいもので問題ないにょ。



わぁぃ@さんへ
＞私はfpsをGAME4のカウンタで計りますね。otyakenさんと同じかな？

あれは良くできているけど無難な作りになっていて無駄も多いため自分が使いやすいように
改造するのもいいかもしれないにょ。

＞処理落ち防止用に、30fpsで同等の動作を確保する「30fpsモード」を搭載予定。

便利そうな機能だけどアプリ側の対応が必要になってくるにょ。
とはいえ、「CAVE」はゲーム自体は30fpsで動作しているので処理落ちの問題はないけど
OSそのものは60fpsを前提としているため動作中にウインドウをドラッグすれば処理落ちが
起きてしまうというのが改善されそうにょ。
もっともCAVEをフル画面起動したら18fpsまで落ちてしまうので30fpsモードを導入しても
処理落ちしまくりだけどね。（あとマルチタスクで複数のアプリを同時実行したら簡単に
30fpsを切ってしまいそうだし）



orirakkusuさんへ
＞完成番では、特設DATA文コーナーにアイコンデータとラベル、常駐のラベル、プログラムNo.
＞を書いて、その下にアプリケーションを書くという方法です。

レスどうもにょ。
APPENDで追加するというのは最も単純で分かりやすいものだけどこの辺をどのように処理して
いくかで制作者の個性がでてくるため工夫の余地は多くあると思うにょ。
私は自分以外の人が自由にアプリを追加できるようにAPPENDのみで済むようにAPPENDする
プログラム内にアイコンデータなどを書こうと思っているにょ。（現時点ではアプリが
1本しかないのでそんな汎用的な作りにはなってないけど）

それだとAPPENDを実行してもOS上からは分からないためそれを認識するための作業（つまり
（インストール作業）をOS上で行う予定にょ。（プチコンでON ERROR GOTOが使えたら
ラベル名が重なったときにダイヤログで「不正な処理を行ったので終了します」とダイアログ
表示させることも可能だけどそれができないため不特定多数の人がアプリを作って追加する
場合にはラベルチェックの重複チェックもしないといけない）

こうすればOS上からアンインストール処理を行えばAPPENDしたプログラムを消去するだけで
済むため削除も簡単にょ。
もっともプチコンの場合は範囲指定をしての削除ができないため簡単といっていいのかは
微妙だけどね。
ということで、どのようにプログラムを書いていくのかという仕様はまだ全然固まって
なかったりするにょ（笑）

＞あと、SPOFSをタッチ時しか実行しないようにしたら
＞アドオン時1250fps
＞日付と時刻起動650fps
＞上+TALK300fps
＞すごい上がった。

私はデフォで必要最小限の表示に抑えたら1190fpsになったにょ。
なんかどんどん無意味な計測になっていっているにょ（笑）

＞あと30fpsを切ったらブルースクリーンルーチンに飛ばすようにした。

なかなか面白い機能だけどfps表示は初回表示時と画面を一端閉じてから開いた時の最初の
表示は不正確なのでそれを回避するルーチンを作らないといきなりブルースクリーンに
なったりする場合があるので注意が必要にょ。

1126：orirakkusu@3DS：2012/06/30(土) 06:30:15
(無題)
土日だし、テストのQR書き出ししてみるか。
50枚越えてたらリスト短縮しないと公開は100%ムリポw
といってもまだ6枚ぐらいだとおもうが。
ちなみタイニーゼビウスforプチコンって何行だっけ？

1127：わぁぃ@：2012/06/30(土) 14:13:50
(無題)
確かにON ERROR GOSUBがあれば便利だな。
99BASICで使ってみたけど良かった。

1128：わぁぃ@：2012/06/30(土) 14:52:32
GGK DreamStar
ＢＧ面にＰＲＩＮＴするルーチンを作成。
ＣＳＲＸ、ＣＳＲＹでＰＲＩＮＴと連動しているほか、ひらがな／カタカナの混在表示が可能（ＣＨＲ＄（９）はかな切り替え、ＣＨＲ＄（１３）は改行に割り当て）

1129：orirakkusu@3DS：2012/06/30(土) 20:26:41
Windous DS
公式サイト作っちゃった(テへ♪
http://www.geocities.jp/orirakkusu/petitcom/mkll/osprj/

1130：御茶目菜子：2012/06/30(土) 23:33:54
レスにょ
orirakkusuさんへ
＞50枚越えてたらリスト短縮しないと公開は100%ムリポw

現時点でたいした枚数でなくてもこれからどんどん機能を拡張していったら枚数は増えるので
油断は大敵にょ。

＞ちなみタイニーゼビウスforプチコンって何行だっけ？

行数はよく分からないけどQRコード109枚だったにょ。（TINY野郎さんのツイート参照）
プチコンプログラムで最も行数の多いのは私が知っている範囲内だとktさんの「PX7」にょ。
http://www.geocities.jp/sp1_ssr/px7.htm
手元にあるver1.00の段階で7373行に達しているにょ。（可読性重視のプログラムなので
行数の割にはQRコード枚数が少ない）
ゲームだとるかかさんの魔導物語が最も行数が多いにょ。
ちなみに私が発表済みのプログラムだと最高でもQRコード4枚だし、今まで発表している
プログラムのQRコードを全部合わせても94枚しかないにょ。（平均すると1作品2枚くらい）

＞公式サイト作っちゃった(テへ♪

ついに作ったにょ！？
それならば、企画倒れにならないように頑張らないといけないにょ。
私は気力が続かないのである完成の目処が立たない限りはそういうサイトは作らないにょ。



わぁぃ@さんへ
＞確かにON ERROR GOSUBがあれば便利だな。

ツールやある程度以上の規模のプログラムを作る場合には必要不可欠といっていいような
命令にょ。
現状だとせっかくERR、ERLでエラー内容、エラー発生行が取得できるのにそれを十分に
生かすこともできないしね。
せいぜいLIST ERLでエラー行を表示するくらいにしか使えないにょ。

＞ＢＧ面にＰＲＩＮＴするルーチンを作成

やっぱり、テキスト表示ならばBG面が一番にょ。
表示も高速だし、文字種も1024使えるしね。
ただし、グラフィックは使えない（使いづらい）のでコンソール主体のアプリに限られて
しまうのが難点にょ。（BG面の上に描画すればいいけどはみ出し処理を行うのが大変）

まったく関係ないけど半年前に初代プチコンで作ったプログラム「2OMP」が見つかったので
書いておくにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/image/2omp.jpg

これは超簡易MML用のMMLデータをOMP用のMMLにコンバートするプログラムにょ。
http://wiki.hosiken.jp/petc/?Toukou%2F%C4%B6%B4%CA%B0%D7MML
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#omp
超簡易MMLの音程、音長指定の方法がOMPに似ているから簡単にコンバートプログラムを
作れそうということで即興的に作ったものにょ。
ただし、あまりに需要が無さそうだし唯一の発表曲である「春の奇跡」も1つの文字列
変数に格納しきれず、String too longエラーとなって153番目の音符までしか変換が
できないということで未発表となっていた品にょ。（まぁ複数の文字列変数に分割保存
するなり、GRPに保存するなりすればエラーは解決できるけど）
良かったら改造するなり、適当に使ってにょ（笑）

1131：御茶目菜子：2012/06/30(土) 23:35:21
プチコンでマルチタスクOS PART2
プチコンでマルチタスク、マルチウインドウのOSもどきのプログラムを作る場合には6月25日に
書いたようにまずはGRP面が4面では全く足らないにょ。
ただし、これは逆に言えば4面で収まる範囲内であれば作れるということも意味するにょ。
つまり、開いているウインドウの合計サイズが256x192以下になればいいということだからね。
ということで、即興で最低限の機能のみを作ったPetit OSだけどその続きを仮に作る場合は
他にどのような問題があるのか、どうやって実現させたらいいのかということについて
書いていくことにするにょ。（以下、「OSもどき」を「OS」と記述）

さて、まずはマルチウインドウを実現するためには重なった部分をバッファに入れていく
ことになるにょ。
別にバッファに入れなくても重なっているウインドウを常に下から順に全部表示していけば
いいのだけどそんなことをしたら何も動作をしていないウインドウをドラッグするだけでも
30fpsを下回る可能性さえあるにょ。
これがバッファに入っている部分だけ再描画するならばウインドウをドラッグする際の描画
速度は数倍にアップするにょ。

そして、ウインドウ用バッファだけではなく表示用バッファも必要になるにょ。
マルチタスク、マルチウインドウを実現するためには直接画面表示するわけにはいかず
一端表示用バッファ（要するに仮想画面）に描画したあとにそれを実画面に転送することが
必要になってくるにょ。
そうしないと管理が複雑になりすぎて実用にならないからにょ。
それだけでなくコンソール表示（テキスト表示）は基本的にキャラ単位でないと表示する
ことができず、マルチウインドウに対応して自由にウインドウをドラッグなんてことは実現
できないにょ。
コンソール表示だけならばBG画面を用いればマルチウインドウ対応にすることは可能だけど
その際も自由に使えるのは2面だけになってしまうにょ。（その代わり1つのウインドウは
512x512ドットまで可能になる）

表示用バッファを用意することでマルチウインドウ処理は簡単になるのだけどそれでも
マルチタスク、マルチウインドウに対応させるためには下記のような6つの重要な問題を
抱えているにょ。

　(1)マルチウインドウのバッファ管理
　(2)事実上グラフィック用命令以外は使えない
　(3)事実上BGMPLAYは使えない
　(4)ウエイトや一時停止を行う命令は使えない
　(5)コンテキストスイッチの保存
　(6)ラベル名、変数名の重複回避

(1)のみOS側の問題であとはアプリを作る際の問題となるにょ。

(1)合計で256x192となる最大バッファサイズを分割して管理することになるけどそれを
どのように割り当てて行くかということが問題にょ。
これがウインドウサイズが固定で128x96のようにキリの良いサイズだと単純に4分割して
それを割り当てればいいけどこれがサイズの異なるウインドウだとうまい具合に大きい
ウインドウから順に開いていってくれれば開いたサイズに割り当てを行うのは難しく
ないものの順不同で開いていくならば残りバッファサイズは十分なのに後から大きい
ウインドウを開けばバッファサイズが不十分になってしまう場合があるにょ。
これはバッファの断片化が起きるためにょ。
これは断片化解消ツールを作れば改善可能なので問題ないにょ。（リアルタイムで
この処理を行うことも可能だけど処理速度の大幅な低下を招いてしまうので実用レベルに
達しないだろうし、下記のダイレクトモード以外だとバッファを整理するための作業エリアの
確保ができないため実現が難しい）

ウインドウは今のところシステム変数としてSCREENX、SCREENYを用意してそれを元に起動時に
ウインドウサイズを決めているけどこれは可変式にすることも可能にょ。
唯一のアプリである「CAVE」は可変式に対応しており、描画される穴の幅などはウインドウ
サイズによって変化するにょ。
アプリの再起動によって変化させるだけではなく原理的にはWindowsのようにドラッグに
よってリアルタイムでウインドウ幅を変化させることもできる（単にSCREENX、SCREENYの
値を変えるだけでいい）けど上記の断片化問題を考えると厳しそうにょ。

(2)表示バッファから実画面への転送はGCOPYを使う都合上、表示バッファの描画はGRP面のみ
有効になるにょ。
つまり、マルチウインドウ処理が容易になる代償としてコンソール、スプライト、BGを使った
描画はできないということにょ。
表示を行う場合はグラフィック命令を用いるか、コンソール、スプライトキャラを表示する
場合はGPUTCHRで描画していく必要があるにょ。

それに加えて表示バッファの割り当てをOS側で行っているためバッファのGRP面に描画する
場合もその仮想画面の座標に描画しないといけないにょ。
例えば96x64のウインドウを(128,96)を起点としたバッファが確保されておりその上に
描画する場合は座標(0,0)がバッファ上の(128,96)に相当し、仮想画面の右下である
(95,63)が(223,159)に相当するにょ。
これを実際にプログラムを作る際に計算して作るのはかなり大変にょ。
まぁ、描画専用のAPI（というかサブルーチン）を用意してそれを経由して描画することで
自動的にOS上で割り当てられたバッファ上に描画するということも考えているけどかなり
面倒臭そうにょ。（機能を実装するのは簡単だけど実際にアプリを作るのは面倒）

(3)音楽を鳴らす場合は各ウインドウで独立して制御する必要があるにょ。
BGMPLAY命令では8チャンネルまで対応しているため最大ウインドウ数が8個ならば各
ウインドウに1チャンネルずつ割り当てれば鳴らすことはできるにょ。
ただし、それはバックグラウンドに移ったウインドウで鳴らしている音を鳴らし続けた
場合には同時発音数の問題で難しいにょ。
かといって、バックグラウンドに移ったゲームで使用されている音楽を停止した場合には
ウインドウを前面に持ってきた際にBGMを再び続きから鳴らすことは現在のBGMPLAY命令
ではできないにょ。
つまり、「BGM再生→BGM停止→BGMを停止箇所から再生」を行うためには音階演奏
プログラムを自前で用意するしかないにょ。
まぁこれはOMPがあるから何とかなるけどね。

(4)そして、マルチタスクに対応させるためにはアプリへの時間の割り当てが問題となるにょ。
WAITやVSYNCでそのアプリを一定時間停止してしまうとマルチタスク処理を行う場合には
他のアプリまで影響が出てしまうためアプリ内でそういう命令を使うことはできないにょ。
OSは60fpsでの動作を前提としているため30fpsのゲームを作る場合には2回に1回実行すれば
良いという感じだけど実際は処理落ちを起こしているということも想定しておかねばならない
ためにMAINCNTLのカウンタを用いて2フレームに1回処理するというように組む必要が
あるにょ。
あとINPUTなどの一時停止が行われる命令は使用することができないにょ。
これはINKEY$やKEYBOARDなどを用いてINPUTの代替となるサブルーチンを用意して解決する
しかないにょ。

(5)マルチタスクOSを作る場合に必要不可欠なのはコンテキストスイッチの保存にょ。
といっても、ただのOSもどきなので本来のコンテキストスイッチとは全然異なるものにょ。
私が作ろうとしているPetitcom OSにおいてアプリA、アプリB、アプリCの3つのアプリを
同時に動かす場合には下記のようになるにょ。

　　アプリA→アプリB→アプリC→OS→アプリA（以下略）
　　　↑--- この間が1/60秒 --- ↑

ただし、これもアプリAからアプリBに処理が移る場合にアプリAのどの部分まで処理が
行われたのかを一端保存して再びアプリAを実行する際にはその続きから実行する必要が
あるにょ。
これがマルチタスクではなく起動しているアプリが1本ならばアプリからGOSUBでOSを
呼び出せば簡単にできるけどマルチタスクの場合は自前で実行箇所のフラグとなるものを
保存してそこにGOTOでジャンプするしかないにょ。

(6)ラベル名が重複してしまうとエラーによって実行不可能になるため事前にチェックして
おく必要があるにょ。
とはいえ、そのプログラム内で使われているラベルを調べることは手動で行わない限りは
無理なのであらかじめそのアプリで使われているラベルを書き記したデータを用意して
インストール時にチェックするしかないにょ。
アプリはAPPEND命令によって追加予定だけど追加しただけではOS上から使用することは
できないためそのアプリが追加されたことをどこかに記す必要があるにょ。
それはOS内にインストーラーを用意してそれを用いてインストール処理を実現する予定と
なっているにょ。（この方法を用いればアンインストール時はアンインストール処理を
OS上で行いAPPENDしたプログラムを削除するだけなので簡単）
その際にアプリ内にあるアイコンデータと使用ラベル一覧を呼び出しアイコンデータを
元にBG面に書き込み、ラベル一覧を元にチェックして現在インストールされている
プログラムとラベル重複がないかをチェックしてそれで使用可能になるにょ。（ラベル
重複がある場合にはインストール済みのどのアプリで使用されているのかということも
表示する）
基本的にラベルはなるべく他のアプリと被らないように先頭の数文字はアプリ名を
使ったものにする（CAVEにおける＠MAINならば＠CAVEMAINとする）ということを推奨
しているけどね。

次に変数の重複問題にょ。
変数の場合は配列変数で二重定義にならない限りはエラーが出ないため問題ないとも
いえるけどラベル数よりも使用する変数の数の方が多くなるだろうから厄介にょ。
そこで考えたのはA〜Zの1文字変数の疑似ローカル変数化にょ。
これによってA〜Zまでは使用変数一覧を作成することなく自由に使えるようになる（どの
アプリでもA〜Zは重複して使用可能になる）けどその代償として速度の低下を招いてしまう
ことになりそうにょ。

使用しているラベルや変数名は配列変数に入れていると同時にGRPにも書き込み、OSの
ブート時には再びそこから使用している配列変数に読み込む予定にょ。
ラベル名が16バイトx1つのアプリで50個使用、変数名が16バイトx1つのアプリで100個使用
と考えた場合には2400バイトとなり、48KBのGRPには20本分のアプリデータを保存可能に
なるにょ。（「MEM$では全く足らない」というのはこれで分かると思う）
実際はデフォで用意するアプリなんて数本だろうし、誰かが自分で追加するなんて可能性も
上記のアプリの作りにくさを考えると望みが薄そうなので48KBあればかなり余裕だけどね。


以上が「Petitcom OS」を脳内シミュレーションで動作させた場合に見つかった問題点にょ。
処理速度の問題やOSそのものの使い勝手の問題は実際に作ってみないと分からないので
「少なくとも」これだけの問題があるということにょ。

さて、これではあまりに制約がありすぎて使えないOSとなってしまいそうにょ。
そこで考えたのはダイレクトモードの搭載にょ。
マルチタスク、マルチウインドウではなくシングルタスク専用モードにょ。
このモードで動作させれば上記の制約はほぼ無くなりプチコンで用意されているほとんどの
機能が使えると同時にすでに作られているプログラムも一部の手直しをするだけでこの
Petitcom OS上で動作させることが可能になるにょ。（アイコンデータと使用ラベルデータ、
変数データを用意して、OSに復帰する処理を加えるだけでいい）
上記のインストーラーや断片化解消ツールなどはこのダイレクトモードでないと作るのが
難しいけどそれをユーザー側（一般アプリ作成側）にも開放しようというものにょ。
ただし、マルチタスク、マルチウインドウがウリとなっているためこのモードを前面に
出してしまうことは両刃の剣となってしまうのが問題にょ。
このモードは端的にいえばたくさんのプログラムをAPPENDでつなげてそれを選択実行
できるランチャー機能でしかないわけだしね。（OSっぽさを出すならばやっぱりマルチ
ウインドウでないと・・・）

したがって、マルチタスク、マルチウインドウが実用レベルになっているかということが
重要になるにょ。
まぁ実用ソフトではなくネタソフトと考えれば「マルチタスク、マルチウインドウの
OSもどき」ということでそれなりの価値はあるだろうけど作るための大変さとネタ的な
面白さを天秤に掛けると微妙なので一晩で作った試作品の続きを作る気力が失われて
しまっているにょ。
これだけ競合が多ければ目新しさも薄れてしまうだろうからね。
簡単に作れるプログラムならばさっさと完成させてもいいけど、どう考えても1週間程度
では完成しそうもないためそれなりの気力がないと駄目にょ。
それにコンテストに出すならば締め切りはまだ先なのでギリギリにならないとエンジンが
かからない私にとってはまだあわてる時間ではないしね（笑）

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