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

おちゃめくらぶ掲示板

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


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

さっきは結構降っていたにょ。
また詳しくは明日書くにょ。
1471：御茶目菜子：2013/02/07(木) 23:28:05
レスにょ
天郷思音さんへ
蠣焼くときは火気に注意と下記→牡蠣焼くときは下記に注意と下記に書き

となったにょ。（by ATOK16）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


《　2/13　追記　》

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

変更しておいたにょ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　(1)性能
　(2)従来との互換性
　(3)コントローラ
　(4)価格
　(5)ソフト

(1)まずは気になるのはPS3と比べて何倍くらいの性能かということにょ。
ここで分かっているPS4の性能指標はGPUの1.84TFlopsというものにょ。
これは1秒間に1.84T回（1T≒10^12）の浮動小数点演算を行える理論性能があるというもの
だけど実はPS3では発表当初は「システム全体で2TFlops」と公式に発言されていたにょ。
それはCPUであるCellが218GFlops、GPUであるRSXが1.8TFlopsという内訳だったにょ。
この数字だけを見ると「PS3とPS4の性能はあまり変わらない」と言えるにょ。
しかし、これは正しくないにょ。
それは、PS3のRSXが1.8TFlopsに達することがないためにょ。
独自計算式で1.8TFlopsになったのだろうけど普通に計算すると下記のようになるにょ。

　RSX　8VS 24PS 500MHz
　 (4+1)x2FP/cycle x 8 VertexShader??x 500MHz　　　　 ＝　40GFlops
　(4x2x2FP + 2x2FP+7)/cycle x 24 PixelShader x 500MHz ＝ 324GFlops
　　　　　　　　　　　　　　　　　　　　　　 　　　　合計364GFlops
　G70のPS、VSのFlops計算方法は下記参照
　http://pc.watch.impress.co.jp/docs/2005/0622/kaigai193.htm

これからするとGPUだけを見ると5倍になっているにょ。
ただし、これは単純に理論演算性能を比較したものであり実際の性能差を表しているわけでは
ないにょ。
演算速度が高いからといって高い描画性能があるとは言えないし、理論値が高くても実効値が
高いともいえないからね。
では、PS4のGPUがどの程度のものなのかは、すでにRadeonのHD7xxxシリーズで採用されている
GCNであることが分かっているためある程度想像が付くにょ。
それは、18個のユニットで1.84TFlopsという数字で判断が可能にょ。
GCNは1ユニットが16x4基（SP）のRadeonコアで構成されており18ユニットではRadeonコアは
1152SPとなるにょ。
1SPで1クロックあたり2Flopsであるため1.84TFlopsになるのは799MHzであるためPS4のGPUは
800MHzと予想できるにょ。
これは概ねRadeon HD7850クラスといえそうにょ。（さすがにFlops性能をGPUメーカーが正式
発表していなかったPS3の時とは異なり、NvidiaもAMDも新GPUが出るたびにFlops性能を発表
しているためこの1.84TFlopsというのがいろいろ盛りまくった数字であるとは思いにくい）

　Radeon HD7970 2048SP 925MHz→　3.79TFlops　TDP250W
　Radeon HD7950 1792SP 800MHz→　2.87TFlops　TDP200W
　Radeon HD7870 1280SP 1GHz　→　2.56TFlops　TDP175W
　PS4用GPU　　　1152SP 800MHz→　1.84TFlops
　Radeon HD7850 1024SP 860MHz→　1.76TFlops　TDP130W
　Radeon HD7770??640SP 1GHz　→　1.31TFlops　TDP 80W
　Wii U用GPU　　 320SP 550MHz→　 352GFlops

PC用のGPUの中ではミドルクラスの性能であり、決して高性能なものではないけどPC用の
GPUはハイエンドなものだとTDPが200〜300W（最上位となるデュアルGPUになるとTDPは
400〜500W）に達しておりコスト面でも消費電力の面でもコンシューマゲーム機に搭載は
極めて困難であるためゲーム機用のGPUとしては無難な選択肢ではないかと思われるにょ。
ちなみにWii Uと比較するとすでにWii Uを分解、解析している人がいてその解析結果より
320SP、550MHzとされているにょ。
これから単純に考えるとPS4のGPU性能はWii Uの約5倍といえるにょ。
GCNはRadeon HD 6xxxまでと比べて実効性能が向上しているためアーキテクチャの違いを
考慮すればWii Uの約6倍といえるにょ。
Wii UのGPUもPS3と比べて1.5倍程度はあるためPS3と比べると10倍近い実効性能があると
いえそうにょ。

現行のHD機（PS3、Xbox360、WiiU）はどれも「フルHD、60fps」が難しい状態なのだけど
PS4のGPUならばそれは十分達成できそうにょ。
ただし、4Kを視野に入れているならば十分とは言えないにょ。
4K対応TVも徐々に発表されてはいるものの現時点でコンテンツがないということを考えると
今後5、6年で普及することはないだろうからそれほど問題は無さそうにょ。（HDTVもBS、
CSでのHD放送によって普及が始まり、地デジへの完全移行でようやく普及した）

ゲームにおいてはGPUの存在が非常に大きいのだけどやはりそれに似合うCPUがあって
初めてその恩恵を得られるにょ。
Wii UはGPUはPS3と比べて高性能なのにフレームレートが大きく落ちる場面があるのは
CPUがボトルネックになる場面があるためにょ。
確かにCPU性能が高ければ高い方が有利なのは確かだけど昨今は昔と違ってGPUのウェイトが
高くなっているためボトルネックにならないレベルのCPU性能があれば十分といえるにょ。

上記の公式配布のスペックを見るとAMDのJaguarの8コアと記されているにょ。
JaguarはAMD Eシリーズに搭載されているBobcatの後継となるCPUにょ。
http://pc.watch.impress.co.jp/docs/column/kaigai/20120831_556374.html
2〜4コアでの投入が予定されているためPS4用のCPUは4コアのものをMCMでパッケージした
ものと推測されるにょ。
さて、問題はどのような性能になるかということにょ。
現行のBobcatは低消費電力がウリだけど性能は同社のメインストリーム用CPUである
Trinityと比べてもクロック当たりでは8割程度しかなくHTTのないCore i3と比べても
クロック当たりでは半分程度の性能しかないにょ。
256bit-SIMDであるAVXに対応したりとか従来は2クロックで実行されていた128bit-SIMDが
1クロックで実行できるようになるとかいうように拡張命令を使用した際にはBobcatと比べ
大きな改善がありそうだけどそうでない場合はクロック当たりの性能は微増に止まりそうな
感じにょ。

PS4に搭載のCPUの動作クロックがどの程度になるのかは分からないけど例えば2GHzになって
も4コアのTrinity換算だと2.4GHz程度にしかならないにょ。（8コアで4コアの1.5倍の実効
性能になると仮定した場合）
決して高いCPU性能ではないもののGPUに特化したゲームならば問題はないのではないかと
思われるにょ。

Jagarを採用する背景にはBullzozerアーキテクチャの電力効率の低さがありそうにょ。（あと
GLOBALFOUNDRIESが28nmの立ち上がりが芳しくないためPS4を年内に登場させるのが難しくなる
というのも大きな理由であると考えられる）
最新のプロセス技術で作られるIntel製のCPUを使えばそのような問題は一気に解消されるの
だけどIntel製にするとコストの面で不利になるのと自由なカスタマイズが難しいというのが
AMDを採用した理由ではないかと思われるにょ。
CPUはある程度の性能があれば良くてPCで開発に慣れているx86CPUを搭載することでサードが
参入しやすい環境を作り出すということが重要なわけであり、そしてコストが最も重要に
なってくるからね。

Jagarを採用によって低消費電力が期待できるにょ。
BobcatのTDPは1.7GHzのE2-1800でTDP18Wとなっているにょ。
「TDP＝消費電力」ではないのだけどここでは消費電力と考えて計算してGPUが18Wのうち8Wを
占めていると仮定すればCPU1コアあたり5Wとなるにょ。
仮にPS4に搭載のCPUが2GHzであっても32nmのE2-1800から28nmへと微細化によって相殺される
ためCPUの消費電力は多く見積もっても8コア分で40Wとなるにょ。
実際はCPU、GPU以外のロジック部分やキャッシュの消費電力もありかなり丼勘定で計算して
いるため実際の消費電力はこれより低いものになると思われるにょ。（恐らくCPUコアだけ
ならば20〜30Wくらいか）
これに上記のGPUをパッケージングしているのだけどGPUのTDPはRadeon HD7850で130Wとなって
いるにょ。
ただし、2.18TFlopsのモバイル用となるRadeon HD7900MのTDPは100Wということを考えると
GPU部分の消費電力は100Wを下回る可能性が高そうにょ。
そもそもGPUのTDPはメモリを込みの値で発表されているわけだからね。
そうするとPS4のAPU（Jagar8コア＋1152SPのRadeon）の消費電力は100W前後ではないかと
思われるにょ。
これはPS3が発売当初のCellやRSX単体と大差ない数字であるためこれならばそれほど大きな
筐体でなくても十分な冷却ができそうにょ。

実は、PS4のスペックで目を引く部分といえばメモリにょ。
何せGDDR5で8GB搭載しているわけだからね。
メモリ帯域は176GB/sにまで達しているにょ。
これは一般的なPCのメインメモリに搭載されているDDR3-1600の12.8GB/sの13.7倍の帯域にょ。
とはいえ、これはGPUと共有ということを考えると決してずば抜けている数字ではないにょ。
Radeon HD7850は153GB/sだけどこれは独立して使えるわけだからRadeon HD7850よりメモリ
クロックは若干高いとはいえCPU用にDDR3-1600のデュアルchメモリを確保できていれば
そちらの方が合算ではメモリ帯域は広くなるにょ。
実際に使用する場合には共有だと不利な点が多いけどコスト面では有利になるにょ。

もっとも現状では広く量産されているDDR3の方が圧倒的に低コストにょ。
だからコスト面を考えるとメインをDDR3にしてVRAMをGDDR5にした方が低コストになりそう
という計算ができるけど時代とともに性能が上がっていくPCとは異なりゲーム機の場合は
同じスペックでずっと生産されることになるので現時点で低コストだから将来的にも
低コストで済むとはいえないにょ。
GDDR5はx16モードとx32モードが選択できるにょ。
GPUと256Mbitでデータをやりとりしている場合にはx16モードであればチップを16枚搭載
可能であり、x32モードであればチップを8枚搭載可能にょ。
容量を稼ぎたい時にはx16モードは有用だけどチップ数を減らしてコストを押さえたい
ゲーム機だとx32モードになるにょ。
そうするとGDDR5を256Mbitで接続する限りは現時点ではチップ数は8枚もしくは16枚必要
だけど将来的に微細化が行われてもチップ数は8枚必要になってくるにょ。

そして、メインとVRAMが共用でないならばメインメモリ用のDDR3も別途必要になるにょ。
DDR3は16bitとなっているため64bitのシングルchでも最低4枚、デュアルchで動作させる
ならば8枚のチップが必要となり、どれだけ微細化が進んでもメインとVRAMを合わせて全部で
メモリは16枚も必要になってくるにょ。
メモリチップ数は微細化によって変えることは出来ない部分であるため将来的なコスト
ダウンを見込むならば出来るだけ少なく済むような構成にする必要があるというわけにょ。

さらに異なるメモリを搭載したらメモリコントローラは2つ分搭載する必要があるにょ。
そうなるとコントローラの分よりもAPUとして1つにパッケージしている関係上CPUから出る
ピンの数に問題があるにょ。
メモリを分けてしまうと必要以上にピンの数が増えて複雑な構成になるにょ。
これはコスト面の問題だけではなく将来的な小型化を行う場合にも設計の自由度を下げて
しまうことになるにょ。
つまり、PS4がメイン、VRAM共有でGDDR5のみに絞ったのは性能面と将来的なコストダウンを
考えると十分納得がいくにょ。

ただし、メインメモリにDDR3を使うのとは異なりGDDR5を使うということはレイテンシが
大きくなるという点と粒度が大きいという点が問題になるにょ。
一般的なPCはメインメモリとCPUは64bit単位でデータをやりとりしているけどPS4の場合は
これが256bit単位になるからね。
GPUの描画に用いるだけならば並列性が極めて高く粒度が高くても問題になることはなく
単にコストの問題だけに止まるのだけど条件分岐が多いCPUに使用となると粒度が高くなると
スループットは下がってしまうにょ。
http://pc.watch.impress.co.jp/docs/2007/0326/kaigai346.htm
このレイテンシと粒度の問題はキャッシュがうまくヒットすればある程度は隠蔽が可能で
あるため十分なキャッシュを搭載すればそれほど問題ではなくなるもののそれはCPUの
ダイサイズの増大を招きコストアップにも繋がるため難しいにょ。
したがって、PS4の実効性能は今回書いた数字だけでは量りきれない部分があるにょ。

(2)現行機であるPS3との互換性はCPUもGPUもアーキテクチャが変わっているため確保する
ことはできないにょ。
エミュレーションによってカバーするためには性能が全然足らないので難しいからね。
特にCellはピーク性能が極めて高くこれを速度を落とさずエミュレーションできるx86CPUは
現時点では存在しないにょ。
というか、理論性能で218GFlopsのCellは4コアのIvyBridgeならば6.8GHzにOCしてようやく
互角レベルだからね。
これはCellが単精度浮動小数点演算に特化したベクトルプロセッサと言ってもいいような
ものであり、汎用的に使える一般的なPC向けのx86CPUとは単純比較ができないものの
リアルタイムでのエミュレーションを行うためには桁違いの性能差が必要ということを
考えるとx86CPUを用いてPS3をエミュで動作させるというのは不可能であることが分かるにょ。
そうするとPS4がCellを搭載していない時点で互換性はないといえるにょ。

そこでクラウドゲーミングが導入されるにょ。
これによってPS3用に発売されたゲームもPS4でプレイ可能になるにょ。
クラウドゲーミングには昨年の12月29日にも書いたような問題点が存在するにょ。
メーカー（SCE）にとってはサーバコスト、ユーザーにとっては遅延が問題となるにょ。
クラウドゲーミングはいくら頑張っても遅延ゼロ（≒1/60秒未満の遅延）は不可能である
ためにいかに遅延を抑えるかが重要になってくるけどそのためにはサーバを増強する必要が
あり多くのコストが必要となるにょ。
所持しているPS3タイトルはソフトのディスクを挿入したら自動的にクラウドサーバに繋がり
意識せずにクラウドゲーミングが可能になるというギミックもあれば良さそうだけどそうなると
ユーザー登録や支払いの面の問題があるにょ。（所持ソフトが無料でクラウドプレイが可能で
あればその問題は無くなるけど）

(3)新ゲーム機は「単に性能が上がっただけ」ではなくそのゲーム機だからこそ遊べる要素も
必要となるにょ。
それを可能にするのがコントローラにょ。
その辺はやはり任天堂は優れており、ファミコンでは十字ボタンによる操作を確立して
ニンテンドー64では3Dスティックを取り入れることで3Dポリゴンを使ったゲームも快適に
プレイできるようになったにょ。
そして、WiiではWiiリモコン、DSではタッチパネルを導入などそれに合わせたゲームも
多数登場したにょ。

では、SCEはどうなのかというとN64のコントローラの影響を受けてデュアルショックを
発売し、Wiiリモコンの影響を受けてPS Moveを発売したにょ。
デュアルショックはSCPH-7000以降のプレステには標準添付して大きく普及に貢献したものの
PS Moveは別売りのままであるため対応ゲームは極めて限られるというのが現状にょ。
そのコントローラがあることで真価が発揮できるようなゲームがたくだん登場するためには
コントローラがデフォルトになる必要があるにょ。
したがって、標準コントローラがどのようなものかというのは新たなハードのスタート
ラインを決める上では非常に重要なものになるにょ。

ここで、PS4のコントローラを見ると新型となるデュアルショック4が標準添付となって
いるにょ。
デュアルショック4はデュアルショック3の6軸検知に加えて小型のタッチパッドとPS Moveの
ような3D位置検知システムを導入しているにょ。
WiiにおけるWiiリモコンのようにPS Moveを標準コントローラにするというのは避けてその
技術を用いて無難な形に仕上げた感じにょ。
タッチパッドはただのポインティングデバイスくらいにしか使用できそうにないけど
PS Vitaを見ても「タッチ対応」というのは重要な要素になっていくため今後数年間戦う
ゲーム機ならば外すことはできないと思われるにょ。
あとWii UのようにPS Vitaやスマホやタブレット端末でPS4用のゲームをプレイするという
セカンドスクリーンもPS4では標準サポートされるけど遅延がほぼゼロのWii Uとは異なり
遅延を無くすことができないPS4ではこれはメインではなくあくまでサブ的なものに止まり
そうな感じにょ。
ということで、コントローラに関しては想定の範囲内といえるにょ。

(4)さて、普及させるならば重要なのは価格にょ。
PS3の時は初期型においてはPS2との互換性があったものの苦戦したのは価格が高価であった
というのが大きいからね。
やはり、据え置き機は3万円を切ったあたりから普及の勢いが大きくなり広く普及（国内で
販売台数が1000万台を大きく越える）させるためには2万円を切るということが重要になって
くると思われるにょ。（つまり、初期段階で高価であっても将来的に2万円を切ることが可能
になる設計にしておくということが1000万台以上売るハードには求められてくる）

ハードの価格においてはやはり重要なのは製造のためのコストにょ。
PS4は高コストになりそうな部分といえばAPU（CPU＋GPU）と8GBのメモリにょ。
恐らく両方とも原価は1万円を越えると思われるにょ。（GDDR5については単体での販売が
ないためいくらくらいという予想も立てづらい）
あとHDDもコストアップの要因になる部分であり現行のPS3よりも少ない容量を搭載する
というのは考えにくいためここも高コストになるにょ。
同クラスのPCを組んでメモリが少し高めということで単純に考えると現時点での原価は
5万円程度になりそうな感じにょ。
PS3のときよりはコスト面ではかなり下がっているとはいえ逆ざや無し（もしくは逆ざやが
わずか）ならば販売価格は49800円くらいになってしまいそうにょ。

ただし、これはあくまで現時点での話であり将来的には微細化によってAPUの価格が下がり
GDDR5の価格も量産効果で安くなれば現在のPS3並の価格に抑えることは可能になりそうにょ。
したがって、ある程度の逆ざやを許容して量産効果によるコストダウンを加味すれば
39800円の発売開始は十分に可能だと思われるけどこれでもデフレが進んだ現状では苦戦を
しそうな感じにょ。
かといって、現状分かっているスペックで29800円で登場させた場合には逆ざやが極めて
大きなものになるためいくらハードが売れても巨額の赤字を抱えてしまうにょ。
ソフトによって得られるロイヤリティ収入を加味しても1台あたり1万円の赤字ならば
100万台売れたら100億円の赤字だからね。（定価29800円ならば恐らく1台あたり1万円では
済まないと思う）
Wii Uが発売前のウワサ通りの性能ではなくコスト重視の性能になったということを考えると
29800円で出すためにコストを抑えるという可能性も考えられなくもないけどね。
ということで、私の予想は本命39800円、対抗49800円、大穴29800円にょ。

(5)やはりユーザーとしては最も重要なのがソフトにょ。
昨年12月28日にPS Vitaの敗因をいくつか挙げてみたけどやはり最大の原因はモンハンのような
「キラーソフトがない」というのが一番の理由だからね。
現時点でソフトが発表されていないPS4でまだ何とも言えないのだけどやはり昔のような独占
タイトルの登場は期待は薄そうにょ。
ハードが高性能化によって開発コストが増大になってきているのだけどそれを抑えるには
開発しやすい環境であるということが求められているにょ。
Cellは確かにピーク性能は高いもののそのピーク性能を活かすのは科学技術演算（行列演算
など）に限られてくるにょ。
普通にゲームを作る上では性能を発揮できないというのが問題だったにょ。
任天堂もかつてN64で「開発しにくいハード」という汚名を着せられたにょ。
そのためGCでは開発のしやすさを重視して、その流れはWii、Wii Uと続いているにょ。
ただし、Wii UはGPUの性能に釣り合わない貧弱なCPUということで再びソフトメーカー
泣かせのハードになっているような気がするにょ。

