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

おちゃめくらぶ掲示板

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


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

さっきは結構降っていたにょ。
また詳しくは明日書くにょ。
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週間程度
では完成しそうもないためそれなりの気力がないと駄目にょ。
それにコンテストに出すならば締め切りはまだ先なのでギリギリにならないとエンジンが
かからない私にとってはまだあわてる時間ではないしね（笑）

1132：わぁぃ@：2012/07/11(水) 01:07:20
(無題)
そういえば、超簡易MMLからプチコンのMMLに変換するソフトを作ったけど、和音の処理ができてないし、無駄が多いから発表してない。

1133：わぁぃ@：2012/07/11(水) 05:47:16
(無題)
GGK DreamStar用のデスクトップ背景を本物のwindows XPに入れてみたww

1134：orirakkusu@3DS：2012/07/11(水) 06:15:14
Twitterでは
変態紳士と呼ばれている(呼んでほしい)らしい(form orirakkusu@情報アンテナVer1.00)

1135：御茶目菜子：2012/07/12(木) 02:09:40
レスにょ
わぁぃ@さんへ
＞そういえば、超簡易MMLからプチコンのMMLに変換するソフトを作ったけど、和音の処理ができてないし、無駄が多いから発表してない。

超簡易MML→OMPはほとんど同じようなアルゴリズムだったから和音を含めて簡単に
変換プログラムはできたけどプチコンのMML（BGMPLAY形式）に変換する場合には大きく
異なるため簡単にはいかないからね。

和音処理を実現するには変換元のMMLを2度読み取る必要があるにょ。
まず、1度目は音長0の音符が最大何個連続しているかを調べるにょ。
「音長0の最大連続数＋1」が同時発音数となっているのでそれだけ分のトラックにデータを
書き込めばいいことが分かるにょ。
2度目の読み取りでいよいよ変換にょ。
例えば元のMMLが最大3和音で四分音符のドを鳴らす場合にはトラック0にはC4を書き込んで
トラック1、トラック2には四分休符（R4）を書き込むにょ。
音長0でド、ミ、ソを同時に発音している場合にはトラック0にC4、トラック1にE4。
トラック2にG4を書き込めばいいにょ。
こうやって、1つずつ順番に変換していけば難しいことはないにょ。
ただし、これだと細切れの休符がたくさん書き込まれるため休符はその都度書き込まず
休符の長さだけを各トラックごとカウントしていってそのトラックの音符を書き込む際に
休符をまとめて書き込むといいかもしれないにょ。
そのトラックにおいて四分音符14個分の休符があったら「R4R4R4R4・・・（14個分）」では
なくて「R1R1R1R2」とすればデータ効率はアップするにょ。

私もOMP→プチコン用MMLの変換プログラムを作ろうという考えはあったけど私自身が特に
必要としていないし、需要も無さそうなのでやめたにょ。
1画面では作れそうになかったしね（笑）

＞GGK DreamStar用のデスクトップ背景を本物のwindows XPに入れてみたww

一瞬、XPの壁紙をGGK DSに入れたのかと思ったけどその逆とは・・・。
次はXP上で動くプチコン風の文字やスプライトキャラを使ったプログラムを作れば完璧にょ。



orirakkusuさんへ
＞変態紳士と呼ばれている(呼んでほしい)らしい(form orirakkusu@情報アンテナVer1.00)

私ってそんなイメージあるー？
それどこ情報？どこ情報にょー？

1136：otyaken：2012/07/12(木) 03:03:35
変換
前作った事あるけど音長192で和音にした

1137：orirakkusu@3DS：2012/07/02(月) 17:35:39
(無題)
Twitterのタイムラインだお！

1138：orirakkusu@3DS：2012/07/02(月) 17:37:12
(無題)
↓追記
@zwisser 失礼な！できれば変態紳士とよんてほしいものです(笑)
みたいなツイートだったような気がするするー

1139：orirakkusu@3DS：2012/07/02(月) 17:41:13
(無題)
あとGCOPYの意味やっとわかった。

1140：御茶目菜子：2012/07/02(月) 22:24:03
レスにょ
otyakenさんへ
＞前作った事あるけど音長192で和音にした

私が作ったプチコンMMLは音長999で和音になるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/mml.htm
そうではなくて、BGMPLAYに変換するときに音長192で和音を表現するということにょ？
BEEPを使った演奏プログラムならば勝手に音が鳴り続けるから和音の表現は簡単だけど
BGMPLAYの場合は音が伸びないのでちゃんとトラックごとに分けないと厳しそうにょ。



orirakkusuさんへ
＞Twitterのタイムラインだお！

「どこ情報？」というのはただの「地獄のミワサ」ネタにょ（笑）
http://www.google.co.jp/#hl=ja&site=&source=hp&q=%E3%81%9D%E3%82%8C%E3%81%A9%E3%81%93%E6%83%85%E5%A0%B1

＞あとGCOPYの意味やっとわかった。

これでGCOPYを使ったプログラムが作れるにょ？

1141：まるまる：2012/07/02(月) 23:37:15
先日はありがとうございました。
こんばんは。初めて書き込みをさせて頂きます。
Twitterでプチコンのカラーパレットの並び順について教えて頂いた者です。

先日は本当にありがとうございました。
16×16で並んでいる色を見ただけだと規則性が分からず困っていたので助かりました。

おかげで、以前から作っていた3D迷路のゲームを完成させる事が出来ましたので
手前味噌ですが、お礼の意味を込めてQRコードを貼らせてもらいます。

http://www2.plala.or.jp/canaan/up/maze.png

ルールは、エネルギーが無くなる前に迷路を3階分踏破すれば勝ちです。
◎を踏むとエネルギーが回復します。▲が階段です。

もともと、「ウィザードリー風の3D迷路を描きたい！」と言う気持ちだけで
作り、後から無理やりゲーム性を持たせたので面白さはイマイチかもしれません。

このサイトにはプチコンで必要なソースの短縮化ロジックが多数書かれていたので
参考にさせて貰います。

では。失礼します。

1142：御茶目菜子：2012/07/03(火) 23:12:01
レスにょ
まるまるさんへ
＞こんばんは。初めて書き込みをさせて頂きます。

こちらでは初めましてにょ！

＞先日は本当にありがとうございました。
＞16×16で並んでいる色を見ただけだと規則性が分からず困っていたので助かりました。

役に立ったようで何よりにょ。

＞もともと、「ウィザードリー風の3D迷路を描きたい！」と言う気持ちだけで
＞作り、後から無理やりゲーム性を持たせたので面白さはイマイチかもしれません。

迷路ゲームとしては基本に忠実で良くできていると思うにょ。
ただ、エネルギー回復ポットの判定が気になったにょ。
行き止まりの場所で回復ポットがないのに誤判定によって回復してポットの残り数が
マイナスになるという状況が発生する場合があるにょ。

＞このサイトにはプチコンで必要なソースの短縮化ロジックが多数書かれていたので
＞参考にさせて貰います。

