レス数が1スレッドの最大レス数(1000件)を超えています。残念ながら投稿することができません。
おちゃめくらぶ掲示板
-
現在大阪オフ中にょ
現在大阪オフにょ。
昼食を12時に済ませ現在3時のおやつ休憩にょ。
昼ご飯を食べてから現在までいろいろ買い物をしたけどもう3万円くらい使っているにょ。
めぼしいものは大体買えたけどそろそろ資金が尽きるにょ。
マリモーマさんへ
＞今日は 大阪オフだけど 関西は 雨が降ってたよ
さっきは結構降っていたにょ。
また詳しくは明日書くにょ。
-
レスにょ
orirakkusuさんへ
＞BGじゃなくGRPだお！
GRPだと自由度は高いけど処理が重くなりがちだし、GRPは全部で4面しかないのがネックにょ。
＞SSはTwitterで#windous ハッシュタグをつけてツイートしてます。
Windousなんてハッシュタグを付けているのは他にないので一発で見つかるにょ。
＞あと、日付と時刻を開いてる時にTALK+BGMPLAYを実行すると上画面のG面にノイズいっぱいイヤー！
それってただの処理落ちでは・・・？
GRPでの描画は重いけどTALKもめちゃくちゃ重いからね。
専用DSPでの再生ではなくCPUによる再生であるため処理に1フレーム以上に時間がかかっており
確実に処理落ちしてしまうにょ。
これがGRPの描画途中であれば表示のちらつきを生んでしまうにょ。
otyakenさんへ
＞OSもどきなら前作った事がある。
＞ー応ダイアログサイズのウインドウを重ねることが出来た。
OSもどきを作るのが流行ってるにょ！？
ということで、私も試しに作ってみたにょ。
まぁOSというのはほど遠いレベルだけど・・・（笑）
＞初代から開発しててmk2で実行したら割と速かった。
＞でも最初はWindowsもどきを作ろうとしていたら全然違うものになり、
＞面影はコントロールパネルのアイコンとコマンドプロンプトのアイコンだけ…
初代で作ってその速度ということはGRPだとあり得ないのでBG面でウインドウ表示をして
いるにょ？
-
プチコンでマルチタスクOSを作る
なんだかプチコンでOSもどきを作るのが流行っているみたいなので私も試しに作ってみたにょ。
名付けて「Petitcom OS」にょ。（また、ストレートなネーミング・・・）
http://ww5.tiki.ne.jp/~ochame/petitcom/image/Petitcom_OS.jpg
http://www.youtube.com/watch?v=_zzCVJQwKsY
（ちなみにこの動画ではアプリの起動、ウインドウのドラッグ、アプリの実行、アプリを
無敵モードにしてアプリ動作中のウインドウのドラッグの様子を記録している）
とりあえず、一晩で作ったということでまだ機能は最低限しかないにょ。
現時点でできることとはアプリケーションの起動（ただし、現在の対応アプリは横スクロール
ゲーム「CAVE」のみ）、終了、ウインドウのドラッグのみにょ。（通常版の「CAVE」は
プチコン講座の第7回のサンプルプログラムとして公開しているのでそれを参照）
ウインドウはGRPで描画されているので1ドット単位で自由に移動することができるにょ。
一応マルチタスクに対応しているためアプリ動作中でもウインドウを自由に動かすことは
可能になっているにょ。
現時点ではアプリが1つのみということでマルチウインドウには対応していないものの
重ね合った部分をバッファに入れておけばマルチウインドウに対応させるのは簡単にょ。
マルチタスクに対応させるためにはアプリ側の対応も必要になってくるにょ。
これがシングルタスクならばタスク終了スイッチさえ用意すれば簡単に実現できるけど
マルチタスク対応にするならばアプリ実行中に一定のタイミングでOS側に処理を移し、
そして再びそのアプリの続きの処理を実行するように作る必要があるにょ。（アプリの方で
OSに移す処理を忘れたらアプリでCPUが占有されるためWin9xでは頻繁に見られたフリーズ
状態になってしまう）
このPetitcom OSでは1/60秒単位でアプリとOSを切り替えているためアプリを3つ同時実行
させる場合には1つ平均180fpsで動作させる必要があるにょ。
それより遅い場合は処理落ちをしてしまうので、いくら高速なプチコンとはいえ現実的に
考えるとバックグラウンドに回ったアプリは自動停止させる方が無難かもしれないにょ。
自動停止したら困るアプリもあるから「デフォでは停止」にしてバックグラウンドに回った
時も動作し続けるアプリも作れるようにした方がいいかもしれないにょ。
《 3本のアプリをマルチタスク動作させる場合 》
アプリ→アプリ→アプリ→OS
↑--- この間が1/60秒 ---↑
ただ、問題となるのはmkIIでもGRPが4面しかないということにょ。
表示用、表示バッファ用、記録用で3面必要になるためウインドウの重ね合わせのバッファ
用にはGRPが1面しか余ってないにょ。
つまり、マルチウインドウに対応といってもウインドウは1つしか開けないことになるにょ。
もっとも1つのGRPが256x192なので128x96のウインドウならば4つまで確保できるものの
それを越えるサイズが1つでもあったらその時点で1つ分しかバッファが確保できなくなって
しまうためにょ。
記録用のGRPを諦めてウインドウのバッファ用に回せば2〜8つのウインドウを開くことが
できるものの保存するデータが大きくなるからMEM$ではかなり細切れ保存が必要になるし
唯一余っているSPUだけどこれも32バイト単位でしか読み書きできないため使い勝手を
考えると厳しいにょ。
このPetitcom OSで難点となるのはマルチタスク対応アプリを作るのが非常に難しいと
いう点にょ。
まず、ローカル変数が使えず、すべてグローバル変数となるBASICでは変数名やラベル名の
のバッティングを避けることができないにょ。
それはアプリ名（8文字）＋変数名という長い変数名を用いれば何とか解決可能だし、
このOS用の簡易言語＋コンパイラを作り変数名の管理はすべてOS側で行うという方法もある
（この方法だとHSPのAWAIT命令のようなものを用意すればOSへの処理の受け渡しとアプリ内
でのウエイト処理を手軽に行えるようになる）のだけどやはり最大の問題となるのはGRP面の
少なさにょ。
すべてのアプリでGRP面1つを共用しているためCAVEのようなGCOPYを使ったスクロールゲームを
作る場合には一部の領域を常時占有してしまうことになるにょ。
これが128x96以下のサイズであれば使用していない領域を使用すればいいだけの話だけど
このCAVEはウインドウサイズが160x120であるためその時点で残り横幅が96もしくは縦幅が
72というのが他のアプリで使用できる最大サイズとなってしまうにょ。
これが常時占有しない（常に画面全体を新規描画する）アプリであれば問題ないのだけど
CAVEのようなアプリが1つでもあったらその時点でGRPの面数の関係でマルチタスクで
動作させるのが難しくなってくるにょ。（ちなみに1/60秒単位でアプリとOSを切り替える
ためにアプリ内でVSYNCやWAIT命令を使用するのは不可でOSの動作用にVSYNC 1を使って
いるのみ）
というわけで、即興で作ったものの何か画期的な方法が思い浮かばない限りは先に進む
ことができないためこれで一端開発終了とするにょ（笑）
まぁ思いつきで作っただけだから問題はないけどね。
思いつきといえばレイヤー対応のお絵かきソフトも結局GRPの面数不足で開発凍結状態と
なっているにょ。
GRPが8面あればこのPetitcom OSも表示用、記録用を除いても6面余るためアプリ1つあたり
アプリ動作用で1面、ウインドウの表示バッファ用で1面の合計2面分使ってもアプリ3つを
同時に動かすことができるためようやくマルチタスクOSの意味が出てくるにょ。
現状でもウインドウの最大サイズを128x96に制限すれば4つ以上のアプリを同時に動かす
ことは可能だし、フル画面専用にすれば重ね合わせ処理用のバッファが要らなくなるため
2つ以上のアプリを同時に動かすことは可能なので何かを妥協すれば現状のGRP4面であっても
マルチウインドウ対応に作れないわけではないけどね。
-
GGKDreamStar
ローマ字入力、ひらがな表示対応。
漢字(小1-2)も導入予定。
ウィンドウシステムも随時改修中。
-
(無題)
YsのPSG番エンディング(FLY ME うんたらかんたら)とスーパーマリオブラザーズのBGMを同梱いやっふううううううう！
-
SS
http://cdn-ak.f.st-hatena.com/images/fotolife/o/otyakenrabu/20120626/20120626171024.jpg
若干高速化
-
(無題)
＞漢字(小1-2)も導入予定。http://ugomemo.hatena.ne.jp/05763C20AA3C5510@DSi/movie/3C5510_0B1BDAAD71C03_006
この漢字フォントなら7*7で1ドット相手、習った順に並んでいるから使いやすそう。
もちろん許可取らないといけませんが。
http://d.hatena.ne.jp/TTT0918/20110704/1309708418
-
レスにょ
わぁぃ@さんへ
＞ローマ字入力、ひらがな表示対応。
＞漢字(小1-2)も導入予定。
＞ウィンドウシステムも随時改修中
どんどんパワーアップしているにょ。
私は脳内にあったマルチタスクOSがプチコンで実現可能かを試しただけなので今のところ
バージョンアップ予定はないにょ。（気が向いたら9月のコンテストに向けて無理矢理完成
させるかも）
orirakkusuさんへ
＞YsのPSG番エンディング(FLY ME うんたらかんたら)とスーパーマリオブラザーズのBGMを同梱いやっふううううううう！
Windousに同梱するにょ！？
otyakenさんへ
＞若干高速化
150fpsとはなかなか速いにょ。
私が作ったものはOSにVSYNC 1を入れているため60fpsが上限にょ。
これを取り除いてCAVEのゲームオーバー画面を表示させた場合には73fpsだったにょ。
アクティブウインドウは常時描画しているのでGRPではこれが限界か・・・。
ちなみにCAVEの動作中にウインドウをドラッグすると30fps台まで落ちるため処理落ちが
酷いにょ（笑）
-
1インチセンサーが今後の高級コンデジのスタンダードになる！？
1インチセンサーを搭載した高級コンデジ「DSC-RX100」のレビューが行われているので
見てみることにするにょ。
http://dc.watch.impress.co.jp/docs/review/newproduct/20120622_541398.html
やはり、気になるのは操作感と描写力にょ。
操作感については発売開始前のファーストインプレッションにも記されているためそれも
見てみるといいかもしれないにょ。
http://dc.watch.impress.co.jp/docs/review/impression/20120614_540132.html
やはり、RX100の操作面の特徴は背面のダイヤルに加えて前面に設けられたリングダイヤルを
使った操作にあると思われるにょ。
このダイヤルはキヤノンのPowershot S90系（S95/S100を含む）を彷彿させるものだけど
このRX100の場合はそれと比べるとクリック感が無く無段階での回転となっているにょ。
そのため感覚で1段分や2段分変えるというわけにはいかず液晶画面を見る必要があるのだけど
あえてクリック感を無くしているのは動画にそのクリック音が入らないためにょ。
とはいえ、適度な重みがあるので操作感は悪くなさそうにょ。（まだ私も実機を触ってない
ため何とも言えないけど）
描写力で気になる部分といえばやはりレンズ性能と1インチセンサーの実力にょ。
一般的な1/2.3インチセンサーのコンデジと比べたら4倍、1/1.7インチセンサーの高級コンデジ
と比較しても2.8倍のセンサーサイズとなっており、あえて比べるまでもなくそれらとはランク
違いになることが予想されるけど懸念材料となるのはやはり2000万画素もあるということにょ。
いくらセンサーサイズが大きくても画素ピッチは1/1.7インチ、1000万画素の高級コンデジと
比べるとあまり差がないからね。
この辺はフルサイズで3630万画素のニコンD800がAPS-Cで1600万画素クラスの機種と比べると
画素ピッチではあまり差はなくても総合性能では格上となっていることを考えると画素ピッチ
だけで語ることはできないためやはり実機での描写性能こそがすべてとなるにょ。
まずは広角端の絞り開放（F1.8）の描写を見てみるにょ。
http://dc.watch.impress.co.jp/img/dcw/docs/541/398/03.jpg （ISO125）
http://dc.watch.impress.co.jp/img/dcw/docs/541/398/05.jpg （ISO125）
さすがにこのサイズで絞り開放から高い解像力を求めるのは無理があるけどこれをもって
判断を下すのも危険にょ。
F5.6まで絞るとかなりの解像感を得られるにょ。
ISO400でもこのレベルだからね。
http://dc.watch.impress.co.jp/img/dcw/docs/541/398/05.jpg （ISO400）
ボケに関してはややうるさいのがネックだけどこの辺は個人差もあるから置いておくにょ。
望遠端においてはこのレベルの描写力となっているにょ。
http://dc.watch.impress.co.jp/img/dcw/docs/541/398/90.jpg （ISO125）
大半のコンデジは広角〜標準域ではそこそこの描写力であっても望遠側においてはイマイチと
なっていることを考えるとやはり高画素かつコンパクトな割にレンズは頑張っているといえる
かもしれないにょ。
1/2.3インチセンサーのコンデジで1000万画素超になるとレンズの解像力がセンサーの画素
ピッチに対して明らかに不足しているというのに加えて回折現象による解像力の低下もある
からね。
1/2.3インチで1600万画素になるとF2.5で解像するレンズを作る必要があるのだけどその
明るさは一部のコンデジの広角端でようやく達成できているレベルにょ。（明るくてもその
絞りで解像できなければ意味はないけど）
しかし、望遠端でF2.5なんてコンデジは1/2.3インチセンサー搭載機の中には存在しないにょ。
比較的明るい機種でF4程度で最近の高倍率ズーム搭載機だとF5.6より暗い機種は少なくない
からね。
回折限界を超えたからといってすぐに明確な影響が出るわけではないけどその画素数では
物理的に解像しないわけであって大半のコンデジは等倍では見るに堪えられない縮小前提の
描写力となっているにょ。
その点1インチセンサーのRX100ならばF5.6までならば回折の影響はあまりないためちゃんと
解像力のあるレンズさえ搭載していれば等倍でも十分に見れるレベルの描写力となるにょ。
まぁ描写力といっても解像感だけではなくダイナミックレンジや色再現性も重要になって
くるのだけどさすがにこの辺は画素ピッチの広いAPS-Cやフルサイズと比べるとやや劣る
もののサイズから考えて一般的なコンデジと比較した場合には十分なレベルあると
思われるにょ。
続いて感度別の描写力を見てみるにょ。
ISO125 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/75.jpg
ISO200 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/76.jpg
ISO400 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/77.jpg
ISO800 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/78.jpg
ISO1600 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/79.jpg
ISO3200 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/80.jpg
ISO6400 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/81.jpg
（マルチショットNR）
ISO6400 http://dc.watch.impress.co.jp/img/dcw/docs/541/398/82.jpg
ISO125、ISO200は全く問題ないもののISO400からはやや目立ったノイズが出てくるように
なっているにょ。
これは昨今のAPS-Cセンサーを搭載したデジタル一眼と比べるとISO125ではそれほど差は
ないけど400くらいになるとその差が出てくるといえそうにょ。
とはいえ、ISO800、ISO1600でも等倍で見なければ十分に実用レベルにょ。
等倍ではたいしたことはないけれど1/2の1000万画素にリサイズすれば1/1.7インチ、
1000万画素の高級コンデジと比べたら明確なアドバンテージがあるように見えるにょ。
とはいえ、常用として使えるのはISO1600までにょ。
ISO3200では明らかにノイズリダクションによるディティール低下が目立ってきている
ため縮小前提画質となってしまっているにょ。
ISO3200でも常用可能なレベルにあるAPS-Cセンサー搭載のデジタル一眼レフと比べると
1〜2段分劣っている感じにょ。（等倍ではなく同一サイズへリサイズした場合の比較）
しかし、これはセンサーサイズを考えるとAPS-Cの方が3.16倍大きいのと妥当なものと
いえるにょ。
つまり、2000万画素と画素数は多いものの高画素による目に見えるデメリットはなくて
センサーサイズなりの性能はあるということにょ。（DIGIC5を搭載したS100はコンデジ
として見ればかなり高感度画質に優れていたけれどRX100と比べるとセンサーサイズの差は
大きいと感じる）
さすがにISO6400は厳しいけどそれはマルチショットNRで解決にょ。
これはソニーのコンデジでは「手持ち夜景モード」として数年前から使用されている
ものであり、高速連射を生かして複数枚（6枚程度）の写真を撮影してそれを重ね合わせ
処理を行うことで最大2段分程度のノイズ軽減を行えるというものにょ。
これは私が普段使っているコンデジTX1でも採用されているけどISO1600でも通常のISO400
クラスの低ノイズの写真が撮れているため非常に実用性の高い機能にょ。
もちろん動体撮影には不向きだし、手ぶれをしてしまうと解像感の低下を招いてしまう
ため万能なものではないけどね。
こうしてみるとやはり「センサーサイズ」が極めて偉大であることが改めてよく分かった
感じにょ。
1/2.3インチセンサーでもF0.9-2.4のズームレンズを搭載すればRX100と計算上は対等に
なれるけれど現実的に考えるとその明るさで1/2.3インチの極小ピッチセンサーでまともに
解像できるレンズを作ることはほぼ不可能だからね。
Nikon 1を見ると1インチセンサーで2000万画素は厳しいという先入観があったものの
RX100はレンズ一体型であり、デジタル補正がフルに使えるからこそ2000万画素でも実用
レベルの描写力となっていると思われるにょ。
画素ピッチからいえば上記のように一般的な高級コンデジよりも広いため決して無茶な
ものではないといえるにょ。
さて、スマホに搭載されるデジカメの性能は年々アップしており、1月31日にも書いた
ようにスマホと差別化や共存が狙える機種でないと今後生き残ることが難しいと考えて
いるにょ。
したがって、安いだけのコンデジではもう生き残ることができないにょ。
これはすでにメーカー側も気づいていることであり、各社とも生き残りを考えた機種を
発表しているにょ。
スマホのデジカメがいくら良くなってもあくまでローエンドコンデジと同レベルのもの
であり、高倍率ズーム搭載機や画質重視のモデルは十分に生き残ることができるにょ。
ただ、画質重視する場合には昨今はミラーレスが小型化、低価格化しておりコンデジから
ステップアップ用としてメーカー側も入門者的な位置づけの機種を積極的にラインナップ
しているにょ。
確かにフォーサーズセンサー搭載機でも一般的なコンデジと比べると別格の描写力となって
いる（ただし、高感度に関してはそれほど強くない機種が多い）もののコンデジの代わり
にはならないにょ。（コンデジの代わりというよりもデジタル一眼の入門機が大きく重い
という人の代わりであるためミラーレスの普及でシェアを失うのはコンデジではなくて
デジタル一眼の方）
確かにセンサーサイズが大きくなれば画質に与える影響は極めて大きくなるのだけど
今度は筐体サイズだけではなくレンズも大型化してしまうという問題が発生してしまう
ことになるため「センサーサイズを大きくすれば解決」という単純な問題ではないという
ことにょ。
そういう面では1インチセンサーというのは落としどころとしてはベストだと思うし
そのセンサーサイズでこの筐体サイズを実現しているからこそRX100の魅力は大きいと
思われるにょ。
ミラーレスのサイズを受け入れられないユーザーの受け入れ先としては高級コンデジは
非常に有用な存在であり、廉価コンデジの将来はないため恐らくRX100を発端として
各社の高級コンデジに1/1.7インチを越える大型センサーを搭載するものをラインナップ
してくるのではないかと予想されるにょ。
-
(無題)
Ysのほうは@tiny_yarouにリプライ飛ばす
マリオの方はneko8000さんに聞く
----
現在背景実装中！全部内蔵してやるへへへ
-
レスにょ
orirakkusuさんへ
＞現在背景実装中！全部内蔵してやるへへへ
気を付けないとQRコード100枚越えの超大作になってしまうにょ。
配布を行うならばほどほどにしないとね。
-
(無題)
いまのところSIZEはSixRockChainより小さい16720。
さてFPSは(事実CPSだが)
アドオン時725fps
日付と時刻起動時300fps
上+TALK125fps
どうだ素晴らしいだろう。Win9x系によく見られたアプリによるフリーズは対策の仕様がOS側ではないな。
-
レスにょ
orirakkusuさんへ
＞??いまのところSIZEはSixRockChainより小さい16720。
私の方は最小限の機能のみなので2130バイトにょ。
完成時にはこの数10倍になりそうだけどね。
あとは、アプリをどれだけ入れるのかでもサイズが変わってきそうにょ。
＞さてFPSは(事実CPSだが)
＞アドオン時725fps
＞日付と時刻起動時300fps
＞上+TALK125fps
＞どうだ素晴らしいだろう。
私の方はOSの起動時（画面表示はデスクトップ、マウスカーソル、タスクバー、時計のみ）
で790fpsだったにょ。
ただし、唯一のアプリであるCAVEを起動時には73fpsまで低下してしまうにょ。
これはマルチタスク、マルチウインドウに対応できるように仮想画面に描画してそれを転送
している関係上どうしても遅くなってしまうにょ。
とはいえ、デフォの160x120のゲーム画面を128x96にすれば102fps、96x64にすれば160fpsに
なったにょ。（CAVEはウインドウサイズ可変に対応しているのでサイズを小さくしても普通に
遊べる）
96x64ならばCAVEの動作中にウインドウをドラッグしまくっても96fps出るけどさすがにこの
画面サイズだとやや寂しいにょ。
＞Win9x系によく見られたアプリによるフリーズは対策の仕様がOS側ではないな。
ちなみにorirakkusuさんはWindous DSではどうやってアプリを追加予定にょ？
やっぱり、APPENDで追加にょ？
-
(無題)
調べてみたら34352バイトだった。
けどほとんどが旧アプリ(windowシステム2.0)でそれを消したら多分半分以下になると思う。
そういやfpsとかってどうやって測定しているんですか?
自分はどっかのゲームからfpsカウンタだけ取り出して使っている。
-
(無題)
私はfpsをGAME4のカウンタで計りますね。otyakenさんと同じかな？
-
(無題)
完成番では、特設DATA文コーナーにアイコンデータとラベル、常駐のラベル、プログラムNo.を書いて、その下にアプリケーションを書くという方法です。
FPSのはかり方(その時その時で違うけどね)
49.IF TIME$!=MT$ THEN (表示部):F=1 ELSE F=F+1
57.MT$=TIME$
あと、SPOFSをタッチ時しか実行しないようにしたら
アドオン時1250fps
日付と時刻起動650fps
上+TALK300fps
すごい上がった。
あと30fpsを切ったらブルースクリーンルーチンに飛ばすようにした。
-
GGK DreamStar
追加の仕方はorirrakusuさんと同じ感じ。
速度はおちゃめさんと同じ60fps。
処理落ち防止用に、30fpsで同等の動作を確保する「30fpsモード」を搭載予定。
-
レスにょ
otyakenさんへ
＞調べてみたら34352バイトだった。
＞けどほとんどが旧アプリ(windowシステム2.0)でそれを消したら多分半分以下になると思う。
それでも17KBか・・・。
どんな機能を持っていてどんなアプリを用意しているのか分からないので長いのか短いのか
判断するのが難しいところにょ。
＞そういやfpsとかってどうやって測定しているんですか?
1秒間（60フレーム）の描画回数をカウントしてそれを表示すればいいだけにょ。
私が普段使っているのはこんな感じにょ。
FPS=FPS+1:IF !(MAINCNTL%60)THEN LOCATE 0,0:?FPS,:FPS=0
（余分なコロン、スペースを省略して）変数名に1文字変数を使えばfps表示プログラムと
しては最短になると思うにょ。（1文字変数を使わないのは普段はリスト短縮のため優先的に
使用しているため削ることが可能なfps表示に使用するのがもったいないため）
MAINCNTL%60の値が0になるのは60フレームごとなのでTHEN以下は60フレームごとに実行
されるにょ。（ただし、60fpsを越える場合は1フレームに2回以上実行される可能性がある）
特に初期設定無しでこの1行を追加するだけでOKでありお手軽なのだけどこの方法はVSYNCや
WAIT命令によって上限が60fpsになっている場合しか使えないにょ。（つまり1〜60fpsの
範囲内で測定可能）
60fps超を測定するには前回のMAINCNTLの値を変数に入れれば簡単に判定が可能にょ。
FPS=FPS+1:IF MAINCNTL-CNT>=60THEN LOCATE 0,0:?FPS,:FPS=0:CNT=MAINCNTL
そうすれば前回から60フレーム以上経過しているかどうかというのを判定すれば済むにょ。
わざわざ前回のカウンタの値を変数に入れたりと無駄に変数を増やしたくないならば最初の
リストを改造すれば条件付きで測定可能にょ。
FPS=FPS+1:IF (FPS>9)*!(MAINCNTL%60)THEN LOCATE 0,0:?FPS,:FPS=0
こうすることでデフォの10倍となる10〜600fpsで測定可能にょ。（「FPS>19」にすれば
デフォの20倍まで測定可能）
基本さえ抑えておけばあとは自分が使いやすいもので問題ないにょ。
わぁぃ@さんへ
＞私はfpsをGAME4のカウンタで計りますね。otyakenさんと同じかな？
あれは良くできているけど無難な作りになっていて無駄も多いため自分が使いやすいように
改造するのもいいかもしれないにょ。
＞処理落ち防止用に、30fpsで同等の動作を確保する「30fpsモード」を搭載予定。
便利そうな機能だけどアプリ側の対応が必要になってくるにょ。
とはいえ、「CAVE」はゲーム自体は30fpsで動作しているので処理落ちの問題はないけど
OSそのものは60fpsを前提としているため動作中にウインドウをドラッグすれば処理落ちが
起きてしまうというのが改善されそうにょ。
もっともCAVEをフル画面起動したら18fpsまで落ちてしまうので30fpsモードを導入しても
処理落ちしまくりだけどね。（あとマルチタスクで複数のアプリを同時実行したら簡単に
30fpsを切ってしまいそうだし）
orirakkusuさんへ
＞完成番では、特設DATA文コーナーにアイコンデータとラベル、常駐のラベル、プログラムNo.
＞を書いて、その下にアプリケーションを書くという方法です。
レスどうもにょ。
APPENDで追加するというのは最も単純で分かりやすいものだけどこの辺をどのように処理して
いくかで制作者の個性がでてくるため工夫の余地は多くあると思うにょ。
私は自分以外の人が自由にアプリを追加できるようにAPPENDのみで済むようにAPPENDする
プログラム内にアイコンデータなどを書こうと思っているにょ。（現時点ではアプリが
1本しかないのでそんな汎用的な作りにはなってないけど）
それだとAPPENDを実行してもOS上からは分からないためそれを認識するための作業（つまり
（インストール作業）をOS上で行う予定にょ。（プチコンでON ERROR GOTOが使えたら
ラベル名が重なったときにダイヤログで「不正な処理を行ったので終了します」とダイアログ
表示させることも可能だけどそれができないため不特定多数の人がアプリを作って追加する
場合にはラベルチェックの重複チェックもしないといけない）
こうすればOS上からアンインストール処理を行えばAPPENDしたプログラムを消去するだけで
済むため削除も簡単にょ。
もっともプチコンの場合は範囲指定をしての削除ができないため簡単といっていいのかは
微妙だけどね。
ということで、どのようにプログラムを書いていくのかという仕様はまだ全然固まって
なかったりするにょ（笑）
＞あと、SPOFSをタッチ時しか実行しないようにしたら
＞アドオン時1250fps
＞日付と時刻起動650fps
＞上+TALK300fps
＞すごい上がった。
私はデフォで必要最小限の表示に抑えたら1190fpsになったにょ。
なんかどんどん無意味な計測になっていっているにょ（笑）
＞あと30fpsを切ったらブルースクリーンルーチンに飛ばすようにした。
なかなか面白い機能だけどfps表示は初回表示時と画面を一端閉じてから開いた時の最初の
表示は不正確なのでそれを回避するルーチンを作らないといきなりブルースクリーンに
なったりする場合があるので注意が必要にょ。
-
(無題)
土日だし、テストのQR書き出ししてみるか。
50枚越えてたらリスト短縮しないと公開は100%ムリポw
といってもまだ6枚ぐらいだとおもうが。
ちなみタイニーゼビウスforプチコンって何行だっけ？
-
(無題)
確かにON ERROR GOSUBがあれば便利だな。
99BASICで使ってみたけど良かった。
-
GGK DreamStar
ＢＧ面にＰＲＩＮＴするルーチンを作成。
ＣＳＲＸ、ＣＳＲＹでＰＲＩＮＴと連動しているほか、ひらがな／カタカナの混在表示が可能（ＣＨＲ＄（９）はかな切り替え、ＣＨＲ＄（１３）は改行に割り当て）
-
Windous DS
公式サイト作っちゃった(テへ♪
http://www.geocities.jp/orirakkusu/petitcom/mkll/osprj/
-
レスにょ
orirakkusuさんへ
＞50枚越えてたらリスト短縮しないと公開は100%ムリポw
現時点でたいした枚数でなくてもこれからどんどん機能を拡張していったら枚数は増えるので
油断は大敵にょ。
＞ちなみタイニーゼビウスforプチコンって何行だっけ？
行数はよく分からないけどQRコード109枚だったにょ。（TINY野郎さんのツイート参照）
プチコンプログラムで最も行数の多いのは私が知っている範囲内だとktさんの「PX7」にょ。
http://www.geocities.jp/sp1_ssr/px7.htm
手元にあるver1.00の段階で7373行に達しているにょ。（可読性重視のプログラムなので
行数の割にはQRコード枚数が少ない）
ゲームだとるかかさんの魔導物語が最も行数が多いにょ。
ちなみに私が発表済みのプログラムだと最高でもQRコード4枚だし、今まで発表している
プログラムのQRコードを全部合わせても94枚しかないにょ。（平均すると1作品2枚くらい）
＞公式サイト作っちゃった(テへ♪
ついに作ったにょ！？
それならば、企画倒れにならないように頑張らないといけないにょ。
私は気力が続かないのである完成の目処が立たない限りはそういうサイトは作らないにょ。
わぁぃ@さんへ
＞確かにON ERROR GOSUBがあれば便利だな。
ツールやある程度以上の規模のプログラムを作る場合には必要不可欠といっていいような
命令にょ。
現状だとせっかくERR、ERLでエラー内容、エラー発生行が取得できるのにそれを十分に
生かすこともできないしね。
せいぜいLIST ERLでエラー行を表示するくらいにしか使えないにょ。
＞ＢＧ面にＰＲＩＮＴするルーチンを作成
やっぱり、テキスト表示ならばBG面が一番にょ。
表示も高速だし、文字種も1024使えるしね。
ただし、グラフィックは使えない（使いづらい）のでコンソール主体のアプリに限られて
しまうのが難点にょ。（BG面の上に描画すればいいけどはみ出し処理を行うのが大変）
まったく関係ないけど半年前に初代プチコンで作ったプログラム「2OMP」が見つかったので
書いておくにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/image/2omp.jpg
これは超簡易MML用のMMLデータをOMP用のMMLにコンバートするプログラムにょ。
http://wiki.hosiken.jp/petc/?Toukou%2F%C4%B6%B4%CA%B0%D7MML
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm#omp
超簡易MMLの音程、音長指定の方法がOMPに似ているから簡単にコンバートプログラムを
作れそうということで即興的に作ったものにょ。
ただし、あまりに需要が無さそうだし唯一の発表曲である「春の奇跡」も1つの文字列
変数に格納しきれず、String too longエラーとなって153番目の音符までしか変換が
できないということで未発表となっていた品にょ。（まぁ複数の文字列変数に分割保存
するなり、GRPに保存するなりすればエラーは解決できるけど）
良かったら改造するなり、適当に使ってにょ（笑）
-
プチコンでマルチタスクOS PART2
プチコンでマルチタスク、マルチウインドウのOSもどきのプログラムを作る場合には6月25日に
書いたようにまずはGRP面が4面では全く足らないにょ。
ただし、これは逆に言えば4面で収まる範囲内であれば作れるということも意味するにょ。
つまり、開いているウインドウの合計サイズが256x192以下になればいいということだからね。
ということで、即興で最低限の機能のみを作ったPetit OSだけどその続きを仮に作る場合は
他にどのような問題があるのか、どうやって実現させたらいいのかということについて
書いていくことにするにょ。（以下、「OSもどき」を「OS」と記述）
さて、まずはマルチウインドウを実現するためには重なった部分をバッファに入れていく
ことになるにょ。
別にバッファに入れなくても重なっているウインドウを常に下から順に全部表示していけば
いいのだけどそんなことをしたら何も動作をしていないウインドウをドラッグするだけでも
30fpsを下回る可能性さえあるにょ。
これがバッファに入っている部分だけ再描画するならばウインドウをドラッグする際の描画
速度は数倍にアップするにょ。
そして、ウインドウ用バッファだけではなく表示用バッファも必要になるにょ。
マルチタスク、マルチウインドウを実現するためには直接画面表示するわけにはいかず
一端表示用バッファ（要するに仮想画面）に描画したあとにそれを実画面に転送することが
必要になってくるにょ。
そうしないと管理が複雑になりすぎて実用にならないからにょ。
それだけでなくコンソール表示（テキスト表示）は基本的にキャラ単位でないと表示する
ことができず、マルチウインドウに対応して自由にウインドウをドラッグなんてことは実現
できないにょ。
コンソール表示だけならばBG画面を用いればマルチウインドウ対応にすることは可能だけど
その際も自由に使えるのは2面だけになってしまうにょ。（その代わり1つのウインドウは
512x512ドットまで可能になる）
表示用バッファを用意することでマルチウインドウ処理は簡単になるのだけどそれでも
マルチタスク、マルチウインドウに対応させるためには下記のような6つの重要な問題を
抱えているにょ。
(1)マルチウインドウのバッファ管理
(2)事実上グラフィック用命令以外は使えない
(3)事実上BGMPLAYは使えない
(4)ウエイトや一時停止を行う命令は使えない
(5)コンテキストスイッチの保存
(6)ラベル名、変数名の重複回避
(1)のみOS側の問題であとはアプリを作る際の問題となるにょ。
(1)合計で256x192となる最大バッファサイズを分割して管理することになるけどそれを
どのように割り当てて行くかということが問題にょ。
これがウインドウサイズが固定で128x96のようにキリの良いサイズだと単純に4分割して
それを割り当てればいいけどこれがサイズの異なるウインドウだとうまい具合に大きい
ウインドウから順に開いていってくれれば開いたサイズに割り当てを行うのは難しく
ないものの順不同で開いていくならば残りバッファサイズは十分なのに後から大きい
ウインドウを開けばバッファサイズが不十分になってしまう場合があるにょ。
これはバッファの断片化が起きるためにょ。
これは断片化解消ツールを作れば改善可能なので問題ないにょ。（リアルタイムで
この処理を行うことも可能だけど処理速度の大幅な低下を招いてしまうので実用レベルに
達しないだろうし、下記のダイレクトモード以外だとバッファを整理するための作業エリアの
確保ができないため実現が難しい）
ウインドウは今のところシステム変数としてSCREENX、SCREENYを用意してそれを元に起動時に
ウインドウサイズを決めているけどこれは可変式にすることも可能にょ。
唯一のアプリである「CAVE」は可変式に対応しており、描画される穴の幅などはウインドウ
サイズによって変化するにょ。
アプリの再起動によって変化させるだけではなく原理的にはWindowsのようにドラッグに
よってリアルタイムでウインドウ幅を変化させることもできる（単にSCREENX、SCREENYの
値を変えるだけでいい）けど上記の断片化問題を考えると厳しそうにょ。
(2)表示バッファから実画面への転送はGCOPYを使う都合上、表示バッファの描画はGRP面のみ
有効になるにょ。
つまり、マルチウインドウ処理が容易になる代償としてコンソール、スプライト、BGを使った
描画はできないということにょ。
表示を行う場合はグラフィック命令を用いるか、コンソール、スプライトキャラを表示する
場合はGPUTCHRで描画していく必要があるにょ。
それに加えて表示バッファの割り当てをOS側で行っているためバッファのGRP面に描画する
場合もその仮想画面の座標に描画しないといけないにょ。
例えば96x64のウインドウを(128,96)を起点としたバッファが確保されておりその上に
描画する場合は座標(0,0)がバッファ上の(128,96)に相当し、仮想画面の右下である
(95,63)が(223,159)に相当するにょ。
これを実際にプログラムを作る際に計算して作るのはかなり大変にょ。
まぁ、描画専用のAPI（というかサブルーチン）を用意してそれを経由して描画することで
自動的にOS上で割り当てられたバッファ上に描画するということも考えているけどかなり
面倒臭そうにょ。（機能を実装するのは簡単だけど実際にアプリを作るのは面倒）
(3)音楽を鳴らす場合は各ウインドウで独立して制御する必要があるにょ。
BGMPLAY命令では8チャンネルまで対応しているため最大ウインドウ数が8個ならば各
ウインドウに1チャンネルずつ割り当てれば鳴らすことはできるにょ。
ただし、それはバックグラウンドに移ったウインドウで鳴らしている音を鳴らし続けた
場合には同時発音数の問題で難しいにょ。
かといって、バックグラウンドに移ったゲームで使用されている音楽を停止した場合には
ウインドウを前面に持ってきた際にBGMを再び続きから鳴らすことは現在のBGMPLAY命令
ではできないにょ。
つまり、「BGM再生→BGM停止→BGMを停止箇所から再生」を行うためには音階演奏
プログラムを自前で用意するしかないにょ。
まぁこれはOMPがあるから何とかなるけどね。
(4)そして、マルチタスクに対応させるためにはアプリへの時間の割り当てが問題となるにょ。
WAITやVSYNCでそのアプリを一定時間停止してしまうとマルチタスク処理を行う場合には
他のアプリまで影響が出てしまうためアプリ内でそういう命令を使うことはできないにょ。
OSは60fpsでの動作を前提としているため30fpsのゲームを作る場合には2回に1回実行すれば
良いという感じだけど実際は処理落ちを起こしているということも想定しておかねばならない
ためにMAINCNTLのカウンタを用いて2フレームに1回処理するというように組む必要が
あるにょ。
あとINPUTなどの一時停止が行われる命令は使用することができないにょ。
これはINKEY$やKEYBOARDなどを用いてINPUTの代替となるサブルーチンを用意して解決する
しかないにょ。
(5)マルチタスクOSを作る場合に必要不可欠なのはコンテキストスイッチの保存にょ。
といっても、ただのOSもどきなので本来のコンテキストスイッチとは全然異なるものにょ。
私が作ろうとしているPetitcom OSにおいてアプリA、アプリB、アプリCの3つのアプリを
同時に動かす場合には下記のようになるにょ。
アプリA→アプリB→アプリC→OS→アプリA（以下略）
↑--- この間が1/60秒 --- ↑
ただし、これもアプリAからアプリBに処理が移る場合にアプリAのどの部分まで処理が
行われたのかを一端保存して再びアプリAを実行する際にはその続きから実行する必要が
あるにょ。
これがマルチタスクではなく起動しているアプリが1本ならばアプリからGOSUBでOSを
呼び出せば簡単にできるけどマルチタスクの場合は自前で実行箇所のフラグとなるものを
保存してそこにGOTOでジャンプするしかないにょ。
(6)ラベル名が重複してしまうとエラーによって実行不可能になるため事前にチェックして
おく必要があるにょ。
とはいえ、そのプログラム内で使われているラベルを調べることは手動で行わない限りは
無理なのであらかじめそのアプリで使われているラベルを書き記したデータを用意して
インストール時にチェックするしかないにょ。
アプリはAPPEND命令によって追加予定だけど追加しただけではOS上から使用することは
できないためそのアプリが追加されたことをどこかに記す必要があるにょ。
それはOS内にインストーラーを用意してそれを用いてインストール処理を実現する予定と
なっているにょ。（この方法を用いればアンインストール時はアンインストール処理を
OS上で行いAPPENDしたプログラムを削除するだけなので簡単）
その際にアプリ内にあるアイコンデータと使用ラベル一覧を呼び出しアイコンデータを
元にBG面に書き込み、ラベル一覧を元にチェックして現在インストールされている
プログラムとラベル重複がないかをチェックしてそれで使用可能になるにょ。（ラベル
重複がある場合にはインストール済みのどのアプリで使用されているのかということも
表示する）
基本的にラベルはなるべく他のアプリと被らないように先頭の数文字はアプリ名を
使ったものにする（CAVEにおける＠MAINならば＠CAVEMAINとする）ということを推奨
しているけどね。
次に変数の重複問題にょ。
変数の場合は配列変数で二重定義にならない限りはエラーが出ないため問題ないとも
いえるけどラベル数よりも使用する変数の数の方が多くなるだろうから厄介にょ。
そこで考えたのはA〜Zの1文字変数の疑似ローカル変数化にょ。
これによってA〜Zまでは使用変数一覧を作成することなく自由に使えるようになる（どの
アプリでもA〜Zは重複して使用可能になる）けどその代償として速度の低下を招いてしまう
ことになりそうにょ。
使用しているラベルや変数名は配列変数に入れていると同時にGRPにも書き込み、OSの
ブート時には再びそこから使用している配列変数に読み込む予定にょ。
ラベル名が16バイトx1つのアプリで50個使用、変数名が16バイトx1つのアプリで100個使用
と考えた場合には2400バイトとなり、48KBのGRPには20本分のアプリデータを保存可能に
なるにょ。（「MEM$では全く足らない」というのはこれで分かると思う）
実際はデフォで用意するアプリなんて数本だろうし、誰かが自分で追加するなんて可能性も
上記のアプリの作りにくさを考えると望みが薄そうなので48KBあればかなり余裕だけどね。
以上が「Petitcom OS」を脳内シミュレーションで動作させた場合に見つかった問題点にょ。
処理速度の問題やOSそのものの使い勝手の問題は実際に作ってみないと分からないので
「少なくとも」これだけの問題があるということにょ。
さて、これではあまりに制約がありすぎて使えないOSとなってしまいそうにょ。
そこで考えたのはダイレクトモードの搭載にょ。
マルチタスク、マルチウインドウではなくシングルタスク専用モードにょ。
このモードで動作させれば上記の制約はほぼ無くなりプチコンで用意されているほとんどの
機能が使えると同時にすでに作られているプログラムも一部の手直しをするだけでこの
Petitcom OS上で動作させることが可能になるにょ。（アイコンデータと使用ラベルデータ、
変数データを用意して、OSに復帰する処理を加えるだけでいい）
上記のインストーラーや断片化解消ツールなどはこのダイレクトモードでないと作るのが
難しいけどそれをユーザー側（一般アプリ作成側）にも開放しようというものにょ。
ただし、マルチタスク、マルチウインドウがウリとなっているためこのモードを前面に
出してしまうことは両刃の剣となってしまうのが問題にょ。
このモードは端的にいえばたくさんのプログラムをAPPENDでつなげてそれを選択実行
できるランチャー機能でしかないわけだしね。（OSっぽさを出すならばやっぱりマルチ
ウインドウでないと・・・）
したがって、マルチタスク、マルチウインドウが実用レベルになっているかということが
重要になるにょ。
まぁ実用ソフトではなくネタソフトと考えれば「マルチタスク、マルチウインドウの
OSもどき」ということでそれなりの価値はあるだろうけど作るための大変さとネタ的な
面白さを天秤に掛けると微妙なので一晩で作った試作品の続きを作る気力が失われて
しまっているにょ。
これだけ競合が多ければ目新しさも薄れてしまうだろうからね。
簡単に作れるプログラムならばさっさと完成させてもいいけど、どう考えても1週間程度
では完成しそうもないためそれなりの気力がないと駄目にょ。
それにコンテストに出すならば締め切りはまだ先なのでギリギリにならないとエンジンが
かからない私にとってはまだあわてる時間ではないしね（笑）
-
(無題)
そういえば、超簡易MMLからプチコンのMMLに変換するソフトを作ったけど、和音の処理ができてないし、無駄が多いから発表してない。
-
(無題)
GGK DreamStar用のデスクトップ背景を本物のwindows XPに入れてみたww
-
Twitterでは
変態紳士と呼ばれている(呼んでほしい)らしい(form orirakkusu@情報アンテナVer1.00)
-
レスにょ
わぁぃ@さんへ
＞そういえば、超簡易MMLからプチコンのMMLに変換するソフトを作ったけど、和音の処理ができてないし、無駄が多いから発表してない。
超簡易MML→OMPはほとんど同じようなアルゴリズムだったから和音を含めて簡単に
変換プログラムはできたけどプチコンのMML（BGMPLAY形式）に変換する場合には大きく
異なるため簡単にはいかないからね。
和音処理を実現するには変換元のMMLを2度読み取る必要があるにょ。
まず、1度目は音長0の音符が最大何個連続しているかを調べるにょ。
「音長0の最大連続数＋1」が同時発音数となっているのでそれだけ分のトラックにデータを
書き込めばいいことが分かるにょ。
2度目の読み取りでいよいよ変換にょ。
例えば元のMMLが最大3和音で四分音符のドを鳴らす場合にはトラック0にはC4を書き込んで
トラック1、トラック2には四分休符（R4）を書き込むにょ。
音長0でド、ミ、ソを同時に発音している場合にはトラック0にC4、トラック1にE4。
トラック2にG4を書き込めばいいにょ。
こうやって、1つずつ順番に変換していけば難しいことはないにょ。
ただし、これだと細切れの休符がたくさん書き込まれるため休符はその都度書き込まず
休符の長さだけを各トラックごとカウントしていってそのトラックの音符を書き込む際に
休符をまとめて書き込むといいかもしれないにょ。
そのトラックにおいて四分音符14個分の休符があったら「R4R4R4R4・・・（14個分）」では
なくて「R1R1R1R2」とすればデータ効率はアップするにょ。
私もOMP→プチコン用MMLの変換プログラムを作ろうという考えはあったけど私自身が特に
必要としていないし、需要も無さそうなのでやめたにょ。
1画面では作れそうになかったしね（笑）
＞GGK DreamStar用のデスクトップ背景を本物のwindows XPに入れてみたww
一瞬、XPの壁紙をGGK DSに入れたのかと思ったけどその逆とは・・・。
次はXP上で動くプチコン風の文字やスプライトキャラを使ったプログラムを作れば完璧にょ。
orirakkusuさんへ
＞変態紳士と呼ばれている(呼んでほしい)らしい(form orirakkusu@情報アンテナVer1.00)
私ってそんなイメージあるー？
それどこ情報？どこ情報にょー？
-
変換
前作った事あるけど音長192で和音にした
-
(無題)
Twitterのタイムラインだお！
-
(無題)
↓追記
@zwisser 失礼な！できれば変態紳士とよんてほしいものです(笑)
みたいなツイートだったような気がするするー
-
(無題)
あとGCOPYの意味やっとわかった。
-
レスにょ
otyakenさんへ
＞前作った事あるけど音長192で和音にした
私が作ったプチコンMMLは音長999で和音になるにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/mml.htm
そうではなくて、BGMPLAYに変換するときに音長192で和音を表現するということにょ？
BEEPを使った演奏プログラムならば勝手に音が鳴り続けるから和音の表現は簡単だけど
BGMPLAYの場合は音が伸びないのでちゃんとトラックごとに分けないと厳しそうにょ。
orirakkusuさんへ
＞Twitterのタイムラインだお！
「どこ情報？」というのはただの「地獄のミワサ」ネタにょ（笑）
http://www.google.co.jp/#hl=ja&site=&source=hp&q=%E3%81%9D%E3%82%8C%E3%81%A9%E3%81%93%E6%83%85%E5%A0%B1
＞あとGCOPYの意味やっとわかった。
これでGCOPYを使ったプログラムが作れるにょ？
-
先日はありがとうございました。
こんばんは。初めて書き込みをさせて頂きます。
Twitterでプチコンのカラーパレットの並び順について教えて頂いた者です。
先日は本当にありがとうございました。
16×16で並んでいる色を見ただけだと規則性が分からず困っていたので助かりました。
おかげで、以前から作っていた3D迷路のゲームを完成させる事が出来ましたので
手前味噌ですが、お礼の意味を込めてQRコードを貼らせてもらいます。
http://www2.plala.or.jp/canaan/up/maze.png
ルールは、エネルギーが無くなる前に迷路を3階分踏破すれば勝ちです。
◎を踏むとエネルギーが回復します。▲が階段です。
もともと、「ウィザードリー風の3D迷路を描きたい！」と言う気持ちだけで
作り、後から無理やりゲーム性を持たせたので面白さはイマイチかもしれません。
このサイトにはプチコンで必要なソースの短縮化ロジックが多数書かれていたので
参考にさせて貰います。
では。失礼します。
-
レスにょ
まるまるさんへ
＞こんばんは。初めて書き込みをさせて頂きます。
こちらでは初めましてにょ！
＞先日は本当にありがとうございました。
＞16×16で並んでいる色を見ただけだと規則性が分からず困っていたので助かりました。
役に立ったようで何よりにょ。
＞もともと、「ウィザードリー風の3D迷路を描きたい！」と言う気持ちだけで
＞作り、後から無理やりゲーム性を持たせたので面白さはイマイチかもしれません。
迷路ゲームとしては基本に忠実で良くできていると思うにょ。
ただ、エネルギー回復ポットの判定が気になったにょ。
行き止まりの場所で回復ポットがないのに誤判定によって回復してポットの残り数が
マイナスになるという状況が発生する場合があるにょ。
＞このサイトにはプチコンで必要なソースの短縮化ロジックが多数書かれていたので
＞参考にさせて貰います。
プログラムの可読性とリスト短縮化は相反することが多いので可読性を重視する場合には
役に立つ物は少ないですが、何かの役に立てれば幸いにょ。
-
軽さは正義・・・なのか？
NECからUltrabook「LaVie Z」が正式発表されたにょ。
http://pc.watch.impress.co.jp/docs/news/20120703_544247.html
このLaVie Zは「999g以下」とすでに発表されており、その重量予想クイズが実施されていた
関係上詳細スペックはなかなか公開されず、このクイズの締め切りが終わってからようやく
今回の発表に至ったにょ。
そして、その重量は何と875gにょ。
これは13.3インチのノートPCとしては驚異的な軽さにょ。
13インチクラスのUltrabookの重量は概ね1.3〜1.5kgとなっているにょ。
Ultrabookの中に混じっても軽い部類となっているVAIO Zは1165gであり、通常電圧版と
ULV版の違いによる冷却機構の重量ダウンを考えれば999gという重量は十分に実現可能と
言えそうだけどそれより大幅に下回るのは難しいにょ。
限界まで軽量化しているノートPCといえばやはりVAIO Xが思い浮かぶにょ。
11.1インチ液晶ながら標準バッテリ（Lバッテリ）で765g、オプションの軽量バッテリ
（Sバッテリ）で655gという超軽量を実現しているにょ。
11.1インチと13.3インチではサイズが異なるのでこのレベルを実現するのは不可能だけど
単純に（液晶面積比で）比例計算して考えると標準バッテリとの比較ならば1098g、軽量
バッテリとの比較ならば940gとなるにょ。
もちろん外装重量と同じように内部重量が増えない限りは比例計算は成立しないのだけど
VAIO Xに使用されていたAtom Z（TDP2.4W）とULV Core i5もしくはCore i7（TDP18W）の
違いを考えると冷却機構に大きな差があるし、消費電力の面を見てもいくら省電力な
IvyBridgeとはいえAtomと比べると大きく劣るためある程度のバッテリ駆動時間を確保する
ならばバッテリ重量だけを見てもかなりのものになるため上記の比例計算と比べて大きく
軽量化をするのは難しいにょ。
しかし、「新素材によって800g台になっているらしい」という情報が予想クイズの締め切り
前に出たにょ。
http://plusd.itmedia.co.jp/pcuser/articles/1205/10/news082.html
やはり、重量にインパクトを与えるならば800g台というのは非常に大きいにょ。
海外向けに発表する場合にも2ポンド（約907g）を切っているというのは非常に大きな
インパクトを与えるだろうしね。
これらの情報から軽量化を重視したVAIO Xが「765g（ナムコ）」ならば（サイズを考慮
した場合に）それ以上の軽量化を行っているLaVie Zは「876g（バンナム）」という予想を
した人は多いのではないかと思われるにょ。
それを見越してかLaVie Zはそれよりさらに1g軽い875gを公称重量にしているにょ。
これは安易に予想を的中させないNECの策略といえるにょ（いや違うって）
このLaVie Zに使われている素材は何かというとマグネシウムリチウム合金にょ。
http://plusd.itmedia.co.jp/pcuser/articles/1207/03/news029_2.html
これはNASAが開発した新素材だけど加工が難しいため今までPCでは使用されてこなかった
みたいにょ。
どれくらい軽量なのかはNEC発表の資料を見れば明らかにょ。
比重 同一剛性を得たときの重量（600平方cm）
マグネシウムリチウム合金 1.36 64g
マグネシウム合金 1.8 86g
アルミニウム合金 2.7 112g
プラスチック 1.25 133g
ステンレス 7.9 228g
これを見ると軽量ノートPCならばもれなく採用されている一般的なマグネシウム合金と
比べるとさらに軽くなっていることが分かるにょ。
600平方cmというと天板より一回り小さなサイズだけどそれをすべてこの新素材に変えた
としても軽くなるのは18gでしかないにょ。
つまり、LaVie Zがここまで軽量化できたのは新素材を使ったからという単純なものでは
なくて液晶モニタ、基板までギリギリの軽量化を行っている賜といえるにょ。
軽さに関してはUltrabookの中ではダントツ1位となったLaVie Zだけどそれ以外に関しては
飛び抜けて優れているという要素はないにょ。
http://pc.watch.impress.co.jp/docs/column/hothot/20120703_544255.html
とはいえ、液晶解像度は多くのUltrabookが1366x768のWXGAとなっている中で1600x900の
WXGA++となっているのはまずまずのスペックにょ。
個人的には解像度が高ければ高い方がいいのでフルHDならばなお良かったのだけど一般的に
考えるとDPI設定を変えないと使いづらいという機種は売り辛いと思われるためこれは
スペックと無難さを天秤に掛けた場合にはベストな選択といえるにょ。
13.3インチフルHDでは166ppiとなってしまい、50cmの距離からだと人間の目の分解能と
されている300ppi（30cm時）ギリギリの高精細であるため長時間の使用には抵抗がある人も
多いだろうからね。
これが1600x900ならば138ppiとなるにょ。
この数字は11.6インチWXGAの135ppiとほぼ同レベルであり、「11.6インチWXGAでは文字が
小さすぎて使えない」という人でなければ全く問題がないレベルにょ。
ただし、メモリが4GB固定であることを懸念している人もいるかと思うにょ。
確かにかつてのようにOSの肥大化によって世代が上がるごとに数倍のメモリを要求されていた
頃では「今は十分でもすぐに不足を感じるようになる」という不安があったけどVista→7
→8とOSが最小限必要としているメモリは増加どころか減少傾向にさえあるにょ。
OSでメモリを消費しなくなってもアプリの肥大化は避けられないにょ。
ただし、そのようなハイスペックを要求するのは一部のアプリでありUltrabookでそのような
ものを使う人はほぼ居ないということを考えると4GBで問題はないのではないかと思われるにょ。
ハイスペックな要求をし始めたらメモリだけが不足ではなくCPUパワーの不足やGPUパワーの
不足も感じられるようになるわけだしね。
それにメモリが不足して重くなるのはスワップによるものなので高速なSSDを搭載していれば
そのメモリ不足時でも動作速度が遅く感じられなくなるにょ。
このLaVie Zに搭載しているSSDはREADで最大443MB/sというかなり速いSSDであるため4GBでも
それほど問題はないと思われるにょ。
またメモリの消費電力も無視できないにょ。
近年PCの省電力化が進んでいるもののいくらCPUのアイドル時の消費電力を減らしても限界が
あるからね。
同一世代、同一駆動電圧のメモリならばチップ数に比例した消費電力になるにょ。
つまり、8GBならば4GBの2倍の消費電力になるにょ。
仮に4GBのメモリの平均消費電力が1Wならば8GB搭載したら2Wになるということにょ。
それならば4GBではなく2GBにすればいいということになるけどその場合は0.5Wしか省電力化は
できないにょ。
現状では4GBでは足りるけど2GBでは不足するという場面が多いため2GBではスワップが頻発する
ことになりパフォーマンスの低下が起きてしまうにょ。
高速SSDならばそれを最小限に食い止めることができるけどスワップが頻発してしまうと
省電力の面では逆に不利になってしまうにょ。（フラッシュメモリは書き込みの際に大きな
消費電力を必要としているため）
したがって、2GBならば4GBと比べて省電力とは言い難いにょ。
もちろん、4GBでは足らなくて常時8GB付近のメモリが必要な使い方をしてれば4GBのメモリで
あっても8GBよりも省電力とは限らないけどそれは上記のようにごく一部の用途に限られるため
現在のPCにおける一般的な使い方においては4GBがベストな選択といえるにょ。（もちろん
軽さや消費電力を最重視しない場合は8GBがベターなのは言うまでもないことだけど）
バッテリ駆動時間を見てみると公称8.1時間というのは特に優れてはおらず一般的なUltrabook
とほぼ同レベルにょ。
もちろん、この公称8.1時間というのは極めて限定的な環境下で測定されるJEITA測定法に
よるものであるため一般的な使用とは異なっているにょ。
上記レビューでは5時間44分となっているにょ。
これは公称値の0.71倍となっているにょ。
液晶の明るさを実用レベルにして普通にWeb閲覧を行えば概ね公称値の0.6〜0.7倍になる機種が
多く、0.8倍を越えることは希ということを考えるとこの0.71倍というのはほぼ予想の範疇で
あるといえるにょ。
ヘビーなモバイル用途ならば実効駆動時間で8時間程度は最低欲しいところだけどUltrabook
ということを考えるとそれほどヘビーなモバイルは想定していないだろうし、バッテリ駆動
時間を伸ばすためにはバッテリ重量が多くなるため軽量化を最重視したLaVie Zの場合は実用
レベルの駆動時間を維持してそれ以上は求めなかったと思われるにょ。（Atom搭載のネット
ブックで1kgの軽量なものは筐体の軽量化にはコストをかけておらずバッテリを減らすことで
軽量化しているためバッテリ駆動時間は公称でもAtomにも関わらず4〜6時間のものが多い）
やはり、気になるのは価格だと思うにょ。
Core i5＋SSD128GBの下位モデルで予価13.5万円、Core i7＋SSD256GBのモデルで予価16.5万円
というのは低価格化が進んでいるUltrabookの中ではかなり高価格といえるにょ。
とはいえ、これは2万円相当のOfficeがインストールされているわけだし、このクラスでは
過去に例のないくらいの軽量化をしているというスペシャルな仕様を考えると決して高価では
ないにょ。（直販ならばOffice無しで109830円から購入可能）
Ultrabookの選択肢はたくさんあるのでこの軽さに価値を見いだせないならば何の特徴もない
代わりに安い機種を選べばいいだけの話だしね。
かつては小型軽量が日本の専売特許みたいなものだったけど最近はかなりそれは感じさせなく
なっていたのがこのLaVie Zでそれが復活できた感じにょ。
とはいうものの個人的にはそこまで軽さは重視しておらず、私の場合はフットプリントを重視
しているため13.3インチの段階でモバイル用途ならば選択肢から外れるにょ。
現在使っているLet'snote R5は横幅が229mmだけどこれをワイド液晶で実現するならば8.9
インチくらいでないと難しいにょ。
重さに関して言うと個人的にはモバイルノートは1kg、両手に持って使う端末ならば500g、
片手に持って使う端末ならば300gをボーダーラインに考えているためそれよりも重いもの
ならば徐々に対象から外れてしまうけど軽くてもそこまでは加点対象にはならないにょ。
液晶サイズは8.9インチでいいのでR5並の横幅を維持して実駆動8時間で800gが実現されたら
それが私にとってのベストになるにょ。
ただし、そんな機種はないにょ。
それにもっとも近いのがLet'snote Jくらいにょ。
-
うごメモネタ
先生)今日はう○こ(以下うこ)のフリーズドライ(!?)を作りますよー
A)おえっ
B)なんでやねんwwwwwwww
先生)おめえがうこを屋上から堂々と漏らしてたのが目の前の袋に入ったんだよww
B)はぁwww？証拠見せてみろよwww
TV)
B
--------------
| うこ |
| 女<キャー |
先生)どうだwww
B)いつだよwww
先生)2012/07/05 15時だよwあとこのパンツその時のやろww
B)はぁ？ちげーしwww
先生)DNA検査と指紋認証したしw
B)どんだけやってんだよw
先生)家庭科室にあったんだよw
B)うわwこの学校終わってるなwww
校長)あん？
全員)(うわぁ・・・。)
B)さてはおめぇ、やばくなったから校長呼び出したんだろww雑魚だなwww
先生)そんなん言うならこっち来いやwwwww
B)うわっ！
先生)じゃーねー♪
バコッ
-
(無題)
＞うごメモネタ
ちょっと意味が分からない
-
レスにょ
orirakkusuさんへ
＞うごメモネタ
内容が内容だけに「う○こネタ」と読んでしまったにょ（笑）
ちなみに先生とAくんとBくんのどれがorirakkusuさんにょ？
-
○○ちゃん危機一髪
プチコンの公式サイトにおけるプレゼントとなる追加素材もついに3回目となったにょ。
第2回 http://smileboom.com/special/ptcm2/co_present/html_present02.php
第3回 http://smileboom.com/special/ptcm2/co_present/html_present03.php
第1回の時は6月23日に書いたように「ハカセ射撃」「ハカセジャンプ」を作ったのだけど
第2回の時はフォントというわけですべてのプログラムにそのまま使用できるためあえてその
フォントに差し替えたものというのは別途発表しなかったにょ。
第3回となった今回はBG画面のマップ用素材がメインとなっているにょ。
プチコンには標準で多数のプリセットキャラデータが入っているのだけど標準で入っている
BG用のチップは一般的なRPGで使える中世風ファンタジーや洞窟やSF用に使えるものが入って
いるにょ。
ただし、さまざまなジャンルのものを網羅している関係上特定のゲームを作る場合には
チップの種類がやや不満が多かったにょ。
それに多くのチップが8x8単位となっているため自キャラが16x16であることを考えるとやや
使いづらいというのが難点だったにょ。
ということで、今回発表された追加素材は16x16を基本としており、標準ではやや不足をして
いたフィールドマップ用のものとなっているにょ。
海や山というごく基本的なチップも標準では用意されてなかったからね。
これによって普通のRPGは作りやすくなるし、RPGに限らずフィールド移動のあるゲーム全般に
おいて役に立つのではないかと思われるにょ。
あと、道路や建物なども用意されているため現代をモチーフとしたゲームも作りやすくなって
いるにょ。
さて、今回の追加素材のもう1つの注目点は新キャラ「ダミーちゃん」の追加にょ。
プチコンはキャラが4人もいるのにつぐみさん成分が無かったからね（笑）
といっても、いきなり無関係の女性キャラを登場させるわけにはいかなかったのかAI
（人工知能）という設定になっているにょ。
ダミー（DMMY）の名前の由来は恐らくかつて工画堂スタジオから発売された人工知能搭載の
ギャルゲー「EMMY」が由来だと思われるにょ。
このダミーちゃんについてはMONOistのプチコン虎の穴の第3回を見るといいと思うにょ。
http://monoist.atmarkit.co.jp/mn/articles/1207/04/news001.html
コンソールキャラだけで描かれたダミーちゃんはなかなか秀逸にょ。（PCGで書き換えれば
もっと緻密にできるけどデフォキャラだけで表現というのもある意味重要）
しかし、追加キャラがあっても例のごとくパターン数の少なさを何とかカバーできるような
ゲームを考える必要があるにょ。
というわけで、速攻で作ったのがこの「ダミーちゃん危機一髪」にょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/dmmy_chan.htm
これはタイトルからすぐに想像が付くように「マ○ちゃん危機一髪」をインスパイアした
ゲームとなっているにょ。（伏せ字にする意味がなかったり・・・）
これを作るに至った経緯はこんな感じにょ。
新キャラが追加されているけどいいゲームのネタが思いつかない
↓
葛城コニミル氏がプチコンで作っていたマリちゃん危機一髪の動画を公開（7/5 PM9時半）
↓
マリちゃん風のじゃんけんゲームならばすぐに作れそう
↓
とりあえず完成！（7/6 AM1時半）
ということで、構想から完成まで4時間のゲームにょ（笑）
ステージ構成やゲームシステムを考えたり下記の包丁グラフィックの作成の時間やデバッグの
ためのテストプレイなどがあるから実質3時間弱くらいの制作時間となっているにょ。
開発速度優先プログラムとなっているのでリスト短縮はされてないにょ。
GRPに描画されている「包丁を持った手」のキャラはGPAGE 1にGLINEを使って描画しているにょ。
これはコニミル氏のマリちゃんでもやっているけどかつての8ビット機の時代ではこれはごく
一般的なものだったにょ。
このGLINEの座標は特にツールは使用しておらず脳内で座標展開してそれを直接プチコン上に
数字入力して作っているにょ。
さすがに脳内だけだと誤差があるので部分的に数字を微調整しているもののこれくらいならば
ツールなんて使うまでもないにょ。
座標計算はポケコンでもよく行っていたのでこれくらいならばまだ余裕なんだけどさすがに
顔グラフィックを同じようにやったら微調整しまくりになるのでツール無しだとかなり厳しい
と思われるにょ。
とりあえず、ダミーちゃんのキャラはこのゲームならばパターン数の少なさは問題ないし、
背景には今回用意されたBG画面用素材を使うことにしたのでその点も問題ないにょ。
その素材の使用方法に書いている、水辺、雪原、毒の沼のアイデアもそのまま頂くことに
したにょ（笑）
せっかくなので、前回（第2回）で追加されたフォントも使うことにしたにょ。
やはり、メッセージが多いゲームなのでひらがなフォントが活用できるにょ。（カタカナも
標準のものより見やすい追加素材の方を使うことにした）
ただし、単純にひらがなフォントに置き換えてしまうとカタカナが使えないという問題がある
ため厄介にょ。
カタカナはゲーム内で使用しないキャラコード96（&H60）〜159（&H9F）のキャラを書き換える
ことでひらがな、カタカナの共存が可能になるにょ。（ただしアルファベット小文字は使う
ことができない）
これによって、「ひらがな」「カタカナ」の追加素材データをプチコンに保存していない
場合でもデフォのカタカナ表示によって問題なくゲームをプレイすることも可能になって
いるにょ。（あらかじめカタカナを96〜159に割り当てたリソースを読み込ませて使用する
ゲームの場合はリソース無しでプレイすると文字化けしてプレイができない）
このプログラムではとくにこれといったテクニックは使用していないのでリストを見ても
参考になる部分は少ないのだけどじゃんけん部分について書いておくことにするにょ。
じゃんけんの勝敗判定部分はTipsコーナーの「剰余を使ったリスト短縮」ですでに書いて
いるのでそれを参考にしてもらうとしてここではコンピュータの出す手の決め方について
書いてみるにょ。
多くのじゃんけんゲームはA=RND(3)のように単純に0、1、2の3つの値をとる乱数によって
相手（コンピュータ）の出す手を決めていると思うにょ。
しかし、このゲームでは簡単ながら思考ルーチンを導入しているにょ。
これはプレイヤーの出す手をパターン分析してそれによって次に何を出す確率が高いかを
考えてそれに勝つ手を出すようにしているにょ。
例えばプレイヤーは「バーの後にグーを出すことが多い」ならば、コンピュータはグーに
勝てる「パーの確率を高める」ようにしているにょ。
この方法は、昔、ポケコンで野球拳を作っていたときに考えたものであり、単純ながら
「どうせじゃんけんだから適当に押しても問題ない」ということで適当なプレイをして
いたらコンピュータに勝つのは難しくなるため運の要素が非常に高いじゃんけんゲーム
であるにも関わらず戦略性を高めているにょ。
あと、じゃんけんゲームの場合はグー、チョキ、パーをどのボタンに割り当てるかという
ことも重要になってくるにょ。
タッチパネルを使えば直感的に操作が可能だけどボタン操作の場合はDSのボタンが3つ横に
並んでいるわけではないのでどの配置となっているのか慣れて覚えるか画面を見ながら
そのボタンを押すしかないにょ。
しかし、ボタンを良く見ていったら何となく「B」がグー、「Y」がチョキ、「X」がパー
に見えてきたのでこれは簡単に解決したにょ。
余った「A」ボタンは画面送り用に使えば誤動作防止となるのでボタン配置はこれ以上ない
というものになっていると思うにょ（笑）
このゲームは当初はコンティニュー不可だったので恐ろしく難易度が高いゲームだったため
これではさすがに厳しいと思ってダミーちゃんが死ぬまでは何度でもステージの最初から
やり直せるようにしたにょ。
そうしたらかなり難易度が落ちたにょ。
ただ、twitterで公開したあとに気づいたけどテストプレイを重ねるとさすがにこれでは
簡単すぎる気がしてきたにょ。
理由を考えると野球拳ならばコンピュータが勝ったら服を着る場合が多いため服（＋下着）を
5枚着ているならば5回多く勝つ必要があるにょ。
プレイヤーが10勝ならば負けは5回まで許されるということにょ。
しかし、このゲームにおいては5回負ける前に5回勝てばいいのでそれと比べた場合には
かなり楽になっているにょ。
その辺は急にトライ機能（ステージ最初からやり直し機能）を導入したためバランス調整
不足は否めないにょ。
まぁテストプレイに十分な時間をかけてないからやむを得ないけどね。（普段はテスト
プレイを非常に重要視しているけど今回は開発速度最優先だったので妥協した）
とりあえず、その部分だけはver1.1で必要勝利数を変更してステージ1はプレイヤーは
5勝で勝てるけどステージ2は6勝、ステージ3は7勝必要にしたにょ。（それとver1.1では
刺された変質者の顔グラフィックを変えてなかったのを修正するなどの微修正をしている）
-
(無題)
PRG:OCHADMMYの205-の簡素マニュアルがまちがってる。
205>' ■■タイトル■■
って
205>'■■ダミーチャンキキイッパツ■■
じゃない？
-
(無題)
変質者…
-
レスにょ
orirakkusuさんへ
＞PRG:OCHADMMYの205-の簡素マニュアルがまちがってる。
ちゃんと簡易マニュアルを見てくれていたとは・・・。
テンプレから変えるのを忘れてたにょ（笑）
QRコードを差し替えるついでにデバッグモードを搭載したにょ。
[SELECT]ボタンを押しながら起動するとデバッグモードになり、コンピュータがプレイヤーの
手をどのように分析しているのかが分かるようになるにょ。
表示されている数字は次にプレイヤーが「グー」「チョキ」「パー」のどれを出すのかを予想
した確率となっているにょ。
あと動画も公開したにょ。
http://www.youtube.com/watch?v=09Ne1KZfhOU
名無しさんへ
＞変質者…
実はダミーちゃんを開発したハカセが自分の言うことを聞いてくれないダミーちゃんを
消し去ろうとするといったバックボーンストーリーを考えていたけど面倒くさいから
「ダミーちゃんを狙う変質者でいいや」となってしまったにょ（笑）
-
(無題)
腹減ったからジュース飲んで〜
熱いのも今日でおさらば〜(エアコンがつく
さてHPの整理しなきゃね〜
ああーWindousの機能ネタどうしよう〜
あーうごメモの声投票しなきゃね〜
あーーーー時間がなくなって行く〜
ちゃっちゃん！
ぱちぱちぱち(あ？
-
(無題)
プチコン大好きクラブでスクリーンショット撮影サービスを始めた。
カメラを使わず、SDからGRPとしてPC直接転送するので、公式サイトにあるようなものが撮れる。
それだけ。
-
チャット
http://www.geocities.jp/orirakkusu/chat.html
でけた。
-
レスにょ
orirakkusuさんへ
＞熱いのも今日でおさらば〜(エアコンがつく
私の部屋は扇風機のみにょ。
むしろノートPCが暖房代わりにょ（笑）
デスクトップPCよりはマシだけど3台同時使用しているのでそれなりの熱はあると思うにょ。
＞ああーWindousの機能ネタどうしよう〜
私は試しに作ってから放置状態にょ。
＞チャット
そういえば最近は絵チャしか使ってないので普通のチャットはここ何年も使ってないにょ。
わぁぃ@さんへ
＞プチコン大好きクラブでスクリーンショット撮影サービスを始めた。
確かに「簡易スクリーンショットカメラ」は便利なプログラムだと思うけど色の問題と
表示優先順位問題があるので自動的にキャプチャするのは難しいにょ。
CHKCHRやSPREADではパレット情報を取得できないためGPUTCHRでGRP面に描くのはパレット0に
しているけどこれだとパレット0以外を使用している場合には正常な表示を行うことが
できないにょ。
それを行うためにはキャラ1つ1つに対して手動でパレット情報を設定するしかないけど
そうなると今度はGPUTCHRを使用するとGRPのパレットが書き換わるという問題が発生して
しまうにょ。（その使用するパレットで書き換わる16色を使用していなければ問題ないけど）
次に問題なのは表示優先順位だけど現状のプログラムだと奥から順にGRP/BG/SPとなっている
場合にしか使用できないにょ。
例えば「ダミーちゃん危機一髪」では、奥から順にBG/SP/GRPとなっているため正常に
GRP面にすべて表示するためには一端最初にGRP面に表示しているものを使用していない
GRP面にコピーしてBGキャラをGPUTCHRで描画、SPキャラをGPUTCHRで描画した後に再び
その上に元の面にあったGRPをコピーする必要があるにょ。
これによって、すべてのキャラを正常にGRP面に描きこむ場合には1つのキャラごと手動で
行わないといけない場合が多くあると思うにょ。（現状のプログラムだと16x16以外の
スプライトはそのままでは描画できないし）
これは結構たいへんな作業になると思うので頑張ってにょ。
-
簡易スクリーンショットカメラ
確かにスプライトがものすごく大変。
実際、GGKDSのメモ帳使用時を撮影したとき、カーソルが8×8のスプライトだったので面倒だったのだが、点滅しているのをいいことに写さなかった。
パレットの重複回避はプログラムでできそう。
使用したパレットを記録して、重複しそうになったらパレットを書き換えればいい。
-
(無題)
osもどきの正式名称を決めた
その名も
otyaX!
(何かに名前が似ている気がしなくもない)
あと昔（初代）作ったボタン取得ルーチンが汚かったので書き直した。
-
レスにょ
わぁぃ@さんへ
＞確かにスプライトがものすごく大変。
やはり、スプライトの定義サイズや優先順位や使用パレット番号を取得できる命令がない
というのが辛いにょ。
自動的に処理をすることができないため下手をするとスプライト1つずつプログラムを解析
してサイズやパレットを手動で指定してGRP面に描く必要があるからね。
パレット問題は例えば「JUMPING ISLAND」でスコア表示の文字を本来の赤（パレット13）で
GRP面に描画すれば地面の色（GCOLOR 223）も赤になってしまうにょ。
GCOLOR 223をのパレットを書き換える（本来の緑色にする）と文字の色も赤ではなくなる
という問題が起きてしまうにょ。
したがって、GCOLOR 223以外の色を使って地面を表示してCOLSETでGCOLOR 223と同じ色に
なるようにパレットを書き換える必要があるにょ。
しかし、当たり判定にGSPOITを使っている場合は安易に色を変えられないのでプログラムの
解析も必要になってくるにょ。（JUMPING ISLANDならばGCOLOR 200番台の色ならば問題ない
けど他のプログラムもそうとは限らない）
結局、問題があったらその都度プログラムを書き換えて対応するしかないにょ。
otyakenさんへ
＞osもどきの正式名称を決めた
＞その名も
＞otyaX!
なかなかそれっぽい名前にょ。
私なんて「Petitcom OS」（仮称）だからね。
もしも、続きを作る機会があれば「Ochame」の文字を入れることにするにょ。
-
やっぱり、セルフ開発できないと・・・
私がポケコンにハマったのは「お手軽」かつ「いつでもどこでもプログラミングできる」
というのが大きいにょ。
「お手軽」というのは初心者でも扱い安い高級言語のBASICを搭載しているということや
ハードウェアキーボードを備えているというのが大きいにょ。
「いつでもどこでもプログラミングできる」というのは本体が小型軽量で長時間駆動ができ
そして欠かせないのがスタンドアローンでセルフ開発可能なことにょ。
ポケコンに出会う前にすでにパソコン（当時は「マイコン」と呼んでいた）に触れていた
ために当時は主流だった1行表示（機種によって異なるけど1画面に12〜24文字しか表示
できなかった）のポケコンを見て「これがコンピュータなのか」と思っていた部分もあった
けれど実際に触ってみると「ちゃんと自作プログラムが動く」ということでその不安点は
払拭されたにょ。
当時パソコンが欲しくても買えなかった（PC-8801ならば本体＋モニタで20万円以上していた）
けどポケコンならば安い機種ならば1万円台なので小遣いを数ヶ月分ためれば何とか手が
届く金額であるためポケコンを買うことにしたにょ。
まぁ「ちっちゃいものが好き」というのもかなり影響しているけどね（笑）
ここで難しいのは当時ポケコン界のトップ2であるカシオとシャープのどちらにするのか
ということにょ。
周りに使っているユーザーが多かったのと自由にキャラ表示を行えるシャープの機種に
することにしたにょ。
ただし、予算の関係もあって買えたのはローエンドのPC-1245だったけどね。
このPC-1245はメモリ2.2KB（この2.2KBにはVRAMなどのワークエリアや変数記録専用の領域を
含んでいるため実際にユーザーが使えるのは1486バイト）、12文字表示の液晶ということで
上位機種のPC-1251やPC-1255と比べると見劣りしていたけどメモリと画面サイズ以外は同一で
あるためソフトウェア資産を生かすことが可能にょ。
このPC-12xxシリーズは後継となったPC-1246系を除けばPOKEでVRAMに直接データを書き込む
ことでオリジナルのキャラ表示（グラフィック表示）が可能だったということが上記の
ように私の大きな選択ポイントになったにょ。
ただし、その反面コンソール（文字）のみでゲームを作る場合にはカシオのPB-100シリーズ
と比べて大きく劣っていたにょ。
それは、PB-100系はPRINT CSRで12桁の液晶の自由な位置に（LOCATE表示と同じ）文字表示が
できたけどシャープのPC-12系（126x系を除く）はそれができなかったからね。
それに使用できるキャラ数もPB-100系の方が多く文字だけでゲームを作る場合にはかなり
不利な立場だったにょ。（PC-12系は演算中は文字が消えてしまう仕様であるためそれを
防ぐにはCALL &11E0としてLCDをONの設定にする必要があったけどPOKEやCALLは隠し命令
扱いだったためマニュアルには記載されていない）
それに処理速度の面もPB-100系の方が速かったにょ。
何せPC-1245はFOR〜NEXTの1000回ループで42秒もかかったからね。
これは同じシャープのポケコンでも最近まで現役機種だったPC-E650が1.4秒であるため
30倍の速度差となるにょ。（FOR〜NEXT以外はそこまでの差はないけどそれでも10倍以上
PC-E650より遅かった）
しかし、PC-12系はPB-100系と比べて圧倒的に優れている点はマシン語が使えるという点にょ。
VRAMに直接書き込むことでグラフィック表示が可能になるとはいえ、速度面ではかなり
厳しかったからね。
アクションゲームなんてとても実用レベルという速度は無理で固定画面のゴルフゲーム
とかのそこまで処理速度を要求しないゲームが精一杯だったにょ。
「ポケコンマシン語入門」を片手にハンドアセンブルして簡単なマシン語プログラムを
作ってみたけどマシン語の場合は事前にセーブすることが必要不可欠だったにょ。
当時セーブする媒体といえばカセットテープだったにょ。
部屋の中をあさったらポケコンプログラムをセーブしたカセットテープが見つかったにょ。
http://twitpic.com/a5p4zy
たぶん部屋の中を探せばさらに10本くらいは見つかりそうにょ。
ちなみに新品のカセットテープもあったにょ。
http://twitpic.com/a5p77i
今は無き「パソコン用カセットテープ」にょ。
昔はFDは高価であり、8ビット機の時代はパソコンでもカセットテープによるプログラムの
保存はポピュラーなものだったにょ。
当時のポケコンの記録速度は300bpsであったため2KBのプログラムのセーブやロードに
約1分かかる計算となるにょ。（PC-1245を購入当初はカセットデッキと接続するインター
フェイスを購入する予算が無かったのでプログラムはすべて紙に書き写すという原始的な
方法で保存していたためカセットに記録できるというだけでもかなりの恩恵があった）
PC-1245は1486バイトだったけど次に買ったPC-1401は3534バイト、PC-1350は3070バイトで
あったため1分半〜2分必要だったにょ。
カセットテープの場合は音量などの調整をしないとロード時にエラーが発生することが多く
あるためセーブやロードが頻発するだけではなくアセンブラは非搭載であるため紙に
アセンブラを記述した後にニモニック表を見ながらハンドアセンブルをしなくては開発
できなかったマシン語はポケコンの手軽さを損ねることになったにょ。（脳内でバグ無しの
プログラムを書けてニモニック表を無しで直接入力できる人ならばまた変わってくるだろう
けれど私はマシン語をそのレベルに達することはできなかった）
PC-1245が故障してから次に買ったのは上記のようにPC-1401にょ。
これはPC-1245と同じ12桁表示の液晶だけどCPUのクロックがPC-1245の576KHzから768KHzに
なっているため演算速度の高速化が行われており「高速版PC-1245」として重宝したにょ。
メモリもPC-1245の上位機種のPC-1251と同じ3534バイトだし、購入当時の価格はPC-1251
よりも安かったからね。（ただし、ROMアドレスやフリーエリアのアドレスが異なるため
POKEやCALLを使ったBASICプログラムや絶対ジャンプを使ったマシン語プログラムは作り
変えないと動作しなくなってしまった）
それに、電卓モードが搭載され関数電卓感覚で計算可能になったのは便利にょ。
元々ポケコンはRUNモード（プチコンで言うと実行用モード）とPROGRAMモード（プチコンで
言うと編集用モード）を備えておりRUMモードではプチコンとは異なりPRINT命令を使わなく
ても「2*3[ENTER]で6を表示可能」なものだったので電卓モードが無くても電卓的な使い方は
できていたけどね。
PC-1350を買ってからは画面サイズが大きく（24文字x4行と当時のポケコンの中では最大
クラス）、直接VRAMにPOKEで書き込まなくてもPSETやLINEやGPRINTといったグラフィック用
命令を備えているためBASICでもグラフィカルなゲームを作れるようになったにょ。
また演算速度もPC-1401と同レベルであり、PC-1245と比べれば速いとはいえ、それでも画面
サイズの割にかなり遅かったため100m走のプログラムをBASICで書いたら表示を簡略化しても
9fpsしか出なかったため連射ではなくボタンを押すタイミングを重視したゲームとなったにょ。
そこで重宝したのが「ポケコンマシン語ブック」に掲載されていた「BASICコンパイラ」にょ。
一部互換性のない命令があり、BASICプログラムはそのまますべて使えるというわけではない
もののBASICで普通に作ったものと比べ簡単に10〜30倍程度の速度が得られたにょ。
PC-12系用にも「ポケコンパイラ1251」があったもののPC-1245ではメモリ不足で使えなかった
けれどメモリが標準で3070バイトあるPC-1350ならばコンパイラを使用してもフリーメモリが
1000バイト少々あるため簡単なアクションゲームは十分に作れたにょ。
カセットテープによるセーブ、ロード地獄から逃れられたわけではないけど速度面においては
不満がないレベルになったにょ。
ポケコンはカセットテープにしかプログラムを記録できないというわけではなくオプションで
FDDも用意されていたにょ。
ただし、シャープのポケコン用に用意されたポケットディスクは厳密にはランダムアクセスが
できないクイックディスクと同じ原理の製品であり、片面64KB（両面128KB）の記録容量にょ。
それで、定価が49800円（メディアが10枚で5000円）というのは当時としてもやや高めの価格
設定だったにょ。（あまり売れないオプションだから仕方ないけど）
やはり、プログラムを保存する媒体として重宝したのがメモリーカードにょ。
ただし、今で言うとSDカードのような汎用品ではなくプレステやPS Vitaのメモリーカードの
ような専用品だったにょ。（当時は汎用規格そのものが無かったから当然だけど）
ちなみに私の手元にあるのは8KBと32KBのメモリーカードにょ。
http://twitpic.com/a5pafi
これは8「GB」でも8「MB」でもなく8「KB」にょ。
これで定価が18000円だったからいかに当時とはいえ割高感は否めなかったにょ。
これも大量に売れないオプションであるから仕方ないことだけど・・・。
メモリーカードはPC-1350用のは持っておらず、これはその後継機種PC-1360以降のポケコンで
使えるものにょ。
このメモリーカード（RAMカード）はメインメモリと同じSRAMが使用されているため単なる
外部記録装置ではなく動作用メモリ（メインメモリ）の拡張用にも使えたにょ。（本体メモリを
メインにするかRAMカードをメインにするか、合算したものをメインにするかはMEM$命令で
簡単に設定できるけどこれはプチコンのMEM$とは全く異なるものとなっている）
さて、やはり開発環境が大きく変わったのはPC-E500の登場だと思われるにょ。
PC-E500はPC-8801（初代）に匹敵する演算速度（ただし、表示に関してはPC-88と比べたら
さすがに完敗だった）を持ちポケコンの中では当時最速でありPC-1350と比べると何と5倍以上の
速度だったにょ。（それに標準で32KB、フリーエリアも28600バイトもメモリがあったため
当時としてはすごい大容量だった）
そして、プログラムの高速化を駆使（普通に組んだ場合と比べて2〜5倍速になり、雑誌掲載の
プログラムでも平均3倍速を実証済み）すればPC-1350のBASICコンパイラ以上の速度となった
ためにマシン語を使わなくてもBASICでもそれなりに高速なゲームを作れるようになったにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/basic1.htm
もっともその高速なポケコンもプチコン（ver.1.1）と比べた場合でも60〜100倍くらい遅い
のだけど・・・。
http://ww5.tiki.ne.jp/~ochame/petitcom/what.htm
PC-E500系はPC-1350と互換性があるGRPINT命令によるグラフィックキャラ表示も行えるけど
それは非常に遅いためフォント書き換え（プチコンではBGF0をCHRSETで書き換えるPCGに相当
するもの）がポピュラーなテクニックとして定着したにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/TECH005.HTM
さらに、その「フォント書き換え」を応用したOPASを使えばドット単位の横スクロールゲームも
作れるようになったにょ。（プチコンでいえばPCGを駆使してBG画面によるスクロールのような
ものを実現している感じだけどこれはポケコンのPCGの柔軟性が高いからこそ実現可能になった
機能といえる）
http://ww5.tiki.ne.jp/~ochame/E500/TECH/OPAS.HTM
演算速度は現在唯一の現行生産されているポケコンである「PC-G850VS」と比べて半分くらい
しかないものの上記のフォント書き換えやOPASを使えばゲーム作成においては速度面では有利な
立場に立てるわけだし、RAMカードが使えるし、BTEXT$によってセーブ無しで複数のプログラムの
同時編集が可能になるためお手軽さはポケコンの中でもナンバーワンといっても過言ではない
感じにょ。
PC-E500が経年劣化が原因ボタンが言うことを効かなくなり（それが発端となって接触不良を
招き動作自体しなくなった）、PC-E650に買い換えたけどそのE650も3月27日に書いたように
液晶破損で使えなくなってしまったにょ。
お手軽プログラミング環境といえばやはり最近ハマっているのはプチコンにょ。
プリセットキャラが豊富に用意されているためグラフィカルなゲームも手軽に作れるし
処理速度を考えなくてもよほど重いゲームでない限りは快適な動作が期待できるため
（いくらポケコンの中では速いPC-E500系とはいえ速度を意識して高速になるように
プログラミングしなければならない）ポケコンと比べたらプログラミングのハードルは下に
なる（より簡単にゲームが作れる）かもしれないにょ。
http://ww5.tiki.ne.jp/~ochame/E500/LECTURE/making_3.htm
ソフトウェアキーボードも当初はかなり厳しかったけど慣れれば普通に両手持ちで親指で
高速タイピングも可能だしね（ただし、タイプミスも多いため3DS LLが欲しいところ）
また、いつでもどこでもプログラミング可能かどうかという点に関しては3DSは十分小さい
ので気にならないにょ。
むしろ、ほぼバッテリ残量が気にならないポケコンと異なり、3DSだと4時間くらいで
バッテリ切れになるためその点がやや不満なところにょ。
あと、当初問題だった手軽に公開できないという点に関してはmkIIでQRコードに対応した
ために全く気にならなくなったにょ。（とはいえ、大量のリソースを使ったり、数1000行の
大作プログラムを作るとQRコードを公開する側も読み取る側も大変だけど）
では、プチコンでポケコン（PC-E650）の代わりができるかというと微妙にょ。
それは1つはバッテリ駆動時間の短さもあるし、もう1つは電卓的な活用ができないという
ことにょ。
PC-E650は標準で倍精度演算（有効数字20桁の浮動小数点演算）を備えており、かつBCD演算
であるため非常に演算誤差が少ないため電卓として考えた場合には極めて優秀な存在にょ。
それに対してプチコンは32ビット固定小数点であるため演算誤差が大きくそれがおきにくい
ようにするためにはプログラムも工夫が必要になるにょ。
ゲームを作るならばプチコンの方が絶対的に有利なのだけど向き不向きがあるからね。
しかし、「お手軽」かつ「いつでもどこでもプログラミングできる」という点を満たせる
ものがあればそれも使ってみたいところにょ。
以前、P/ECEでのプログラミング（C言語に関しては、四半世紀前に「はじめてのC」で少し
勉強した程度であり、昨今ポピュラーなC++は未経験）も一時期やったことがあるけどPCで
開発してそれを転送して実機で動作させるというクロス開発は私には向かないと思ったにょ。
やはり、スタンドアローンでセルフ開発できないと駄目ということにょ。
スマホ用アプリでも様々な開発言語アプリが登場しているけど使い勝手のよいものがある
ならばそれも一度試してみたいところにょ。
-
(無題)
otyaXにWindows XPの壁紙を取りこんでみた。
おかげてこっちの方がWindousよりWindowsっぽいw
スクショは日記の方にある。
-
(無題)
スクリーンショットのアイデア思い付いた。
まずグラフィック面を保存
SAVE"GRP"+STR$(I)+"SSGRP"+STR$(I)
次にBGを写して保存
SAVE"GRP:SSBG~
次にスプライトを保存
SAVE~
後はpcで合成
-
(無題)
プチコンばかりじゃなく他のも..
と思ってWii Sports Resortをやったら右肩が痛くなりました。
でもこらずに今日もやりますw
# 有野課長は岩手で無事にパイロットウイングスをクリアしたようです。
-
(無題)
いまさらかもしれないがJUMPING ISLAND攻略中。
-
レスにょ
otyakenさんへ
＞otyaXにWindows XPの壁紙を取りこんでみた。
初代の頃はそういうことができなかったけどmkIIは有志が作ったツールのお陰でPCでデータを
作って簡単に取り込めるようになったからね。
いかにうまく減色するかが鍵にょ。
単純に減色するだけではなくタイルパターンを駆使すればさらに見た目が良くなるにょ。
＞スクリーンショットのアイデア思い付いた。
まぁPCを使えば後の加工はいくらでもできるからね。
とはいっても、どんどんSSから遠ざかっていっている気がするにょ（笑）
ただし、この場合でもスプライトは優先順位を考えてGRPに描かないと正確に再現できないにょ。
一番いいのはPC上で動作するプチコンエミュレータ（プチコンシミュレータ）を作ること
だけどそれはかなり難易度が高いにょ。
orirakkusuさんへ
＞プチコンばかりじゃなく他のも..
＞と思ってWii Sports Resortをやったら右肩が痛くなりました。
私はプチコンを買ってから他のソフトを全然遊んでないにょ。
800円でこれだけ遊べたらコストパフォーマンスは抜群にょ（笑）
＞いまさらかもしれないがJUMPING ISLAND攻略中。
プレイどうもにょ。
難易度は大して高くないので全面クリアは簡単にできると思うにょ。
だからクリア後にいかにスコアを稼げるかがポイントになるにょ。
難しいルート（ロングジャンプを駆使しないと進めないルート）の方がスコア面で有利に
なるためただクリアするだけと比べてハイスコアルートは難易度が格段に上がるにょ。
ぜひ、私のスコアを超えて欲しいにょ。（ステージ1とステージ9の私の記録はリプレイ
データを参照）
-
(無題)
otyaXに抜かれたくない！
が、なんのしようもない。
...どうすればいいんだ俺！
-
otyaX
キーワード作ってみたけど、スクリーンショット多いw
結構アップしていたんだなー
日記に2種類の壁紙の画像貼ってみた。
-
(無題)
PetitEditorを解析してプチコンでプチコンのQRが作れるプログラムつくったらどうかなー
-
(無題)
QRコードを作成するプログラムはあるのでそれのデータをいじるだけでいいかもと思った。
-
レスにょ
orirakkusuさんへ
＞otyaXに抜かれたくない！
＞が、なんのしようもない。
＞...どうすればいいんだ俺！
「草原」を15色に減色してみたので良かったらWindousの壁紙に使ってみてにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/sample/sougen.htm
＞PetitEditorを解析してプチコンでプチコンのQRが作れるプログラムつくったらどうかなー
ファイル関係が弱いプチコンでは難しそうにょ。
作るとしたらまずプログラム本体をGRPに書き出すところから始めないといけないにょ。
これは自動化ができないのでファンクション経由で1行ずつ行わなくてはならないので1000行
くらいのプログラムならばすごく大変な作業にょ。
これができたらようやくQRコード化だけどZIP圧縮しないと枚数が増えるのでZIP圧縮
ルーチンも自作しないといけないにょ。
しかし、2台のDSi（3DS）本体を使って片方でQRコード表示、片方でQRコード読み取りをする
くらいならば2台の本体を直接ファイルのやりとりすればいいだけの話に思えるにょ。
まぁネタプログラムとしてならばありだと思うけどね。
あと誕生日おめでとうにょ。
otyakenさんへ
＞キーワード作ってみたけど、スクリーンショット多いw
こうしてみるとどのように改良してきたかが良く分かるにょ。
＞QRコードを作成するプログラムはあるのでそれのデータをいじるだけでいいかもと思った。
まとめWikiのやつはQRコード生成部分だけなのだけどプログラムそのもののQRコードを本体
のみで作成する場合はQRコード生成の準備をする方が大変にょ。
-
(無題)
みんな、PRGばっかり解析進んでてさ、MEM,GRP,COL,SCU,CHRとかーはさ、なんで解析しないの？
-
(無題)
GRPとかCOLとかCHRとかなら作成ツールある。
SCUとかもあった気がする。
MEMは見たことない
-
(無題)
気分はゲーセン(昨日撮った写真)
http://twimode.jp/p/p/13285_500104d9c7025_1rwK.png
で、翌日3DS+DSiLLの箱の上になぜか置かれ、痛い目に会った太鼓とPSP-1000であった。
ちなみbit.lyやt.coから始まるURLは投稿できないらしい。
-
簡易スクリーンショットカメラ「2SC」
・名前の由来
SCreen Shot Camera
↓
SCSC
↓
2SC
・不具合？
イリガールリソースタイプ が出ました。
原因は分かりません。
-
レスにょ
orirakkusuさんへ
＞みんな、PRGばっかり解析進んでてさ、MEM,GRP,COL,SCU,CHRとかーはさ、なんで解析しないの？
PTCUtilitiesを見てのようにそれらの解析は一通り行われているにょ。
http://micutil.com/ptcutilities/top.html
PRG以外は解析する人（PC間とプチコン間でやりとりするツールを作る人）が少ないように
見えるのはやはり需要の問題だと思うにょ。
プチコン単体の編集機能は貧弱だし、ソフトウェアキーボードも決して使い勝手がいいわけ
ではないからね。
私のようにスタンドアローンによるセルフ開発に拘っている人を除けばPCのテキスト
エディタでコーディングしてプチコンに転送した方が楽に感じるかもしれないにょ。（まぁ
長いプログラムの場合はPCの方が格段に快適に編集ができるといってもQRコードの枚数も
多くなってしまうのが難点だけど）
PRG以外で需要が大きいのはGRPだと思うにょ。
私が知るだけでも3人の人がプチコンとやりとりするためのツールを作っているにょ。
GRPが自由にできればPCで作った画像をそのままプチコンで使用できるというメリットが
あるだけではなくプチコン上でCHRリソースに変換するのは容易だからこれでGRPだけでは
なくBGF、BGU、SPUに対応可能にょ。
COLは上記のGRPでセットで解析されているためそれ単体で解析してツールを作るのは
無意味だし、「フルカラー表示できるわけではない」「液晶の発色の差異」の問題がある
ためPC上で微調整をしてもあまり意味がないというのも理由に挙げられそうにょ。
MEM、SCUに関してはプチコン上で十分手軽に編集できるのでわざわざ解析してそれを
編集するためのツールを作る人が少ないのはやむを得ないにょ。
結局「一通り解析は進んでいる」「各リソースは需要に応じて解析している人数に差が
ある」ということだと思うにょ。
＞気分はゲーセン(昨日撮った写真)
これが誕生日プレゼントでもらった品にょ？
＞ちなみbit.lyやt.coから始まるURLは投稿できないらしい。
恐らくスパム防止のためだと思われるにょ。
otyakenさんへ
＞GRPとかCOLとかCHRとかなら作成ツールある。
＞SCUとかもあった気がする。
＞MEMは見たことない
上記のように一通りのリソース編集機能をもったPTCUtilitiesもMEMリソースの編集機能は
ないからね。
MEMリソース（というかシステム変数MEM$の値）はプチコン上で簡単に編集できるため
わざわざPCで転送して編集するという手間を掛ける必要性はないと思うにょ。
わぁぃ@さんへ
＞・名前の由来
単純にScreen Shot Camera→SSC→2SCかと思ったにょ。
ちなみにわぁぃ@さんは自分用の識別コードは用意してないにょ？
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/qr.htm#r4
プチコンのファイルがフォルダ管理できない関係上ファイル名がダブったりしないために
たくさんのプログラムを作る人は可能な限り識別コードがあった方がいいと思うにょ。
ザウルス用の944BASICでは同じようにフォルダ管理できない関係上、BASICの開発者が
強制的な識別コード制をとっていたのに対してプチコンの場合は各自の自由で問題ないん
だけどね。
＞イリガールリソースタイプ が出ました。
＞原因は分かりません。
何行目でエラーが出たのかが分からないけどリストを見る限りIllegal resource type
エラーになる可能性があるのはバンク指定をしている30行と34行しかないにょ。
30行でエラーが出たのならばCの値は0未満もしくは512以上になっていると思われるし
34行でエラーが出たならばCの値は0未満もしくは1024以上になっていると思われるにょ。
しかし、リストを見る限りではCの値がその範囲外になるとは考えにくいにょ。
考えられるのは特定のプログラムに対応させるためリストを書き換えてその結果エラーと
なってしまったということくらいにょ。（そうなるとその書き換えたリストを見ないと
原因が分からない）
-
(無題)
ポケモ...あ、間違えた、プチコン大好きクラブの日記で長々と語ってみた。
時間があるときにどうぞ。
http://putikonclub.g.hatena.ne.jp/orirakkusu/20120715/
-
識別コード
昨日まとめwikiに”EnglishQuiz”を投稿しました。
とりあえず識別コードを導入しました。
ファイル名の頭に”WA_”をつけることにしました。
-
GGK DreamStar
PNL=(PNL+1)%4
と
PNL=PNL+1
IF PNL>3 THEN PNL=0
を比べると、どっちが速いですかね？
追記
カウンタで計ったところ、上の方が速いようです。お騒がせしました。
-
(無題)
草原、128色版も作ってくれたらいいなぁ〜
ま、やってくれることはないだろうけど！
-
レスにょ
orirakkusuさんへ
＞ポケモ...あ、間違えた、プチコン大好きクラブの日記で長々と語ってみた。
＞時間があるときにどうぞ。
とりあえず読んでみたにょ。
徐々に完成に近づいているみたいにょ。
しかし、たくさんの機能を搭載させるみたいだけどこれを全部実装するのはかなり大変
そうにょ。
MEMEDはそれほど難しくないけど電卓は加減乗除に限定しないと難しいにょ。（四則演算
のみならばプチコンの演算範囲内を越える演算も可能になる）
Excel（表計算）もかなり機能を限定しないと難しいにょ。
Word（ワープロ）やエディタはローマ字かな変換ならばそれほど難しくはないけどこれが
漢字変換となると辞書データだけでも莫大なものになるため区点入力以外は実現するのが
難しいと思われるにょ。
マルチタスクは手動切り替えのマルチタスクならばそれほど難しくはないけどリアルタイム
によるWindowsのようなマルチタスクを実現しようとするならば私がサンプルを作った
「Petitcom OS（仮称）」のようにかなり面倒で問題点が多いにょ。
DOS窓はネタとして作るのならば問題ないけどファイル操作が基本的にかなり制限されている
プチコンで何を行うかが問題にょ。
しかし、（自称）10歳ではなく本当に10歳にょ！？
＞草原、128色版も作ってくれたらいいなぁ〜
とりあえず用意してみたにょ。
http://ww5.tiki.ne.jp/~ochame/petitcom/sample/sougen128.htm
QRは拡大するのが面倒なのでブラウザで拡大してにょ。
わぁぃ@さんへ
＞昨日まとめwikiに”EnglishQuiz”を投稿しました。
無難な作りだけど大文字、小文字関係なく正解になるようにした方がいいかもしれないにょ。
大文字、小文字を厳格に分けたいならば「Monday」は大文字で始まらないといけないにょ。
私も中学、高校の頃にポケコンでこんな感じのプログラムを作って英単語を覚えていたにょ。
紙の単語帳と違ってランダムに出題できるし、合っているかの判定も自動的に行ってくれるし
間違えたところ（間違いやすいところ）を保存してればそれを重点的に出題させることも
できるため紙の単語帳より優れている部分も多いにょ。
＞とりあえず識別コードを導入しました。
＞ファイル名の頭に”WA_”をつけることにしました。
これでわぁぃ@さんが大量にプログラムを発表してもファイル名の重複を気にすることなく
QRコードを読み取れるようになるにょ。
重複した場合にはすでに保存した旧バージョンと判断できるため何も考えず上書き保存を
行えるようになるからね。
これが、識別コードのないファイル名だと上書きして良いのかはその場では判断ができない
ため一端戻って確認するか別名保存する必要があるにょ。
-
(無題)
ここだけの話、本当に10才です。
証拠
http://www.geocities.jp/orirakkusu/gakusei.html
-
(無題)
で、GRP:SOUGEN80を読み込もうとしたら
QRコード読み込み
保存のための空き要領が足りません。
リソース名: GRP
ファイル名: SOUGEN80
←-\
_/ 戻る
なんとか空けたw
-
(無題)
先日、プチコンまとめwikiに「デフォルト216色変換」を投稿してみた。
本当にプチコン本にお世話になったー。
-
HTML5
いじってみた。
http://www.geocities.jp/orirakkusu/plivate/zikken/h5t.html
動作保証:DSiブラウザー、3DS インターネットブラウザー
<input type="range">が面白い。
0-100の値の中を1刻みでアナログに操作できる。
どうやらDSi(と3DSの100%モード)は1dot単位で操作しているらしい。
ということは横102dotあるということでは...
あとできればSS欲しいです。
-
レスにょ
orirakkusuさんへ
＞ここだけの話、本当に10才です
信じることにするにょ。
＞保存のための空き要領が足りません。
プチコンの保存領域はそれほど大きくはないからGRPをたくさん保存したらすぐに一杯に
なってしまうにょ。
＞先日、プチコンまとめwikiに「デフォルト216色変換」を投稿してみた。
これはなかなか便利そうなプログラムにょ。
mkIIはQRコード経由でBMP形式の画像を簡単に本体に転送できるようになったけどGRPで
グラフィック表示を行うプログラムで使用する場合にはデフォのパレットが使えないという
問題があるからね。
このプログラムのようにPCから取り込んだ画像をデフォのパレット用に変換するというのも
1つの解決方法になるにょ。
もっとも、デフォのパレットだと微妙な階調は表示できないのでグラデーションがかかった
画像の場合は単純なベタ塗りになってしまうという問題があるけどね。
ただ、プログラムリストを見て1つ疑問に思ったことがあるにょ。
なぜ、読み込むパレットをGRPではなくSPにしているにょ？
単に1バイト減らすためとか・・・？
＞いじってみた。
見れないにょ。
というか、サイト自体が消えているにょ。
＞あとできればSS欲しいです。
何のSSにょ？
-
プチコンとポケコン
Googleのウェブマスターツールを導入して1ヶ月経ったのでおちゃめくらぶのGoogle経由の
アクセスについて書いてみるにょ。
まずは、クリック回数（実際のアクセス回数）ベスト20のページを書いてみるにょ。
1位 プチコン1画面プログラム ・・・ 15.4％
http://ww5.tiki.ne.jp/~ochame/petitcom/1page.htm
2位 トップページ ・・・ 6.9％
http://ww5.tiki.ne.jp/~ochame/
3位 プチコン講座 第2回 スプライトとBG画面を使おう ・・・ 5.4％
http://ww5.tiki.ne.jp/~ochame/petitcom/p002.htm
4位 プチコンゲーム制作講座 ・・・ 4.6％
http://ww5.tiki.ne.jp/~ochame/petitcom/lecture.htm
5位 プチコン講座 第4回 タッチパネルを使おう ・・・ 3.8％
http://ww5.tiki.ne.jp/~ochame/petitcom/p004.htm
6位 プチコン講座 番外編 プチコンで疑似乱数を作ろう ・・・ 2.7％
http://ww5.tiki.ne.jp/~ochame/petitcom/rnd.htm
7位 プチコン講座 第6回 疑似3Dゲームを作ろう（レースゲーム編） ・・・ 2.7％
http://ww5.tiki.ne.jp/~ochame/petitcom/p006.htm
8位 プチコン講座 第3回 BEEPで音階演奏をしよう ・・・ 2.3％
http://ww5.tiki.ne.jp/~ochame/petitcom/p003.htm
9位 プチコン講座 第1回 コンソールとグラフィックを使おう ・・・ 2.3％
http://ww5.tiki.ne.jp/~ochame/petitcom/p001.htm
10位 プチコンMML ・・・ 2.3％
http://ww5.tiki.ne.jp/~ochame/petitcom/mml.htm
11位 IF文を制する者はBASICを制す PART 1 ・・・ 2.3％
http://ww5.tiki.ne.jp/~ochame/E500/TECH/if1.htm
12位 プチコン講座 第5回 疑似3Dゲームを作ろう（スキーゲーム編） ・・・ 1.7％
http://ww5.tiki.ne.jp/~ochame/petitcom/p005.htm
13位 おちゃめくらぶ ポケコン研究部 ・・・ 1.7％
http://ww5.tiki.ne.jp/~ochame/E500/POCKECOM.HTM
14位 プチコンMML with OSP2 ・・・ 1.2％
http://ww5.tiki.ne.jp/~ochame/petitcom/osp_mml.htm
15位 プチコンTips QRコード使用時の注意 ・・・ 1.2％
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/qr.htm
16位 プチコンTips セーブ機能を付ける方法 ・・・ 1.2％
http://ww5.tiki.ne.jp/~ochame/petitcom/tips/save.htm
17位 プチコン講座 第7回 グラフィック面（GRP）をスクロールさせよう（後編） 1.2％
http://ww5.tiki.ne.jp/~ochame/petitcom/p007_2.htm
18位 私とポケコン ・・・ 1.2％
http://ww5.tiki.ne.jp/~ochame/E500/POCKE1.HTM
19位 G800/E500シリーズＢＥＥＰ音階表 ・・・ 1.2％
http://ww5.tiki.ne.jp/~ochame/E500/TECH/BEEP.HTM
20位 ポケコンBASICによる アクションゲーム制作講座 〜初級編〜 第1回 ・・・ 1.2％
http://ww5.tiki.ne.jp/~ochame/E500/LECTURE/action_b1.htm
この上位ベスト20の合計で総アクセス数の62.5％になるにょ。
以前は需要があるかないかの判断は掲示板やメールでの反応を見たり、数ヶ月おきに適当な
キーワードでぐぐってそれを元に判断していたけどこのウェブマスターツールの導入によって
少なくともGoogle経由の閲覧においてはある程度信頼できるデータを得ることが可能になった
感じにょ。
これを見るとプチコン関係のページが圧倒的に強いことが分かるにょ。
それ以前のメインだったポケコンコンテンツを大きく越えるものであり、1位のプチコン
1画面プログラムにおいては総アクセス数の約1/6となる15.4％に達しているにょ。
これはGoogleの検索において「プチコン 1画面プログラム」なら1位、「プチコン
プログラム」でも5位、「プチコン」単体での検索時でも10位となっていることが大きいにょ。
とはいえ、「プチコン 1画面プログラム」で検索する人はあまりおらず、「プチコン」
単体での検索による表示回数が約半分を占めているということを考えるとプチコンの
コンテンツを求めている人により多く検索された感じにょ。
2位のトップページは省略するとして3位以下はプチコン講座が連続しているにょ。
プチコン講座を読んでくれている人は結構多いということが言えそうにょ。
ポケコン関係はというと第11位の「IF文を制する者はBASICを制す」がトップとなって
いるにょ。
これは「basic if」で検索してたどり着いた人が多いため実際はポケコンコンテンツ目的
ではなくてBASICのプログラミングにおけるIF文の重要性が分かったといえそうにょ。
そうなるとポケコン関係の事実上のトップは13位の「おちゃめくらぶ ポケコン研究部」
ということになるにょ。
私が力を入れているBASIC高速化関係においてはあまり需要がない感じにょ。
http://ww5.tiki.ne.jp/~ochame/E500/TECH/basic1.htm
所詮BASICの高速化は自己満足の域を脱してないということかもしれないにょ。
というか、ポケコンコンテンツ自体が需要が少ないためやむを得ない感じにょ。
今では1日40〜50アクセスあるトップページもプチコン関係のコンテンツを作る前は1日
15〜20アクセスだったからね。
とはいえ、おちゃめくらぶのトップページは全盛時（10年ちょい前）は1日300アクセス
くらいあったためプチコン人気でアクセス数が増えた今と比べても6〜7倍の閲覧数となって
いたにょ。
やっぱり、ポケコン関係の需要低下がかなりアクセス数に影響してそうにょ。
最もメジャーだったポケコンPC-E650も製造が終了して唯一残ったのが学校教育用となる
PC-G850VSだけだからね。
確かに一部ショップで入手可能とはいえ、基本的には学校教育用であるため一般販売は
していないのでポケコンの入手性の低下の影響が大きいにょ。
その点、プチコンならばわずか800円だし、それを動作させるための本体である3DSやDSiは
小中学生を中心にかなり普及しているため動作させる本体を個人的に所有していないから
使えないという問題もないので事実上プチコンの800円の投資だけで使えるようになるのが
大きいにょ。
-
(無題)
多分GRP:SOUGEN80のQRコードが多いのでSSを見てから取り込みたい的な感じ。
-
レスにょ
otyakenさんへ
＞多分GRP:SOUGEN80のQRコードが多いのでSSを見てから取り込みたい的な感じ。
なるほどにょ。
というわけで、sougen128色版のSSも置いておいたにょ。
ついでに比較用として15色版のSSも置いておいたにょ。
こうやって両者を比較すると128色版の方がQRコードの枚数が多いだけあって明確に差がある
というのが分かるにょ。
ただし、orirakkusuさんが作った「デフォルト216色に変換」でデフォパレットで表示した
場合には異なっているにょ。
15色版は変換前とほとんど変わらないのに対して128色版の方は細かい階調が失われて
しまうからね。
ただし、128色版も色数が減ることで変換後は15色版と同じ14枚までQRコードが減るため
好みの問題になりそうにょ。（128色版の変換後はotyaXの壁紙と似た感じだけど元の画質が
いいせいのと減色の方式が異なるためかそれよりも細かく描画されてる感じ）
しかし、orirakkusuさんはサイトも消してどうしたのやら・・・。
-
2012年pixiv上半期報告
私は別HNでpixivに投稿しているのはここで何度も書いた通りにょ。
そして、pixivにおいてランカーを目指しているというのはここで何度かに分けて書いた
「底辺絵師によるpixivランカーへの道」などのpixiv関連の書き込みにおいて詳しく
書いているにょ。
◎底辺絵師のpixivランカーへの道
http://6407.teacup.com/ochame/bbs/2755
◎底辺絵師のpixivランカーへの道 PART2
http://6407.teacup.com/ochame/bbs/2820 （前半）
http://6407.teacup.com/ochame/bbs/2819 （後半）
◎底辺絵師のpixivランカーへの道 PART3
http://6407.teacup.com/ochame/bbs/3066
◎pixivでランキング入りするための条件
http://6407.teacup.com/ochame/bbs/2824
◎pixivでランキング入りするための条件 PART2
http://6407.teacup.com/ochame/bbs/2909
◎pixivでランキング入りするための条件 PART3
http://6407.teacup.com/ochame/bbs/2969
◎pixivにおける閲覧数と評価の関係
http://6407.teacup.com/ochame/bbs/3069
昨年12月30日に「今年のpixiv総まとめ」ということで2011年の年間投稿作品をまとめて
前年、前々年と結果と比較してみたけど今回は、その2012年の上半期報告を書いておこうと
思うにょ。
その前にここ数ヶ月間に起きたpixivのシステム面の変化について書いておくにょ。
主に追加された機能は下記の2つにょ。
(1)グループ機能
(2)オリジナルランキング
(1)グループ機能は3月末に実施が開始されたのだけど簡単に言えばmixiにおけるコミュニティ
みたいな機能にょ。
これはpixivがSNSならばあって当たり前の機能だったのだけど今頃になってようやく開始
されたにょ。
新しいグループはプレミアムのユーザーならば誰でも作ることができるためすでに多くの
グループが存在しているにょ。
私はpixivにはSNS的なものは求めておらず、多くの人に見てもらい私の絵の善し悪しの判断を
してもらえたらいいので今のところどのグループにも入ってないにょ。
中には積極的に意見交換しているようなグループもあるので興味がある人はどんどん入って
みるのも良さそうにょ。
(2)pixivにおけるランキングについては2010年に地域ランキングとRR（ルーキーランキング）、
2011年にはイラスト/漫画ランキングと男女別ランキングが追加されランキングに入るための
ハードルはかなり下がったにょ。
公開ブクマ1つ20点換算で計算した場合にDR（デイリーランキング）は投稿初日において
1400〜2000点程度必要（投稿する曜日や各種補正によって必要な数字は変わってくる）という
ことでかなりハードルは高いのだけどRRは500〜700点くらいで入ることができるためDRよりは
低くなっているにょ。
地域ランキングは「関東」「近畿」といった地域全体ランキングと都道府県別ランキングに
よって構成されているにょ。
ボーダーラインは過密地域と過疎地域では桁違いの差があり、過疎県では本来発表されるべき
50位まで発表されておらず、100点未満でもランキング入り可能となっているにょ。
しかし、地域ランキングは過疎地域はランキングに入りやすいといってもランキングを見る
人自体が少ないわけだし、地域を公開設定していないと反映されないという問題点もあるにょ。
漫画、イラストのランキングは漫画形式の投稿が可能になったため追加されたにょ。
漫画形式はイラストよりも閲覧数が増えやすい傾向があるけどそのため大きなマイナス補正が
加えられておりイラストより評価点で上回っても総合ランキングではイラストよりも低い順位
とになってしまうにょ。
漫画、イラスト別のランキングも総合ランキングとは別に用意されることでその問題点は
改善されたにょ。
これは当初DRのみだったけどRRにも採用されイラストRRならばブクマ込みで400点弱で入る
ことも可能になったにょ。
pixivにおいては現在女性ユーザーが多数を占めていると思われ女性にはウケしない絵を描いて
いる人からは不満の声も大きかったにょ。
昨年10月16日の「pixivでランキング入りするための条件 PART3」で書いたようにこの男女別
ランキングが発表されることで女性ウケするか否かが総合ランキングに大きな影響を与える
ことが分かったからね。
とはいえ、女性主体のランキングを見るのが嫌という層にとっては好意的に受け入れられたの
ではないかと思われるにょ。
男女別ランキングは男女片方に大きな支持がある場合にはR-18ならば100点台でも入ることが
可能（ブクマ込みで200点前後が最低ボーダー）であるためランキング入りのハードルは極めて
低いにょ。（健全ならば男女片方のみに支持されるというのは困難であるため400〜500点は
最低でも必要になっている）
ただし、男女均等に支持があるような作品において男女別ランキングに入るためにはR-18で
ブクマ込みで300〜400点、健全で900点〜1000点必要（これは私が男女両方ギリギリ
ランキング入りしたときの評価を元にした推測値）となっており男女片方に支持されると簡単に
入れるけどそうでない場合はそれなりにハードルは高くなっているにょ。（R-18の方がかなり
低いのは投稿枚数が健全より1桁少ないのに加えて総合ランキングを見ると健全は総合も
男女別もDR500位まで発表されているのに対してR-18は総合が100位までで男女別は300位まで
発表されているためハードルが低くなっている）
このため男女別ランキングがRRより入りやすいかはその人の絵柄やジャンルによって変わって
くると思われるにょ。
この度（といっても2ヶ月前だけど）はこれにオリジナルランキングが加わったにょ。
これはpixivだけに限ったことではないけど人気版権キャラを描いた場合とオリジナルキャラを
描いた場合だと基本的に前者の方が閲覧数において圧倒的に有利になっており、それによって
評価面でも有利に働く場合が多いにょ。
そのためオリジナルはランキングにおいてマイナスではなくプラス補正を行っているものの
それでもその値はわずかだと思われるためあまり影響はないにょ。
オリジナルと版権キャラでは同じ土俵で順位付けするのに無理があるのが分かっていたためか
ニコニコ静画では当初よりオリジナルは創作カテゴリとして版権キャラとは別カテゴリの
投稿となっているにょ。（順位はカテゴリ単位で行うため総合的な順位というものはない）
オリジナルランキングによってオリジナルオンリーで描いている人のランキング入りのための
ハードルはかなり下がったにょ。
ブクマ込みで200点台でランキング入りが可能となっているからね。（評価点のみで200点
あればよほどブクマが少なくない限りランキング入りは可能っぽい）
これは（イラスト/漫画といった細分化カテゴリ化された）RRに入るよりもハードルが低く
男女別ランキングに入るよりもハードルが低いものといえるにょ。
しかし、これは簡単に入れるというわけではなくオリジナルは元々pixivにおいてはは最大の
人気を誇る「東方」タグよりも多くの投稿があり、昨日1日のみで1000枚近い投稿があるにょ。
そのため発表される300位に入るためにはそれなりに高い倍率となっているにょ。（3倍という
わけではなく前日や前々日の繰り越しランキング入りがあるため実質倍率は投稿数のさらに
約3倍となる）
そうなるとそれなりの画力や魅力を兼ね揃えた人でない限りは交流によって閲覧数を増やし
たり、地道に投稿を重ねて被お気に入りを増やさないとランキング入りは難しいにょ。
私は版権キャラオンリーでR-18絵を多く投稿しているため被お気に入りはそれなりにはいる
ため1月29日に書いたように新規アカウントを作り交流無し、宣伝なし、健全、オリジナル、
初投稿でどれくらいの閲覧数や評価が得られるか試したにょ。
その結果は閲覧数240、評価50点、ブクマ3だったにょ。
私の本アカウントの結果は下記にまとめているように1枚評価点だけでも平均700点弱に達して
おり、投稿初日だけでも（オリジナルランキングのボーダーである）200点ならば軽々越える
（ブクマ別で計算して平常で300〜400点、良い時で500点くらい）だけどそれは所詮は版権
キャラ人気、ジャンル人気や被お気に入りの影響ということがこれで良く分かったにょ。
オリジナルは埋もれがちでありタグ検索での伸びも少ないため閲覧も余り伸びずランキングに
入らない限りはなかなか被お気に入りは増えないにょ。
私は普段1枚投稿するごとに被お気に入りは5〜30人増えているけど上記の新規アカウントの
オリジナル絵では1人しか増えなかったからね。
つまり、オリジナルでランキング入りするためには上記のように地道に被お気に入りを
増やす必要があるけどそれはかなり大変なことであることが分かると思うにょ。
これは閲覧者側からしても自分好みのオリジナル絵を描いている投稿者を発掘する場合に
非常に困難であることを意味するにょ。
上位レベルの人だとDRやRRには余裕で入るけど中堅クラス（pixivにおける平均レベルの
画力を持った人）となると発掘はまず無理だからね。
それがこの度のオリジナルランキングの導入で可能になったにょ。
当初はデイリーランキングの中の1項目にすぎなかった「オリジナルランキング」だけど
今ではトップページから直接行けるようになったのも大きいにょ。
ただの1項目だと見る機会はほとんどないけどトップページにサムネ入りで表示されると
桁違いに閲覧の機会が増えるにょ。
これはDRより格下扱いのRR（RRがDRに入れない人のみのランキングであるため）にも
関わらず上位3作品においてはトップページにサムネ表示されている影響で大きく閲覧、
評価が伸びており、DR中〜上位レベルにまで達しているからね。
オリジナルランキングもトップページから直接行けるだけではなくサムネ表示される
ことで注目度が桁違いに高くなったにょ。
今回書いた「グループ機能」「オリジナルランキング」と2月2日に書いた「人気順検索」の
合計3つが今年のpixivの大きな変更点だと思われるにょ。
さて、前置きはこれくらいにして私自身の上半期の投稿はどうだったのかを書いておくにょ。
しかし、実を言うと最近またスランプでしばらく投稿できてなかったりするにょ（笑）
私は昨年12月20日にも書いたように頻繁にスランプ状態になっているにょ。
そのスランプ状態になったら気分転換に別のことを行っているのだけどそれがスランプの
長期化を招いていることも少なくないにょ。
私は基本的に投稿前に駄目と分かっているような絵は投稿前にボツにしてしまうため多少の
波はあるものの評価は上向き状態となっているにょ。
いいか悪いかの事前判断は主観的なものなので投稿してみたら意外に伸びた（伸びなかった）
という場合もあるけどね。
したがって、ボツばかりで完成しない状態になったときスランプ状態になったということに
なるわけにょ。（時間を置いたり他のことをすることで、完成度の高さ＜絵を完成させたい思い
となったときスランプ脱出となるけど必然的にスランプ脱出直後は低評価になりがち）
今年の投稿作品は現時点で10枚に満たないというていたらくぶり（目標は週1枚投稿なので
現時点で30枚の投稿が目標であり、悪くても20枚くらいいきたかった）なのでキリよく10枚の
平均を求めるために年末投稿分を含めて計算することにするにょ。
◎pixivに最近投稿した10枚の1枚当たりの平均値
閲覧数 3421
評価点 693点（評価率2.1％）
ブクマ数 26
被お気に入り増加数 15人
閲覧数においては時間が経てばどんどん増えるためあまり参考にはならないし、R-18だと
閲覧数が増える傾向にあるため単純には比較できないものの昨年と比べると大幅に減っている
感じにょ。（昨年同時期に投稿した作品と比べると1/4くらいに減っている）
それは、やはり昨年上半期はまどマギブーストと閲覧水増しがあったためにょ。
まどマギキャラを描くだけで私の場合はそれまで描いていた版権キャラと比べて閲覧数が5倍、
評価が3倍くらいに跳ね上がったからね。
それに加えて閲覧水増しが2.5〜3倍程度あったため数字を単純比較すれば昨年と比べて減って
いるもののそれを考慮して計算すれば昨年を上回る結果を得られていると言えそうにょ。
評価点数においては最近10枚はどれも500点越えであり最高点は1000点越えということで
かなり安定しているものの1000点越えを連発して2000点越えもいくつもあった昨年上半期と
比べると数字を単純比較したら昨年よりもダウンしているにょ。
これもまどマギというpixiv内で別次元の人気を誇る作品（現在ならば黒子のバスケが相当し
半年前ならばタイバニがそれに相当する）をメインに投稿していたためにょ。
それを考慮して比較するとこれでも昨年を上回る結果と言えるのではないかと思われるにょ。
評価率においては閲覧バグがあった昨年は平均で0.6％程度しかなかったということを考えれば
閲覧バグを考慮しても昨年を上回っていると言えそうにょ。
評価率は投稿直後は被お気に入りによる評価がメインとなるため健全で5〜8％、R-18で3〜5％
という感じだけど数ヶ月経った状態では一見さんがメインとなるため閲覧数が増えても
なかなか評価には繋がらず評価率は時間が経てば経つほど下がる傾向にあるにょ。（この
下がり方が大きいのは私の絵に一見さんに評価させるだけの魅力が備わっていないだけなので
単なる私の実力不足といえるけど海外サイト等にたくさん転載されているためその影響で
閲覧数だけは増えているのかもしれない）
ブクマ数に関しては上記のように別次元の人気であるまどマギキャラの投稿がメインだった
昨年と比べても互角となっているにょ。
作品人気を考慮すれば昨年と比べて大幅な向上が行われているといえそうにょ。
それは被お気に入りの増加量にも現れているにょ。
昨年はRRに入った作品は20人くらい増えたけどそれ以外は1作品平均で5〜6人の増加に止まって
いたのだけど最近10作品においては1作品あたり15人くらいの増加があるからね。
これはイラストDRに入った影響もあるし、技術力向上によって可能になったと思われるにょ。
基本的に被お気に入りは上記のように枚数を重ねれば徐々に増えていくものなので1枚平均で
3人増える人ならば100枚投稿すれば300人増えるにょ。
したがって、何人増えたかではなくどのような割合で増えたかということが重要になって
いるにょ。
ほぼ均等に3人ずつ増えた場合だと単に枚数によって増えた場合と最初の頃は1枚1人だったのが
最後の方では1枚10人増えていき結果として100枚投稿する間に300人増えたとという場合の
2通りの場合を考えるならば同じ「1枚平均3人」という増え方であっても後者のように最近の
方が増え方が大きい方が向上している判断することが可能になるにょ。（前者のように固定的
増え方だといくら被が増えても向上しているかどうかは疑わしい）
またpixivに拘らなくてもお絵かき投稿サイト（お絵かきSNS）はたくさんあるにょ。
私もpixiv、ニコニコ静画、TINAMIを併用しているからね。
私が現在最もランカーに近いのがニコ静にょ。
投稿した絵はほぼ確実にDR100位以内に入っているからね。
最新絵においてはDR（デイリーランキング）12位だったにょ。（これ1枚だけでpixivの
被お気に入りに相当するウォッチリスト人数が一気に100人くらい増えた）
それならばpixivではなくニコ静一本に絞っても問題なさそうだけどそういうわけにも
なかなかいかないにょ。
その理由を書く前に3カ所に私が投稿した最新作品の結果を記しておくにょ。
閲覧数 評価回数 ブクマ数 コメント数
pixiv 2799 64 23 0
ニコ静 19128 無し 248 81
TINAMI 322 5 1 0
※評価回数はTINAMIは「支援数」と表記され1人1票のみとなっているのに対して
pixivは1日1回までなら何度でも入れられる（ニコ静では該当するものは無い）
※ブクマ数はニコ静では「クリップ数」、TINAMIでは「被コレクション」と表記。
最新絵のpixivに投稿分は上記のように最近10枚と比べて閲覧数、評価回数、ブクマ数
ともに平均を下回るものとなっているにょ。
数字だけを見ると良い作品とはいえないけどこれは投稿したジャンルがそれほど人気度が
高い版権ではないためにょ。
したがって、版権人気を考慮すればまずますの数字にょ。
しかし、同じ絵なのにニコ静の場合はpixivと比べて桁違いに良い結果となっているにょ。
とはいえ、pixivとニコ静で数字を単純比較もできないにょ。
そこで、数字を相対比較することにしてみるにょ。
最近10枚の投稿においてはニコ静は平均閲覧数は7736となっており、上記のpixivの平均と
比べて2倍以上となっているにょ。
しかし、それを考慮しても最新絵の閲覧数は多いことが分かるにょ。
ブクマ数を見るとpixivが平均ブクマ数が26なのに対してニコ静では平均ブクマ数
（クリップ数）は95もあるにょ。
これはpixivの3.6倍の数字にょ。
それを考慮しても最新絵のブクマ数は多いことが分かるにょ。
つまり、版権キャラとしてはややマイナー気味だけど結果は大成功といえるものにょ。
TINAMIにおいては閲覧数、評価回数（支援数）ともに少ないけど会員数を考えれば
妥当な数字だと思われるにょ。（実際、他の投稿作品と比べて劣っている数字ではない）
さて、これだけを見るとニコ静はpixivよりもユーザー数が多いからと結論付けできそう
だけどそういう単純なものでもないにょ。
というのもニコ静はウケる絵とウケない絵の差が大きいためにょ。
ニコ静の場合は新着ランキングや毎時ランキングがあり、細かいランキングに入るのは
簡単にできるけどそれによって多くの人の目にとまりそしてウケた場合には上位に入り
続けることになり、それは結果としてDRの上位に入れることを意味するにょ。
つまり、ウケるかウケないかですべてが決まるにょ。
最近10枚の絵を見るとニコ静に投稿したものは最高閲覧数が19128に対して最低閲覧数は
2483となっており、上下差は7.7倍となっているにょ。
ブクマ数（クリップ数）においては最高は248に対して最低が27となっており上下差は
9.1倍あるにょ。
pixivにおいては同様に最高閲覧数が5992、最低閲覧数が2417で上下差2.4倍、最高ブクマ数
46、最低ブクマ数14で上下差3.2倍となっているにょ。
pixivは比較的安定しており、同じ版権作品キャラを描いた場合には同じような閲覧数に
なるのに対してニコ静では絵によって大きなバラツキがあるにょ。
自分の実力がそんなに簡単に変わるわけではないのでそんなに大きなバラツキが出るよう
では自分の実力を客観評価するには難しいにょ。
その点、pixivはいい意味でも悪い意味でも安定しているためジャンル人気や被お気に入り
補正を行えば自分の上達ぶりをある程度客観的に判断することが可能になっているにょ。
この安定は悪い方に考えると多少上達しても評価にプラスになることはないため今回は
良く書けたからいい評価が得られると期待していたら期待はずれだったということにも
なってしまいがちにょ。（多くの場合は主観で良いと感じても他人から見たらそれほど
変わってないというのが原因）
絵の評価となるとTINAMIの方がpixivよりもさらに客観性が高そうだけどいかんせんまだ
ユーザー数が少なくどれか1本に絞るという際にはTINAMI1本に絞ることはあり得ないにょ。
ネットで公開するのは多くの人に見せたいというのがあるからね。
これは絵だけではなく文章においても同じ考えであり、mixiの日記もよほどプライベートな
ものを書かない限りは公開設定を「全体公開」にしているにょ。
現時点のデータからすると多くの人に見せられるのはpixivよりもニコ静となってしまうの
だけど上記のようにニコ静は客観評価の材料としては使えないというのに加えてR-18の
投稿ができないためそれ1本に絞ることはできないにょ。
したがって、どれか1本にするならば必然的にpixivとなってしまうのだけど別にどれか
1本に絞らなくてはならないという理由もないしね。
R-18以外は基本的に同じ物を投稿しているだけなので3カ所に投稿しても対して手間も
かからないし、私は特に交流を行ってないため3カ所に投稿しても負担は全くないにょ。
pixivが投稿年数が一番長いため過去との比較もやりやすいというのもあるためpixivが
よほど廃れない限りはpixivを使い続けると思うにょ。（別にプレミアム会員でもないため
タダで使っているわけだから廃れたらその時考えればいいだけ）
その前にスランプを脱出して投稿をしないといけないにょ。（描いているうちにコレジャ
ナイ感が増してきて完成になかなか至らないため投稿ができないでいる）
今のpixivならば多少マイナー作品だろうと現放送中のアニメ作品キャラを描いてDR入り
できないようならば「普通絵師」とは呼べないにょ。
言い換えれば技術面（線画力、塗り力）、魅力面が普通以上ならばランカーになれると
いうことにょ。（多少技術で劣っていても魅力でカバーは可能であり、地道に被お気に入りを
増やしても可能になるかもしれない）
この辺はオリジナルオンリーだと上記のようにハードルの高さが変わってくるけどやっぱり
自分の好きなキャラを描いてランカーになりたいからね。
いくら今pixiv内で「黒子のバスケ」が大人気といっても私は別に好きではないのでその
キャラを描いて高評価を得たいとは思わないにょ。
普通以上の実力が備われば上記のように超人気作品に頼らなくてもDR入りはできるので
地道に実力アップを図るのが一番にょ。
-
GGK DreamStar速報
つ、ついに漢字変換に成功したぞ！！
記念すべき第一字は漢数字の「一」だ！！
-
(無題)
わあい＠さんが漢字変換に成功したみたいなので連文節変換するプログラムを作ってみた。
そして前作った漢字変換プログラムを思い出した。
http://putikonclub.g.hatena.ne.jp/otyakenrabu/20120405/1333615270
-
レスにょ
わぁぃ＠さんへ
＞ついに漢字変換に成功したぞ！！
＞記念すべき第一字は漢数字の「一」だ！！
ちなみに変換方式は単漢字変換にょ？
熟語変換ならばまともに使えるようにするためには辞書データだけでもかなりの量に
なりそうにょ。
otyakenさんへ
＞わあい＠さんが漢字変換に成功したみたいなので連文節変換するプログラムを作ってみた。
連文節変換となると文節を識別しなくてはならないのでただの文節変換よりもさらに
ハードルが高くなるにょ。
実用レベルにするためには一体どれだけの辞書サイズになることやら・・・。
ポケコンでも自前のフォントを用意して日本語変換システムを作った人がいるけどそれ
だけで数100KBのデータ量になっているにょ。
フロントエンドの部分さえできればあとは辞書データを増やすだけとはいえ、実用レベルに
するためには万単位の辞書登録が必要になるため私はとても作る気が起きないにょ（笑）
-
GGK DreamStar
昨日、漢字変換成功の報告を入れたけど、今日は辞書を追加してみたにゅ。
しかし、厄介なのは同じ読みの漢字が複数あることにゅ。
まあそれは、配列の次元数を増やせばどうにかなるにゅ。
ただ、処理速度がキーボード切り替えで60fpsを切るくらいだから、辞書の端から端まで検索したら確実に処理落ちするにゅ。
ここは、いかに絞り込みを行うかが重要にゅ。
最後に書くのもなんだけど、単漢字変換にゅ。
-
アイコン
アイコンに某OSっぽいのを表示してみた。
http://cdn-ak.f.st-hatena.com/images/fotolife/o/otyakenrabu/20120720/20120720215622.png
-
レスにょ
わぁぃ@さんへ
＞しかし、厄介なのは同じ読みの漢字が複数あることにゅ。
＞まあそれは、配列の次元数を増やせばどうにかなるにゅ。
単漢字変換ならば必要な辞書のサイズもそれほど大きくはならないので地道に登録して
いけば十分に完成しそうにょ。
＞ただ、処理速度がキーボード切り替えで60fpsを切るくらいだから、辞書の端から端まで検索したら確実に処理落ちするにゅ。
検索速度に関しては辞書をテーブル化しておけば何とかなりそうにょ。
処理落ちするというのは変換候補を画面にたくさん表示しているせいにょ？
一度に表示する候補数を減らすか、多少の処理落ちは諦めるしかなさそうにょ。
otyakenさんへ
＞アイコンに某OSっぽいのを表示してみた。
IMEの名前は「OTY-IME」に決定にょ？
連文節変換が本当に実用レベルでできるようになるのか楽しみにしてるにょ。
辞書サイズだけでQRコードの枚数はとんでもないことになりそうだけど・・・。
-
処理落ちの件
原因は
FOR I=0 TO HMAX
IF WORD$==HWD$(I) THEN BGPUT(後略)
NEXT
つまり、FOR地獄だから
-
いらだち
ACLSにCOLINIT相当の機能はいらないにょ！！
-
(無題)
ACLSにVISIBLEみたいな機能が付いたら便利かも
-
ACLSの案
ACLSは画面の初期化に限定して
全キャラ、カラーを初期化する命令(AINITとか？)を作るのはどうかな？
-
レスにょ
わぁぃ@さんへ
＞つまり、FOR地獄だから
そうなると処理落ちを無くすにはループ回数を減らすしかなさそうにょ。
＞ACLSにCOLINIT相当の機能はいらないにょ
確かにこれがあるせいでパレット書き換えをしたらACLSは事実上使えなくなってしまうにょ。
＞ACLSは画面の初期化に限定して
＞全キャラ、カラーを初期化する命令(AINITとか？)を作るのはどうかな？
互換性を重視するならばACLSはそのまま残してパレット関係以外を初期化する命令を
追加する方が良さそうにょ。
otyakenさんへ
＞ACLSにVISIBLEみたいな機能が付いたら便利かも
それがベストかもしれないにょ。
何を初期化するのかユーザーで選べて引数をすべて省略してACLSと表記した際には
現在のようにすべて初期化というのがいいにょ。
-
(無題)
@L
GOSUB@1
GOTO@L
@1
FOR I=I2 TO I2+50
IF ...
NEXT
I2=I+1
RETURN
みたいな処理を思い付いた
実現出来るかは知らない
-
(無題)
お風呂で思いついたダジャレ
「確か、はしかは、シカトする、歯科で治せない」
分かりにくいので「、」で区切った。
-
レスにょ
otyakenさんへ
＞みたいな処理を思い付いた
＞実現出来るかは知らない
これだけでは何の処理かは分からないけどIMEで使おうとしている処理にょ？
わぁぃ@さんへ
＞お風呂で思いついたダジャレ
これを一発変換できるIMEをプチコンで作ったら神レベルにょ（笑）
ちなみにATOKでも自分で文節設定を行わない限りは一発変換はできなかったにょ。
-
(無題)
有名なもの
貴社の記者が汽車で帰社して喜捨した
とか
酢桃も桃も桃のうち
MS O IME2012では
確かはしかはシカトする歯科では直せない
そこかw
-
(無題)
昔作った意味不明な何か
ノートに書いてたようなと思ってあさくったら見つかった
悟飯のいる五班でご飯を食べる
墨と炭を隅にこぼした
端にある橋に箸をおく
皮いいやっぱ皮いい皮も可愛い
医師の意志で石投げる
串で櫛(髪の毛を解くくし)を作ろうとして苦死する
虫蒸し無視
家うちウチ悲しむ
都市のトシ歳
-
レスにょ
otyakenさんへ
＞有名なもの
＞貴社の記者が汽車で帰社して喜捨した
＞とか
＞酢桃も桃も桃のうち
これくらいならばATOKで一発変換可能にょ。
＞昔作った意味不明な何か
＞ノートに書いてたようなと思ってあさくったら見つかった
さすがにこれらは一発変換は厳しいにょ。
というか、一体なんのために考えたにょ？（笑）
-
キヤノン初のミラーレス「EOS M」のライバルは・・・？
キヤノンがミラーレスカメラ「EOS M」を発表したにょ。
http://dc.watch.impress.co.jp/docs/news/20120723_548287.html
APS-Cセンサーを搭載ということで他社においてライバルとなるのはNEX-5Nあたりになるの
ではないかと思われるにょ。
あと、センサーサイズの違いがあるとはいえ、他社のモデルとも比較してみたにょ。
EOS M NEX-5N Nikon 1 J1 GF5
センサー APS-C APS-C 1インチ 4/3インチ
AF方式 ハイブリッド コントラストAF 位相差検出AF コントラストAF
フラッシュ 外付け 外付け 外付け 内蔵
EVF 無し 外付け 無し 外付け
本体サイズ 108.6x66.5x32.3 110.8x58.8x38.2 106x61x29.8 107.7x66.6x36.8
本体重量 298g 269g 277g 267g
標準ズーム全長 61mm 60mm 42mm 26.8mm
重量 210g 194g 115g 95g
本体＋標準ズーム重量 508g 463g 392g 362g
※本体重量にはメディア、バッテリを含む
この表において本体サイズはグリップ部を含んだ厚みとなっているため本体そのものの
厚みを示すわけではなく平坦な造りのEOS Mは概ねNEX-5Nと同レベルといえるにょ。
高さにおいては7.7mmの差ということで2台を並べておいたらEOS Mの方がやや大きく見える
のではないかと思われるにょ。
それでも、APS-Cセンサー搭載機としてはかなりコンパクトサイズといえるにょ。
また重量もメディア、バッテリ込みで300gを切っており、APS-Cセンサーを搭載、同社初の
ミラーレスということを考慮すれば軽量といえるにょ。
本体サイズ、重量はセンサーの小さな機種（J1、GF5）と比べて極端に大きなものにはなって
いないけどここで何度も書いているようにレンズの方はそうはいかないにょ。
標準ズームの重量は同社の一眼レフ用のものよりも小型軽量とはいえセンサーサイズなりの
重量となっているため実際の使用時に小型軽量を求めるという人においてベストチョイスに
なるとは言い難いにょ。
もっとも、これは標準ズームを使用時であってパンケーキレンズならばその差はさらに
縮まるとはいえ、逆にいえば望遠レンズを使用時にはさらに差が広がることを意味するにょ。
これは本体の小型軽量化と比べてレンズの小型軽量化は極めて困難だからにょ。
本体の薄型化は主にフランジバックで左右されるのだけどEOS MのフランジバックはNEXの
Eマウントと同レベルの18mmとなっており、センサーサイズの割にはかなり短くなっている
ことが有利に働いているにょ。
ミラーレスの中では大きなAPS-Cセンサーを搭載ということで、画質面においては有利な
ものになっているにょ。
同世代のセンサーならば画素数ではなくセンサーサイズが画質を決める最も大きな要素に
なるからね。
EOS MのセンサーはEOS KissX6iと同等のセンサーと思われるため画質面においてほぼ同等で
あると思われ高感度画質も極めて良好なものになっていると予想できるにょ。
とはいえ、高画素が無意味というわけではなく十分な明るさがあり、その画素ピッチで
十分に解像できるレンズを装着時には解像面で有利に働くにょ。
しかし、センサーサイズの割に画素数が多くなってしまうと解像しないレンズも出てくる
ため標準ズームで完結する初心者ユーザーには適したものになるとは言い難いし（新規の
マウントの場合だとレンズの選択肢がない場合もある）フランジバックが短くなると
テレセン性の問題が出てくるため周辺画質において不利になってしまうにょ。
そのためEOS MのセンサーがEOS KissX6iと同等だとしてもレンズの違いやフランジバックの
違いがあるため同等の画質を得られるという保証はなくそのEOS Mマウント用のレンズを
使用時のレビューを待つ必要があるにょ。
AFに関してはやはり像面位相差検出方式を採用したセンサーを搭載しているという点が
大きいにょ。
これは6月9日に書いたようにEOS KissX6iではライブビューや動画撮影時に非常に大きな
効果を発揮しているにょ。
元々キヤノンのデジカメはコントラストAFが遅いためライブビューでは他社と比べて
かなり劣っていたからね。
位相差検出方式ならば業界トップのキヤノンもAFの遅さがアキレス腱となってしまい
常にライブビューでの撮影となるミラーレスならば像面位相差検出方式は必要不可欠と
思われていたためEOS KissX6iで像面位相差検出センサーが採用された時点でキヤノンの
ミラーレスはこのセンサーを使うであろうことがほぼ予想できたにょ。
とはいえ、現在のセンサーはピント精度が低いため位相差検出方式で素早くおおざっぱに
ピントを合わせた後にコントラストAFで微調整を行うというハイブリッド方式になっている
ため位相差検出方式のみのNikon 1と比べるとAF速度では劣っているにょ。
この辺は将来の改善に期待したいところにょ。
EOS Mの登場で国内大手メーカー全社からミラーレスが出そろったにょ。
これによって従来よりもさらに競争の激化が予想されると同時にミラーレス市場の拡大も
期待できそうにょ。
ミラーレスは基本的にコンデジでは物足りないという層がメインとなっているにょ。
従来だとそういう層は一眼レフだったのだけどやはり一眼レフだと大きく重いというのが
難点だったからね。
それでも2000年代後半になってデジタル一眼の低価格化によってデジタル一眼は大幅に
シェアを拡大していったにょ。
これは銀塩カメラとは異なりデジカメは身近なものとなったことで潜在的需要が拡大された
というのが主な理由だと思われるにょ。
しかし、いくらデジタル一眼の低価格化が進んでもサイズや重量の問題もあるため普及には
限界があるにょ。（構造が複雑であるため低価格化も限界まできているし）
そうなると小型化しやすく構造がシンプルであるためデジタル一眼と比べて低コスト化も
可能なミラーレスが各社から登場したのは自然な流れだと思われるにょ。
ここで重要なのが各社のミラーレスの位置づけにょ。
現在一眼レフを作っていないPanasonicやFujifilmは単にコンデジより上の存在ということで
問題ないのだけど現在一眼レフを作っているメーカーの場合は立ち位置が微妙なものになって
しまうにょ。
ニコンはコンデジと一眼レフの中間に位置するものとして提示しているにょ。
そのためセンサーサイズは1インチに止めたにょ。
あくまで一眼レフの領域までは浸食しないようにするためにょ。
しかし、APS-Cセンサーを搭載した場合はそうもいかなくなるにょ。
APS-Cセンサーを搭載したNEXの場合はその立ち位置はかなり微妙なものになっているからね。
それはαシリーズがTLM（トランスルーセントミラー）を採用しているというのも大きいにょ。
現行のαシリーズはすべてこのTLMが採用されているのだけどこれは一眼レフの形状であり
ながらEVF専用で搭載しているミラーは位相差検出センサー専用となっているにょ。
つまり、像面位相差検出方式センサーを搭載すればこの一眼レフスタイルにする意味は全く
無くなるということにょ。（像面位相差検出方式は現状では専用センサーを使った位相差
検出方式と比べて速度面や精度面では劣っているからすぐに置き換わるわけではないと思う）
そうなると近い将来はαシリーズは終了してNEXシリーズがメインになるということは十分に
考えられるにょ。
とはいえ、現在のEマウントのレンズラインナップを考えるとまだまだα終了までには時間が
かかりそうにょ。（フルサイズセンサー搭載のα99の登場も予想されているしね）
それではキヤノンの場合はどうなのかを考えてみるにょ。
キヤノンのデジタル一眼はプロからの支持も厚くそれが終了するなんてことは少なくとも
今後10年そこらの間では100％あり得ないにょ。
ただし、デジタル一眼がフルサイズメインになるということは十分に考えられるにょ。
キヤノンだけではなくニコンもフルサイズ機のラインナップを拡大していく予定としているの
だけどそこ根底にあるのがAPS-Cセンサー搭載機の縮小にょ。
真っ先に切り捨てられるとなるとやはり廉価モデルとなるEOS Kissシリーズにょ。
APS-Cセンサーを搭載のミラーレス「EOS M」の登場によってKissのユーザー層がかなり
奪われてしまうと思われるからね。
つまり、EOS Mの一番のライバルはNEXではなくてKissといえそうにょ。
ユーザーの多くがレンズキットを買って終了するであろうKissならば現状でEOS M用レンズの
ラインナップが乏しいというのもそれほどネックにはならないにょ。（コントラストAFで
あるため当初の変換アダプタでは従来のα用レンズはAFが実用的な速度で動かなかったNEX
とは異なり、像面位相差検出方式のEOS MならばすべてのEOS用レンズがそれなりの速度で
AFが可能になると思われるためレンズ資産のある人にとっても有用）
オプションでもEVFがないという問題は一眼レフのサブとして使う人にはネックとなる
けれどコンデジからのステップアップの人にとってはそれほど大きな問題ではないにょ。
とはいえ、ユーザー層を拡大していくためには今後のレンズラインナップの充実は欠かす
ことはできないし、オプションとしてEVFの用意やEVF内蔵モデルを用意する必要性もある
のではないかと思うにょ。
-
GGK DS
辞書データの形式を変えてみた。
従来
DATA 1,32
現在
DATA 1,”ﾆ”
これにより可読性が向上した。(「が」のように濁点が一体になった文字があるので、一部例外あり、例”げつ”→リスト上は”▲つ”)
-
(無題)
形式って
DATA 漢字コード,読み方
?
-
>>otyakenさん
従来
DATA 漢字コード,読みの文字コード,終了符(-1)
読みが2字ならバラメータは4つ(漢字1字+読み2字+終了符1字)
現在
DATA 漢字コード,読み文字列
|
|
掲示板管理者へ連絡
無料レンタル掲示板