PS4はどうかというとGPUを重視したPCのようなハードであり、PCでの開発に慣れている
ソフトメーカーであれば開発はPS3よりも楽になっているのではないかと思われるにょ。
もっとも、8コアJagarの性能がどれほどのものかは分からないためCPU性能がボトルネックに
なってしまう可能性も考えられなくもないけどね。
あと、開発費をより効率よく回収させるにはマルチに頼るしかないにょ。
昨今はPC、PS3、Xbox360というマルチタイトルは非常に多くなっているけどこれもマルチ
前提で開発しておけばわずかな開発コスト増で済むためにより開発コストを下げる効果が
期待できるからにょ。
そういう面からするとPS4はアーキテクチャから考えてもPCとのマルチは非常に有利にょ。
次世代Xboxの性能はまだ分からないもののPS4とそれほど大きな開きはないため次世代Xboxも
PS4とのマルチタイトルになりそうにょ。（Wii Uはそういう面では当初の予想よりも性能が
低いため今後はマルチタイトルにおいてはかなり苦戦しそうな感じ）
もっとも、マルチだけではなく独占タイトルを確保できるかも重要になってくるのだけど
この辺は今後のSCEの手腕にかかっているにょ。（というか、ローンチタイトルに関しては
すでにある程度できてないと年内の発売はできないけど）


さて、以上のようにPS4を見てきたけど思っていた以上に性能を高めてきた感じにょ。
4Kをターゲットにせず、フルHD、60fpsが目的ならばもう少し低くても十分に出せるのだけど
ギリギリだとセカンドスクリーンを実行するのが難しいにょ。
Wii UはそもそもフルHD、60fpsが微妙なスペックなので専用のWii Uゲームパッドへの出力の
ため2画面出力を行うには性能が足りないみたいだしね。
あと、その余力を活かしてPS4では常時ゲームプレイを録画しているにょ。
この録画によって、プレイ動画をネットで手軽に公開が可能になっているにょ。
メモリも本来であれば半分の4GBで十分足りると思うけどそうやってさまざまなことに使用
できいる余力が残されているということを考えると奮発して8GB搭載した恩恵は十分にあるの
ではないかと思われるにょ。

とはいっても、すでにHD対応はPS3が出てきた時に謳っておりユーザーからすればぱっと見た
感じはPS3から大きな向上があるようには見えないかもしれないにょ。
実際はフルHDどころか720pもないようなゲームもあり、60fpsに満たないゲームも多く存在
するため異なるのだけどそれを大きくアピールするのは難しいにょ。
よって、性能以外の部分でアピールしていかないといけないにょ。
従来であれば理論値でも何でもいいから数字が前モデルと比べてこれだけ大きくなったという
ことをひたすらアピールして高性能であることを謳っていたけどそれが通じなくなってしまう
となるとどんなゲームがプレイできるか、どんな遊び方、楽しみ方ができるかをユーザーに
強くアピールしていく必要があるにょ。

そういう観点からするとやはりPS3登場時とは異なり高価格では売りにくいためやはりローンチ
から定期的に有力ソフトを投入していかない限りはかなり苦戦をしそうにょ。
Wii Uも発売した昨年12月は年末商戦と合わさって売れたものの年が明けてからはソフト不足に
よって売り上げは鈍化してしまい現状はかなり苦戦をしているにょ。
Wii UはWiiとの互換性があるため徐々に売れていくとは思うけどその互換性がないPS4（上記の
ようにクラウドゲーミングによって互換性を持つともいえるけどこのクラウドゲーミングが
十分快適にプレイできなおかつ現在所持しているPS3ソフトに関しては無料プレイができない
限りは互換性があるとは認めることはできない）は厳しいものになることが予想されるにょ。

1486：御茶目菜子：2013/02/25(月) 23:59:08
D7100はDXフォーマットの最上位機種に相応しいのか・・・？
ニコンから中級機となるデジタル一眼レフD7100が発表されたにょ。
http://dc.watch.impress.co.jp/docs/news/20130221_588730.html
公式ではD7000の後継機ではなくD7000の上位モデルとのことだけどこれは現行機との併売が
行われる間に限っての慣習的なものであり、事実上の後継機種と言えるにょ。
両方のスペックを比較すると下記のようになるにょ。

　　　　　　　　　　D7100 　　　　　　　　D7000
センサーサイズ　　　APS-C　　　　　　　　 APS-C
画素数　　　　　　　2410万画素　　　　　　1620万画素
画像処理エンジン　　EXPEED 3　　　　　　　EXPEED 2
連写速度　　　　　　6コマ/秒　　　　　　　6コマ/秒
　　　　　　　　（7コマ/秒 ※クロップ時） −−−−−
AFポイント　　　　　最大51点　　　　　　　最大39点
液晶モニタ　　　　　3.2インチ122万ドット　3インチ92万ドット
サイズ　　　　　　　133.5x106.5x76mm　　　132x105x77mm
重量（バッテリ込み）765g　　　　　　　　　780g

気になる点といえば下記の点にょ。

　(1)センサーと画像処理エンジン
　(2)連写速度
　(3)AF

(1)センサーを見ると2410万画素ということで画素数は前モデルより1.5倍に増えているにょ。
すでに何度も書いているように画素数の増加は画質向上に必ずしもプラスになるとはいえ
ないにょ。
とはいえ、そのセンサーで十分に解像するレンズを装着した場合には高い解像感を得ることが
できるにょ。
APS-Cで2400万画素というのは個人的にはやや多すぎると感じるけど単焦点レンズや一部の
高解像力のズームレンズを装着時にはその恩恵を得られるため必ずしもダメというわけでも
ないにょ。
ニコンの場合はすでにAPS-Cは入門機であるD3200からすべて2400万画素で固められているため
D7100の2400万画素は必然的な物だったといえるにょ。（キットズームしか使わない人も多い
入門機は高画素の恩恵はなくファイルサイズが大きいだけというデメリットしかないので
個人的には1600万画素で十分に感じる）

D7100は単に画素数が増えたというだけではなくローパスレスになり、クロップ撮影ができる
ようになったにょ。
1月9日にも書いたようにローパスレスというのは高画質化を行うものではないにょ。
ベイヤー配列のセンサーの場合はモアレや偽色のためローパスフィルタが多くの機種で採用
されているけどコンデジはずっと前から普通にローパスレスであり、センサー性能にレンズ
性能が追いついてない場合はローパスフィルタは不要にょ。
フルサイズのデジタル一眼であるD800Eではローパスレスが話題になったけどこのクラスに
なると十分な解像力のレンズを使用時にはレンズ解像力はセンサーの画素ピッチを上回る
ためローパスフィルタによって解像感を落とすのを避けるためにローパスレスになって
いるにょ。
D7100も同様に解像力アップのためにローパスレスとなっていると思われるにょ。

クロップ撮影は単純に言えばトリミングズームにょ。
拡大による画素補完を行うデジタルズームとは異なり画質の劣化はないというメリットが
あるにょ。
コンデジの場合はすでにレンズが解像していない状態なのでこのようなトリミングズームには
意味がないけど一般的なコンデジと比べて桁違いに大きなセンサーサイズのデジタル一眼の
場合は十分な解像力のあるレンズを使用していれば恩恵は十分にあるにょ。
ニコンにおいてはFXフォーマット（フルサイズ）でDXフォーマット（APS-C）用のレンズを
使用時には自動的に1.5倍のクロップになるけどD7100の場合は画素数の多さを活かして
DXフォーマットでさらなる1.3倍のクロップ撮影を可能にしているにょ。
画素数は1540万画素となりセンサーサイズはフォーサーズより若干小さくなるものの
クロップ撮影によってレンズの焦点距離はフルサイズ換算で約2倍となるにょ。
つまり、300mmのレンズが約600mm相当の画角になるにょ。

(2)クロップ撮影時には連写速度が上がっているというのもメリットとなるにょ。
とはいえ、標準が6コマ/秒でクロップ時が7コマ/秒ということでもD7000が6コマ/秒という
ことを考えると少し頑張って欲しかったところにょ。
しかし、1番の問題は連写速度ではなく連続撮影可能枚数にょ。
D7100のバッファ容量はD7000から改善されてないみたいなので12bitRAWだとD7000が11コマに
対してD7100は7コマに減っているにょ。
つまり、7コマ/秒だと1秒でバッファフルになるということにょ。
JPEGならば最大100コマまで連続撮影可能とはいえ、さすがにRAWでこの枚数というのはこの
クラスのデジタル一眼としては少なすぎるにょ。
バッファが増やせないならばキヤノンのようにsRAWを導入して欲しいところにょ。

(3)恐らく強化されているであろう部分がAFにょ。
AF測距点は従来の39点から上位機種と同じ51点にまで増えたにょ。
これは下位機種のD5200が39点になったことから差別化として増加したのだと思われるにょ。
AF測距点の増加は必ずしもAF性能の向上に繋がるというわけではないけどより広いエリアを
カバーできるようになったということは喜ばしいことにょ。
特に1.3倍のクロップ撮影時には画面のほぼ全域をカバーしているのは圧巻にょ。
あとは、実際に動体にどれくらいの追従性があるかどうかが問題だけどこれはレビューを
待つことにするにょ。
あと中央1点のみとはいえF8に対応したのも大きいにょ。
これによってズームレンズ＋テレコンという使い方でもAFが可能になるわけだからね。
まぁ600mmF4クラスの単焦点超望遠と組み合わせてもいいけどね。
クロップ撮影と合わせると換算焦点距離はかなり稼げそうにょ。


(1)〜(3)以外も防塵防滴がかなり強化されている感じにょ。
そして、D7000より若干小型軽量化されているというのも良い点にょ。
こうしてみると、D7000での不満点（解像感が低い）などが改善された正統派の後継機種と
いえそうにょ。（2400万画素もあり、不満点の1つだった高感度画質においては改善が
難しいだろうけどそれをクロップモードという方法で活かすことにしたのはプラスかも）
これはD5200が出たこともありスペックを底上げする必要があったのだろうけどそれでも
やはり、従来のDXフォーマットのフラッグシップモデルであったD300sの後継として考える
ならば力不足に感じている人も多いにょ。
特に連写や筐体の作りなどは依然として劣っているからね。

D300sは国内ではすでにディスコンとなっているため後継機種を求める声をよく見かけるにょ。
20万円弱のFXフォーマットのD600がすでに発売されていて、それに予価13万円のD7100が
加わるということはD300sの後継機種（D400もしくはD9000あたりか）のポジションはかなり
微妙になっているにょ。
仮に出すとしてD7100との差別化は十分可能であり、連写は通常時10コマ/秒、1.3倍クロップ
時には12コマ/秒くらいになれば多少高価になってもこちらを選ぶという人はいるのではない
かと思われるにょ。
というか、D7100は将来出るであろうDXフォーマットのフラッグシップモデルとの差別化のため
意図的に連写速度と連続撮影枚数を落としているような感じさえさせてしまうからね。

これに関しては海外では「D7100はDXフォーマットのフラッグシップモデルではない」という
正式なアナウンスがあったみたいだけどこれによってD300s後継機種が登場するかというと
登場するまでは安心はできないにょ。
D300sが発売された当時とは異なりFXフォーマットの選択肢が増えており単純に画質を求める
ならばDXのフラッグシップモデルには価格分のメリットはないということもあり、そこまで
大きな需要があるかというと微妙なわけだしね。
とはいえ、ライバルであるキヤノンがAPS-CフラッグシップモデルとしてEOS 7D mkIIを投入
する見込みでありニコンも出さないというわけにもいかないからすでに準備はしている
だろうけど7Dの投入はもう少し先になりそうなのでニコンもその様子見をしているのかも
しれないにょ。（私の予想としてはD300sの後継機種を出すならば今年の秋〜来年初頭かも）
個人的にはD300sの後継機が出ても予算面で手が出せないためD7100が限界なのだけど唯一
不満に感じるのはやはりRAW連写で7枚という点にょ。
まぁ連写で撮影する機会がそれほど多くはないとはいえ現行のEOS 7DがRAWで23枚、RAW＋
JPEGで17枚でありそれと比べて大幅に劣るスペックなわけだからね。
EOS 7DがAPS-Cフラッグシップなのに対してD7100はフラッグシップではないということで
単純比較はできないけど格下のEOS 60DでもRAWで16枚撮影できることを考えるとやはり
少ないと言わざるを得ないにょ。（D300s後継機との差別化のためにこうしたのであれば
非常に残念）
この辺に不満を感じない人であれば上記のようにD7000から多くの面で改善されているため
D7100は良い機種だと思うにょ。

1487：御茶目菜子：2013/02/26(火) 23:59:24
固定小数点と浮動小数点はどちらがいいのか？
プチコンでは浮動小数点ではなく固定小数点が採用されているにょ。
一見すると扱える範囲が広そうな浮動小数点の方がいいのだけど果たして本当にそうなのか？
まずは次の式を見て欲しいにょ。（N88BASICなど多くのBASICで動作するはず）

A=(A+1) mod 4
※modは剰余を返す演算子とする

これは、どのような動作をするのかというとすごく簡単でAの値は0、1、2、3、0、・・・を
繰り返すにょ。
つまり、0から特定の値-1まで繰り返すカウンタが欲しい場合はこれで簡単に実装できるにょ。
プチコンにおいては剰余を返す演算子はC言語と同じ％だけどプチコンがC言語や他の多くの
BASIC言語と異なる点は剰余の演算にで小数を含む値を使用できるという点にょ。（剰余で
小数が扱えるため2月1日に書いたようなことも可能になる）
それをふまえて次の式を見て欲しいにょ。

A=(A+0.25)%1

プチコンで実行したことがない人には分かりにくいけどこれは最初に書いたものを単純に4で
割っただけなのでAの初期値が0ならば0、0.25、0.5、0.75、、0、・・・を繰り返すことは
予想ができると思うにょ。
実際にループで実行して表示を繰り返してみれば分かるけど初期値がどのような数であっても
ループ4回で初期値に戻るにょ。
では、Aに加算するのが0.25ではなく0.1だったらどうなるのか・・・？

A=(A+0.1)%1

これをプチコンで実行すればループ10回で初期値に戻るように見えると思うにょ。
しかし、実際はそうならないにょ。
というのも0.1には固定小数点による誤差があるからにょ。
プチコンは32bit固定小数点であり、符号1bit、整数19bit、小数12bitとなっているにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/p005.htm#column
つまり、0.1という定数はプチコン内部では409/4096という形になっているわけにょ。

それを踏まえて考えるとA=(A+0.1)%1というのはA=(A+409)%4096というものを4096で割ったもの
といえるにょ。
そう考えるとAの初期値が0ならば10回ループした後ではAの値は4090/4096でありちょうど1に
なっていないためループ10回では初期値に戻らないというのが分かると思うにょ。
それではループ何回で初期値に戻るのかを考えてみるにょ。
初期値に戻るためには409を一定倍して4096の倍数になるかを求めればいいのだけど409は
素数であり、4096＝2^12で互いに素であるため409n＝4096k（n、kはともに整数）が成立する
最小のnは4096となるにょ。
つまり、A=(A+0.1)%1という式はループ4096回で初期値に戻るというわけにょ。

これが何の役に立つのかというと難しいところだけど以前作った疑似乱数発生ルーチンで
有用になってくるにょ。
0〜1の疑似乱数を発生させるルーチンはY=(Y+1)%4095X=(X*479232+Y)%4096/4096というように
なっていたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/rnd.htm
X=(X*479232+10)%4096/4096という式だと周期は4096しか確保できないにょ。
これだとあっと言う間に同じ値を繰り返すため256x192ドットの画面をランダムに表示された
ドットで埋めるなんてことは不可能であり実用性は低くなってしまうにょ。
したがって、別途変数Yによるカウンタを用いて周期を長くしたものが上記の疑似乱数にょ。
変数Yは4095回で元に戻るため4096回周期のXとは異なる周期であり、4096と4095は互いに素で
あるため周期は4096×4095＝16773120に達するにょ。

ここで変数Yに注目すると単に長い周期を繰り返せばY=(Y+1)%4095に拘る必要はないにょ。
A=(A+0.1)%1でAが4096回で初期値に戻るというのを利用してこれをカウンタに使えばいいの
だけど周期4096ではXと周期が同じであるため意味がないにょ。
したがって、4096とは素となる数（2の倍数ではない数）を4096で割ったものを設定する
必要があるにょ。
別に何でもいいのだけどここでは1.1（4096倍すれば4505）にしてみるにょ。
Y=(Y+0.1)%1.1でYは4505回周期となり、4096回周期のXと組み合わせると周期は18452480と
なるにょ。
そうすれば1.1ではなくもっと大きな数に設定すればさらに周期が伸びると考えるけど
周期が伸びてもXの取る値に変化はないため1より極端に大きな値を指定しても意味はないため
リスト短縮を考えて1.1がベターだと考えたにょ。（ちなみに4095回周期にしたければ0.9998に
すればよい）

出力するXの値が0〜1の範囲内であればXの方もX=(X*479232+Y)%4096/4096から短くできるため
次のようになるにょ。
Y=(Y+0.1)%1.1X=(X*117+Y)%1
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#rand
0〜1の値を返す疑似乱数は固定小数点の誤差を上手く活用することで10文字分短縮できたと
いうことが分かるにょ。

プチコンの固定小数点は一見すると簡単に誤差が出るため非常に使い勝手が悪いような気が
するけど浮動小数点とは異なり加減算で新たな誤差が生まれないというのは大きなメリット
だと思うにょ。
それがあるからこそ上記のようなことが可能になったのだからね。
固定小数点は内部に保存する段階で誤差が発生するというだけにょ。

32bit浮動小数点（float）では符号1bit、指数部8bit、仮数部23bitとなっているにょ。
そのためfloatでは絶対値が1.175494×10^-38〜3.402823×10^38の数を扱うことができるにょ。
こうしてみると同じ32bitでもプチコンの固定小数点よりも優れているように思えるかも
しれないけど問題なのは仮数部が23bitしかないということにょ。
23bitで扱える数は1〜8388607（＝2^23-1）となるにょ。
このため非常に大きい数と非常に小さい数を加算すると小さい数はちゃんと加算されないにょ。
これがプチコンの固定小数点の場合は525288以上の大きい数は事前に2のべき乗で割れば誤差
無しで加算できるにょ。
この方法によってプチコンで32bit整数演算は擬似的に可能となるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#int
小さい数字は整数倍することでこちらも誤差無しで加算可能にょ。
何せ整数部と小数部で31bitあるためfloatよりも事実上扱える範囲は大きいにょ。
floatがさらにやっかいなのは減算にょ。
桁落ちによって誤差が拡大されてしまうからね。

固定小数点は小数点を含む数を表記すると（小数部分が1/4096単位で正確に表せる数を除き）
表記の段階で誤差が発生してしまうものの加減算では整数演算と同じように演算誤差が発生
しないにょ。
そのため誤差を減らすさまざまな方法を工夫すれば誤差無しで演算可能だけどfloatは確実に
誤差が出てしまうため誤差が発生しても問題ないようなコードを書く必要があるにょ。
もしも32bit浮動小数点のみだと初心者向けではなく玄人向けになってしまうにょ。
そう考えると変数の型を選べないプチコンで固定小数点となったのは納得がいくにょ。
整数演算だと誤差の心配はないけど小数が扱えないとさすがに不便だからね。

ポケコンの場合はシャープのポケコンは8byteBCD演算という極めて精度の高いものを搭載
しているにょ。
そして、PC-1280およびPC-E500シリーズでは倍精度演算（有効桁数20桁）が可能になって
いるにょ。
BCD演算は内部で10進数演算が可能であり、誤差は極めて小さいし、さらに有効数字で20桁の
倍精度となるとこれに適うBASICを搭載したパソコンは存在しないにょ。
まさに電卓の進化系であるポケコンならではといえるにょ。
ここまでくると固定小数点より圧倒的に扱いやすいため初心者でも安心して使えるにょ。
したがって、「固定小数点は初心者向き」と書いたもののあくまで1つに型を絞るならば浮動
小数点よりも固定小数点の方が初心者に向いているというだけのことにょ。

1488：御茶目菜子：2013/02/28(木) 00:05:04
タブレット端末はポケコンになれるのか？
タブレット端末が多数発表されたにょ。