プログラムの可読性とリスト短縮化は相反することが多いので可読性を重視する場合には
役に立つ物は少ないですが、何かの役に立てれば幸いにょ。

1143：御茶目菜子：2012/07/03(火) 23:13:33
軽さは正義・・・なのか？
NECからUltrabook「LaVie Z」が正式発表されたにょ。
http://pc.watch.impress.co.jp/docs/news/20120703_544247.html
このLaVie Zは「999g以下」とすでに発表されており、その重量予想クイズが実施されていた
関係上詳細スペックはなかなか公開されず、このクイズの締め切りが終わってからようやく
今回の発表に至ったにょ。
そして、その重量は何と875gにょ。
これは13.3インチのノートPCとしては驚異的な軽さにょ。

13インチクラスのUltrabookの重量は概ね1.3〜1.5kgとなっているにょ。
Ultrabookの中に混じっても軽い部類となっているVAIO Zは1165gであり、通常電圧版と
ULV版の違いによる冷却機構の重量ダウンを考えれば999gという重量は十分に実現可能と
言えそうだけどそれより大幅に下回るのは難しいにょ。
限界まで軽量化しているノートPCといえばやはりVAIO Xが思い浮かぶにょ。
11.1インチ液晶ながら標準バッテリ（Lバッテリ）で765g、オプションの軽量バッテリ
（Sバッテリ）で655gという超軽量を実現しているにょ。
11.1インチと13.3インチではサイズが異なるのでこのレベルを実現するのは不可能だけど
単純に（液晶面積比で）比例計算して考えると標準バッテリとの比較ならば1098g、軽量
バッテリとの比較ならば940gとなるにょ。
もちろん外装重量と同じように内部重量が増えない限りは比例計算は成立しないのだけど
VAIO Xに使用されていたAtom Z（TDP2.4W）とULV Core i5もしくはCore i7（TDP18W）の
違いを考えると冷却機構に大きな差があるし、消費電力の面を見てもいくら省電力な
IvyBridgeとはいえAtomと比べると大きく劣るためある程度のバッテリ駆動時間を確保する
ならばバッテリ重量だけを見てもかなりのものになるため上記の比例計算と比べて大きく
軽量化をするのは難しいにょ。

しかし、「新素材によって800g台になっているらしい」という情報が予想クイズの締め切り
前に出たにょ。
http://plusd.itmedia.co.jp/pcuser/articles/1205/10/news082.html
やはり、重量にインパクトを与えるならば800g台というのは非常に大きいにょ。
海外向けに発表する場合にも2ポンド（約907g）を切っているというのは非常に大きな
インパクトを与えるだろうしね。
これらの情報から軽量化を重視したVAIO Xが「765g（ナムコ）」ならば（サイズを考慮
した場合に）それ以上の軽量化を行っているLaVie Zは「876g（バンナム）」という予想を
した人は多いのではないかと思われるにょ。
それを見越してかLaVie Zはそれよりさらに1g軽い875gを公称重量にしているにょ。
これは安易に予想を的中させないNECの策略といえるにょ（いや違うって）

このLaVie Zに使われている素材は何かというとマグネシウムリチウム合金にょ。
http://plusd.itmedia.co.jp/pcuser/articles/1207/03/news029_2.html
これはNASAが開発した新素材だけど加工が難しいため今までPCでは使用されてこなかった
みたいにょ。
どれくらい軽量なのかはNEC発表の資料を見れば明らかにょ。

　　　　　　　　　　　　　　　比重　　　同一剛性を得たときの重量（600平方cm）
　マグネシウムリチウム合金　　1.36　　　　　64g
　マグネシウム合金　　　　　　1.8 　　　　　86g
　アルミニウム合金　　　　　　2.7 　　　　 112g
　プラスチック　　　　　　　　1.25　　　　 133g
　ステンレス　　　　　　　　　7.9　　　　　228g

これを見ると軽量ノートPCならばもれなく採用されている一般的なマグネシウム合金と
比べるとさらに軽くなっていることが分かるにょ。
600平方cmというと天板より一回り小さなサイズだけどそれをすべてこの新素材に変えた
としても軽くなるのは18gでしかないにょ。
つまり、LaVie Zがここまで軽量化できたのは新素材を使ったからという単純なものでは
なくて液晶モニタ、基板までギリギリの軽量化を行っている賜といえるにょ。

軽さに関してはUltrabookの中ではダントツ1位となったLaVie Zだけどそれ以外に関しては
飛び抜けて優れているという要素はないにょ。
http://pc.watch.impress.co.jp/docs/column/hothot/20120703_544255.html
とはいえ、液晶解像度は多くのUltrabookが1366x768のWXGAとなっている中で1600x900の
WXGA++となっているのはまずまずのスペックにょ。
個人的には解像度が高ければ高い方がいいのでフルHDならばなお良かったのだけど一般的に
考えるとDPI設定を変えないと使いづらいという機種は売り辛いと思われるためこれは
スペックと無難さを天秤に掛けた場合にはベストな選択といえるにょ。
13.3インチフルHDでは166ppiとなってしまい、50cmの距離からだと人間の目の分解能と
されている300ppi（30cm時）ギリギリの高精細であるため長時間の使用には抵抗がある人も
多いだろうからね。
これが1600x900ならば138ppiとなるにょ。
この数字は11.6インチWXGAの135ppiとほぼ同レベルであり、「11.6インチWXGAでは文字が
小さすぎて使えない」という人でなければ全く問題がないレベルにょ。

ただし、メモリが4GB固定であることを懸念している人もいるかと思うにょ。
確かにかつてのようにOSの肥大化によって世代が上がるごとに数倍のメモリを要求されていた
頃では「今は十分でもすぐに不足を感じるようになる」という不安があったけどVista→7
→8とOSが最小限必要としているメモリは増加どころか減少傾向にさえあるにょ。
OSでメモリを消費しなくなってもアプリの肥大化は避けられないにょ。
ただし、そのようなハイスペックを要求するのは一部のアプリでありUltrabookでそのような
ものを使う人はほぼ居ないということを考えると4GBで問題はないのではないかと思われるにょ。
ハイスペックな要求をし始めたらメモリだけが不足ではなくCPUパワーの不足やGPUパワーの
不足も感じられるようになるわけだしね。
それにメモリが不足して重くなるのはスワップによるものなので高速なSSDを搭載していれば
そのメモリ不足時でも動作速度が遅く感じられなくなるにょ。
このLaVie Zに搭載しているSSDはREADで最大443MB/sというかなり速いSSDであるため4GBでも
それほど問題はないと思われるにょ。