HP、Samsungが7〜8型タブレットを発表
http://pc.watch.impress.co.jp/docs/news/event/20130225_589230.html
ソニー、「Xperia Tablet Z」のWi-Fiモデル
http://pc.watch.impress.co.jp/docs/news/20130226_589341.html
オンキヨー、直販9,480円からのAndroidタブレット6機種
http://pc.watch.impress.co.jp/docs/news/20130226_589403.html
Lenovo、Androidタブレット「IdeaTab」3機種を発表
http://pc.watch.impress.co.jp/docs/news/event/20130226_589410.html
ASUS、通話機能付き7型タブレット「Fonepad」を249ドルで発売
http://pc.watch.impress.co.jp/docs/news/event/20130226_589345.html
8.9型WUXGA液晶の「Kindle Fire HD 8.9」を予約開始
http://pc.watch.impress.co.jp/docs/news/20130227_589604.html

今回の多数の製品を見て目立った点といえば下記の3つにょ。

　(1)7インチクラスの普及
　(2)低価格化
　(3)Atomの本格導入の期待

(1)タブレット端末といえば10インチクラスのiPad（正確には9.7インチ）が爆発的にヒット
したため各メーカーもそれに追従して10インチクラスの製品を主に投入していったにょ。
しかし、10インチクラスの製品は軽い物でも500〜600gであり、基本的に片手で持って使用
することになるタブレット端末としてはどうしても重量面で難があったにょ。
また家庭内で持ち運ぶには10インチクラスの製品が問題ないのだけどバッグに入れて電車や
バスの中で気軽に取り出して活用するには10インチクラスでは大きいにょ。

サイズや重量の面ではスマホを活用すればいいというが意見もあると思うにょ。
確かに、国内においてはスマホは携帯電話の出荷台数の7割以上を占め普及率も今年中には
5割を越えることが予想されているにょ。
そうすると、「10インチタブレットでカバーできない領域はスマホ」となるのは自然な流れ
だけどユーザーが選ぶのが10インチではなく7インチになる可能性もあるにょ。
ここで、スマホを持っていて7インチクラスのタブレット端末が必要かということになるの
だけどスマホの高解像度化は止まらずこの昨年まで1機種しか無かったフルHD液晶搭載機が
この春の新機種では一気に増えたにょ。
フルHDだとスマホとしては大画面となる5インチでも441ppiに達するため計算上は20cmまで
近づいてもドットを認識するのは困難にょ。（一般的な人だと30cmの距離で300ppi程度まで
認識できる）

300ppiくらいまでは情報量のアップに貢献できたけどそれを越えてしまうと文字のキレイさ
くらいしか高精細のメリットはなくなるにょ。
その高精細も15cmまで近づいてみても600ppiまでしか認識できないためそれで高精細も打ち
止めになるのではないかと思われるにょ。
これは逆に言えばスマホの実質的な文字情報量はいくら精細度を高めても5インチでもWXGA
クラスあるかどうかというレベルしかないことを意味するにょ。

これが7インチだとWXGAで213ppiであり、5インチのスマホだと少し前にはハイエンドだった
QHD（960x540）よりも精細度が若干低いため十分に文字が認識できるにょ。
そして、7インチフルHDだと314ppiだけどこれは5インチWXGAとほぼ同じにょ。
両方とも手に持って使う端末であるため精細度が同じであれば文字の見やすさはほぼ同じに
なるにょ。
「WXGAとフルHDで情報量が分からない」なんて言う人はほぼ居ないと思うけどこの情報量の
多さこそが7インチタブレット端末のメリットだと思うにょ。（それにサイズが大きいと
文字入力の際にソフトウェアキーボードの使い勝手も良くなるし）
それならば10インチクラスの方がさらに情報量が多くなるという意見もありそうにょ。
確かに10.1インチ2560x1600でも299ppiであるため7インチフルHDよりも文字が見やすい
からね。
しかし、これは10インチクラスが片手で長時間保持できて気軽に持ち歩くことが出来る
という人に限られるにょ。（もしくは、ほぼ家庭内でしか使用しないためそこまでの
携帯性には拘らない）

ただし、これはスマホが「5インチ」というサイズで打ち止めであるということを前提に
しているにょ。
もしも、今後スマホがさらなる大型化を続けることになれば7インチタブレットの領域まで
スマホが浸食することになるからね。
ただし、そのサイズになるとポケットに入れることがほぼ難しくなるにょ。
現在アニメでも放送中の「ROBOTICS;NOTES」の世界では7インチのスマホが主流になっており
このスマホは通称「ポケコン」と呼ばれているにょ。（おちゃめくらぶで普段使用している
ポケコンとは別物であるため注意）
3.5〜4インチクラスだったスマホが現在は4〜5インチであるため数年後には7インチにならない
という保証はないけどそれはそういう時代になってから考えればいいにょ。
現時点では上記のようにスマホと差別化は可能だし、本体が別であるということは当然ながら
バッテリが別であるためただでさえバッテリ容量が小さくバッテリ切れの心配によって思う
ように使えないスマホの変わりに自由に使える端末が別途あるというとそれだけで大きな
メリットがあると私は感じるにょ。（単純にバッテリだけの問題ならばスマホ1台で済ました
場合には別途モバイルバッテリを持ち歩けばわざわざ別端末を持ち歩く必要はないけど）

(2)7インチクラスのタブレットが脚光を浴びるようになったのはNexus 7の登場が大きいと
思われるにょ。
従来は10インチクラスが主流であり、7インチは品質があまり良いとは言えない中華パッドの
ような格安品しかなかった中にそこそこのスペックで19800円という低価格で登場したわけ
だからね。
そして、Appleも7インチよりは1周り大きいiPad mini（といっても4:3の液晶であるため
短辺は大きいけど長辺は7インチクラスと互角）を投入してさらにこのクラスの競争が激しく
なったにょ。
スペックのわりに（登場時には）割安感があったNexus 7とは異なりiPad miniは予想以上に
割高感があったにょ。
それでもやはり小型iPad2というべきスペックであり、多くの人にはそれほど不満を感じ
させるものではない（CPUやGPUの性能はそのままでRetina液晶を搭載してしまえばスペック
不足でもっさりしてしまうのでiPad miniはRetina液晶を搭載しなくて正解だと思う）という
こでもあり、そして、Appleのブランド力もあって高い人気を誇っているにょ。

そうなると後続がそれらに対抗するにはスペックやブランド力で上回る必要はあるけど
ブランド力で上回るのは無理であり、スペックで上回るとそれらより高価格になるのは
必至であるためブランド力の無いメーカーだとかなり苦戦をしてしまうにょ。
そこで選んだ道は低価格化にょ。
従来だと中華パッドがカバーしていたような1万円を切る製品まで発表されているにょ。
ただし、その最下位クラスの製品だと当然のことながら格安中華パッドと大差ない性能に
まで落ちているため注意が必要にょ。
個人的にはスマホと共存するためには7インチタブレットにはWXGA以上が必須であると
考えているので低価格化による選択の幅が広がるのは歓迎するけど私ならば数千円余分に
払ってでも必要なレベルのものを購入するにょ。

(3)Intelがスマホやタブレット端末用として満を持して一昨年に発表したOak Trailだけど
参考出品の製品こそいくつかあったものの実際の製品として販売されたものは皆無にょ。
それから1年余り経ち昨年秋にはその後継となるClover Trailを発表したにょ。
Window8タブレット端末の多くに搭載され従来のAtomでは難しかった10インチクラスで
ARM SoCを搭載したAndoroidタブレット端末とほぼ互角のサイズ、重量、駆動時間を実現
したにょ。

それが今回Clover Trail+としてさらなるバージョンアップをしたにょ。
http://pc.watch.impress.co.jp/docs/news/20130225_589280.html
このClover Trail+はGPUコアを変更しAndoroid OSへの最適化が図られているとのことにょ。
http://pc.watch.impress.co.jp/docs/column/ubiq/20130227_589550.html
つまり、Clover Trailと比べてさらに長時間駆動が可能になるということにょ。
参考展示レベルだけどこれを採用しているタブレット端末も発表されたにょ。
Oak TrailではAtomを採用する意味はほぼ無かったけどClover Trail+がハイエンドなARM SoC
と比べて割高でないならば採用する意味は出てくるにょ。
というのも、それはIntelの今後のロードマップを見た場合に非常に見通しが明るいためにょ。

各ファウンドリは昨年28nmによる製造プロセスを立ち上げたものの依然として十分な供給が
できているとは言えないにょ。
特にGFは28nmの大幅な立ち上がりの遅れがありAMDの今後のCPUのロードマップが白紙状態に
までなってしまったくらいにょ。
PS4に採用のCPUがJaguarに決定したのはこれが一番の理由だろうからね。
その点Intelは昨年の段階で22nmプロセスの量産化が可能になっているにょ。
そして、来年には14nmプロセスの立ち上がりはほぼ予定通りに行われると思われるにょ。
Atomは現状では旧世代の32nmプロセスが採用されているものの年内には22nmプロセスを
使った「Bay Trail」の登場が予定されていて来年には最先端の14nmプロセスを使用した
Atomも投入される見込みにょ。

この世界最先端の製造技術は他社にとっては脅威にょ。
基本的に製造プロセスが微細化すれば同一ダイ面積に搭載できるトランジスタ数が増えるため
性能の向上に繋がるし、最先端の省電力化テクノロジも採用されているため低消費電力も
期待ができるにょ。（従来であれば駆動電圧を下げることでピーク時の省電力化が可能に
なっていたけど昨今は駆動電圧を下げるのが難しくなっているけどそれでも40nm→28nmでは
大幅な省電力化が行われた）
性能面と省電力面のアドバンテージがAtomにあるならばよほどコスト面で問題がない限りは
採用はこれからどんどん進むと思われるにょ。
Oak Trail登場時と現在では状況が全く異なっているということにょ。


さて、こうしてみると7インチのタブレット端末の普及はこれから加速するのは確実にょ。
当初は10インチばかりだったのは(1)で書いたようにiPadが市場を牽引したためであり
ユーザーが10インチを選んだわけではないにょ。
これからは10インチと7インチとラインナップの幅が広がり「10インチが良い」という人を
除けば低価格な製品が多い7インチクラスが選ぶだろうからね。
そうなるとあとは価格の問題にょ。
デフレによって15インチクラスのノートPCでさえ新品でも4万円以下で入手可能だし、11.6
インチクラスのUltrabookも安い製品ならば4万円台からあるにょ。
つまり、「とりあえずPCが欲しい」という人にとっては4万円くらいが主力品となっている
10インチタブレットは価格面でかなり苦しむのではないかと思われるにょ。

価格面の問題といえばかつて80年代前半、まだPC（というか当時はマイコンと呼んでいた）が
一般家庭にほとんど無かった時代はパソコン（マイコン）は高嶺の花だったにょ。
当然のことながら当時はノートPCなんてものは存在せず、機能が限定されたハンドヘルド
コンピュータやポケットコンピュータ（ポケコン）が携帯型のコンピュータとして用いられて
いたにょ。
特にポケコンは当時一般的な8bitパソコンが本体＋ディスプレイで10〜20万円していた時代に
1〜2万円で購入可能ということで多くの注目を集めていたにょ。
使用する用途が異なるため実際は比較対象にさえならならず別腹という感じだったのだけど
恐らくこの状況はPCとタブレット端末の間においても言えるのではないかと思われるにょ。
「PCより安価で携帯性に優れているもの」がタブレット端末が普及するためには必要に
なるにょ。

ポケコンは残念ながら電卓の延長線的な製品であるため当時の8bitパソコンががカバーする
領域はカバーできなかったにょ。（ただし、ポケコンは速度で劣っていても演算精度で
優れており、電池で数10時間〜100時間の連続使用が可能であった）
タブレット端末はポケコンがなし得なかった真にパーソナルなコンピュータになれる可能性を
持っているにょ。
まぁスマホがすでにそれをなし得ている（もしくはそれに近づいている）といえばそれまで
だけどスマホはあくまで携帯電話の役割として購入している人が多いということを考えると
タブレット端末は端末だけの魅力（もちろん、その端末を使ったサービスを込み）で普及
させていかなくてはならないため簡単ではないにょ。
かつてのポケコンやPDAは一般層に普及する前に形を変えて姿を消したけどタブレット端末は
それらと比べると今後の展望は非常に明るいといえるにょ。

1489：道産子の初心者：2013/03/02(土) 00:41:02
識別コード追加依頼
コードは「DS」です。お願いします。

http://www53.atwiki.jp/petctournament

1490：道産子の初心者：2013/03/02(土) 01:00:57
リンク申請
http://www53.atwiki.jp/petctournament
リンクお願いします。(相互リンク希望)

http://www53.atwiki.jp/petctournament

1491：進：2013/03/02(土) 15:28:57
リンク申請
前回お話ししたサイトのリンクをお願いします。
http://www48.atpages.jp/~kolang/pukiwiki/index.php?Petcです。
名前は、「幻想楽団プチコンのページ」
でおねがいします。

1492：御茶目菜子：2013/03/02(土) 23:59:46
レスにょ
道産子の初心者さんへ
＞リンクお願いします。(相互リンク希望)

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


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

リンク申し込みどうもにょ。
こちらからもリンクを張っておいたにょ。

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

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

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

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


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

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

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

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


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

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

スマホが普及し、クラウドだけで何でもできるようになるという時代になりつつあるけど
そのサービスの低価格化によって質の低下の懸念されるにょ。
サーバを扱うのは人間なのでその人間がミスをすればファーストサーバのような大惨事は
どこであっても考えられるにょ。（本来ならばバックアップも消去するなんて考えられない
けどそれはゼロではない）
したがって、基本的にはユーザー自身がバックアップを取り、そしてさらにクラウドでバック
アップというのが安心してクラウドサービスを利用できる使い方になると思われるにょ。

1494：御茶目菜子：2013/03/04(月) 23:56:41
プチコンでデータを圧縮しないことがユーザーに配慮していると言えるのか？
先日twitterのプチコンクラスタでプチコンにおけるデータ圧縮について盛り上がったにょ。
データを圧縮するメリットやデメリットは下記のようになると思われるにょ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

私はかつてポケコンにおいて「PSS(ポケコンソフト統一規格)」というものを提案したにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/PSS.HTM
これはユーザーにいかに配慮したプログラムを作れるかということで考案したのだけど
これらの項目は長年掛けて多くの経験をすることでようやく完成に至ったにょ。
単なる自己満足で終わらないためにはそれによって生じるメリットとデメリットを天秤に
かけて少しずつ調整していく必要があるにょ。
そう考えると単に圧縮をしてないからユーザーに配慮しているなんてことにはならない
ことは自ずと分かってくるにょ。（私はまだプチコンにおいては経験不足であるためPSSと
同等のものをプチコンで作るのは難しい）

1495：御茶目菜子：2013/03/05(火) 23:54:50
ユーザーに配慮したプログラムを作ろう
昨日書いたようにプチコンでユーザーに配慮したプログラムを作るという意識が高まっている
みたいなのでPSS（プチコンソフト統一規格）を作ってみたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/pss.htm
これは18年前にポケコン（PC-E500系）用に考案したPSSを元にして作られているにょ。
ポケコン用のをベースにしてプチコン用にアレンジを加えたのがこの12個の項目にょ。

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

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

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

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

18年前だと私はネットをやっておらずリアルメールで意見交換をしていたため草案から
正式規格化まで2年の歳月を費やしたにょ。
しかし、今はネットで意見を募ればすぐに反応があるため草案さえ出しておけば規格化は
容易でありそれほど問題はないにょ。
というわけで、ポケコン用に作ったものに加えて今までtwitter等で出てきた意見を元に
してできたのが今回のPSSというわけにょ。
もちろん、これで完成というわけではなくさらに多くの意見を取り入れて必須項目や
推奨項目の追加が今後行われる可能性は十分にあるにょ。
私は（BASIC歴が10年を越えた）20年くらい前からユーザーに配慮したプログラムに
ついて考えてきたけどユーザーに配慮するためには自分自身にある程度の余裕が必要にょ。
「とりあえず動く」というプログラムを作るのが精一杯の人にユーザーに配慮したものを
作ろうというのはなかなか出来るものではないけどプチコンで初めてBASICに触れた人も
初代プチコンからなら約2年、mkIIから始めた人も約1年ということでそろそろある程度
（気持ちの面で）余裕が出てくる頃ではないかと思われるにょ。
その出てきた余裕をどのように使うかは人それぞれだけどプレイしてくれるユーザーの
ために使えるようになると良いのではないかと私は思うにょ。

1496：マリモーマ：2013/03/06(水) 01:02:01
目の付け所が　オワコン
シャープ、韓国の「サムスン電子」と資本提携へ
http://potemkin.jp/archives/50808917.html
http://www3.nhk.or.jp/news/html/20130305/k10015978941000.html

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

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

http://liv0.com

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

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

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

主に液晶パネル関係だからポケコンはあまり関係が無さそうにょ。
というか、G850VSは現時点で国内で作っているにょ？

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

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

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

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

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

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

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

まぁ、ここまでシンプルなアルゴリズムの簡易的な地球儀でも実行速度はデフォ（半径64）の
場合で0.4fpsと非常に遅いにょ。
現在は64色だけどこれを16色x16階調くらいにしてシェーディング処理を行うという方法も
あるけどこれよりもさらに遅くなることを考えると微妙にょ。
まぁそれでもBASICでここまで出来るならば御の字といえるかもしれないにょ。
ATANによる角度計算、ドットの読み取り、表示を1秒間に約5000回行えているわけだしね。
魚眼フィルタの方は角度の計算にもう少し時間がかかっているけどこちらはそこまで高速性を
求めないので問題は無さそうにょ。
というか、地球儀以外で魚眼フィルタを何に使うかが問題かもしれないにょ（笑）

1499：ありふれた：2013/03/10(日) 11:40:25
プチＯＳを、のせて
ＰｕｔｉｔＣｏｍｐｕｔｅｒＯＳのＱＲコードを、のせて。
1500：御茶目菜子：2013/03/10(日) 23:58:05
レスにょ
ありふれたさんへ
＞ＰｕｔｉｔＣｏｍｐｕｔｅｒＯＳのＱＲコードを、のせて。

とりあえずCAVEだけが動くという未完成品なので公開はしていないにょ。
作りながら仕様を考えていったのでプログラムはぐちゃぐちゃだし考えた仕様もほとんどが
搭載されていないので使いものにならないしね。
未完成でもこれをベースに改造してみようと考えているのならばこれに使われているコードは
使用せずに一から作り直した方がいいくらいにょ（笑）
ぶっちゃけ私の未完成品よりプチコンコンテストに投稿されている「OTYAX」の方が遙かに
優れていると思うにょ。
http://wiki.hosiken.jp/ptcmcon/?Toukou%2FOTYAX

1501：御茶目菜子：2013/03/10(日) 23:59:18
祝プチコン2周年
非公式プチコンコンテストは昨日でエントリーが締め切られたにょ。
私はエントリー開始日（3月3日）に1画面プログラム「PETIT DRUM+BASS」を投稿しているけど
どうも今回はエントリー数が少ないみたいなので先日作った「簡易地球儀」に少し手を加えた
簡易地球儀2を作って投稿してみたにょ。
http://wiki.hosiken.jp/ptcmcon/?Toukou%2F%B4%CA%B0%D7%C3%CF%B5%E5%B5%B72
http://www.youtube.com/watch?v=cUmHzYcWIPE

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

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


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

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

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

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

というわけで、昨日ちょうど発売から2周年を迎えたプチコン（mkIIも14日で1周年）だけど
まだまだユーザーの盛り上がりは衰えてないにょ。
いずれ登場するであろう3DS版のプチコンは現時点では詳細は全く出ていないため発売は
早くても半年以上先と思われるけどまだまだmkIIで十分いけそうな感じにょ。
ただし、何度も書いているように保存領域の問題だけは深刻なのでそれさえ何とかする
方法（例えば保存専用の追加DSiウェアを用意するとか）が欲しいところにょ。
一番いいのはプチコンからSDカードにセーブできるのだけどこれはDSiウェアでは対応が
可能とはいえプログラムのセーブが可能になって公式に自由に使えるようにするのは
任天堂の認可をもらうのが難しいのかもしれないにょ。（セーブしたプログラムは本体に
紐付けしていれば問題はないと個人的には思うけど）

1502：御茶目菜子：2013/03/14(木) 23:52:37
プチコンmkII発売1周年＆私の今後の予定
今日でプチコンmkIIが発売されてちょうど1年経ったにょ。
プチコンmkIIでは初代プチコンでは不満の1つだった自作プログラムのやりとりがQRコード
経由で可能になり、発表する側もそれを実行するユーザー側も非常にお手軽になったにょ。
しかし、それ故にここで何度も書いているように保存領域がすぐに一杯になるという問題を
生み出してしまったんだけどね。
それはおいといて、ここ1年の私の作品を振り返ってみるにょ。

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

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

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

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

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

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

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

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

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

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

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

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


ということで、mkIIが発売されて1年間を振り返り、今後の私の予定も書き記したのだけど
公式twitterでは明日なにやら発表があるらしいにょ。
mkIIの後継が発表か・・・とも思えなくもないけどそこまでハードルを上げるなという
公式ツイートにもあるように追加データの配信かもしれないにょ。
使えそうなデータの配信ならばそれを使って何かプログラムを作ってみることにするにょ。

1503：天郷思音：2013/03/15(金) 17:12:56
(無題)
プチコン新作ならず。残念。

1504：御茶目菜子：2013/03/15(金) 23:17:50
レスにょ
天郷思音さんへ
＞プチコン新作ならず。残念。

mkII後継が発表されないのは想定内だったにょ。
大喜利を今開催するということは後継はもうしばらくかかるのかもしれないにょ。
年内に発売されるかどうかという感じかも・・・。
それまでは保存領域不足が深刻化しているプチコンmkIIで何とかやりすごすしかなさ
そうにょ。（まぁそれ以外は大きな不満もないけど）

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

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

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

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

すでに第2回プチコン大喜利は本日から受け付けを開始しており、4月30日までエントリーを
行っているにょ。
私も当然参加予定にょ。
可能ならば1画面プログラムを1本、1画面超のプログラムを1本作る予定にょ。
前回の第1回プチコン大喜利ではPETIT RUN mkIIで技術賞を戴いたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#prun2
今回もやはり参加するならば入賞を狙いたいところにょ。
まぁ「参加するなら大賞を狙う」と大きく出たいたいところだけど大賞になるためには並の
アイデアでは難しいからね。（誰も作らないものにあえて挑まないと・・・）
あと今回は大賞とは別にMVPという賞もあるみたいにょ。（Most Valuable Programmerの
略らしい）
こちらの賞も何だか気になるところにょ（笑）

1506：松田：2013/03/18(月) 10:34:01
ELGIN WATCH
人気の高額腕時計ロレックスやオメガなど欲しかったあのブランドが
お手頃価格で見つかるかも
ELGIN WATCH

http://www.elygine.com

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

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

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

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

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


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

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

私が知る限りでは2軸回転プログラムをプチコンで作っているのは私だけなのでこれならば
インパクトのあるものが作れそうだけどそれを活かしたものとなると結構難しいにょ。
マリオカートのようなレースゲームならば（敵車を出さなければ）簡単に作れるけど
「1分」というテーマを考えるとレースゲームはあまりに単純過ぎて面白みがないにょ。
（普通にプレイすれば1分でゴールできるくらいのコースにすればいいだけのことだし）
やはり、作るならば何かひねりが欲しいところにょ。
前回の大喜利は何とか「技術賞」をいただけたけど次は競争率が高いだけに大賞どころか
入賞さえもかなり厳しそうだからね。

1508：hatena：2013/03/21(木) 20:58:44
おちゃめくらぶ 誤字報告
誤字があったページはこちらです。
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm

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


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


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

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

報告どうもにょ。

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

初期の頃の作品はどれもリスト短縮の余地がありまくりにょ。
プチコン100m走はプチコン100m走mkIIとして、PETIT RUNはPETIT RUN mkIIとしてリスト短縮
してその短縮した分を画面表示をアップさせたり、ゲーム性をアップさせたりしているにょ。
他のも短縮できる余地はたくさんあるけど今のところ保留にょ（笑）
リスト短縮テクニックはどんどん新しいものが見つかっているためmkII発売以降に作ったものでさえ
リスト短縮が可能なものが多いにょ。

1510：御茶目菜子：2013/03/23(土) 23:59:52
EOS Kiss X7はミラーレス対抗のデジタル一眼なのか・・・？
キヤノンからデジタル一眼レフEOS Kiss X7とEOS Kiss X7iが発表されたにょ。
http://dc.watch.impress.co.jp/docs/news/20130321_592405.html
http://dc.watch.impress.co.jp/docs/news/20130321_592445.html

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

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

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

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

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

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

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

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

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

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

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

1511：道産子の初心者：2013/03/26(火) 15:13:27
リンクの説明の書き換え申請
プチコントーナメントのエントリーは締め切ったので説明を書き換えお願いします。

http://www53.atwiki.jp/petctournament

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

リンクの説明文を書き換えておいたにょ。

1513：道産子の初心者：2013/03/27(水) 21:54:04
レス
=おちゃめさんへ=
確認しました。ありがとうございます。

http://www53.atwiki.jp/petctournament

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

いえいえ、また何かあったら言ってにょ。

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

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

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

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

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

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

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

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

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

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

さて、そうなると「10fpsあればボタン入力判定漏れ」は緩和できるとはいえ可能な限り
30fpsに近づけるようにするのがベターだといえるにょ。
それにボタン入力判定も「秒5回」で「半分の時間押している」という仮定において10fps
ならば問題ないというだけであって連射をしなくても秒7〜8回の入力は十分行えるわけ
なのでそうなるとスピード感はともかくとして快適にプレイできる最低のボーダーラインは
15fpsくらいになると思われるにょ。
したがって、私が大喜利用に作るゲームもそれを目標に高速化を行う予定にょ。

1516：天郷思音：2013/03/30(土) 19:05:07
(無題)
今使ってるカメラはカインズのトイデジで131万画素で1980円。
「カインズ　トイカメラ」と検索したら出てきたのでそれなり知名度があるようなのでカメラに詳しいおちゃめさんのところに今使ってるカメラの報告に来た。
モニターがない。動画も撮れる。静止画は1280*1024で保存されるけど半分くらいにリサイズしないと質が悪い。
青系の色が変なのはなぜだろうと思ったがほかの人の持ってる同機種でも同じようなことが起こるとのこと。

1517：御茶目菜子：2013/03/30(土) 21:55:08
レスにょ
天郷思音さんへ
＞今使ってるカメラはカインズのトイデジで131万画素で1980円。
＞「カインズ　トイカメラ」と検索したら出てきたのでそれなり知名度があるようなのでカメラに詳しいおちゃめさんのところに今使ってるカメラの報告に来た。

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

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

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

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

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

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

というわけで、「トイデジカメ」ということを考えると納得できる範疇だと思うにょ。
もしも、画質に不満があるならば昨今の国内の大手メーカー製のデジカメを買うのが良いの
ではないかと思われるにょ。
1年前の機種でも大きく性能が落ちるなんてことはないため半値以下に下がった型落ち品の
セール品を狙うのが良いのではないかと思われるにょ。
あまり安価な機種だと光学式の手ぶれ補正がないため室内や暗所などではフラッシュ撮影が
不可欠になるにょ。（フラッシュを使ったら描写が不自然になったり、反射で撮影対象が
映らなかったりという問題もあるため個人的にはフラッシュはほとんど使わない）
あと室内や暗所などでの撮影が多いならば高感度設定で使う頻度が高いのでそれを重視して
いる機種を買うのがベターだと思われるにょ。

1518：御茶目菜子：2013/03/30(土) 21:56:41
やっぱりゲームはUIが重要
ゲームでは重要なものの1つにUIがあるにょ。
プチコンはDSiウェアということでDSiのハードウェアボタンやタッチパネルを使用することが
できるにょ。
3DSでもDSiウェアとして動作するため3DS専用のデバイスにはプチコンは対応していないにょ。
画面解像度や立体視はまぁ仕方ないとしてアナログ入力が可能なスライドパッドは対応して
いるとゲームの幅が広がるだけに残念に感じている人も多いのではないかと思われるにょ。
それならば作ればいい・・・ということで「アナログPAD」ルーチンを作ってみたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#pad

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

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

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

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

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

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

DSや3DSではレースゲームがたくさんあるけどタッチパネルをハンドルに見立てて操作する
ゲームというのは私が知る限りではリッジレーサー（北米版）くらいしかないにょ。
これはハンドルは直感的な操作が可能とはいえタッチパネルとボタン操作の両立が難しい
というのが一番の原因ではないかと思われるにょ。
そうなると私が作ろうとしているレースゲームもその辺が重要になってくるかもしれないにょ。

1519：マリモーマ：2013/03/31(日) 00:45:56
ネジコンも　昔あったな
ハンドルコントローラーで使いにくいのは wiiのマリオカートのやつかも
あれは　慣れないと難しい気がする

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

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

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

WiiのマリカーはプレイしていないけどWiiリモコンの加速度センサーを利用しているだけで
ハンドルコントローラーはただの外枠だからやっぱりコツをつかむまでは難しそうにょ。
どんなコントローラでもやはり重要なのは慣れなので十字ボタンでの操作に慣れている以上は
初見だとそれが一番簡単に感じてしまうにょ。

1521：道産子の初心者：2013/04/01(月) 12:04:03
リンク説明書き換え申請
プチコントーナメントが開催されたので説明の書き換えをお願いします。
何度もお願いして申し訳ございません。お願いします。

http://www53.atwiki.jp/petctournament

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

説明を書き換えておいたにょ。
せっかく開催させるわけだからぜひ成功させてにょ。

1523：御茶目菜子：2013/04/01(月) 22:23:04
真実はいつもひとつ・・・？
さて、4月1日ということで恒例のエイプリルフールネタが今年も健在にょ。
http://nlab.itmedia.co.jp/nl/articles/1303/29/news077.html
http://www.kotaku.jp/2013/04/april_fools_day.html

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


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

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



《　4月2日追記　》

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

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

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

ちなみに動いている様子の動画を撮影したのはこんな感じにょ。
ポリゴンだと1〜2fpsということで拡大縮小や回転のペン操作もまともに受け付けてくれない
けどワイヤーフレームならばそこそこ反応はいいというのは分かると思うにょ。
http://www.youtube.com/watch?v=XmvYJA1iuz0

1524：gamekool.net：2013/04/04(木) 15:57:17
R4i sdhc rtsが3DS V5.0.0-11に運行できるため、更新方法の指導
3DSの新バージョンV5.0.0-11で運行できるように、R4i SDHC 3DS V4.5とR4i SDHC RTSを更新する必要があります。
　実は違ったカードの更新方法はそんなに大きな差別が’ありません、こちらはR4i SDHC 3DS

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

http://blog.livedoor.jp/

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

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

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

http://blog.livedoor.jp/

1526：天郷思音：2013/04/06(土) 09:33:09
(無題)
攻撃の威力は「攻撃力/防御力」と「攻撃力-防御力」どっちの式がいいだろうか。
ちなみに公式素材の戦車を使ったゲームです。

1527：御茶目菜子：2013/04/06(土) 23:30:57
レスにょ
gamekool.netさんへ
＞ニンテンドーの3DS/LL本体は更新できない症状と解決方法

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


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

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

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

ちなみにドラクエの場合は基本的には攻撃力/2−守備力/4にょ。
はぐれメタルの守備力が1023ならば攻撃力が512以上あってようやく普通にダメージを
与えることが可能になるのと同時に攻撃力が600あれば平均的に40少々のダメージを与える
ことができるようになるにょ。
その辺を考慮すれば攻撃力が512を大きく越えるまでパラメータが上昇しないということも
分かるにょ。

1528：マリモーマ：2013/04/09(火) 13:31:17
win
Windows XPはサポート終了後も使われ続ける? その数は少なくとも数千万台規模か 【デジ通】
http://itlifehack.jp/archives/7820893.html

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

http://liv0.com

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

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

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

セキュリティ面ではWin8の方がWin7より優れているのは確かだけど7もXPよりは遙かに優れて
いるし何よりWin8はタブレット端末での使い勝手向上のためにタッチパネルのないPCでは
使い勝手がダウンしているというデメリットがあるからね。
自作PCに入れるならばWin8で使いたい機能がない限りWin7をオススメするにょ。
とりあえず、Win7が入手できるうちに1本確保しておくといいかもしれないにょ。

1530：御茶目菜子：2013/04/11(木) 23:53:16
第2回プチコンコンテスト結果発表
1ヶ月前に行われた非公式の第2回プチコンコンテストの結果が発表されたにょ。
今回のエントリー作品数は12作品で投票者数は42人となっているにょ。
結果は以下の通りにょ。

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

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

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

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

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

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

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

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

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

半年に1回開催されるみたいなので次回は今年の9月の予定にょ。
その前に公式コンテストであるプチコン大喜利の締め切りが今月末に控えているにょ。
しかし、現時点では何もできてないにょ。
未だに大喜利の投稿予定ゲームに使うポリゴン表示プログラムの最適化を図っている状態
だからね。
このプログラムが完成しないと大喜利用のプログラムのコーディングができないためまだ
ゼロどころかマイナスかもしれないにょ（笑）

1531：御茶目菜子：2013/04/13(土) 22:14:04
プチコン用ポリゴン表示プログラムがついに完成
2ヶ月前から作っていたプチコン用ポリゴン表示プログラムがついに完成したにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/polygon.htm
http://www.youtube.com/watch?v=4OkGjWAIGt8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1532：hatena：2013/04/14(日) 15:53:17
おちゃめくらぶ 誤字報告
このページに誤字がありましたので報告致します。
http://ww5.tiki.ne.jp/~ochame/petitcom/polygon.htm

《　さらに初心者向けの　データ作成例　》　にて、
あとはこれでラベル@TRIANGLEを[A]{B][X][Y]いずれかのボタンに登録すれば良いです。
となっていました。

あとはこれでラベル@TRIANGLEを[A][B][X][Y]いずれかのボタンに登録すれば良いです。
こちらが正しいかと思います。

1533：ありふれた：2013/04/14(日) 16:32:31
ユウチューブがおかしくなっています。
ochame_nacoさん君のyoutudeがプレゼントに、なっています。
その、アドレスは、"http://www.youtude.com/watch?v=_zzCVJQwKsY&quot;

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

1534：マリモーマ：2013/04/14(日) 19:17:47
スパム？
下のアドレスは　よく分からない　アンケートに飛ぶよ
踏まないようにね

http://liv0.com

1535：御茶目菜子：2013/04/14(日) 23:55:58
レスにょ
hatenaさんへ
＞このページに誤字がありましたので報告致します。

報告どうもにょ。
校正は十分にやっているつもりだけど絶対に何かあると思っていたにょ。
まだまだたくさんありそうにょ。
十分に校正を行っているサイトに掲載の文章でもこれなんだからこの掲示板に書いている
文章は校正を最小限しか行っていないため誤字、誤変換が大量にあると思うにょ（笑）


マリモーマさんへ
＞下のアドレスは　よく分からない　アンケートに飛ぶよ

報告どうもにょ。

1536：御茶目菜子：2013/04/21(日) 00:01:30
大型センサー搭載のコンデジがこれからのトレンドになる！？
コンデジはここ数年出荷台数の前年割れが続いているにょ。
その1つの理由としては昨年の1月31日に書いたようにスマホの普及による影響にょ。
スマホに搭載されているカメラは飛躍的な性能向上しており、一般的なコンデジとそれほど
大きな差がないレベルの画質を得られるようになってきているからね。
それは国内ではスマホが普及前にガラケーですでに行われていたことなのでスマホによる
影響といえばSNSなどとの親密性にょ。
撮影してすぐに投稿できるというのは普通のデジカメではできないからにょ。
そのためデジカメ本体に無線LANを内蔵してスマホと連携させる機能を持たせるというのが
ここ1年くらいのトレンドになっているにょ。

スマホにないコンデジのメリットはやはり高倍率ズームや防水機能ではないかと思われるにょ。
どちらもスマホが現状のように薄型、軽量を重視している限りは搭載が困難（防水機能に
おいては生活防水レベルならば簡単にスマホでも導入できるけど海水浴等で気軽に使える
レベルではない）ということでそれらはスマホと共存することができるもののローエンドの
コンデジは今後生き残るのが難しいと思われるにょ。
それとやはり高画質で撮影できる機種にょ。
スマホに搭載されているセンサーやレンズは筐体サイズを考えると高性能とはいえないものの
それでもスマホの画面で見るだけならば十分な性能を持っているにょ。
しかし、それをプリントしたりPCの大画面で閲覧する際には十分な画質とは言い難いにょ。
そのためデジカメ市場はコンデジの大幅な下落によってトータルの販売台数は減っているけど
ミラーレスやデジタル一眼レフは依然として前年比増が続いているにょ。
http://dc.watch.impress.co.jp/img/dcw/docs/596/344/html/004.jpg.html

ミラーレスやデジタル一眼の販売台数が伸びているというのは「高画質」というニーズが
強まっている影響といえるにょ。
スマホにカメラ機能が搭載されているとはいえミラーレスやデジタル一眼はそれよりも高い
画質を得ることができるという認識が多くのユーザーにある現れともいえるにょ。
その高画質のニーズによって各社ともに最近は高級コンデジに力を入れているにょ。
高級コンデジというのはニッチなニーズであり、昨今はミラーレスのシェア拡大によって
高級コンデジの立ち位置が微妙になってきてはいるもののそれは各社ともに自社製品内で
競合が起きないように工夫をすることで克服しているにょ。
ミラーレスでは大きなシェアを獲得しているソニーは高級コンデジとして1インチセンサーの
RX100、フルサイズセンサーのRX1という高級コンデジを発売しているけどこれは同社の
ミラーレスであるNEXは現時点ではAPS-Cセンサーを搭載であり、それらと棲み分けのための
措置だと考えることができるにょ。（近い将来フルサイズNEXが登場すると予想されている
ためRX1後継機とフルサイズNEXをどのように販売していくかが注目点となる）
ニコンにおいてはミラーレスであるNikon 1は1インチセンサーを搭載であり、先日発売した
COOLPIX AはAPS-Cセンサーであるため棲み分けが可能であると言えるにょ。

もっとも単純にセンサーサイズだけではなくレンズ一体型の大型センサー（1インチ以上）
搭載の高級コンデジは「レンズ交換ができない」ということに価値があると思われるにょ。
それは、センサーとレンズをマッチングさせることで高い性能を発揮できるようにすることが
可能になるというだけではなく本体とレンズを別々に用意するよりも小型軽量化が可能になる
というメリットやレンズ一体型であるため機密性が高く内部に塵や埃が入りにくいという
メリットもあるにょ。
デジタル一眼はその構造上レンズ交換時の埃の進入を避けるのは非常に困難であり、その点
レンズ一体型ならばその心配がほとんどなくなるので気軽に使用可能になるにょ。


そんな中ペンタックスリコーからAPS-Cセンサーを搭載で世界最小最軽量となる高級コンデジ
「GR」が発表されたにょ。
http://dc.watch.impress.co.jp/docs/news/20130417_596186.html
APS-Cセンサーを搭載の機種というのは少し前までは非常に珍しい存在だったけど富士フィルム
X100とその後継であるX100s、シグマDP1Merrill、DP2Merrill、ニコンCOOLPIX Aなどがあるにょ。
後発というほどではないけどすでに他社からも出ており単純にセンサーサイズだけを見ると
新鮮味に欠けるにょ。
しかし、GRはAPS-Cセンサーを搭載で世界最小最軽量というのが大きなアドバンテージとなって
いるにょ。
メーカー的には明言はしていないけど事実上GRデジタルIVの後継機といえそうにょ。

GRデジタルは銀塩で出ていた高級コンパクトカメラGR1をベースにデジカメ化したものにょ。
ただし、センサーサイズは高級コンデジとしては一般的であった1/1.7インチセンサーが
採用されていたにょ。
本モデルGRはそのデジタル化されたGRDの5代目といえるわけにょ。
では、前モデルであるGRD IVと競合機種であろうCOOLPIX Aとスペック比較してみるにょ。

　　　　　　　　GR　　　　　　　　　GRD IV　　　　　　　COOLPIX A
センサーサイズ　APS-C　　　　　　　 1/1.7インチ　　　　 APS-C
画素数　　　　　1620万画素　　　　　1000万画素　　　　　1616万画素
レンズ　　　　　換算28mmF2.8　　　　換算28mmF1.9　　　　換算28mmF2.8
最短撮影距離　　10cm　　　　　　　　1cm　　　　　　　　 10cm
手ぶれ補正　　　無し　　　　　　　　有り　　　　　　　　無し
感度　　　　　　ISO100-25600　　　　ISO80-3200　　　　　ISO100-6400（拡張25600）
シャッター速度　300-1/4000　　　　　180-1/2000　　　　　30-1/2000
動画　　　　　　H.264フルHD　　　　 MotionJPEG VGA　　　H.264フルHD
サイズ　　　　　117x61x34.7　　　　 108.6x59.8x32.5　　 111x64.3x40.3
重量　　　　　　245g　　　　　　　　219g　　　　　　　　299g