またメモリの消費電力も無視できないにょ。
近年PCの省電力化が進んでいるもののいくらCPUのアイドル時の消費電力を減らしても限界が
あるからね。
同一世代、同一駆動電圧のメモリならばチップ数に比例した消費電力になるにょ。
つまり、8GBならば4GBの2倍の消費電力になるにょ。
仮に4GBのメモリの平均消費電力が1Wならば8GB搭載したら2Wになるということにょ。
それならば4GBではなく2GBにすればいいということになるけどその場合は0.5Wしか省電力化は
できないにょ。
現状では4GBでは足りるけど2GBでは不足するという場面が多いため2GBではスワップが頻発する
ことになりパフォーマンスの低下が起きてしまうにょ。
高速SSDならばそれを最小限に食い止めることができるけどスワップが頻発してしまうと
省電力の面では逆に不利になってしまうにょ。（フラッシュメモリは書き込みの際に大きな
消費電力を必要としているため）
したがって、2GBならば4GBと比べて省電力とは言い難いにょ。
もちろん、4GBでは足らなくて常時8GB付近のメモリが必要な使い方をしてれば4GBのメモリで
あっても8GBよりも省電力とは限らないけどそれは上記のようにごく一部の用途に限られるため
現在のPCにおける一般的な使い方においては4GBがベストな選択といえるにょ。（もちろん
軽さや消費電力を最重視しない場合は8GBがベターなのは言うまでもないことだけど）

バッテリ駆動時間を見てみると公称8.1時間というのは特に優れてはおらず一般的なUltrabook
とほぼ同レベルにょ。
もちろん、この公称8.1時間というのは極めて限定的な環境下で測定されるJEITA測定法に
よるものであるため一般的な使用とは異なっているにょ。
上記レビューでは5時間44分となっているにょ。
これは公称値の0.71倍となっているにょ。
液晶の明るさを実用レベルにして普通にWeb閲覧を行えば概ね公称値の0.6〜0.7倍になる機種が
多く、0.8倍を越えることは希ということを考えるとこの0.71倍というのはほぼ予想の範疇で
あるといえるにょ。
ヘビーなモバイル用途ならば実効駆動時間で8時間程度は最低欲しいところだけどUltrabook
ということを考えるとそれほどヘビーなモバイルは想定していないだろうし、バッテリ駆動
時間を伸ばすためにはバッテリ重量が多くなるため軽量化を最重視したLaVie Zの場合は実用
レベルの駆動時間を維持してそれ以上は求めなかったと思われるにょ。（Atom搭載のネット
ブックで1kgの軽量なものは筐体の軽量化にはコストをかけておらずバッテリを減らすことで
軽量化しているためバッテリ駆動時間は公称でもAtomにも関わらず4〜6時間のものが多い）

やはり、気になるのは価格だと思うにょ。
Core i5＋SSD128GBの下位モデルで予価13.5万円、Core i7＋SSD256GBのモデルで予価16.5万円
というのは低価格化が進んでいるUltrabookの中ではかなり高価格といえるにょ。
とはいえ、これは2万円相当のOfficeがインストールされているわけだし、このクラスでは
過去に例のないくらいの軽量化をしているというスペシャルな仕様を考えると決して高価では
ないにょ。（直販ならばOffice無しで109830円から購入可能）
Ultrabookの選択肢はたくさんあるのでこの軽さに価値を見いだせないならば何の特徴もない
代わりに安い機種を選べばいいだけの話だしね。
かつては小型軽量が日本の専売特許みたいなものだったけど最近はかなりそれは感じさせなく
なっていたのがこのLaVie Zでそれが復活できた感じにょ。

とはいうものの個人的にはそこまで軽さは重視しておらず、私の場合はフットプリントを重視
しているため13.3インチの段階でモバイル用途ならば選択肢から外れるにょ。
現在使っているLet'snote R5は横幅が229mmだけどこれをワイド液晶で実現するならば8.9
インチくらいでないと難しいにょ。
重さに関して言うと個人的にはモバイルノートは1kg、両手に持って使う端末ならば500g、
片手に持って使う端末ならば300gをボーダーラインに考えているためそれよりも重いもの
ならば徐々に対象から外れてしまうけど軽くてもそこまでは加点対象にはならないにょ。
液晶サイズは8.9インチでいいのでR5並の横幅を維持して実駆動8時間で800gが実現されたら
それが私にとってのベストになるにょ。
ただし、そんな機種はないにょ。
それにもっとも近いのがLet'snote Jくらいにょ。

1144：orirakkusu@3DS：2012/07/06(金) 16:28:37
うごメモネタ
先生)今日はう○こ(以下うこ)のフリーズドライ(!?)を作りますよー
A)おえっ
B)なんでやねんwwwwwwww
先生)おめえがうこを屋上から堂々と漏らしてたのが目の前の袋に入ったんだよww
B)はぁwww？証拠見せてみろよwww
TV)
　　 B
--------------
|　　うこ　　|
| 女<キャー　|
先生)どうだwww
B)いつだよwww
先生)2012/07/05 15時だよwあとこのパンツその時のやろww
B)はぁ？ちげーしwww
先生)DNA検査と指紋認証したしw
B)どんだけやってんだよw
先生)家庭科室にあったんだよw
B)うわwこの学校終わってるなwww
校長)あん？
全員)(うわぁ・・・。)
B)さてはおめぇ、やばくなったから校長呼び出したんだろww雑魚だなwww
先生)そんなん言うならこっち来いやwwwww
B)うわっ！
先生)じゃーねー♪
バコッ

1145：　：2012/07/06(金) 20:54:54
(無題)
＞うごメモネタ
ちょっと意味が分からない

1146：御茶目菜子：2012/07/06(金) 23:49:05
レスにょ
orirakkusuさんへ
＞うごメモネタ

内容が内容だけに「う○こネタ」と読んでしまったにょ（笑）
ちなみに先生とAくんとBくんのどれがorirakkusuさんにょ？

1147：御茶目菜子：2012/07/06(金) 23:52:03
○○ちゃん危機一髪
プチコンの公式サイトにおけるプレゼントとなる追加素材もついに3回目となったにょ。

第2回　http://smileboom.com/special/ptcm2/co_present/html_present02.php
第3回　http://smileboom.com/special/ptcm2/co_present/html_present03.php

第1回の時は6月23日に書いたように「ハカセ射撃」「ハカセジャンプ」を作ったのだけど
第2回の時はフォントというわけですべてのプログラムにそのまま使用できるためあえてその
フォントに差し替えたものというのは別途発表しなかったにょ。
第3回となった今回はBG画面のマップ用素材がメインとなっているにょ。
プチコンには標準で多数のプリセットキャラデータが入っているのだけど標準で入っている
BG用のチップは一般的なRPGで使える中世風ファンタジーや洞窟やSF用に使えるものが入って
いるにょ。
ただし、さまざまなジャンルのものを網羅している関係上特定のゲームを作る場合には
チップの種類がやや不満が多かったにょ。
それに多くのチップが8x8単位となっているため自キャラが16x16であることを考えるとやや
使いづらいというのが難点だったにょ。