GRのGRD IVに対する最大のアドバンテージはセンサーサイズにょ。
1/1.7インチセンサーは普及クラスのコンデジに試用されている1/2.3インチセンサーと
比べて約1.5倍の面積であるもののAPS-Cサイズはその大きな1/1.7インチセンサーと比べて
約8倍の面積となっているにょ。
面積比がそのまま画質に繋がるわけではな好条件下においてならば多少の面積差を跳ね返す
ことは可能になるにょ。
APS-Cセンサーを搭載したデジタル一眼レフも普及クラスの標準ズームを装着した場合には
そのセンサー性能を引き出すことは難しいため高性能なレンズを採用しているGRD IVは日中
屋外であればそのAPS-Cのデジタル一眼と比べてそれほど大きな差はないくらいの画質を得る
ことができていたにょ。
しかし、当然ながらAPS-Cセンサー＋高性能レンズであればよりGRD IVを上回る画質になるのは
必至といえるにょ。

では、GRのセンサーサイズ以外のスペックを見てみるにょ。
最初に気が付くのはレンズの明るさにょ。
高級コンデジにおいて普及クラスのものと差別化をするため1/1.7インチセンサーを採用の
高級コンデジは昨年7月27日に書いたようにレンズが明るくする傾向にあるにょ。
明るくするということはセンサーの画素ピッチが狭くなってきている昨今のコンデジでは
回折限界のためセンサーの画素数分の解像感を得ることが不可能になってきているという
ことを考えれば価値のあることであり、高級コンデジでは絞りの自由度を高めるということに
効果があるにょ。（絞っても回折限界で画質が落ちる一方であるためNDフィルターによって
露出を制御しているコンデジが大半だけどそれだと絞りで被写界深度をコントロールする
ことはできない）
普及クラスのコンデジでも広角側のみF1.8という機種があるけど昨年から始まった高級
コンデジにおいては望遠側もF2.3〜2.8と比較的明るくなっているにょ。

GRD IVは単焦点であるため元々F1.9という明るいレンズを搭載しているにょ。
昨今のトレンドに載って明るいレンズを・・・といってもこれより明るくするのはコストや
性能を考えた場合かなり困難にょ。
そこで、もう1つの選択肢としてセンサーの大型化への道を進んだにょ。
レンズは1段少々暗くなったけどセンサーサイズが8倍以上になっているためボケ量においても
暗所性能においても単純計算で約2段分くらい向上しているにょ。
これは設定感度においても現れており、ISO25600というのは一般的なAPS-Cのデジタル一眼レフ
並といっていいにょ。
とはいえ、センサーサイズが大きくなってギリギリまで小型化している影響で手ぶれ補正
機能がないのは残念にょ。
手ぶれ補正が3段分あると仮定すれば「手ぶれを考慮した限界撮影」はGRD IVの方が1段分
有利になるからね。

ただ、センサーが大きくなるとマクロ性能（最大撮影倍率）の面では不利になりやすいにょ。
コンデジがレンズ前1cmで撮影可能な機種が多いというのはセンサーが小さいから可能になって
いるにょ。
GRではレンズ前10cmということでGRD IVと比べて一見すると10倍ダウンに見えるけどレンズと
センサーとの間の距離を考えると10倍もないにょ。
厚みから考えるとGRの最短撮影距離はセンサー面から14cm程度と推測されるけど一般的な
APS-C用の換算28mmのレンズでは20〜30cm前後が一般的であるためその半分の距離で撮影が
可能になるということは一般的なレンズと比べて撮影倍率で2倍程度高くなるといえるにょ。
実際はセンサー面からの距離ではなく投影距離を考慮しないといけないためこの単純計算
通りにはいかないもののAPS-Cセンサーを搭載の換算28mmレンズよりは遙かに高倍率撮影が
可能になるのは確実にょ。（まぁそれでもGRD IVの1cmマクロよりは撮影倍率で劣るけど）

センサーサイズが大きくなるというのはメリットが多いのだけど問題は筐体サイズと価格にょ。
筐体サイズは上記の表のように8倍センサーが大きくなったにも関わらず筐体サイズはGRD IV
と比べて一回り大きくなっただけにょ。
銀塩のGR1と比べるとほぼ同サイズということで現在水準から考えるとコンデジとして見た
場合には大きく感じるけどAPS-Cセンサーを搭載しているということを考慮すればこのサイズや
重量はかなり大きなアドバンテージになるにょ。
これはミラーレスのようなレンズ交換式では実現が困難であるためまさに一体型ならではと
いえるにょ。
センサーサイズが大きくなった場合には本体は小型化できてもレンズを小型化するのは
画質を犠牲にしない限りは難しいからね。
センサーサイズが大きくなった場合にはレンズが大型化してしまうけどコンデジとして使用
する場合にはレンズバリアがある方が使い勝手がいいにょ。
キャップ式だとどうしてもキャップを開けるという作業が必要になるからね。

すでに発売されているニコンのCOOLPIX AはAPS-Cセンサー搭載でそこそこ小型軽量でさらに
レンズバリア式ということでなかなか良いコンデジだったけど問題なのは価格だったにょ。
予価128000円というのはさすがに辛かったからね。
これが、ハイブリッドビューファインダーを搭載して高コストであることが分かるX100sなら
128000円というのは納得できる価格であるため問題ないけどそれと比べて同価格であるならば
COOLPIX Aは高精細のEVFを同梱すべきだったと言えるにょ。
その点、このGRは予価99800円というのは同じAPS-Cセンサー搭載のCOOLPIX Aと比べると3万円
程度安価であり、すでにやや価格が下落しているCOOLPIX Aと比べて実売価格でも約1万円
安価となっているにょ。
「ニコンブランド」や、COOLPIX Aの外観デザインに高い価値を置いている人で無ければこの
GRの方が格段にお買い得感が高いにょ。

昨今の高級コンデジのトレンドは「明るいレンズ」もしくは「（1インチ以上の）大型
センサー」であるためそれらの選択肢はこれからどんどん増えていくと予想されるにょ。
これは冒頭で書いたようにすでに「普及型のコンデジは売れなくなってきている」という
ことからスマホと競合しない高いニーズのある高画質で撮影できる機種というのは確実に
一定数の需要があるためにょ。
一眼レフの低価格化やミラーレスの普及で高画質を求めるため高級コンデジの出番は無く
なるかと思われたもののやはり一眼レフ、ミラーレスと高級コンデジは別腹と感じる
ユーザーがそれなりに多いというのとメーカー側が自社内で競合しないようにしている
ということが高級コンデジのラインナップの増加を行っているといえそうにょ。
センサーの大型化は素直に歓迎したいところだけど価格面を考えると入門機のデジタル
一眼やミラーレスを買った方が安いというのがネックにょ。
対象ユーザーを考えると一眼レフならば中級機クラスと価格を比べる必要があるため
一概に高価とはいえないけど一眼レフがどんどんデフレしているのに高級コンデジは
センサーの大型化などによって高価格化が進んでおり価格面を考えた場合にはそこまで
大きなシェアを得ることはできないのであまり乱売するとメーカー側にとっては厳しい
結果に終わるのではないかと思われるにょ。

1537：御茶目菜子：2013/04/22(月) 23:48:14
お絵かきを始めよう！（お絵かき初心者向け講座）
私は趣味としてお絵かきを始めてから今年で27年になるにょ。
その割りには全然上手くないんだけどそれはマイペースで頑張っているためにょ。
上達するためには昨年1月9日に書いたように目標と目的が重要となるにょ。（もちろん
それを実現するための練習が必要不可欠なのは言うまでもない）
http://6407.teacup.com/ochame/bbs/3050
例えば絵を描く理由がpixivで評価合計100点以上をとるためならば上達する必要はないし
単に「描くのが楽しいから描いている」というならば好きなように描けばいいけどそれでは
上達が期待できないということにょ。
私も一時期（90年代半ば）は雑誌への掲載率を高めるため上達を目指していたためその頃は
大幅な上達があったにょ。
それからは、それで満足してしまったということもあり上達があまり無く、逆に12年前に
アナログからデジタルへと移行した際には大幅に劣化してしまったにょ。
デジタルに移行した当初は全然ダメだったけどここ数年でようやくアナログ全盛時を越える
レベルに達した感じであり、今はもう「デジタル＞アナログ」といった感じにょ。

さて、pixivを見ると（登録年齢が必ずしも正しいかどうかは微妙だけど）10代の活躍が
めざましいにょ。
私のような期間だけベテランな人はお呼びではない感じだけど30代や40代になって生活に
ゆとりができてお絵かきを始める人も少なくはないため未経験だけど今から始めるのは躊躇
しなくてもいいにょ。
実際、私のtwitterのフォロワーの中にも30代になって始めた人は何人かいるからね。
それと同時にやっぱりお絵かきを始める年齢として多いのは10代にょ。
「絵なんて学校の授業以外で描いたこと無い」という人が大半であり、アニメ、マンガ、
ゲームの影響で絵（特に萌え絵）に興味を持つ人も多いにょ。
大半はそういったコンテンツを消化するだけで終わってしまいがちだけど自分で描くという
ことに興味を持っている人も多いと思うにょ。
今回は、そういったこれからお絵かき（主に萌え絵）を始める「初心者」向けに書いてみる
ことにするにょ。


まず必要なのは絵を描く道具にょ。
これはアナログかデジタルかで必要な道具が変わってくるし、単なるラフか完成原稿にする
のかでも変わってくるにょ。

　(1)アナログ完成原稿用
　(2)アナログラフ、デッサン、もしくはデジタルの下書き用
　(3)完全デジタル用

(1)これはあえて説明するまでもないことだけどカラーの場合は一般的に美術の授業で使って
いるような道具がそのまま使えるにょ。
カラー画材としては水彩絵の具、油絵の具、アクリル絵の具などがあり、それに適した用紙を
選択すれば良いにょ。
アナログのカラーマンガを描く場合はコピック（コミックマーカー）という選択肢もあるにょ。
ただし、コピックは1本あたり400円弱と高価だし、必要最小限の色を揃えるだけで数千円の
予算が必要になってくるため「興味があるからちょっとやってみよう」という人には気軽に
オススメできないのが難点にょ。

モノクロ完成原稿となると厚手の上質紙、ケント紙、もしくはマンガ原稿用紙が必要にょ。
下書きは鉛筆やシャープペンシルで十分だけどペン入れをするならばGペンや丸ペンとインクが
必要になってくるにょ。
そして、濃淡や各種表現を行うためにはスクリーントーンが必要になるにょ。
スクリーントーンはサイズによって価格が大幅に変わってくるものの必要なものを一通り
揃えるだけで数千円必要になってくるにょ。
まぁICの61番などの定番のものだけを買って必要になったらその都度買い増しすれば出費は
最小限に抑えることができるけどね。

(2)絵を描いたことない初心者にいきなりアナログ完成原稿を求めるのは厳しいためやはり
最初は気軽に始められるラフ、デッサン、模写などがよいかもしれないにょ。
これは基本的には絵が描ける道具であれば何でもいいにょ。
ただし、描きやすいものやランニングコストを考えるとある程度絞られてくるにょ。
描く道具は普段使っている鉛筆やシャープペンシルで十分にょ。
デッサンを行うには2B以上の鉛筆とスケッチブックがベターだけど濃淡表現を行うという
のでなければシャープペンシルで問題はないにょ。

描くための用紙も何でもいいのだけど何らかの意図がない限りは線が入っていない無地の
用紙がベターにょ。
コスト面を考えるとオススメなのがコピー用紙にょ。
これならばホームセンター等では500枚入りで200円程度で購入が可能であるため毎日10枚、
20枚使っても「紙がもったいない」とかいうことがあまりなくなるにょ。（上手くなるため
には数をこなす必要があるため気軽に使えるレベルのランニングコストが重要となる）
線が入っていると便利なのは比率を考えながら模写の練習をする場合にょ。
ただし、ずっと方眼紙のようなものを使っているとそれがないと描けなくなってしまうため
ある程度慣れたら無地の用紙を使うのがベターにょ。

PCで描く（デジタル塗り）用の下書きに使う場合には次の(3)で示したようなPCが必要になる
他にPCに取り込むための道具が必要になってくるにょ。
フラットヘッドスキャナ（一般的なスキャナ）がかつてはポピュラーだったけど最近はむしろ
プリンタと合体した複合機の方がポピュラーになっているにょ。
よほど古い製品（20年前の製品とか）でない限りはスキャナのスペックが問題になってくる
ことはほぼないので安心にょ。
スキャナで取り込む場合には解像度設定がまず必要になるにょ。
どの程度にするかはPCのスペックとの相談になるけどB5〜A4の用紙に描いた場合には300〜
600dpi程度で取り込むのがベターにょ。（1200dpiとかの高精細で取り込むのはPCに極めて
高いスペックが要求されてくるし、何よりそこまで精度を上げても元の原稿がボトルネック
になるため意味がない）
スキャナや複合機がないという人は絵を描く以外にも使えるため新規購入をオススメしたい
ところだけど安くても1万円程度する（エプソンやキャノン以外の製品はインクが高価だったり
古い製品になると店頭入手ができにくくなるため安くてもオススメしにくい）ということで
デジカメで代用したいという人もいると思うにょ。

スキャナの代わりにデジカメを使うというのは10年前ならかなり厳しかったけど昨今は
デジカメの性能も上がっているためそれほど問題はないにょ。（500万画素くらいでキレイに
撮れるレベルの性能があれば問題ないため昨今のデジカメならばどの機種であっても概ね
大丈夫だけどDSiや3DSに付いているようなおまけ程度のデジカメ機能では実用レベルの
画質を得ることができない）
しかし、使用する場合にはいくつか注意点が必要になるにょ。
まずは撮影に関しては描いた用紙の真上から撮影しカメラや撮影者の影が用紙の上に来ない
ようにしなくてはならないにょ。
斜めから撮影してもPC上で台形を補正すれば済むだけとはいえ補正もある程度の知識か専用
ソフトを使わないと難しいためできることならば真上からの撮影がベターにょ。
撮影する場合には室内となるため手ぶれには注意が必要にょ。
フラッシュを使う場合には描くのに使った画材によっては光を反射する場合があるため可能
ならばノンフラッシュがベターにょ。（ノンフラッシュで手ぶれを起こすならば反射光で
多少白飛びしてもPCで補正が楽なのでフラッシュを使った方がいい）

この線画をPCで使用する場合にはPC上でこれを元にペン入れをするのであれば問題はないけど
ペン入れをせず、PCで取り込んだ線画をそのまま使って色塗りをするという場合には線画を
目立つように補正する必要があるにょ。（白い用紙を撮影したらグレーになるため撮影時には
露出補正が必要になるけどそれでも白が真っ白には映らない）
白くするためにはPhotoshopならばレベル補正で下限のバーを右にずらして白になるように
して中央のバーを左右に動かし線がかすれたりしないレベルでなるべく線が濃くなるように
するといいにょ。（撮影環境や実際に描いている線の濃さで変わってくるため具体的な数字を
書くのは難しいため自分の目で確かめるしかない）

(3)PCで描く場合には必要なのはPC本体とソフトにょ。
そして、できるだけあった方がいいのがペンタブレットにょ。
PCのスペックは今時のPCであれば気にする必要はないにょ。
CPUは高速であればいいのは確かだけど普通にお絵かきする程度であればPen4、PenM、Atom
程度でもそれほど困ることはないにょ。（最近10年以内のPCであれば問題ない）
むしろ重要なのはメモリの方にょ。
Pen4やPenM世代のPCをメモリ増設せずに使っている場合は256MB程度しかないためいくら
WinXPであってもこれではあまりに心許ないにょ。
描くキャンバスサイズ（縦横の解像度）によっても変わってくるし、使用するレイヤーの
数などによっても左右されるため一概には言えないけどXPであれば1GB、Vistaや7であれば
2GBあれば普通にお絵かきするのに困ることはあまりないにょ。（A4を600dpiで取り込んだり
ギャルゲ塗りなどのレイヤーを多用する塗りを行う場合にはプラス1〜2GBのメモリが欲しい）
あと古いPCだと液晶が劣化している場合もあるけどこれは予算があれば外付けの液晶モニタを
用意すれば問題ないにょ。（お絵かきで食っていく人ならば液晶モニタも吟味する必要がある
けど趣味で描く程度であればどんなものでもいい・・・とはいえ高視野角のIPS液晶がいい
かもしれない）

ソフトはピンからキリまであるにょ。
使用しているPCがWindows PCであるならば主なものを挙げると次のようなものがあるにょ。
フリーウェアならばAzZainter、Inkscape、Pixia、FireAlpaca、GIMPなどがあり、5000円
程度で購入可能な安価なソフトはSAIやCLIP STUDIO PAINT（ダウンロード版）などがあるにょ。
そして、やはり昔からの定番といえばPhotoshopにょ。
最新版はCS6となっており、本格的にフォトレタッチや画像加工する人にとっては必須ソフト
といってもいいのだけどいかんせん約10万円というのはお絵かき用として購入するには
ハードルが高すぎるし何より多機能でありお絵かきだけではその機能を十分に使い切れず
もったいないとか高機能であるが故にPCもそれなりに高いスペックを要求されてくるにょ。
学生ならばアカデミック版が3万円程度で購入可能であるためそれを購入するのもありだと
思われるにょ。
そこまでの多機能は要らないというのであれば廉価版のPhotshop elementsでもいいにょ。
こちらは約1万円で購入可能にょ。
ただし、印刷原稿を入稿する際に必要なCMYK分離ができないし、パスの作成（ベクター
データの作成）ができない（すでに作られたものを表示はできる）ということで本格的な
作業に使ったり、Illustratorとの併用に使ったりとかはしにくいためあくまでレタッチに
特化したものであり、お絵かき用として購入するならば他のソフトを考慮した方がいいかも
しれないにょ。

私が主に使っているSAIだけどやはりメリットとしてお絵かきに特化してあるため無駄な
機能が全くなくて使いやすいということと機能が少ない分だけ動作が軽いので低スペックの
PCに優しいということにょ。（文字入力やフィルタ機能もないためそれが必要ならば別途
適当なフリーウェアを使う必要がある）
これから始める人に安価な有料ソフトを1本勧めるならばSAI・・・と言いたいところだけど
これから購入するならばCLIP STUDIO PAINT（以下「クリスタ」と略す）の方がいいにょ。
クリスタは従来のイラスタの後継ソフトとして登場したのだけどダウンロード版ならば
5000円程度で購入可能（毎月500円というコースもある）ため1万円近くしたパッケージ版の
イラスタよりも買いやすくなったにょ。
それに64bitOSやマルチコアに完全対応やパース定規や3Dモデル表示の搭載などイラストを
描くのに便利な機能も満載だからね。（その分、SAIより重いと思われるけどここ2、3年の
PCであればローエンドモデルでも問題ないかも）

PCでお絵かきをするならばあった方が絶対にいいのはペンタブレットにょ。
ペンタブも安いものならば5000円程度から購入可能で高価なものは4万円くらいするにょ。
さらに液晶タブレットならば10万円くらいするため上をみたらキリがないのだけどここは
予算との相談になるにょ。
ペンタブといえば情報、性能、消耗品の入手性のどれをとってもワコムの製品以外を選ぶ
ことはないためワコムの製品内で考えると3つのブランドがあるにょ。
安価な万人向けのペンタブレットのBamboo、高性能なペンタブレットのIntuos、そして、
液晶タブレットのCintiqにょ。

Bambooには一昨年の9月8日に書いたように4つのグレードがあるにょ。
1つは最もベーシックなBamboo Pen、タッチ機能が付いたBamboo touch、touchに
イラスタmini、コミスタminiがバンドルされたBamboo Comic、同じくPhotoshop
elementsがバンドルされたBamboo Funにょ。
イラスタmini、コミスタminiは実質体験版であり、制限が多くて使い物にならないため
個人的にはソフト目当てで買うならばBamboo Funがオススメにょ。（安い店で買うと
ソフト単品を買う価格よりも安くペンタブがおまけで付いてくる感じだし）
とりあえず、安い製品が欲しいというのであればペンタブ自体の性能はBambooならばどれも
同じであるため最もベーシックなBamboo Penがオススメにょ。（安い店ならば5000円台で
購入可能）
Bamboo Fun、Bamboo ComicではSサイズとMサイズが選べるにょ。
当然サイズが大きい方が高くなるし、慣れたら大きい方が使いやすいのだけど絵を書き慣れて
ない人だと手の稼働面積が小さいためペンタブが大きいと逆に使いにくいという場合もある
ため必ずしもMサイズの方がいいとは限らないにょ。（私は長い間ハガキサイズのアナログ
イラストを描いていたせいかMサイズが大きめに感じたくらい）

Intuosは「Bambooでは物足りない」という人向けの商品だけどBamboo自体が昔の同社の製品で
あったFAVOと比べると性能が格段に上がっており、Intuosの性能が必要という人はそれほど
多いとは思えないにょ。
しかし、いい道具を使えば上達しないのを道具のせいにできなくなるから予算があれば
初心者がいきなりIntuos買うのもありにょ。
BambooにしろIntuosにしろペンタブには慣れが必要になるためお金が貯まるまでIntuosは
買わずマウスで我慢するというのであればさっさとBambooを買ってたくさん描いた方が遙かに
有意義だと言えるにょ。
もちろん、予算が多ければ初心者がCintiqを買うのもありにょ。
先日発売になったCintiq 13HDは13インチでフルHD液晶を搭載した同ブランドの最新モデルにょ。
http://pc.watch.impress.co.jp/docs/news/20130319_592317.html
ペンタブはペンと画面が別々であるためアナログ絵のようにペン先を見ながら絵を描くことが
できず慣れが非常に重要になってくるのだけど液タブならばペン先を見ながら描けるため
初心者にとってはbambooよりも使い勝手がいいかもしれないにょ。
もちろん、ベテランの人にとっては作業効率アップに有用にょ。
作業効率が高くなり、多くの絵を描けばその分だけ得られる経験値も多くなりより上達も
速くなるので作業効率の良いソフトや機器を使うというのは上達するためには有意的な方法と
いえるにょ。

PC上で描くならばペンタブはマウスとは比べ物にならないくらい使い勝手が良いのだけど
アナログで描いたものをPCで取り込んだものに色を塗るという場合にはペンタブは不要に
考えている人もいるかもしれないにょ。
確かに単純に色を載せていくだけならばマウスでもできるけど筆のように色を塗っていくと
いう感じで塗るためにはペンタブは必要不可欠にょ。
何と言っても筆圧検知があるというのは非常に大きいからね。
したがって、フルデジタルでなくてもペンタブがあった方ができることの幅も広がるし
作業効率もアップするにょ。
上記のようにこれは上達にも繋がるため少しでも早く塗りを上達させるためには少しでも
早くペンタブを導入する方がいいということにょ。


さて、お絵かきに必要な道具は以上の通りにょ。
フルアナログで気軽にラフ絵を描くだけならば追加コスト0円で可能（描いた分だけ用紙が
必要になる程度）だし、すでにPCを持っている人ならばデジカメで線画を取り込んでフリー
ウェアを使いマウスで塗ればこちらも追加コスト0円で可能にょ。
昔（80年代〜90年代）のようにPCがまだ一般家庭には十分普及しておらず、お絵かき用として
家庭にあるPCを独占使用できる人は多くなかった時代とは異なり、今はほぼどの家庭でもPCは
あるし、中高生においても自分専用のPCを持っているという人は少なくないのではないかと
思われるにょ。（まぁ、今は4万円程度で新品PCを購入可能だから安くても10数万円していた
90年代とは比べ物にならないけど）
そして、ソフトもお絵かきに使えるフリーウェアがたくさんあるからね。
Photoshopは昔と変わらず高価だけど安価なソフト、もしくはフリーウェアという選択肢が
たくさんできたお陰で昔よりはPCでお絵かきを始めるためのハードルはかなり下がっているの
ではないかと思われるにょ。

スキャンをする場合とは異なりフルデジタルで描く場合は解像度で悩む人もいるのではないか
と思われるにょ。
印刷するならばdpi設定は非常に重要だけどフルデジタルでWeb上で公開するのであればdpi
設定はほとんど気にする必要はないにょ。
文字入力の際にそのdpiでサイズが決まる程度なので描いた絵に文字入力をしないのであれば
必要になるのはキャンバスサイズ（つまり、その絵の縦横のドット数）のみにょ。
これは公開する予定のサイズから逆算をして決めるといいにょ。
XGA（1024x768）で公開するならばその長辺はその3〜4倍（つまり3000〜4000ドット程度）に
するとベターにょ。
公開サイズより大きいキャンバスで描くことで公開したものがキレイになるにょ。
他人の絵を見て「こんなに細部までキレイに描けない」と思っている場合もそれは縮小に
よって細部の塗り漏らしなどのアラが見えなくなっているというのも1つの理由になって
いるにょ。（1ドット単位で神経質になる必要はないためそれを別の作業に充てることが
できるようになるというメリットがある）
PCのスペックに余裕が無ければ公開サイズと同一サイズでもいいし、色数に制限を行った
絵を描く（16色とか256色）ならば自動的にアンチエイリアスがかかるのを避けるため公開
サイズと同一サイズで描くのがベターにょ。


お絵かきをするならば必要不可欠なのが技術的な情報にょ。
目の前にあるものを描く鉛筆デッサンならば美術の時間で習うし特に問題となることはない
けど萌え絵などのデフォルメ絵を描く場合には現物が目の前（3次元）にはないためにどう
やって描くのか知らないと描けないからね。（模写は除く）
そういう時に便利なのが昔だったら各種のガイドブックにょ。
私は86年にお絵かきを本格的に始めたけどそういうガイドブックの類は一切読まず完全に
独学・・・というか我流で描いていたにょ。
実際にそういうのを見始めたのは90年代になってからにょ。
それまではアタリの取り方も知らなかったくらいにょ。
ちなみに手元にあるガイドブックやお絵かき用の資料はこんな感じにょ。（これでも所有
しているものの一部）
http://twitpic.com/akvvn4

昔だったらそういう紙のガイドブックは非常に有意義だったけど今はネット上にたくさんの
講座があるためそれを見ていけば基本的なことはマスターすることができるにょ。
pixivならば「講座」で検索すればいいし、pixiv外の情報でもGoogleで検索すればすぐに
情報が見つかるからね。
というわけで、「ここから先は適当に検索して頑張ってね！」で終わろうと思ったけどここ
まで書いてきてそれではやや無責任なので初歩的な萌え絵の描き方講座を作ってみたにょ。
http://ww5.tiki.ne.jp/~ochame/CG/lecture/moee_lecture.jpg
（即興で作ったので線がよれよれで自分でもあまりいい絵とは言えないレベルだし、サーバの
容量を節約するためJPEG圧縮率を高めているため最後の完成品はブロックノイズが入り
まくっているのはご容赦願いたい）

これは、17年前に私の自作本で書いた初心者講座のリメイクみたいな感じだけど今回は線画の
アタリの取り方を重視した内容になっているにょ。
単に描けるようにするためには自分が好きな絵を模写するのが一番だけどそれではすぐに
限界が訪れてしまうにょ。
模写をすればそれなりに上手く描けるけどいざ何も見ずに描こうとすれば全く描けないという
状況になるか模写で描いた顔と同じものしか描けないという状況になるからね。
模写をする場合にちゃんと人物を立体で捉えてそれをどのようにデフォルメしてこういう絵に
なったのかをちゃんと考えながら模写をしていけば異なるアングルだろうと問題なく描けるの
だけどそのためには多少ハードルが上がっても最初の段階で立体で考えるということは
長い目でみると非常に重要となってくるにょ。
正面と横向きの2枚の絵から斜めから見た状態が描けるようになるとベターにょ。

ただし、初心者にいきなり「頭部を立体でイメージしろ」というのはあまりにハードルが高い
（というか私自身が十分にできていない）ため簡略化した立体でイメージするのがいいのでは
ないかということでこのような内容（直方体＋三角柱でイメージ）になっているにょ。
もちろん、これも簡略化したとはいえ決して簡単ではなく「立方体があらゆるアングルで
描ける」ということが求められてくるためそういう練習も行う必要があるにょ。（これを
突き詰めていけばパースがきちんと付いた人物画も描けるようになる）
「模写で見たものを見たように描く」という作業だけでは模写の技術は上達しても絵の技術の
上達はないため「萌え絵を自由に描けるようになりたい」という人は「立体を描く練習」と
「デフォルメの練習」（ここでのデフォルメとは目、鼻、口などがリアルとどのように
異なっているのかとううこと）が必要になってくるにょ。（ペンタブに慣れるまでは毎日
円と直線の練習から始めるといいかもしれない）
まぁ、お絵かき歴27年・・・と長いだけでスキルが備わっていない私がいくら言ってもあまり
説得力はないけどね（笑）



《　4月23日　追記　》

目の描き方について少し補足しておくにょ。
斜め向きの顔を描く場合には奥の目は手前の目と比べて縦はあまり変わらず横が細くなった
感じということを描いているけどそれならば手前の目を左右反転して自由変形によって
細く変形すればいいかのように見えてしまうにょ。
しかし、実際は顔や目は曲面で構成されているため単純に細くした場合にはかなり不自然な
ものになってしまうにょ。
この例のように（閲覧者から見て）斜め左に顔を向けて視線は閲覧者（以下、「カメラ」と
する）の方にあるという場合は虹彩（いわゆる黒目）の位置は横向きに近くなるにつれて
カメラ側へとずれてくるわけだし、瞳孔（黒目の中のさらに黒くなった部分）の位置や目の
輪郭部分の形も目が立体であるため横向きに近い斜めになるにつれて正面向きとは異なる
形になっているにょ。（単に細くなるだけではない）
別に難しく考える必要はなくいろいろな角度から見た形を覚えていけばいいと思うにょ。

では、目の縦の長さについて書いておくと単純に考えるとパース（遠近感）によって奥の方は
視点から遠いため小さく見えるけれどこれは普通に書いた場合には無視できるレベルの差
でしかないにょ。
実際に計算すると右目と左目との間隔が7cmの人の場合は斜め45度を向いて手前の目がカメラの
正面にある場合には左右の目の距離差は約5cmとなるにょ。
カメラから手前の目までの距離を200cmとすれば奥の目までは205cmとなり奥の目の方が遠く
なる比率の分だけ小さくなるにょ。
つまり、この場合だと奥の目の高さは手前よりも2.5％短くなるにょ。
これを絵で記した場合にはほぼ無視できるレベルとなるというわけにょ。（正確にいえば
「無視できる」ではなくあまり神経質に長さを考える必要はないといった感じか）

もしも、奥の目の縦の長さ手前の目の0.8倍になっているという絵を描く場合には逆算すると
カメラからの距離は手前の目まで20cm、奥の目まで25cmとなるにょ。
これは概ねモデルの肩の上にカメラを載せて超広角レンズで接写をしたような感じにょ。
実際に超広角レンズで接写撮影をすれば分かるけどそこまで目の大きさが変わるようなレベル
だと顔全体の形もパースによって変形してしまうにょ。
当然肩の上あたりにカメラを載せたら全身は映らないけどこれを映すならば魚眼レンズを使う
という方法があるにょ。
つまり、奥の目と手前の目の縦の長さを明確に変えるということは魚眼レンズ風の描写を
しない限りはありえないということにょ。

とはいえ、「正しいパースが良い絵」と言い切れないのも事実にょ。
「サンライズ立ち」「勇者パース」と呼ばれている絵のように意図的にパースが正しくない
絵にしているものは存在するからね。
しかし、それはそう描くことでカッコよさを引き立てる（剣を強調するという一種の
デフォルメ表現）であるためにょ。
目の縦の長さを変えることに何らかの意図があるというので無ければ上記のようにパース
的に考えても絵的に考えてもメリットは何もないにょ。

しかし、パースについてあまり深く追求するのは初心者には厳しすぎるし、この初心者向けの
解説では不要と感じたので「縦の長さはあまり変わらない」という程度の注釈で止めて
いるわけにょ。
あと今回は線画（顔のパーツ配置）を重視しているため塗りなどはかなり省略しているけど
これは機会があれば書いていこうかと考えているにょ。
あと顔以外についても気が向いたら書くかもしれないにょ。
立体的に考えるということで直方体と三角柱の組み合わせのイメージを行うということを
書いているけどこれが重要になるのは首から下の部分を描く場合だしね。
頭部と首の付け根の位置や首の長さはカメラからの角度によって変化してくるけどこれは
単純かしたとはいえこのように立体で考えることで簡単に理解できるようになるにょ。
難しいものは簡単なもので置き換えていけばどんな身体の向きであっても描くことができる
ようになるため全身の簡略化表現は身体を描く際には有用になってくるにょ。
そのための初期段階の導入として頭部の簡略化表現を描いたというだけにょ。
というわけで、今回の内容だけだと簡略化された直線的な立体で置き換えてイメージする
というのはあまり意味がないにょ。（むしろ、3番目のアタリを入れるときには曲面を
イメージして入れる必要があるため場合によってはマイナスになりかねない）


《　4月24日　追記　》

スポーツの場合は20歳付近をピークに運動神経や体力が落ちていくため少しずつ練習をしても
プロ級と呼ばれるレベルに達することは普通の人にはなかなかできないにょ。
しかし、絵はスポーツとは異なり、体力の心配はないにょ。
週刊連載を抱えているようなマンガ家ならば1日に10数時間描いたり2、3日徹夜をすることが
あったりなど身体にすごい負担がかかる場合があるため体力的な問題が全くないとは
言えないけど普通に趣味でできる範囲内で描いている場合にはそのような心配は不要にょ。
したがって、描いていけばその分が着実に経験値として蓄積されていくにょ。
たしかに時々描いて長期間描かなかったりというムラがあるとなかなか伸びにくいのも
事実にょ。
これは、絵を描くというのが体力的な負担が少なくても感覚的なものが必要であるため
それを取り戻すのに時間がかかるためにょ。
もちろん、過去に出来ていたことならばすぐに再びできるようになるし、変なクセがついて
いた場合にはそのクセが抜けるという場合もあるため長期間描かないということがマイナスに
なるとは言えないにょ。（単に上達が遅くなるだけ）

30代、40代から絵を描き始めようとするならば、一番の問題は続ける意志をどこまで持続
できるかということにょ。
これが10代ならば成長の度合いが早いのだけど30代、40代になると10代の頃よりは確実に
上達が遅くなってしまいがちにょ。
これは「上達をしない」というわけではなくあくまで上達に時間がかかるというだけなので
練習を積み重ねていけば確実に伸びていくにょ。
しかし、現実的にはこれが一番厄介な問題となるにょ。

これは、30代、40代になって始めようとする人は「昔描いていたけどあまり上手くないから
やめてしまった」とか「興味はあるけど絵心がない（美術の成績が悪かった）から手を
出さずにいた」とかいう人だろうから「できないかもしれない」という考えがどうしても
先行してしまいがちになるためにょ。
ただでさえ、絵は積み重ねで少しずつ上達していくものであるため最低でも数ヶ月単位、
できれば年単位のスパンで見なければ目に見える上達は得られないのに30代、40代にも
なって「できないかもしれない」ということにそこまで長期間の間本当に夢中になって
練習を続けるということが非常に難しいからにょ。
ある程度、描けるようになれば絵を描くということが楽しくなってくるのだけど時々絵の
練習をする程度だと数ヶ月での進歩は微々たるものなので多くの人が上達をあきらめて
やめてしまうと思われるにょ。
したがって、その最初の段階を乗り越えられるか否かが一番重要になってくるにょ。
やっぱり、描いていてつまらなかったら長続きしないから「描いていて楽しい」と思えること
こそが最も重要になってくるにょ。（楽しくなったら今度は上達するために自己満足をせず
目標を持って練習をするということが必要になってくるけどまずは「楽しい」と思えるか
どうかがすべて）

1538：マリモーマ：2013/04/23(火) 11:11:12
(無題)
アスキー・メディアワークス 「アスキーPC」休刊へ
http://www.fx-it.com/blog/2013/04/_pc_6.html

これも時代の流れなのかな？


【悲報】「コミックメガストア」休刊！警察の強制捜査の詳細判明
http://newnews2ch.com/archives/1718777.html

http://liv0.com

1539：天郷思音：2013/04/23(火) 20:25:19
レス：マリモーマ
アスキー.PC休刊かぁ。
学校に某年（忘れた）3月号が置いてあって、自作パソコンの作り方とかよかったんだけどなぁ。
いつか買ってみたいと思って忘れてた…

1540：御茶目菜子：2013/04/23(火) 23:15:54
レスにょ
マリモーマさんへ
＞アスキー・メディアワークス 「アスキーPC」休刊へ

雑誌などの出版物は年々部数が減少している上にPC関連雑誌はネットの普及によって情報
入手のために購入するメリットも無くなったからね。
私もかつてはPC関連雑誌を月に5〜6冊は買っていたけど今はほぼ0冊にょ。（特集や付録で
気に入ったものがある号を買う程度）


天郷思音さんへ

私はアスキーPCそのものには何も思い入れはないけど毎月（もしくはそれに近いレベル）で
購入していたコンピュータ関連雑誌は過去に「プログラムポシェット」「Pio」「PJ」
「Oh！PC」「ベーマガ」と休刊を経験しているだけに辛いものがあるにょ。

1541：マリモーマ：2013/04/26(金) 23:29:14
牢屋に　ロリだけの国を作ろうぜ
もはや単純所持禁止は避けられない──新たな児ポ法改正議論の最新事情
http://news.nicovideo.jp/watch/nw595435?marquee


「限りなくリアルな児ポも製造可能？」
CGの技術革新で懸念される児ポ法の新たな問題点
http://www.cyzo.com/2012/05/post_10600.html


「漫画・アニメのせいで子どもが犯される」「文章も禁止」
過激発言満載の児ポ法規制推進派院内集会
http://www.cyzo.com/2012/02/post_9890.html


取材拒否！　日本ユニセフ協会「児ポ法早期改正を求める署名」
に賛同する連合の不見識
http://www.cyzo.com/2010/11/post_5845.html


ここまでされたら　逮捕者だらけだな

http://liv0.com

1542：御茶目菜子：2013/04/27(土) 01:51:12
レスにょ
マリモーマさんへ
＞もはや単純所持禁止は避けられない──新たな児ポ法改正議論の最新事情

実際に被害者がいるそういったものを配布、販売する行為に関してはどんどん取り締まって
いいのだけどここで問題なのは単純所持禁止と現在の児ポ法条文の恐ろしさにょ。
単純所持禁止となると扱いは麻薬と同レベルにょ。
しかも、条文では「十八歳に満たない者」「衣服の全部又は一部を着けない児童の姿態」と
なっているからね。
つまり、18歳未満の子供の下着や露出度の多い水着姿の写真であれば自分の息子（娘）で
あっても自分自身の18歳未満の時の写真であっても「児童ポルノ」に該当してしまうことに
なるにょ。（性行為等が含まれて無くても「性欲を興奮させ又は刺激するもの」であれば
条件を満たす可能性が十分にある）

あと、厄介なのは二次元（非実在青少年）を児童ポルノとして見なそうとしていることにょ。
そうなってしまえばアニメ、マンガ、ゲームの上記該当のものがすべて児童ポルノになると
いう非常に厄介なものにょ。
ただでさえ、日本の児ポ法が欧米の法律と比べて非常に広範囲のものが条文に含まれている
けれど二次元にまで児ポ法が含まれる事態になれば世界最先端となっている日本の文化の
消滅の危機も免れないにょ。（「マンガは子供が読むもの」ではないことこそが日本が
そこまで幅広い層に受け入れられる要因となったのは紛れもない事実）

それに加えて児ポ法ができた経緯を考えても条文を見ても被害者を守るための法律であり
被害の居ない二次元（非実在青少年）まで児童ポルノ扱いするのはどう考えてもおかしい
としか言えないにょ。
そこで良く出されるのが「犯罪を助長している」というものだけどこれと犯罪との因果
関係は全くないにょ。
それに影響されて犯罪を行うという者がいるとすればサスペンスドラマを見て殺人が起きる
からそれを規制すべきというのと同レベルにょ。
それよりも犯罪行為の助長はマスコミにょ。
過去に多くの犯罪がマスコミの報道によって模倣犯が出てきたにょ。
先日のテロの圧力鍋による爆弾の作り方もわざわざ報道する必要はないのに流すことで
本来ならば知らなかった人まで知ることになりこれは「犯罪幇助」と言っても過言では
ないにょ。
寝た子を起こすようなことをして犯罪が増えたなんて結論を出して自分たちに都合が悪い
ものだけを否定するダブルスタンダードでは馬鹿馬鹿しくて話にならないにょ。