ということで、今回発表された追加素材は16x16を基本としており、標準ではやや不足をして
いたフィールドマップ用のものとなっているにょ。
海や山というごく基本的なチップも標準では用意されてなかったからね。
これによって普通のRPGは作りやすくなるし、RPGに限らずフィールド移動のあるゲーム全般に
おいて役に立つのではないかと思われるにょ。
あと、道路や建物なども用意されているため現代をモチーフとしたゲームも作りやすくなって
いるにょ。

さて、今回の追加素材のもう1つの注目点は新キャラ「ダミーちゃん」の追加にょ。
プチコンはキャラが4人もいるのにつぐみさん成分が無かったからね（笑）
といっても、いきなり無関係の女性キャラを登場させるわけにはいかなかったのかAI
（人工知能）という設定になっているにょ。
ダミー（DMMY）の名前の由来は恐らくかつて工画堂スタジオから発売された人工知能搭載の
ギャルゲー「EMMY」が由来だと思われるにょ。
このダミーちゃんについてはMONOistのプチコン虎の穴の第3回を見るといいと思うにょ。
http://monoist.atmarkit.co.jp/mn/articles/1207/04/news001.html
コンソールキャラだけで描かれたダミーちゃんはなかなか秀逸にょ。（PCGで書き換えれば
もっと緻密にできるけどデフォキャラだけで表現というのもある意味重要）

しかし、追加キャラがあっても例のごとくパターン数の少なさを何とかカバーできるような
ゲームを考える必要があるにょ。
というわけで、速攻で作ったのがこの「ダミーちゃん危機一髪」にょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/dmmy_chan.htm

これはタイトルからすぐに想像が付くように「マ○ちゃん危機一髪」をインスパイアした
ゲームとなっているにょ。（伏せ字にする意味がなかったり・・・）
これを作るに至った経緯はこんな感じにょ。

　新キャラが追加されているけどいいゲームのネタが思いつかない
　　　　↓
　葛城コニミル氏がプチコンで作っていたマリちゃん危機一髪の動画を公開（7/5 PM9時半）
　　　　↓
　マリちゃん風のじゃんけんゲームならばすぐに作れそう
　　　　↓
　とりあえず完成！（7/6 AM1時半）

ということで、構想から完成まで4時間のゲームにょ（笑）
ステージ構成やゲームシステムを考えたり下記の包丁グラフィックの作成の時間やデバッグの
ためのテストプレイなどがあるから実質3時間弱くらいの制作時間となっているにょ。
開発速度優先プログラムとなっているのでリスト短縮はされてないにょ。
GRPに描画されている「包丁を持った手」のキャラはGPAGE 1にGLINEを使って描画しているにょ。
これはコニミル氏のマリちゃんでもやっているけどかつての8ビット機の時代ではこれはごく
一般的なものだったにょ。
このGLINEの座標は特にツールは使用しておらず脳内で座標展開してそれを直接プチコン上に
数字入力して作っているにょ。
さすがに脳内だけだと誤差があるので部分的に数字を微調整しているもののこれくらいならば
ツールなんて使うまでもないにょ。
座標計算はポケコンでもよく行っていたのでこれくらいならばまだ余裕なんだけどさすがに
顔グラフィックを同じようにやったら微調整しまくりになるのでツール無しだとかなり厳しい
と思われるにょ。

とりあえず、ダミーちゃんのキャラはこのゲームならばパターン数の少なさは問題ないし、
背景には今回用意されたBG画面用素材を使うことにしたのでその点も問題ないにょ。
その素材の使用方法に書いている、水辺、雪原、毒の沼のアイデアもそのまま頂くことに
したにょ（笑）
せっかくなので、前回（第2回）で追加されたフォントも使うことにしたにょ。
やはり、メッセージが多いゲームなのでひらがなフォントが活用できるにょ。（カタカナも
標準のものより見やすい追加素材の方を使うことにした）
ただし、単純にひらがなフォントに置き換えてしまうとカタカナが使えないという問題がある
ため厄介にょ。
カタカナはゲーム内で使用しないキャラコード96（&H60）〜159（&H9F）のキャラを書き換える
ことでひらがな、カタカナの共存が可能になるにょ。（ただしアルファベット小文字は使う
ことができない）
これによって、「ひらがな」「カタカナ」の追加素材データをプチコンに保存していない
場合でもデフォのカタカナ表示によって問題なくゲームをプレイすることも可能になって
いるにょ。（あらかじめカタカナを96〜159に割り当てたリソースを読み込ませて使用する
ゲームの場合はリソース無しでプレイすると文字化けしてプレイができない）

このプログラムではとくにこれといったテクニックは使用していないのでリストを見ても
参考になる部分は少ないのだけどじゃんけん部分について書いておくことにするにょ。
じゃんけんの勝敗判定部分はTipsコーナーの「剰余を使ったリスト短縮」ですでに書いて
いるのでそれを参考にしてもらうとしてここではコンピュータの出す手の決め方について
書いてみるにょ。
多くのじゃんけんゲームはA=RND(3)のように単純に0、1、2の3つの値をとる乱数によって
相手（コンピュータ）の出す手を決めていると思うにょ。
しかし、このゲームでは簡単ながら思考ルーチンを導入しているにょ。
これはプレイヤーの出す手をパターン分析してそれによって次に何を出す確率が高いかを
考えてそれに勝つ手を出すようにしているにょ。
例えばプレイヤーは「バーの後にグーを出すことが多い」ならば、コンピュータはグーに
勝てる「パーの確率を高める」ようにしているにょ。
この方法は、昔、ポケコンで野球拳を作っていたときに考えたものであり、単純ながら
「どうせじゃんけんだから適当に押しても問題ない」ということで適当なプレイをして
いたらコンピュータに勝つのは難しくなるため運の要素が非常に高いじゃんけんゲーム
であるにも関わらず戦略性を高めているにょ。

あと、じゃんけんゲームの場合はグー、チョキ、パーをどのボタンに割り当てるかという
ことも重要になってくるにょ。
タッチパネルを使えば直感的に操作が可能だけどボタン操作の場合はDSのボタンが3つ横に
並んでいるわけではないのでどの配置となっているのか慣れて覚えるか画面を見ながら
そのボタンを押すしかないにょ。
しかし、ボタンを良く見ていったら何となく「B」がグー、「Y」がチョキ、「X」がパー
に見えてきたのでこれは簡単に解決したにょ。
余った「A」ボタンは画面送り用に使えば誤動作防止となるのでボタン配置はこれ以上ない
というものになっていると思うにょ（笑）

このゲームは当初はコンティニュー不可だったので恐ろしく難易度が高いゲームだったため
これではさすがに厳しいと思ってダミーちゃんが死ぬまでは何度でもステージの最初から
やり直せるようにしたにょ。
そうしたらかなり難易度が落ちたにょ。
ただ、twitterで公開したあとに気づいたけどテストプレイを重ねるとさすがにこれでは
簡単すぎる気がしてきたにょ。
理由を考えると野球拳ならばコンピュータが勝ったら服を着る場合が多いため服（＋下着）を
5枚着ているならば5回多く勝つ必要があるにょ。
プレイヤーが10勝ならば負けは5回まで許されるということにょ。
しかし、このゲームにおいては5回負ける前に5回勝てばいいのでそれと比べた場合には
かなり楽になっているにょ。
その辺は急にトライ機能（ステージ最初からやり直し機能）を導入したためバランス調整
不足は否めないにょ。
まぁテストプレイに十分な時間をかけてないからやむを得ないけどね。（普段はテスト
プレイを非常に重要視しているけど今回は開発速度最優先だったので妥協した）
とりあえず、その部分だけはver1.1で必要勝利数を変更してステージ1はプレイヤーは
5勝で勝てるけどステージ2は6勝、ステージ3は7勝必要にしたにょ。（それとver1.1では
刺された変質者の顔グラフィックを変えてなかったのを修正するなどの微修正をしている）

1148：orirakkusu@3DS：2012/07/07(土) 06:23:09
(無題)
PRG:OCHADMMYの205-の簡素マニュアルがまちがってる。
205>' ■■タイトル■■
って
205>'■■ダミーチャンキキイッパツ■■
じゃない？

1149：　：2012/07/07(土) 15:05:41
(無題)
変質者…

1150：御茶目菜子：2012/07/07(土) 20:37:53
レスにょ
orirakkusuさんへ
＞PRG:OCHADMMYの205-の簡素マニュアルがまちがってる。

ちゃんと簡易マニュアルを見てくれていたとは・・・。
テンプレから変えるのを忘れてたにょ（笑）

QRコードを差し替えるついでにデバッグモードを搭載したにょ。
[SELECT]ボタンを押しながら起動するとデバッグモードになり、コンピュータがプレイヤーの
手をどのように分析しているのかが分かるようになるにょ。
表示されている数字は次にプレイヤーが「グー」「チョキ」「パー」のどれを出すのかを予想
した確率となっているにょ。

あと動画も公開したにょ。
http://www.youtube.com/watch?v=09Ne1KZfhOU


名無しさんへ
＞変質者…

実はダミーちゃんを開発したハカセが自分の言うことを聞いてくれないダミーちゃんを
消し去ろうとするといったバックボーンストーリーを考えていたけど面倒くさいから
「ダミーちゃんを狙う変質者でいいや」となってしまったにょ（笑）