1543：御茶目菜子：2013/04/27(土) 23:58:56
お絵かき講座　PART2
さて、4月22日に「お絵かき講座」ということでお絵かきに必要な道具の紹介と簡単な萌え絵
の描き方（初歩的な顔の描き方）について描いたにょ。
http://6407.teacup.com/ochame/bbs/3781
その中で書いたのは萌え絵を自由自在に描けるようにするには「デフォルメの仕方」と
「立体で捉える」ということが必要だということにょ。
デフォルメについてはやはり1つずつ覚えていくしかないにょ。
目や鼻や口はリアルとは異なり萌え絵の場合はマンガやアニメなどのキャラを模写してどの
ようにデフォルメされているかというのを身体で覚えていくしかないにょ。
あまり多くの作品を参考にすると難しいため最初は「自分がこれ一番が好き」と思える
作家さんの作品を模写してそれでデフォルメの仕方を覚えていくのがベターにょ。（すでに
ある程度デッサン経験がある人ならば「あれもいい」「これもいい」というように画風の
異なる作家さんの作品を模写していってもいいけどそうではなくデッサン経験が乏しい人
だと1人の作家さんに絞った方が上達の速度は早くなる）
最初は模倣でも描いているうちに徐々に自分の画風（デフォルメの仕方）が確立するにょ。
「人まねではなく自分の絵を描きたい」と思っている人も最初のうちだけではこのように
参考にした方が結果として変なクセ（一般的に受け入れられないデフォルメの方法）が
つかず後々のためになるし上達も早くなるのでオススメにょ。（「萌え」というのは
人によって基準が異なるため間違ったデフォルメというのはほぼ無いのだけどそれでも
それを描いた人以外は萌えないような絵は「萌え絵」としては認知されないと思う）

すでにデフォルメされたキャラの模写はデフォルメの仕方を勉強するという初期段階の
労力を軽減させるのには有用だけどある程度描き慣れてきて自分のキャラが欲しいという
場合にはリアルデッサンができた方が有利になるにょ。
萌え絵を描く前の段階でリアルデッサンができている人ならばデフォルメの仕方というのも
パターン化があるためそのパターンを知るだけですぐに萌え絵が描けるようになるにょ。
それでも、手っ取り早く萌え絵を描けるようにするためには上記のようにパターンとして
できあがっているパーツの形を参考にしてそれを覚えていくのが有利だけどね。
デフォルメの仕方について簡単に書くと例えば萌え絵特有の大きな目だけどこれは人間の
目の形状（目を開いたときの上下のまぶたによって形成される形）を単純に六角形として
上まぶたを強調し、したまぶたを省略気味にすることでリアルの人間だとありえないような
大きな目を描くことが可能になっているにょ。（ただ、あまりリアル絵指向の人だと
デフォルメの仕方が分かっても身体が受け付けないかもしれないけど）
どのように強調（デフォルメ）するかは正解がないため今回は省略するけど機会があれば
そのデフォルメの仕方の一例を描いてみたいにょ。

デフォルメの仕方は適当なマンガやアニメのキャラを参考にするとしても難しいのは立体で
捉えるということにょ。
これはデッサンの経験を積まないとなかなかできないからね。（マンガ入門などの教本では
簡単なデッサンの方法を書いたのちにデフォルメの方法を書いている場合が多いけど私は
萌え絵を描きたい人はキャラを描きたいわけであって必要性を感じないうちからデッサンの
話をしてもハードルを上げるだけだと思っているためデッサンは必要に応じて少しずつ
勉強した方がお絵かきを趣味として「楽しく」「長期間に渡って」続けるためには有用
だと思う）
目は模写（他者が描いたキャラの模倣）でなんとかなるけど立体で捉えられないと模写を
行ったものと同じ角度、向きの顔しか描くことができないにょ。（かといって、リアル
デッサンの経験を積み重ねて自由なアングルでリアルな顔が描けるようになった後に
デフォルメの方法を学んでそれで萌え絵を描けるようにするなんてとてもハードルが高く
なりすぎて「ちょっとやってみたい」という人が手を出せるようなものではなくなる）
上下左右360度すべての模写を行えば問題は克服されるけどそれには膨大な時間がかかるし
塗る場合には立体として捉えられないと陰影も付けることができないため最小限の苦労で
済ませるためにはあまり良い方法とはいえないにょ。（そもそもあらかじめ3Dでモデリング
されたデータを閲覧するのでなければ360度自由な方向から見ることはできないわけだし）

しかし、デッサン経験を積み重ねなくても難しい形は簡単な形に置き換えることで容易に
なるにょ。
そこで私が考案したのが頭部を直方体と三角柱で置き換えるという前回書いた方法にょ。
一般的には丸を描いてそれに十字線を入れていくという方法がポピュラーになっているけど
これは顔がどちらを向いているのか分かりにくいということと球体や楕円体で頭部を表現
してしまうと首と頭部の接合部分が上手く描けないという問題があるにょ。（つまり、
これは人体デッサンの経験がない人にオススメの方法とは言い難い）
そして、十字線のアタリを入れるという段階で入れ方を間違ってしまうというのが全くの
未経験者だと起きてしまうためその十字線のアタリを入れる一歩手前の導入段階として
このような簡単な立体での置き換えをしているというわけにょ。（前回の補則参照）

このような簡単な立体に置き換えることで正面から見たら長方形になるため十字線を
入れるのは非常に簡単になるにょ。
そして、斜めからの見た顔やフカン（見下ろし）やアオリ（見下げ）などで描く場合にも
球体だとアタリを入れるのは難しいけどこの簡単な立体ならばアタリは簡単に入れる
ことができるにょ。
アタリは縦横が直交するように入れないと顔が変形してしまうことになるけど頭部は曲面で
構成されているためこの「（正面から見た場合に）直交するアタリ線を斜め向きの顔に
入れるのは慣れないとなかなか難しいからね。
真円ならば地球儀の経線が斜め向きではどのようになっているかを想像してその角度に
応じたアタリを入れることができるけど楕円の場合はこれが非常に難しいにょ。
そして、円や楕円にアタリを入れた場合にはあごがどのような状態になっているのかが
分からないということにょ。

とはいえ、ある程度描き慣れてくるとパーツを配置する正しい場所が感覚的に分かるように
なるためアタリは顔の向きが分かればいいのでそれほど正確さに拘らなくてもいいにょ。
しかし、初心者の場合はアタリが無かったら適切な場所にパーツを置いていくということが
できず、しかも例えば目の場合は顔が向いている方向やアオリかフカンかで形も変化して
いくし、他のパーツもそうなるため適切な場所がどこかを知ることは非常に重要にょ。
萌えキャラにおいては個人的には顔が8割と思っているので顔が非常に重要にょ。
そして、とりわけ重要なのがパーツを置く位置にょ。
これが初心者が萌えキャラを描く場合の最初の難関ではないかと思われるにょ。
普通に行われている「丸に十字を入れる」というアタリはある程度分かっている人が使う
分にはいいのだけどどこにどんな角度でパーツを置いたらいいのかわからないような
初心者が使うには適しているとは言いづらく形だけのアタリ（アタリをとっているような
気分になっている）となってしまう場合があるにょ。

本来であればアタリはどの位置に置いたらいいのかというガイドの役割となっているにょ。
アタリを取れば「正確な位置」だけは分かるにょ。（というか、アタリを基準に描いて
いくわけだからそれがずれていたらすべてがずれる）
あとは、その位置に応じた適切な形やサイズでパーツを描くことができるかという問題が
あるけどこれは正面向きと横向きが正確に描ければ問題なく描くことが可能にょ。
斜めからだと脳内補正が加わって上手く描けたかどうかが分かりにくいけど真っ正面の
顔を描いて左右で大きくパーツや輪郭が異なっていると簡単に分かるにょ。
正面ならば片方だけ描いて左右反転して結合という方法もあるけど人間の顔というものは
左右で微妙に異なっている（髪型においては左右同じということはほぼあり得ない）から
左右全く同じというのも逆に違和感を感じてしまう可能性があるし、反転によってしか
描けないのであれば正面以外の顔を描くことができないにょ。
斜めから描いた絵の脳内補正を少しでも緩和させる方法としてはソフト側の左右反転の
機能を使うというものがあるにょ。（SAIならばワンクリックで一時的に反転ができる）
正面から描けるようになったらそれをアタリに沿ってずらしたりパーツを変形させる
ことで斜めからの顔を正しく描くことができるようになるにょ。（ただこの正確アタリ
線にそって目の形を変形させるというのはデフォルメされたキャラのみに有効な方法で
リアル絵だと目が縦方向に小さいため変形しすぎることになる）
そして、横からの顔が描ければあごや首の付き方も分かるようになるにょ。

萌えキャラといえば目が重要にょ。
正面向きの場合は左右の目の間はある程度目が大きいキャラならば「目の横幅1つ分」
くらいの間隔を開けるのが基本だけどこれも目のサイズ（横幅）が小さいキャラだと
それよりも広くした方がいいにょ。（この場合の目の幅というのはまぶたの横幅を示す
ためまぶたを省略し、黒目（光彩）のみを描くデフォルメキャラの場合には通用しない
けど萌え絵の場合は大きな上まぶたを描くのが普通なので問題ない）
とはいえ、どのくらいのサイズならば「目の大きさが小さい」と言えるのかが分からない
場合には感覚的な部分に頼らなくてはならないにょ。
そのため「目の間隔をどのくらいにするか」ではなく目の位置を顔のどこにするのかを
完全に固定化することで単純化をしてみたにょ。
目の位置は顔を横に4等分した際には左右それぞれの目の横幅の中心点がそれぞれ顔の
4等分の位置くらい（前回でアタリを取った際に目の位置のガイドラインを引いた程度の
位置）になるようにすれば大体一般的な萌えキャラの配置なると思われるにょ。（目が顔の
横幅の3分の1と大きなキャラで左右の目の間隔が「目1つ分」にななりそれよりも目が
小さいキャラだと「目1つ分より少し広め」となるため感覚的に分からない最初の段階には
良いかもしれない）

とはいえ、萌え絵の場合はデフォルメの仕方によって変わってくるため本来であれば正しい
比率といった正解となるものはないにょ。（これがリアル絵と比べて難しい面でもある）
それに一般的に受け入れられる萌えキャラも時代とともに変わってくるためベストな比率を
数値化というのはあまり意味がないからね。（平均化するとデフォルメの仕方が均一化
されてしまい萌えキャラの特徴が失われたモブキャラ化してしまう模様）
したがって、この顔を横に4分割してその場所に目の中心点を置くという方法は初期段階に
おいては有用だけどこれのみにとらわれず自分が「萌え」と感じる比率を確立してその場所に
配置できるようにできるようになった方が良いと思うにょ。（置く場所の比率は数値で表す
よりも目、口、鼻をばらしてのっぺらぼうの状態にした顔に配置するような練習が良いかも
しれない）

そういうわけで上記のものを図示したのがこれにょ。
http://ww5.tiki.ne.jp/~ochame/CG/lecture/moee_02.jpg
前回はアタリの入れ方を重視してそれを元に首から上の頭部ができるまでを再現していった
けれど今回はアタリを元に胴体との接合を行ってみたにょ。
これでバストアップ程度は描けるようになるのではないかと思うにょ。
この講座は自分が正しく理解しているかを確認するために作ったものなので上級者からすれば
低レベルに感じるかもしれないけどその辺はご容赦にょ（間違っている部分があるならば
遠慮無く指摘して欲しい）

1544：ももた：2013/04/29(月) 19:15:00
特定の32bit値を持てる？
こんにちは、いつも大変参考にさせていただいております。
どちらの掲示板に書けば適切か分かりませんでしたが こちらで失礼します。
プチコンmkIIの数値型変数は、符号1+整数19+小数12ビット=計32ビットですが、
この32ビット全体を続けて書いた時の表現として、
&H7FFFFFFFという値を数値型の変数に持つことは、
どんな手段方法を使っても全く不可能なのでしょうか。
なんとかする方法は、どうしてもありませんか。

1545：マリモーマ：2013/04/29(月) 22:32:51
やっぱり小学生は　中出しだぜ
【悲報】児童ポルノ禁止法でエロゲの学園モノ規制へ＼(^o^)／
http://newnews2ch.com/archives/1720089.html

ついに規制が始まるのか？
「ロリとぼくらの。」を　持ってたら　やばそうだな

http://liv0.com

1546：御茶目菜子：2013/04/29(月) 23:49:49
レスにょ
ももたさんへ
＞こんにちは、いつも大変参考にさせていただいております。
＞どちらの掲示板に書けば適切か分かりませんでしたが こちらで失礼します。

どちらでもいいけれど流れの速いこちらの掲示板だとせっかく有益な質問をされても流れて
しまいあとから閲覧する人の参考になりにくいため質問掲示板の方がベターにょ。（ただし
あちらは私が毎日見ているわけではないので即日回答はできない場合が多い）

＞プチコンmkIIの数値型変数は、符号1+整数19+小数12ビット=計32ビットですが、
＞この32ビット全体を続けて書いた時の表現として、
＞&H7FFFFFFFという値を数値型の変数に持つことは、
＞どんな手段方法を使っても全く不可能なのでしょうか。

擬似的に32bit整数を扱う方法ならば32bit整数演算変換ルーチンで可能になるにょ。（型
そのものを変えることができないため異なる型の数値を入れることは擬似的に行う以外は無理）
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/routine.htm#int
&H7FFFFFF（＝2147483647）を表現するためには4096で割ったものであればいいにょ。
したがって、524287.9999とかにすればいいにょ。
正確には524287.999755〜524287.999994の範囲内の数ならばどれでも良いにょ。
ただし、逆変換ルーチンの場合は途中で入る丸め処理の関係で2147483646までの値しか扱う
ことができないにょ。

32bit全体を使うということでもしかして&HFFFFFFFFまでの符号無し32bit整数を扱いたい
というのであれば&H80000000以上の時は負数として記録すれば可能にょ。
&H80010000を表現するならば&H80000000を引いて&H10000としてそれを4096で割った後に16に
マイナスを付けて「-16」と表記すればいいにょ。
しかし、演算の際には負数か正数かを判断して上位1bitと下位31bitを別々に演算する必要が
あり、これは多倍長演算のような処理を行わなくてはならないにょ。
したがって、上記のルーチンでは32bit符号付き整数に限定しているにょ。
こうすることで単純に変換が可能であるため速度面、リストの短さ、演算の汎用性に優れた
ものになっているにょ。（プチコンの固定小数点は32bit整数と比べて小数点の位置が12bit分
ずれているだけのものだからこそ4096を掛けたり割ったりするだけで普通に四則演算が可能に
なっている）



マリモーマさんへ
＞【悲報】児童ポルノ禁止法でエロゲの学園モノ規制へ＼(^o^)／

何で、被害者の居ない2次元（非実在青少年）を規制するのやら・・・。
ただでさえ、99年に児ポ法が施行されたため18歳未満と推測されるような内容は自主規制に
よって行われなくなったにょ。（「○×高校」は不可なので「○×学園」となった）
そして、「登場人物はすべて18歳以上」という警告も成されるようになったにょ。
その5年後にはさらに自主規制が強まり、「5頭身規制」が始まったにょ。
それによって5頭身以下の見た目が幼い絵やデフォルメ絵の大きな絵の表現ができにくく
なったにょ。（5.1頭身以上ならばOKというのもアレだけど基準が明確であるため業界も
それほどの混乱はなくすぐに対応ができた）
というわけで、ソフ倫も業界を守るために自主規制をどんどん強化しているのにこれから
さらに強まって「見た目」が18歳未満が禁止となるのは非常に厄介にょ。
ただでさえ、2次元の非実在青少年の人権を守るなんてワケのわからないことを言っている
のに見た目で規制するのは完全に自己矛盾しているにょ。（現実世界で見た目が成人に
見えないからということで差別をするのと同じこと）

それに犯罪抑止効果なんてこれによって期待できるはずもないにょ。
そもそもその因果関係も現時点では「ほぼない（確認されていない）」といってもいいにょ。
それを所持している人が犯罪を犯せばその影響と判断されているだけでありそれは極論から
言えば犯罪者の99％はパンを食べているから「パンは危険な食べ物」というのと何ら変わら
ないにょ。
こういうことを言うと空想と現実の区別ができない人がいるためであり、パンの例とは
異なるという人もいるかもしれないけど「ゲームやアニメの影響で犯罪を犯す」と考えて
いる人こそが最も空想と現実の区別ができていないにょ。（良識ある人なら区別は付く）
本当に区別ができない人ならばすべての表現を規制しなければ意味がないにょ。
先日も書いたように創作物よりも実際に行われた事件の犯罪の具体的な内容を伝える報道の
方が犯罪への影響が大きくて誰が見てもフィクションと感じるものにおいては一般的な
影響はほとんどないと思われるにょ。

既存の児ポ法に合わせて規制しようとするから無理があるわけで「表現規制法」でも作り
現実世界と同様に空想上の人物に人権を与えて規制を行うのがベターといえるにょ。
もっとも、それによってどのような世界になるのかは小説からアニメ、映画化された
「図書館戦争」を見れば容易に分かるにょ。
そこまでやったら「完全に行きすぎ」と多くの人が感じるだろうから恐らくそういう事態には
ならないだろうけど世界的に見て「児童ポルノ」というものは規制されているにょ。
（もっとも、日本での定義が海外よりも大幅に厳しく曖昧なものであるため同じように規制
するのは無意味だけど）
「児童ポルノ＝悪」というという価値観によってそれと一見関係ありそうな2次元の創作物を
規制するというのは賛同者が得られる可能性が高いものの上記のように全くの別物である
ためそれを法的に規制するというのは根本において間違っていると言わざるを得ないにょ。
これは何を表現してもいいというのではなく実写と間違えるくらいリアルで過度な無修正
画像に関してはわいせつ物として検挙が可能（これも日本特有なものでありグローバル
スタンダードを謳うならばこれはおかしい）なので内容に関しては被害者がいるかどうかで
判断するしかないためにょ。（当然ながらフィクション作品には被害者はいない）

1547：御茶目菜子：2013/04/30(火) 20:37:48
第2回プチコン大喜利　投稿受付終了
先日から募集していた第2回プチコン大喜利の投稿が本日で受付を終了したにょ。
http://smileboom.com/special/ptcm2/co_contest/index.php
さて、私は前回の大喜利ではPETIT RUN mkIIで技術賞に入賞できたので今回も再び入賞を
狙っていたもののいいアイデアがなく私が積み重ねてきた技術を活かせるレースゲームを
作ろうと思っていたにょ。
自機はポリゴンを使用しゲーム画面はGRPの2軸回転によってゲーム内でリアルタイムに自由な
視点に変更可能なレースゲームにょ。
とはいえ「作ろうと思った」だけで事前に作ったものといえばゲーム内で使用する自機の
ポリゴンデータのみにょ。
しかし、実際には肝心のポリゴンプログラムが処理の最適化などで予想よりも遙かに大変
だったということもあり、2週間前にようやくポリゴン表示プログラムが完成したにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/polygon.htm

ここで、すぐに開発に取りかかっていれば良かったのだけど全力を注いでいたポリゴン表示
プログラムが無事公開でき脱力したためプチコンプログラムに取りかかる意欲がわかなく
なってしまったにょ。
これが気合いが入っている時ならば「一晩でとりあえず動く物を作ってみました」とかなるの
だけど気合いが入らないためこういうときは無駄に時間を費やすことになるにょ。
そこで良くやるのが全く関係ないことをしてモチベーションの回復を図るというものにょ。
私はいくつか趣味があり、その中の1つであるお絵かきに集中することでプチコンプログラムの
モチベーションを回復させる方法を行ったにょ。
これは個人の趣味で作っているものだからこそ可能であり、趣味だからこそその時に一番
やりたいことをやるということにょ。
プチコンプログラムを作りたくなったらその時に作り始めればダラダラと作るよりも遙かに
効率がいいはず・・・と思っていたにょ。

ところが、大喜利の締め切りが目前に迫った昨日「いつ作るのか？」「今でしょ！」という
わけで半ば強引に開発を開始したにょ。
作り始めたのはいいけど私は複数のことに同時に全力を注げないシングルタスクな人間
なのでなかなか当初は思うように進まず、軌道に乗り始めたのは日付が変わって今日に
なってからにょ。
当然ながら気が付いた時にはタイムリミットとなっており、結局レースゲームの完成は
今回の大喜利には間に合わなかったにょ。
現状での完成度はこんな感じにょ。
http://twitpic.com/cn17g6