1151：orirakkusu@3DS：2012/07/08(日) 07:27:12
(無題)
腹減ったからジュース飲んで〜
熱いのも今日でおさらば〜(エアコンがつく
さてHPの整理しなきゃね〜
ああーWindousの機能ネタどうしよう〜
あーうごメモの声投票しなきゃね〜
あーーーー時間がなくなって行く〜
ちゃっちゃん！
ぱちぱちぱち(あ？

1152：わぁぃ@：2012/07/08(日) 09:17:59
(無題)
プチコン大好きクラブでスクリーンショット撮影サービスを始めた。
カメラを使わず、SDからGRPとしてPC直接転送するので、公式サイトにあるようなものが撮れる。
それだけ。

1153：orirakkusu@3DS：2012/07/08(日) 11:34:54
チャット
http://www.geocities.jp/orirakkusu/chat.html
でけた。

1154：御茶目菜子：2012/07/08(日) 21:07:18
レスにょ
orirakkusuさんへ
＞熱いのも今日でおさらば〜(エアコンがつく

私の部屋は扇風機のみにょ。
むしろノートPCが暖房代わりにょ（笑）
デスクトップPCよりはマシだけど3台同時使用しているのでそれなりの熱はあると思うにょ。

＞ああーWindousの機能ネタどうしよう〜

私は試しに作ってから放置状態にょ。

＞チャット

そういえば最近は絵チャしか使ってないので普通のチャットはここ何年も使ってないにょ。



わぁぃ@さんへ
＞プチコン大好きクラブでスクリーンショット撮影サービスを始めた。

確かに「簡易スクリーンショットカメラ」は便利なプログラムだと思うけど色の問題と
表示優先順位問題があるので自動的にキャプチャするのは難しいにょ。
CHKCHRやSPREADではパレット情報を取得できないためGPUTCHRでGRP面に描くのはパレット0に
しているけどこれだとパレット0以外を使用している場合には正常な表示を行うことが
できないにょ。
それを行うためにはキャラ1つ1つに対して手動でパレット情報を設定するしかないけど
そうなると今度はGPUTCHRを使用するとGRPのパレットが書き換わるという問題が発生して
しまうにょ。（その使用するパレットで書き換わる16色を使用していなければ問題ないけど）

次に問題なのは表示優先順位だけど現状のプログラムだと奥から順にGRP/BG/SPとなっている
場合にしか使用できないにょ。
例えば「ダミーちゃん危機一髪」では、奥から順にBG/SP/GRPとなっているため正常に
GRP面にすべて表示するためには一端最初にGRP面に表示しているものを使用していない
GRP面にコピーしてBGキャラをGPUTCHRで描画、SPキャラをGPUTCHRで描画した後に再び
その上に元の面にあったGRPをコピーする必要があるにょ。

これによって、すべてのキャラを正常にGRP面に描きこむ場合には1つのキャラごと手動で
行わないといけない場合が多くあると思うにょ。（現状のプログラムだと16x16以外の
スプライトはそのままでは描画できないし）
これは結構たいへんな作業になると思うので頑張ってにょ。

1155：わぁぃ@：2012/07/08(日) 22:50:35
簡易スクリーンショットカメラ
確かにスプライトがものすごく大変。
実際、GGKDSのメモ帳使用時を撮影したとき、カーソルが8×8のスプライトだったので面倒だったのだが、点滅しているのをいいことに写さなかった。
パレットの重複回避はプログラムでできそう。
使用したパレットを記録して、重複しそうになったらパレットを書き換えればいい。

1156：otyaken：2012/07/08(日) 23:37:55
(無題)
osもどきの正式名称を決めた
その名も
otyaX!
(何かに名前が似ている気がしなくもない)
あと昔（初代）作ったボタン取得ルーチンが汚かったので書き直した。

1157：御茶目菜子：2012/07/10(火) 00:02:00
レスにょ
わぁぃ@さんへ
＞確かにスプライトがものすごく大変。

やはり、スプライトの定義サイズや優先順位や使用パレット番号を取得できる命令がない
というのが辛いにょ。
自動的に処理をすることができないため下手をするとスプライト1つずつプログラムを解析
してサイズやパレットを手動で指定してGRP面に描く必要があるからね。
パレット問題は例えば「JUMPING ISLAND」でスコア表示の文字を本来の赤（パレット13）で
GRP面に描画すれば地面の色（GCOLOR 223）も赤になってしまうにょ。
GCOLOR 223をのパレットを書き換える（本来の緑色にする）と文字の色も赤ではなくなる
という問題が起きてしまうにょ。
したがって、GCOLOR 223以外の色を使って地面を表示してCOLSETでGCOLOR 223と同じ色に
なるようにパレットを書き換える必要があるにょ。
しかし、当たり判定にGSPOITを使っている場合は安易に色を変えられないのでプログラムの
解析も必要になってくるにょ。（JUMPING ISLANDならばGCOLOR 200番台の色ならば問題ない
けど他のプログラムもそうとは限らない）

結局、問題があったらその都度プログラムを書き換えて対応するしかないにょ。



otyakenさんへ
＞osもどきの正式名称を決めた
＞その名も
＞otyaX!

なかなかそれっぽい名前にょ。
私なんて「Petitcom OS」（仮称）だからね。
もしも、続きを作る機会があれば「Ochame」の文字を入れることにするにょ。

1158：御茶目菜子：2012/07/10(火) 00:04:26
やっぱり、セルフ開発できないと・・・
私がポケコンにハマったのは「お手軽」かつ「いつでもどこでもプログラミングできる」
というのが大きいにょ。
「お手軽」というのは初心者でも扱い安い高級言語のBASICを搭載しているということや
ハードウェアキーボードを備えているというのが大きいにょ。
「いつでもどこでもプログラミングできる」というのは本体が小型軽量で長時間駆動ができ
そして欠かせないのがスタンドアローンでセルフ開発可能なことにょ。

ポケコンに出会う前にすでにパソコン（当時は「マイコン」と呼んでいた）に触れていた
ために当時は主流だった1行表示（機種によって異なるけど1画面に12〜24文字しか表示
できなかった）のポケコンを見て「これがコンピュータなのか」と思っていた部分もあった
けれど実際に触ってみると「ちゃんと自作プログラムが動く」ということでその不安点は
払拭されたにょ。
当時パソコンが欲しくても買えなかった（PC-8801ならば本体＋モニタで20万円以上していた）
けどポケコンならば安い機種ならば1万円台なので小遣いを数ヶ月分ためれば何とか手が
届く金額であるためポケコンを買うことにしたにょ。
まぁ「ちっちゃいものが好き」というのもかなり影響しているけどね（笑）

ここで難しいのは当時ポケコン界のトップ2であるカシオとシャープのどちらにするのか
ということにょ。
周りに使っているユーザーが多かったのと自由にキャラ表示を行えるシャープの機種に
することにしたにょ。
ただし、予算の関係もあって買えたのはローエンドのPC-1245だったけどね。

このPC-1245はメモリ2.2KB（この2.2KBにはVRAMなどのワークエリアや変数記録専用の領域を
含んでいるため実際にユーザーが使えるのは1486バイト）、12文字表示の液晶ということで
上位機種のPC-1251やPC-1255と比べると見劣りしていたけどメモリと画面サイズ以外は同一で
あるためソフトウェア資産を生かすことが可能にょ。
このPC-12xxシリーズは後継となったPC-1246系を除けばPOKEでVRAMに直接データを書き込む
ことでオリジナルのキャラ表示（グラフィック表示）が可能だったということが上記の
ように私の大きな選択ポイントになったにょ。
ただし、その反面コンソール（文字）のみでゲームを作る場合にはカシオのPB-100シリーズ
と比べて大きく劣っていたにょ。
それは、PB-100系はPRINT CSRで12桁の液晶の自由な位置に（LOCATE表示と同じ）文字表示が
できたけどシャープのPC-12系（126x系を除く）はそれができなかったからね。
それに使用できるキャラ数もPB-100系の方が多く文字だけでゲームを作る場合にはかなり
不利な立場だったにょ。（PC-12系は演算中は文字が消えてしまう仕様であるためそれを
防ぐにはCALL &11E0としてLCDをONの設定にする必要があったけどPOKEやCALLは隠し命令
扱いだったためマニュアルには記載されていない）

それに処理速度の面もPB-100系の方が速かったにょ。
何せPC-1245はFOR〜NEXTの1000回ループで42秒もかかったからね。
これは同じシャープのポケコンでも最近まで現役機種だったPC-E650が1.4秒であるため
30倍の速度差となるにょ。（FOR〜NEXT以外はそこまでの差はないけどそれでも10倍以上
PC-E650より遅かった）
しかし、PC-12系はPB-100系と比べて圧倒的に優れている点はマシン語が使えるという点にょ。
VRAMに直接書き込むことでグラフィック表示が可能になるとはいえ、速度面ではかなり
厳しかったからね。
アクションゲームなんてとても実用レベルという速度は無理で固定画面のゴルフゲーム
とかのそこまで処理速度を要求しないゲームが精一杯だったにょ。
「ポケコンマシン語入門」を片手にハンドアセンブルして簡単なマシン語プログラムを
作ってみたけどマシン語の場合は事前にセーブすることが必要不可欠だったにょ。

当時セーブする媒体といえばカセットテープだったにょ。
部屋の中をあさったらポケコンプログラムをセーブしたカセットテープが見つかったにょ。
http://twitpic.com/a5p4zy
たぶん部屋の中を探せばさらに10本くらいは見つかりそうにょ。
ちなみに新品のカセットテープもあったにょ。
http://twitpic.com/a5p77i
今は無き「パソコン用カセットテープ」にょ。
昔はFDは高価であり、8ビット機の時代はパソコンでもカセットテープによるプログラムの
保存はポピュラーなものだったにょ。

当時のポケコンの記録速度は300bpsであったため2KBのプログラムのセーブやロードに
約1分かかる計算となるにょ。（PC-1245を購入当初はカセットデッキと接続するインター
フェイスを購入する予算が無かったのでプログラムはすべて紙に書き写すという原始的な
方法で保存していたためカセットに記録できるというだけでもかなりの恩恵があった）
PC-1245は1486バイトだったけど次に買ったPC-1401は3534バイト、PC-1350は3070バイトで
あったため1分半〜2分必要だったにょ。
カセットテープの場合は音量などの調整をしないとロード時にエラーが発生することが多く
あるためセーブやロードが頻発するだけではなくアセンブラは非搭載であるため紙に
アセンブラを記述した後にニモニック表を見ながらハンドアセンブルをしなくては開発
できなかったマシン語はポケコンの手軽さを損ねることになったにょ。（脳内でバグ無しの
プログラムを書けてニモニック表を無しで直接入力できる人ならばまた変わってくるだろう
けれど私はマシン語をそのレベルに達することはできなかった）

PC-1245が故障してから次に買ったのは上記のようにPC-1401にょ。
これはPC-1245と同じ12桁表示の液晶だけどCPUのクロックがPC-1245の576KHzから768KHzに
なっているため演算速度の高速化が行われており「高速版PC-1245」として重宝したにょ。
メモリもPC-1245の上位機種のPC-1251と同じ3534バイトだし、購入当時の価格はPC-1251
よりも安かったからね。（ただし、ROMアドレスやフリーエリアのアドレスが異なるため
POKEやCALLを使ったBASICプログラムや絶対ジャンプを使ったマシン語プログラムは作り
変えないと動作しなくなってしまった）
それに、電卓モードが搭載され関数電卓感覚で計算可能になったのは便利にょ。
元々ポケコンはRUNモード（プチコンで言うと実行用モード）とPROGRAMモード（プチコンで
言うと編集用モード）を備えておりRUMモードではプチコンとは異なりPRINT命令を使わなく
ても「2*3[ENTER]で6を表示可能」なものだったので電卓モードが無くても電卓的な使い方は
できていたけどね。

PC-1350を買ってからは画面サイズが大きく（24文字x4行と当時のポケコンの中では最大
クラス）、直接VRAMにPOKEで書き込まなくてもPSETやLINEやGPRINTといったグラフィック用
命令を備えているためBASICでもグラフィカルなゲームを作れるようになったにょ。
また演算速度もPC-1401と同レベルであり、PC-1245と比べれば速いとはいえ、それでも画面
サイズの割にかなり遅かったため100m走のプログラムをBASICで書いたら表示を簡略化しても
9fpsしか出なかったため連射ではなくボタンを押すタイミングを重視したゲームとなったにょ。
そこで重宝したのが「ポケコンマシン語ブック」に掲載されていた「BASICコンパイラ」にょ。
一部互換性のない命令があり、BASICプログラムはそのまますべて使えるというわけではない
もののBASICで普通に作ったものと比べ簡単に10〜30倍程度の速度が得られたにょ。
PC-12系用にも「ポケコンパイラ1251」があったもののPC-1245ではメモリ不足で使えなかった
けれどメモリが標準で3070バイトあるPC-1350ならばコンパイラを使用してもフリーメモリが
1000バイト少々あるため簡単なアクションゲームは十分に作れたにょ。
カセットテープによるセーブ、ロード地獄から逃れられたわけではないけど速度面においては
不満がないレベルになったにょ。

ポケコンはカセットテープにしかプログラムを記録できないというわけではなくオプションで
FDDも用意されていたにょ。
ただし、シャープのポケコン用に用意されたポケットディスクは厳密にはランダムアクセスが
できないクイックディスクと同じ原理の製品であり、片面64KB（両面128KB）の記録容量にょ。
それで、定価が49800円（メディアが10枚で5000円）というのは当時としてもやや高めの価格
設定だったにょ。（あまり売れないオプションだから仕方ないけど）
やはり、プログラムを保存する媒体として重宝したのがメモリーカードにょ。
ただし、今で言うとSDカードのような汎用品ではなくプレステやPS Vitaのメモリーカードの
ような専用品だったにょ。（当時は汎用規格そのものが無かったから当然だけど）

ちなみに私の手元にあるのは8KBと32KBのメモリーカードにょ。
http://twitpic.com/a5pafi
これは8「GB」でも8「MB」でもなく8「KB」にょ。
これで定価が18000円だったからいかに当時とはいえ割高感は否めなかったにょ。
これも大量に売れないオプションであるから仕方ないことだけど・・・。
メモリーカードはPC-1350用のは持っておらず、これはその後継機種PC-1360以降のポケコンで
使えるものにょ。
このメモリーカード（RAMカード）はメインメモリと同じSRAMが使用されているため単なる
外部記録装置ではなく動作用メモリ（メインメモリ）の拡張用にも使えたにょ。（本体メモリを
メインにするかRAMカードをメインにするか、合算したものをメインにするかはMEM$命令で
簡単に設定できるけどこれはプチコンのMEM$とは全く異なるものとなっている）

さて、やはり開発環境が大きく変わったのはPC-E500の登場だと思われるにょ。
PC-E500はPC-8801（初代）に匹敵する演算速度（ただし、表示に関してはPC-88と比べたら
さすがに完敗だった）を持ちポケコンの中では当時最速でありPC-1350と比べると何と5倍以上の
速度だったにょ。（それに標準で32KB、フリーエリアも28600バイトもメモリがあったため
当時としてはすごい大容量だった）
そして、プログラムの高速化を駆使（普通に組んだ場合と比べて2〜5倍速になり、雑誌掲載の
プログラムでも平均3倍速を実証済み）すればPC-1350のBASICコンパイラ以上の速度となった
ためにマシン語を使わなくてもBASICでもそれなりに高速なゲームを作れるようになったにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/basic1.htm
もっともその高速なポケコンもプチコン（ver.1.1）と比べた場合でも60〜100倍くらい遅い
のだけど・・・。
http://ww5.tiki.ne.jp/~ochame/petitcom/what.htm

PC-E500系はPC-1350と互換性があるGRPINT命令によるグラフィックキャラ表示も行えるけど
それは非常に遅いためフォント書き換え（プチコンではBGF0をCHRSETで書き換えるPCGに相当
するもの）がポピュラーなテクニックとして定着したにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/TECH005.HTM
さらに、その「フォント書き換え」を応用したOPASを使えばドット単位の横スクロールゲームも
作れるようになったにょ。（プチコンでいえばPCGを駆使してBG画面によるスクロールのような
ものを実現している感じだけどこれはポケコンのPCGの柔軟性が高いからこそ実現可能になった
機能といえる）
http://ww5.tiki.ne.jp/~ochame/E500/TECH/OPAS.HTM
演算速度は現在唯一の現行生産されているポケコンである「PC-G850VS」と比べて半分くらい
しかないものの上記のフォント書き換えやOPASを使えばゲーム作成においては速度面では有利な
立場に立てるわけだし、RAMカードが使えるし、BTEXT$によってセーブ無しで複数のプログラムの
同時編集が可能になるためお手軽さはポケコンの中でもナンバーワンといっても過言ではない
感じにょ。
PC-E500が経年劣化が原因ボタンが言うことを効かなくなり（それが発端となって接触不良を
招き動作自体しなくなった）、PC-E650に買い換えたけどそのE650も3月27日に書いたように
液晶破損で使えなくなってしまったにょ。

お手軽プログラミング環境といえばやはり最近ハマっているのはプチコンにょ。
プリセットキャラが豊富に用意されているためグラフィカルなゲームも手軽に作れるし
処理速度を考えなくてもよほど重いゲームでない限りは快適な動作が期待できるため
（いくらポケコンの中では速いPC-E500系とはいえ速度を意識して高速になるように
プログラミングしなければならない）ポケコンと比べたらプログラミングのハードルは下に
なる（より簡単にゲームが作れる）かもしれないにょ。
http://ww5.tiki.ne.jp/~ochame/E500/LECTURE/making_3.htm
ソフトウェアキーボードも当初はかなり厳しかったけど慣れれば普通に両手持ちで親指で
高速タイピングも可能だしね（ただし、タイプミスも多いため3DS LLが欲しいところ）
また、いつでもどこでもプログラミング可能かどうかという点に関しては3DSは十分小さい
ので気にならないにょ。
むしろ、ほぼバッテリ残量が気にならないポケコンと異なり、3DSだと4時間くらいで
バッテリ切れになるためその点がやや不満なところにょ。
あと、当初問題だった手軽に公開できないという点に関してはmkIIでQRコードに対応した
ために全く気にならなくなったにょ。（とはいえ、大量のリソースを使ったり、数1000行の
大作プログラムを作るとQRコードを公開する側も読み取る側も大変だけど）

では、プチコンでポケコン（PC-E650）の代わりができるかというと微妙にょ。
それは1つはバッテリ駆動時間の短さもあるし、もう1つは電卓的な活用ができないという
ことにょ。
PC-E650は標準で倍精度演算（有効数字20桁の浮動小数点演算）を備えており、かつBCD演算
であるため非常に演算誤差が少ないため電卓として考えた場合には極めて優秀な存在にょ。
それに対してプチコンは32ビット固定小数点であるため演算誤差が大きくそれがおきにくい
ようにするためにはプログラムも工夫が必要になるにょ。

ゲームを作るならばプチコンの方が絶対的に有利なのだけど向き不向きがあるからね。
しかし、「お手軽」かつ「いつでもどこでもプログラミングできる」という点を満たせる
ものがあればそれも使ってみたいところにょ。
以前、P/ECEでのプログラミング（C言語に関しては、四半世紀前に「はじめてのC」で少し
勉強した程度であり、昨今ポピュラーなC++は未経験）も一時期やったことがあるけどPCで
開発してそれを転送して実機で動作させるというクロス開発は私には向かないと思ったにょ。
やはり、スタンドアローンでセルフ開発できないと駄目ということにょ。
スマホ用アプリでも様々な開発言語アプリが登場しているけど使い勝手のよいものがある
ならばそれも一度試してみたいところにょ。

1159：otyaken：2012/07/10(火) 23:18:55
(無題)
otyaXにWindows XPの壁紙を取りこんでみた。
おかげてこっちの方がWindousよりWindowsっぽいw
スクショは日記の方にある。

1160：otyaken：2012/07/11(水) 07:39:05
(無題)
スクリーンショットのアイデア思い付いた。
まずグラフィック面を保存
SAVE"GRP"+STR$(I)+"SSGRP"+STR$(I)
次にBGを写して保存
SAVE"GRP:SSBG~
次にスプライトを保存
SAVE~
後はpcで合成

1161：orirakkusu@3DS：2012/07/11(水) 15:56:16
(無題)
プチコンばかりじゃなく他のも..
と思ってWii Sports Resortをやったら右肩が痛くなりました。
でもこらずに今日もやりますw
# 有野課長は岩手で無事にパイロットウイングスをクリアしたようです。

1162：orirakkusu@3DS：2012/07/11(水) 19:47:11
(無題)
いまさらかもしれないがJUMPING ISLAND攻略中。

1163：御茶目菜子：2012/07/11(水) 22:04:05
レスにょ
otyakenさんへ
＞otyaXにWindows XPの壁紙を取りこんでみた。

初代の頃はそういうことができなかったけどmkIIは有志が作ったツールのお陰でPCでデータを
作って簡単に取り込めるようになったからね。
いかにうまく減色するかが鍵にょ。
単純に減色するだけではなくタイルパターンを駆使すればさらに見た目が良くなるにょ。

＞スクリーンショットのアイデア思い付いた。

まぁPCを使えば後の加工はいくらでもできるからね。
とはいっても、どんどんSSから遠ざかっていっている気がするにょ（笑）
ただし、この場合でもスプライトは優先順位を考えてGRPに描かないと正確に再現できないにょ。
一番いいのはPC上で動作するプチコンエミュレータ（プチコンシミュレータ）を作ること
だけどそれはかなり難易度が高いにょ。



orirakkusuさんへ
＞プチコンばかりじゃなく他のも..
＞と思ってWii Sports Resortをやったら右肩が痛くなりました。

私はプチコンを買ってから他のソフトを全然遊んでないにょ。
800円でこれだけ遊べたらコストパフォーマンスは抜群にょ（笑）

＞いまさらかもしれないがJUMPING ISLAND攻略中。

プレイどうもにょ。
難易度は大して高くないので全面クリアは簡単にできると思うにょ。
だからクリア後にいかにスコアを稼げるかがポイントになるにょ。
難しいルート（ロングジャンプを駆使しないと進めないルート）の方がスコア面で有利に
なるためただクリアするだけと比べてハイスコアルートは難易度が格段に上がるにょ。
ぜひ、私のスコアを超えて欲しいにょ。（ステージ1とステージ9の私の記録はリプレイ
データを参照）

1164：orirakkusu@3DS：2012/07/11(水) 22:07:53
(無題)
otyaXに抜かれたくない！
が、なんのしようもない。
...どうすればいいんだ俺！

1165：otyaken：2012/07/11(水) 23:14:33
otyaX
キーワード作ってみたけど、スクリーンショット多いw
結構アップしていたんだなー
日記に2種類の壁紙の画像貼ってみた。

1166：orirakkusu@3DS：2012/07/12(木) 15:15:46
(無題)
PetitEditorを解析してプチコンでプチコンのQRが作れるプログラムつくったらどうかなー

1167：otyaken：2012/07/12(木) 17:52:05
(無題)
QRコードを作成するプログラムはあるのでそれのデータをいじるだけでいいかもと思った。

1168：御茶目菜子：2012/07/12(木) 23:52:53
レスにょ
orirakkusuさんへ
＞otyaXに抜かれたくない！
＞が、なんのしようもない。
＞...どうすればいいんだ俺！

「草原」を15色に減色してみたので良かったらWindousの壁紙に使ってみてにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/sample/sougen.htm

＞PetitEditorを解析してプチコンでプチコンのQRが作れるプログラムつくったらどうかなー

ファイル関係が弱いプチコンでは難しそうにょ。
作るとしたらまずプログラム本体をGRPに書き出すところから始めないといけないにょ。
これは自動化ができないのでファンクション経由で1行ずつ行わなくてはならないので1000行
くらいのプログラムならばすごく大変な作業にょ。
これができたらようやくQRコード化だけどZIP圧縮しないと枚数が増えるのでZIP圧縮
ルーチンも自作しないといけないにょ。

しかし、2台のDSi（3DS）本体を使って片方でQRコード表示、片方でQRコード読み取りをする
くらいならば2台の本体を直接ファイルのやりとりすればいいだけの話に思えるにょ。
まぁネタプログラムとしてならばありだと思うけどね。

あと誕生日おめでとうにょ。



otyakenさんへ
＞キーワード作ってみたけど、スクリーンショット多いw

こうしてみるとどのように改良してきたかが良く分かるにょ。

＞QRコードを作成するプログラムはあるのでそれのデータをいじるだけでいいかもと思った。

まとめWikiのやつはQRコード生成部分だけなのだけどプログラムそのもののQRコードを本体
のみで作成する場合はQRコード生成の準備をする方が大変にょ。

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