一応最低限の動作は可能であり、自機セレクト（このセレクト画面ではポリゴン表示
プログラムの機能を使いまくり、回転や拡大縮小が自由にできる）とコースデータの読み
込み（データ作成機能はないのであらかじめ作っておいたGRPデータのみ対応）、コース上を
走行する処理、タッチパネルによって自由に拡大縮小やカメラアングルを切り替える機能を
実装しているに止まっているにょ。
これが動画で公開するならば出来てない部分は隠蔽して動く部分だけを撮影することで
それなりに完成しているようなイメージを与えることができるのだけどプログラムの
ソースを公開するわけだからまだ実装できてない機能が山積みなのは明確に分かって
しまうにょ。
スタートはあるけどゴール判定がないため1分で何m走行できるかという距離チャンレンジに
すれば投稿は間に合ったけどテストプレイもろくにしておらず、バランス調整もぐちゃぐちゃ
ということを考えるととても投稿できるレベルとは言い難いにょ。

ここまで完成度が低いなら投稿しない方がマシということで最終手段として用意したのが
上記のポリゴン表示プログラムにょ。
これだとお題の「1分で十分エンジョイ」の「1分」が満たせないのでラスト1分で投稿用の
原稿を書いて投稿するということで半ば強引にお題を満たすことにしたにょ（笑）
これで参加賞は確保したにょ。
うまくいけば入賞は無理でも第1次選考は通過（前回は64作品中20作品が通過）するかも
しれないにょ。
1画面プログラムでいいものがあればそれを投稿するという方法もあったけど前回の大喜利
以降に作ったものはツールばかりだからね。
ゲームならば1画面でも結構楽しめるけど1画面のツールは1画面であるということで必要
最小限の機能しか有してないためかなり辛いにょ。（とてもだ1次選考を通過できるとは
思えない）
あと私は数だけはたくさん作っているけど1行プログラムとか各種ルーチンのようにあまりに
小規模のものだったり、単体では意味があまりないものだったりなので一番まともなものと
といえばポリゴン表示プログラムしかなかったというのが実際のところにょ。

というか、昨年の9月以降毎月1本以上のノルマで作ってきたプチコン1画面プログラムだけど
今月はまだ作ってないにょ。
まだ日付が変わってないため今から作って今日中に公開すればいいけれどそこまで強引に
作ったものだと公開に値するレベルにはならないため事実上無理にょ。（作りたいネタが
ありリスト短縮を特に行わなくても700バイトを下回る規模であれば30分あればできるけど）
まぁ今回未完成だったレースゲームはゆっくり作ってそのうち完成させるとするにょ。
次回の講座までには公開したいところだけどその講座があまりに書く内容が膨大になり
すぎてどんどん後回しになってきているにょ（笑）

1548：ももた：2013/04/30(火) 23:42:48
返答ありがとうございます。
＞質問掲示板の方がベター
「PC-E500のBASICを使っていて」と書かれていたので
プチコンの質問をしていいものか迷いました。

おそらく有益な返答をいただいていると思うのですが
当方の理解力が不足していると思います。大変失礼とは
思いますが、もう1度、少し表現を変えて書かせてください。

1つの数値型変数につき、32bitの情報を記録したいと思った時に、
たとえば「A=&H7FFFF」と「A=&HFFF/4096」は
それぞれ思ったとおりの動作をするようですが、
まとめて「A=&H7FFFF + &HFFF/4096」とすることができません。
それ以外の他の32bitの組み合わせは全て記録することが
できると思います。この組み合わせだけできないみたい...？
私の考えた限りの範囲では、良い答えは思いつかなかったので
何か違う方法はあるのだろうかと、質問させていただきました。
あの後、考えたことなんですが、たとえば、
小数を含む結果を返す関数に、答えがちょうど&H7FFFFFFFに
なるように引数を与えて、なんとか回避できたり...ないかな

1549：御茶目菜子：2013/05/01(水) 23:56:51
レスにょ
ももたさんへ
＞「PC-E500のBASICを使っていて」と書かれていたので
＞プチコンの質問をしていいものか迷いました。

これはプチコン関係で質問する人は少ないし、こちらの掲示板で質問をすることに関して
特に問題があるわけではないので注意部分を書き換えてなかったためにょ。
先日も書いたように質問や技術系の有益な情報は投稿数の少なく情報密度の高い質問掲示板の
方がベターという私の個人的な判断によるものにょ。
まぁサイト内検索をすればこのメイン掲示板も検索できるようになり、そこまで厳格に
行っているわけではないのでどちらでも構わないにょ。
http://ww5.tiki.ne.jp/~ochame/ochamewords.htm

＞1つの数値型変数につき、32bitの情報を記録したいと思った時に、
＞たとえば「A=&H7FFFF」と「A=&HFFF/4096」は
＞それぞれ思ったとおりの動作をするようですが、
＞まとめて「A=&H7FFFF + &HFFF/4096」とすることができません。

これはプチコンにおいては&H7FFFFFFFに相当する数を代入は可能だけど演算によってこの値に
なるとOverflowと判定されているためにょ。
したがって、私が作った32bit変換ルーチンは代入だけできればいいため&HFFFFFF相当の数を
扱うことができるけど逆変換ルーチンにおいてはこのプチコンの仕様の問題で&HFFFFFFE相当の
数までしか扱うことができないにょ。
正数においてはこのように&H7FFFFFE（＝2147483646）相当までとなっているけど負数に
おいては&H80000001（＝-2147483647）相当の数まで扱うことができるにょ。
符号付き32bit整数は通常&H80000000（＝-2147483648）〜&H7FFFFFF（＝2147483647）までの
範囲を扱うことができるのだけどプチコンでは&H80000000は「-0」を示し本来は想定されて
いない数なので正数、負数も演算範囲が1ずつ小さくなっていると推測されるにょ。

＞小数を含む結果を返す関数に、答えがちょうど&H7FFFFFFFに
＞なるように引数を与えて、なんとか回避できたり...ないかな

この方法を使えば本来は&H7FFFFFE相当の数までしか扱えない32bit整数逆変換ルーチンも
&H7FFFFFFFに相当する数を扱うことが可能になるにょ。
具体的にはサブルーチンの先頭行に次の1行を加えるだけでいいにょ。

IF INT$=="2147483647"THEN INT=524287.9999:RETURN

ただし、この逆変換ルーチンにおいてはリストを短縮するため負数は符号を取り除いて演算
している関係上、本来ならば演算可能範囲内である-2147483647も扱うことができないにょ。
そのため-2147483647かどうかの判定も別途必要となるにょ。
絶対値がちょうど2147483647になる値を使用する頻度は高くないと判断したため有効範囲が
1小さくなる現在の仕様となっているにょ。

1550：ももた：2013/05/02(木) 01:21:39
ありがとうございました
＞正数、負数も演算範囲が1ずつ小さくなっている
あー、なるほど。そういう考え方をすれば、一応は納得できる・・・のかな。。。？

＞＞小数を含む結果を返す関数に、
＞この方法を使えば
＞IF INT$=="2147483647"THEN INT=524287.9999:RETURN
いえいえ、プチコンのマニュアルで言う数学指数対数関数や数学三角関数の項目に
載っているような関数を利用することを言ったんです。オーバーフロー扱い
かどうかを判定する内部処理をすり抜けられるかな、って。

いずれにしても、&H7FFFFFFFは無理ってことですね。
必ず&H7FFFFや&HFFFにならないようにマスク(?)するXOR値なんてのは無いだろうし、
その値の時だけ例外として記録場所を変える処理とか、それはそれで変数領域の
無駄になりそうだし、元々31bit分だけを記録するように工夫するのが良いのかな。
・・・いや40億分の1のためだけに対してどうなんだろう。やっぱり例外扱いの方が
いいのかな。でも並びがわりかし規則的という点では、出現しがちな情報とも
言える・・・か？　うーん、悩ましいところだなあ・・・。

なんとか頑張って考えてみます。ありがとうございました。

特定の数値の時だけ、って、なんだか2000年問題を思い出しました。(笑)

1551：ss：2013/05/02(木) 12:28:42
iPhone5車載充電対応充電器
iPhone5車載充電対応充電器
充電ケーブルと家庭用コンセント対応できる充電アダプタ付き
安心に充電対応

http://www.witdeals.com/iphone5-chargers-adpters/p-5843.html

http://www.witdeals.com/

1552：天郷思音：2013/05/02(木) 17:06:34
(無題)
パソコンやってたらいきなり父が来たのでびっくりした。なんかCドライブがいっぱいなのでFドライブに緊急に音楽フォルダをお引越しです。
ハードディスクの合計サイズが約2TBあるのでいっぱいになることはないと思っていたらCドライブ78.1GBしかないのにそのうち32.9GBが音楽フォルダで占められていたという。
Cドライブの残り容量が10%以下で容量オーバーによるダウンの危険が高い状態だった。
ちなみにパソコンのハードディスクのサイズを合計したら2015.84GBだった。しかもこのパソコンには7つのハードディスクドライブがある。
ちなみに一番容量の多いハードディスクドライブはF:の908GBです。
http://f.hatena.ne.jp/ken10ken/20130502171116

1553：巡音ルカ：2013/05/02(木) 19:30:35
ピーチ姫!いい加減に、整形手術受けろ!!
ピーチ姫!いい加減に、整形手術受けろ!!

いつまで変な顔でいる気だ！

尖ったような口しやがって！

無駄に縦に細長い！

1554：ブラアン：2013/05/02(木) 20:14:58
ブラアンのプチコン
初めて書かせていただきます。
私はポケコンなどにはうといです。
プチコン中心でやってます。
ユーザー識別コードは「BS_」です。
これからよろしくお願いします。

1555：御茶目菜子：2013/05/03(金) 00:15:26
レスにょ
ももたさんへ
＞なんとか頑張って考えてみます。ありがとうございました。

プチコンは例外処理が甘い部分があるためそれを把握していないと場合によってはおかしな
挙動になってしまうにょ。（代入処理においては小数点以下が0.999995〜0.999999の場合に
それは切り捨て扱いでゼロになる）
まぁそういったものは滅多にないのだけどそれを含めてプチコンでのプログラムはいろいろと
奥が深いにょ。



天郷思音さんへ
＞なんかCドライブがいっぱいなのでFドライブに緊急に音楽フォルダをお引越しです。

私のPCもCドライブはギリギリしかないにょ。

＞ちなみにパソコンのハードディスクのサイズを合計したら2015.84GBだった。しかもこのパソコンには7つのハードディスクドライブがある。

7つの論理ドライブ（3つの物理ドライブ）とはすごく細かく分けているにょ。
たぶん旧環境でパーテーションを分けた状態のドライブをそのまま接続しているだけかも
しれないけどね。
私は普段使っているのがノートPCということもあって常時繋がっているドライブ数は多くは
ないのだけど手元にあるHDDの合計ならば10数TBあるにょ。
まぁ、録画用に年間2TBくらい消費しているから勝手に増えただけだけど・・・。



ブラアンさんへ
＞初めて書かせていただきます。

はじめましてにょ。

＞ユーザー識別コードは「BS_」です。

了解にょ。
リストに追加しておいたにょ。

1556：マリモーマ：2013/05/03(金) 14:45:16
重い
僕のハードディスクは　こうなってるよ
https://twitter.com/marimooma/status/330195811948457984/photo/1
容量は　十分あるはずだけど　動画を撮ると重いよ？
3テラバイトのハードディスクにした方がいいのか？

スペックは　こちらを参考に
http://com.nicovideo.jp/community/co47570

http://liv0.com

1557：ひき：2013/05/03(金) 16:38:46
iPhone4S/iPhone5用R- SIM8　Unlock SIMロック解除アダプタ
世界の先進的なクラシックR-SIM8がリリースされました！
別のキャリアのiPhoneにするたびに使用された場合、指導カードとキャリアを再選択する必要がありません。
R-SIM8は3Gネットワーク上で完璧に動作し、（普通は4S、iPhoneと5のため）より多くの互換性のスマートSTKプログラムを持って、操作インターフェースを更新しました。

【製品特徴】

★対応機種:：iPhone5/4S

★iPhone 5/4s iOS6.0.1-6.1.3で完璧運行！3G、4Gネットワークをサポート！

★スマートSTKの運行方式と界面更新、より多くの対応スマートSTKプログラス

★最新、最薄、最高安定性のチップセットNEC108を使う

★100%正規品、アンロックSIMカードのCEとRoHSの許可を得ている

★操作方法簡単!
http://www.gamezway.net/index.php?main_page=product_info&amp;cPath=38&amp;products_id=699

http://www.gamezway.net/index.php?main_page=product_info&amp;cPath=38&amp;products_id=699

1558：名無し：2013/05/03(金) 18:29:36
(無題)
おちゃめくらぶのサイトが軽くて助かるぜ

1559：天郷思音：2013/05/03(金) 23:19:53
レス；マリモーマさん
core i7いいなー
このパソコンはいまだにcore2系らしい

1560：御茶目菜子：2013/05/03(金) 23:57:33
レスにょ
マリモーマさんへ
＞容量は　十分あるはずだけど　動画を撮ると重いよ？

容量の問題はないと思うにょ。
構成を見る限りはWD20EARSに問題がありそうにょ。
このHDDはセクタサイズが4096バイトのAFTを採用しているため使用OSがWinXPならば性能を
十分に発揮することができないにょ。
もっともこれはWDからXP専用ドライバ「WD Align」が用意されているためそれを導入すれば
解決できると思われるにょ。
XPは12年前に作られた古いOSであるため近年の新しい機器にはもう対応できないにょ。
古い環境で動作させるのならばいいけど新しいものを使うならばWin7に乗り換えた方が無難
かもしれないにょ。（XPだと3TBのHDDは使うことができないし）



名無しさんへ
＞おちゃめくらぶのサイトが軽くて助かるぜ

喜んで頂いて何よりにょ。



天郷思音さんへ
＞core i7いいなー
＞このパソコンはいまだにcore2系らしい

私も自作PC、メインノートともにCore2Duoにょ。
モバイル用のサブノートはCore Soloという今となってはネットブックと大差ないレベルの
低スペックCPUにょ。
まぁB5より小さいサイズで1kg未満、11時間駆動というスペックは他に選択肢がないけどね。

1561：マリモーマ：2013/05/05(日) 10:11:40
パーテーション
WD Alignのダウンロードに苦労したけど　使ってみたよ
結果は　こうなった
https://twitter.com/marimooma/status/330851565353185282/photo/1
登録しないと落とせないのと
ダウンロードが　なかなかできないのが辛かった
動画を撮るのは　まだ重いみたいだよ

外付けHDDに保存したから　次から落とさなくてすむよ

http://liv0.com

1562：よくいらっしゃいました：2013/05/06(月) 11:06:20
ホームページ作成
ホームページ作成
有り難うございました。
たいへん当店に感謝します
以上　宜しくお願い致します。(＾０＾）
再度のあなたに感謝する根気良さと愛！!!
↓↓↓
◆★当社: http://www.pplclub.com/?jg
??????????http://www.pplclub.com/?ji
??????????http://www.pplclub.com/?jj

1563：マリモーマ：2013/05/06(月) 13:57:31
分解調査のクライムエッジ
neogeoの映像が乱れるから　本体を分解して原因を調べてみた
でも　中身は綺麗だった　ケーブルが悪いのか？
https://twitter.com/marimooma/status/331271071678488576/photo/1

ーーーーーーーーーーーーーーーーー
1000億円ぶち込んで京の100倍性能のスパコン開発ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
http://alfalfalfa.com/archives/6496849.html

作る意味があるのか分からないな　プライドの問題だけかも

http://liv0.com

1564：御茶目菜子：2013/05/07(火) 00:26:17
レスにょ
マリモーマさんへ
＞動画を撮るのは　まだ重いみたいだよ

もしかして、非圧縮ではなくリアルタイムエンコードを行っているにょ？
さすがにCore i7とはいえフルHDのリアルタイムエンコードはCPU性能の面で厳しそうにょ。
エンコの出力解像度を落としてみてはどうにょ？

＞neogeoの映像が乱れるから　本体を分解して原因を調べてみた

考えられる要因としてはケーブルの断線、ケーブルもしくはカートリッジコネクタ部分の
接触不良あたりにょ。
外見からでは分からないので実際に何をしたら乱れるのかによって問題点を切り分けていく
といいにょ。

＞作る意味があるのか分からないな　プライドの問題だけかも

プライドの問題もあるだろうけど日本が科学技術の分野で世界トップレベルを維持するため
には世界トップレベルのスパコンは必要不可欠にょ。
2020年ならば京の100倍という性能は必要な性能になるだろうしね。

1565：マリモーマ：2013/05/09(木) 14:08:26
水泳アニメの後は　中二病2期？
monsterx-iを　使ってるけど　設定は　こうなってるよ
https://twitter.com/marimooma/status/332359902611795968/photo/1
https://twitter.com/marimooma/status/332360007704268800/photo/1

エンコードは　どうなってるか分からないけど
いらないファイルを　外付けに移して
クッキーや一時ファイル等を　全部消して
クリーンマネージャーを使って　再起動して
ウイルスバスターを　全部　停止(一部タスクマネージャから停止)させたら
なんとかなるみたい
ゲームによっては　重くならないのもあるみたい

neo-geoのケーブルは　金があったら買って試してみるかも


ーーーーーーーーーーーーー
Microsoft、「Windows Blue」を今年後半に出荷
タッチスクリーンを持たない PC 利用者に配慮
http://japan.internet.com/allnet/20130508/3.html

http://liv0.com

1566：御茶目菜子：2013/05/10(金) 00:08:16
レスにょ
マリモーマさんへ
＞monsterx-iを　使ってるけど　設定は　こうなってるよ

その設定を見る範囲内では解像度指定が見あたらないにょ。（別の場所にあるのでは？）
解像度別の設定項目はあるけど肝心の解像度はどれを指定しているのかは分からないからね。
ビットレート指定があるので現在録画している解像度のビットレートを下げるだけでもかなり
CPU負荷は小さくなりそうにょ。

＞Microsoft、「Windows Blue」を今年後半に出荷
＞タッチスクリーンを持たない PC 利用者に配慮

むしろ、最初からそうすべきだったにょ。
すべてのPCにタッチパネルが搭載されているわけではないのにタッチ前提のUIを前面に
出していたらユーザーから「使い勝手が悪い」という反応があることは目に見えていたにょ。
改良というより、これでようやくまともに移行が進みそうにょ。

＞水泳アニメの後は　中二病2期？

時期的にはそんなものかもしれないにょ。
ということで、2期決定記念絵を描いてみたにょ。（30分程度で描いた落書きだけど）
http://twitpic.com/cp644n

1567：マリモーマ：2013/05/10(金) 14:16:24
もう販売終了品なのか
解像度指定は　たぶんないと思うよ
そういう細かい設定をするなら　別のキャプチャーソフトが必要かも
http://www.sknet-web.co.jp/product/mhvxi.html


ドカベンすら発禁になる可能性があるのか
http://buhisoku.blog28.fc2.com/blog-entry-5567.html

http://liv0.com

1568：御茶目菜子：2013/05/11(土) 01:08:45
レスにょ
マリモーマさんへ
＞そういう細かい設定をするなら　別のキャプチャーソフトが必要かも

ソースの解像度に合わせて自動的に出力解像度設定が行われるということはビットレート調整
くらいしかCPU負荷を下げる方法がないにょ。
あまりにCPU負荷が高いようならば非圧縮で取り込んで後からエンコという選択肢もあるにょ。

＞ドカベンすら発禁になる可能性があるのか

本来ならば実写のみに適用される児ポ法を二次元に適用するならば少年マンガレベルでさえ
多くの作品が発禁になる可能性があるからね。
実際はそうならない可能性も高いけどそれだけ広範囲に影響が出るというのはこの法律の
本来の目的（実際に被害を受ける児童を守る）とは全く異なるものであり、マイナス影響
しかないと言っても過言ではないにょ。（これによって救われる人はまず居ない）

1569：天郷思音：2013/05/11(土) 15:04:13
(無題)
パソコンをスタンバイ状態から復帰すると画面の位相が変なのはなぜだろう。

1570：ありふれた：2013/05/11(土) 19:27:04
公開してください。
Petitcom OSを、公開してください。

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