レス数が1スレッドの最大レス数(1000件)を超えています。残念ながら投稿することができません。
おちゃめくらぶ掲示板
現在大阪オフ中にょ
現在大阪オフにょ。
昼食を12時に済ませ現在3時のおやつ休憩にょ。
昼ご飯を食べてから現在までいろいろ買い物をしたけどもう3万円くらい使っているにょ。
めぼしいものは大体買えたけどそろそろ資金が尽きるにょ。
マリモーマさんへ
>今日は 大阪オフだけど 関西は 雨が降ってたよ
さっきは結構降っていたにょ。
また詳しくは明日書くにょ。
AU光を 検討中
今日は 2ちゃんねる どころか 実況難民も落ちてる
実況難民
http://kita.jikkyo.org/lnanmin/
実況難民板も死んでない?
http://ex14.vip2ch.com/test/read.cgi/part4vip/1420816341/
http://liv0.com
(無題)
時間が掛かる繰り返し処理のとき、
処理の進行度合いは見たいが頻繁にコンソールに表示すると重いので
観察用の簡易プログレス表示を間引いて表示するために、今まで
FOR I=0 TO 99999
IF I MOD 100==0 THEN PRINT I
とかやってたけど、
MODと==と演算を2つもしてるのってどうなの重いんじゃないのとか
なんとなくしっくりこなかったんだけど、
今回、こんな方法を思いついて
PF=0
FOR I=0 TO 99999
IF I>PF THEN PRINT I:INC PF,100
演算が1つに減って、しかも1文字だけの演算子で。
なんだかスッキリ書けたような気がしてます。
実際にどっちが早いかって? こまけぇこたぁいいんだよ!
new3DSのブラウザは、
勝手に文字が超ちっちゃくゴマ粒になって
拡大ボタンも押せないサイトがあって
あの時は困惑しました。
CSSとかで画面の横幅を設定してて
強制的に画面内に全幅を表示するような動作になったのが原因っぽいです
ブラウザの解釈が悪いのかサイトの書き方が悪いのかは知りません
でも、どんな時でも拡大ボタンを無効化すんなよとは思った。
(ちなみにモバイル版ページをリクエストしても変わらなかった
レスにょ
マリモーマさんへ
>AU光を 検討中
ケータイがauならばauひかりはコストパフォーマンスはかなり高いにょ。
理論値1Gbpsの回線といってもPCがGbEに対応していて1000BASE-Tケーブルを使わないとその
本領は発揮できないにょ。(マリモーマさんのPCのマザーボードP7P55D-EはGbEに対応して
いるのでケーブルさえ買い換えれば問題ない)
あとMTU、RWINもauひかりにあった設定にする必要があるにょ。
最適な設定の情報は検索すれば出てくると思うにょ。
XPはデフォルト設定だと1Gbpsの回線なんて考慮されてないからね(XPが発売当時は1Mbps
程度のADSLがやっと普及しはじめた程度なのでデフォルト設定だと100Mbpsの光回線でも
その実力を発揮できない)
チラシ裏次郎さんへ
>実際にどっちが早いかって? こまけぇこたぁいいんだよ!
私が測ってみたところ後者の方が1割くらい速くなっているにょ。
100回に1回進行状況を表示するだけならばIF文は不要なのでそれよりも速くすることが
できるにょ。
FOR I=0 TO 99900 STEP 100
PRINT I
FOR J=0 TO 99
(処理)
NEXT
NEXT
これはポケコン講座の「E500BASIC高速化のすべて」で書いているにょ。
http://ochameclub.web.fc2.com/E500/TECH/basic6.htm
この講座は私が長年培ってきて誰にも負けない自信がある高速化テクニックを集めたもので
プチコンでも活用できる部分は多くあるにょ。
まぁプチコン3号ならばアホみたいに重い処理をしない限りはNew 3DSで動作させれば簡単に
60fpsのゲームを作れるためあまり高速化については考える必要はないんだけどね。
>new3DSのブラウザは、
>勝手に文字が超ちっちゃくゴマ粒になって
>拡大ボタンも押せないサイトがあって
>あの時は困惑しました。
3DSの画面解像度は横幅400pixelしかないので拡大表示ができないのならば横幅400pixel程度に
抑えたサイトでないと読みにくくなるにょ。(下画面が320pixelなので320pixelがベター)
PC向けだと推奨環境XGA以上だろうから2〜3倍に拡大しないと文字を読むことさえ困難になって
しまいそうにょ(笑)
>CSSとかで画面の横幅を設定してて
>強制的に画面内に全幅を表示するような動作になったのが原因っぽいです
CSSはWebブラウザがちゃんと解釈してくれたら環境依存しない閲覧が可能とはいえ閲覧する
ハードウェアには画面解像度や精細度において大きな違いがあるためCSSで環境を固定化して
しまうとかえって読みにくくなる場合もあるからね。(推奨環境以外では読みにくくなる)
その点おちゃめくらぶはそういう余分なことを一切してないため3DSで閲覧するときは(Web
ブラウザの仕様で980pixel相当でレンダリングされているため)ブラウザで自分が読みやすい
ように拡大すればいいし、(PCで閲覧時は)ウインドゥサイズを調整して表示してやれば全く
問題ないにょ。
解像度指定されてないサイトで980pixel相当にレンダリングするのは3DSに限ったことでは
なくスマホでも同じにょ。(1280x720のHD液晶を搭載のスマホで縦表示でおちゃめくらぶを
閲覧した際には73%くらいに縮小されるけどこれくらいならば普通に読むことができる)
980pixelでレンダリングすれば現在主流のXGA必須のサイトの画面横幅に合わせて表示可能にょ。
これがCSSで横幅1280pixelでサイズ指定していてる場合はスマホでも読みにくいしPCで
読む場合にもWXGAの小さな画面でウインドゥ表示しているとWebブラウザでは縮小表示を
しない限りは横スクロールを頻繁に行わないと読めなくなってしまい非常に読みにくい
サイトになってしまうにょ。(縮小表示をしても文字が潰れて読みにくくなる)
その点、おちゃめくらぶならば横幅640pixelあれば横スクロールは一切無しで閲覧が可能に
なるにょ。(WXGAの狭い画面でも横に2つ並べて表示が可能!)
>(ちなみにモバイル版ページをリクエストしても変わらなかった
サイトがモバイル対応になってない限りは変わらないにょ。
ちなみにおちゃめくらぶのトップページを3DSで縮小表示せずに表示できるように試しに
作ってみたにょ。(PCで見たら画像が小さくなっただけの違いしかない)
http://ochameclub.web.fc2.com/test.htm
スマホで閲覧時も文字が約3倍拡大されるにょ。
画面の横幅を320pixelに指定して画像サイズも320pixelにした以外は何も変更してないにょ。
横幅一杯に表示してなおかつ文字が読みやすい大きさになっているけどこれでおちゃめ
くらぶのコンテンツを表示したらかえって読みにくくなるにょ。
3DSの画面解像度に特化したらスマホだと1画面の情報量が少なすぎてしまうしね。
モバイル版といってもモバイル端末の環境なんてピンからキリまであるのでどこに合わせる
のかというのがネックとなるため結局は推奨環境以外では読みやすくなるかは微妙にょ。
これでプチコン3号によるボタン入力判定はほぼ完璧!
プチコン3号入門講座を更新したにょ。
ボタンやスライドパッドでキャラを動かしてみよう
http://ochameclub.web.fc2.com/petitcom3/lecture/button.htm
論理式で深まる条件判断
http://ochameclub.web.fc2.com/petitcom3/lecture/logic.htm
BUTTON関数はプチコン3号で初めてプログラミングに挑戦する初心者にとっては鬼門となって
いるにょ。
それは使うためにはビット演算が必要不可欠になるためにょ。
ビット演算を理解するには2進数に対する理解が必要であり、そうなると必然的に使うための
ハードルが高くなるにょ。
ただし、これは理解するためには必要不可欠であるけどボタン入力判定のプログラミングに
おいて必ずしも必要かというとそうではないにょ。
というのもある程度ブラックボックス化しておけば10進数でいくらでも説明ができるからにょ。
例えばAボタンとBボタンを両方押している時のBUTTON関数の値は48になるにょ。
これはAボタン(000000010000)とBボタン(000000100000)のORを計算し000000110000 と
いう結果を求めそれを10進数に直して48とする必要はなくAボタンが16、Bボタンが32だから
合わせて48という説明で十分に理解できるにょ。(なぜ、16、32にするかというのはどの
ボタンを押したかを合計の数値から逆算するためにはそうしなければならないという説明で
十分)
これならば10進数で説明するだけで同時ボタン入力の判定も簡単にできるけど問題は十字
ボタンを押しながらAボタンを入力するなどの判定にょ。
これはB AND 16などの計算が出てくるためビット演算を理解していないと難しいにょ。
ただし、これもANDをブラックボックス化してやればいくらでも説明ができるにょ。
それがこの入門講座の本文で書いている内容にょ。
IF B==16 THEN 〜 でAボタンが押されているかが判定できる
↓
IF B==48 THEN 〜 でA、Bボタンが両方押されているかが判定できる
↓
IF (B AND 16)==16 THEN 〜 で他のボタンに影響されずAボタンが押されているかが判定できる
↓
IF (B AND 48)==48 THEN 〜 で影響されずA、Bボタンが両方押されているかが判定できる
※変数BにBUTTON関数の値が入っている場合
正しく判定するのが難しいA、Bボタンを両方押した場合の判定もこの単純なステップアップで
初心者でも容易に理解が可能になるにょ。
意味も分からず「B AND 16」でAボタンの判定が可能になると覚えておいた場合には
IF (B AND 16) AND (B AND 32) THEN 〜でA、Bボタンを両方押されたかどうかの判定をして
しまいがちだけどこれは正しくないことは明らかにょ。
しかし、私の講座を応用すれば初心者であってもあらゆるボタン入力判定がいとも簡単に
できてしまうにょ。
あと難しいのがVSYNC 1(60fps)以外でのボタン入力判定にょ。
BUTTON(2)相当のものを作るにはビット演算の知識が不可欠にょ。
もちろん、NOT A AND Bをブラックボックスとして活用するのもありだけどこれは初心者で
あっても「前回押してなくて今回押したボタン」というだけでそれと同等のものを作る
ことが可能になるにょ。
Aボタンの押された瞬間の判定はIF (A AND 16)!=16 AND (B AND 16)==16 THEN 〜でいい
わけだからね。(変数Aには前回のBUTTON関数の値が入っている場合)
では、IF B AND 16 THEN 〜って何なのかというのが論理式を使った講座にょ。
IF文においてはTHEN以下が実行されるかは「0以外」か「0」かで判定されるわけだけど
それには論理式の知識が必要不可欠にょ。
式が成立した時は1、不成立の時は0の値を取ることさえわかればなぜ条件成立時にTHEN
以下が実行されるかが分かるし、ANDやORで複数の条件式を判定する場合の動作の仕組みも
理解できるようになるにょ。
そして、問題となるのが比較演算を省略すると判定がうまくできない場合があるという
ことにょ。
つまり、IF B AND 16 THEN 〜のような書き方は本来はIF (B AND 16)==16 THEN 〜となる
けれど「==16」をこの時は省略可能な場合であるということを理解して初めて書けるという
わけにょ。
「Aボタンを押している」かつ「Bボタンを押している」という判定を行うならばプチコン3号
から加わった論理演算子&&や||を使うのが簡単にょ。
これならばIF A ANF 16 && B AND 16 THEN 〜で可能だからね。
しかし、これは「0がfalse」「0以外がtrue」ということを理解して初めて上手く使うことが
できるにょ。
したがって、それが分からなければ結局比較演算を書いて0か1の状態にする必要があるにょ。
それならばANDとORで複数の条件判断を行っても誤判断は起きないにょ。(ごく希にある例外
としてはASC(INKEY$())のようなものがある)
&&は1つ目の条件がfalseであれば2つ目は実行されないため1つ目がtrueの場合でないと2つ目で
エラーが発生するような判定はANDで記述ができないというわけにょ。(論理演算子を使わず
ともIFを2つ連ねて書けば問題ないけど)
さて、この2回の講座でボタン入力判定はほぼあらゆる場合を網羅できるにょ。
ただし、詳しい仕組みについては説明する必要があり、それはそのうちビット演算の回で
じっくりと書く予定にょ。
プチコン3号入門講座もこれで13回目となったにょ。(回数だけならばこれよりも多く書いて
いる人もいるけど私の講座は今回20KB、前回28KBのテキスト量であり入門講座の割にやたら
情報量が多いのがウリ)
入門講座はようやく折り返し地点といった感じだけど2月下旬にプチコン3号の公式ガイドが
出るためそれとの兼ね合いも考える必要があるかもしれないにょ。
もっとも、私の講座は恐らく公式ガイドに書いてないことが多いだろうから公式ガイドが
発売されてしまえば洋梨になるなんてことはないと思うにょ。
しかし、この講座を書くのに時間を取られているのに加えて仕事が忙しくて第3回プチコン
大喜利用の作品は未だに全くの手つかずの状態にょ。
締め切りまですでに1週間を切っているということを考えるとかなり厳しいにょ。
第1回プチコン大喜利は技術賞入賞、第2回プチコン大喜利は技術賞にノミネートだったけど
第3回はこのままだと参加賞狙いになりそうにょ(笑)
(無題)
カーネルパワー41エラーという重大エラーが再び
電源入れっぱなしで放置してたら起動時しかしない音がして慌てて確認すると再起動してた
イベントビューワで見ると上記エラー
親に言うかな
そしてバックアップ開始
(無題)
あ、そういえば急にマウスきかなくなって学校でもらったやつ使用中
変なもの入っていないと思うがそれも心配な
(無題)
天郷思音さん
ハードウェア的な問題は考えられませんか?だとすると部品交換でないとどうにもならないかもしれません。なんにせよ、早い目にデータをバックアップするのがいいと思います
同じ悩みを抱えた人のページです
http://freesoft.tvbok.com/windows7/tool/kernel-power_41.html
(無題)
ちなみに去年これでデータ壊れました(復旧は余裕だったけどたしかチェックディスクの悪さ)
物理的な問題なのは確かだけど起動時の異音が謎
(無題)
天郷思音 さん
私だったら、HDD取り出して別の機械(ノートPCとか)ででーた吸い出します。あーでもないこーでもないとマザーボードいじるより手っ取り早いので。
http://www.century.co.jp/products/pc/hdd-copy/cros2u3rv.html
http://groovy.ne.jp/products/hddset/ud_505sa.html
レスにょ
天郷思音さんへ
>ちなみに去年これでデータ壊れました
データが壊れてから初めてバックアップの重要性を知ることになるにょ。
やはり定期的にこまめなバックアップは行いたいにょ。(私もできてないけど)
い・かえるさんへ
>私だったら、HDD取り出して別の機械(ノートPCとか)ででーた吸い出します。
私も同じことをするにょ。
HDDさえ取り出せばあとはいくらでも何とかなるからね。(HDDそのものが物理的に壊れて
ない限り)
第3回プチコン大喜利への投稿作品が完成したものの・・・
第3回プチコン大喜利は1月31日に締め切られたにょ。
http://smileboom.com/special/ptcm3/ogiri/
私は残念ながらプチコン3号用のゲームは作ることができなかったにょ。
というわけで、プチコンmkII用の「3Dポリゴン立体視プログラム ver.1.1」を作って大喜利に
投稿したにょ。
◎3Dポリゴン立体視プログラム ver.1.1
http://ochameclub.web.fc2.com/petitcom/polygon_stereogram.htm
https://www.youtube.com/watch?v=7jAdvXDFX5E
これは、mkIIで作った「プチコン用ポリゴン表示プログラム」を元にして作ったにょ。
◎プチコン用 ポリゴン表示プログラム
http://ochameclub.web.fc2.com/petitcom/polygon.htm
このポリゴン表示プログラムの最大の特徴は処理の高速であるということであり、最大で
300ポリゴン/秒くらいの表示性能があるにょ。(24面体で14fps程度)
これは他で数人の人が作っているポリゴン表示プログラムと比べると2〜3倍の性能にょ。
その性能を使って実は以前にも立体視対応となる「3Dポリゴン立体視プログラム」は作って
いるにょ。
◎3Dポリゴン立体視プログラム
http://wiki.hosiken.jp/ptcmcon/?Toukou%2F3D%A5%DD%A5%EA%A5%B4%A5%F3%CE%A9%C2%CE%BB%EB%A5%D7%A5%ED%A5%B0%A5%E9%A5%E0
今回作ったver.1.1は端的に言えばこのプログラム(ここではver.1.0と呼ぶことにする)の
問題点を改善したものにょ。
ver.1.0の最大の問題は立体視の調整がプログラムの書き換えをしないとできないという
点にょ。
実際に目で確認しながら微調整を行うことができないためかなり問題といえるにょ。(まぁ
搭載するのが面倒だったというわけではなく単に締め切り時刻の関係で搭載できなかった
というだけなんだけど)
あともう1つの問題は28mmレンズ相当の広角レンズによる描写であるという点にょ。
これはプログラムではなく絵(パース)についての話になるのだけど透視図法というのは
機械的に遠近感を付けられているため広角レンズは自然に見える状況というのは極めて
限られるにょ。
◎奥行きの圧縮を考えて描く方法
http://ochameclub.web.fc2.com/CG/lecture.htm #okuyuki
簡単に説明するとパースは対象物までの距離が重要であり、広角パースで描くというのは
鑑賞時の目からの距離が重要になってくるということにょ。
つまり、鑑賞時の距離によって画面で描かれるパースも変えるべきということにょ。
これは絵に限った話ではなく透視図法に則って計算されている3DCGもそれと同じことが
言えるわけにょ。
とりわけ立体視においては自然に見えるようにするには重要な項目であるといえるにょ。
これを正確に求めるためには目から画面までの正確な距離が必要にょ。
しかし、それは難しいにょ。
ただ、透視図法においては標準レンズや望遠レンズで描写すれば広角レンズほどは鑑賞距離を
選ばないにょ。
つまり、画角が重要になるのは画面にかなり近づいたときだけで3DSの視差バリア方式での
裸眼立体視の推奨鑑賞距離となる30〜40cmくらいの距離だとそこまで画角に関して考える
必要はないにょ。
というわけで、ver.1.1の方向性は決まったにょ。
これら2つの点をいかに単純化して搭載するかを重視したにょ。(立体視の効果を確認しながら
複雑な操作はできないため)
それについては「このプログラムにおける立体視の解説」に詳しく書いているにょ。
ワイヤーフレームやポリゴンのような3Dモデルにおける立体視を行う方法についての初心者
向けの解説もしているので興味がある人は読んでみてにょ。
プチコン用 3Dポリゴン立体視プログラム ver.1.1(このプログラムにおける立体視の解説)
http://ochameclub.web.fc2.com/petitcom/polygon_stereogram.htm #explain
というわけで、このプログラムは鑑賞距離10cm以下の超至近距離で鑑賞した場合には3DSの
裸眼立体視では体験できないような自然で迫力ある立体視が可能になっているにょ。
私は目の前5〜6cmくらいまでは立体視が可能なのでその効果は極めて強く体感しているの
だけど実際に「10cmの距離で立体視ができる」という人自体が限られてきそうな感じにょ。
その際は20cmの距離であれば飛び出し量(立体視の効果)は50くらいを基準にして微調整
すれば自然な感じに表示できるけど迫力はほとんど無くなってしまうにょ。
このver.1.1は原型となったver.1.0があったから短時間でできたのだけどそれでも大喜利の
締め切りに間に合わせるために大喜利に投稿版は計算ミスで立体視の効果は想定していた
数字とは異なるものになっているにょ。(正式公開版ではそれは修正されている)
ver.1.0の完成度の低さを考えるとこのver.1.1こそが真のver.1.0といっても過言ではない
かもしれないにょ。
私は第1回の大喜利では技術賞受賞、第2回の大喜利では技術賞にノミネートということで
第3回では最低でもノミネート、できれば入賞を目標にしてきたけどプチコン3号用の
すごいプログラムがどんどん発表されていて大喜利への投稿作品数が100作品超であると
いうことを聞くとこのプログラムではノミネートさえ厳しいと思われるにょ。
このプログラムの原型となったポリゴン表示プログラムが前回ノミネートとなっている
ために新鮮味が無くなってしまっているので参加賞をゲットするのがせいぜいかもしれ
ないにょ。
本当はプチコン3号用のゲームも投稿したかったけどこれは時間が無かったこともあるし、
空き時間の大半をプチコン3号入門講座を書くのに費やしたためやむを得ないにょ。
プチコン3号では初心者が増えた感じがするので初心者向けの講座を早急に書く必要性が
あると感じたため自分のプログラム制作の時間を講座を書くのに使ったにょ。
まぁ講座を書くというのは自分自身の理解度を再確認するのにも有効であり、書くことで
理解がどんどん深まっているということを考えると長期的にはプラスになっているし
講座が初心者の役に立っているというのを耳にすると講座を書くモチベーションアップ
にも繋がるからね。
ただし、初心者が非常に多いMiiverseでこそ私が書いた入門講座を知らせたいのだけど
Miiverseでは外部サイトのURLの貼り付けができないため「その質問は私の講座を読めば
一目瞭然である」というのを伝えたくてもできないのがもどかしいにょ。
ネット検索すれば私の講座もすぐに見つかるのだけど分からないことは検索するクセが
付いている人ならば散々既出な質問をしたりしないだろうからね。
プチコンでポリゴン!?
久しぶりにmkIIを起動し、ポリゴンのプログラムを読み込んでみました。
すごいなと思いました。
私もこんなものが作れたらな〜って思います。
http://kusoft.web.fc2.com/
サブ・コンテンツについて
「お絵かき」にアクセス出来ないのですが・・・・・・
http://kusoft.web.fc2.com/
(無題)
移転以来リンク切れがあるんだよね。報告したようなしてないような。
(無題)
結構ありますよね。
http://kusoft.web.fc2.com/
レスにょ
みほさんへ
>久しぶりにmkIIを起動し、ポリゴンのプログラムを読み込んでみました。
>すごいなと思いました。
>私もこんなものが作れたらな〜って思います。
ポリゴンは初心者には少し難易度が高いけど立体を線のみで表現するワイヤーフレームならば
簡単にょ。
3Dモデルやカメラの回転を行わないならば四則演算のみで作れるため小学生でも作ることが
可能にょ。
回転処理がある場合も回転行列の公式にぶち込めばいいだけでそれほど難しくはないので
小中学生でも十分作ることができるにょ。
>「お絵かき」にアクセス出来ないのですが・・・・・・
更新をした際にURLに余分な文字列が入っていたみたいだったので修正をしておいたにょ。
http://ochameclub.web.fc2.com/CG/data.htm
今は問題なく表示が可能にょ。
天郷思音さんへ
>移転以来リンク切れがあるんだよね。報告したようなしてないような。
とりあえず、報告があった分はすべて修正しているし、自分で見つけた分も修正している
もののまだリンク切れを100%は修正できてないと思うのでもしもリンク切れを見つけたら
教えて欲しいにょ。
プチコン3号でGRP2軸回転
プチコン3号でGRP2軸回転プログラムを作ってみたにょ。
(プチコン3号)GRP2軸回転プログラム
https://www.youtube.com/watch?v=cYI3XT5MMaQ
公開キー【QK3E2EH3】
※公開キーは今後変更される可能性があるのでダウンロードはお早めに!
これは以前プチコンmkII用に作った「GRP2軸回転プログラム」をほぼベタ移植したものにょ。
プチコン用GRP2軸回転プログラム
http://ochameclub.web.fc2.com/petitcom/2rotate.htm
このプログラムはGRP面のX軸、Z軸の2軸回転が可能になっていてこれによって拡大縮小は
もちろんのことカメラアングルの変更や360°自由な旋回が可能になりマリオカートやF-ZEROの
ようなゲームさえも作ることが可能になるというものにょ。
このサンプルプログラムでの操作方法や詳しい仕組みについては上記のmkII版のページを
見てもらえると分かると思うけどこのプログラムの最大の特徴は自由なカメラアングルの
変更機能にょ。(ワイヤーフレームやポリゴン表示プログラムでは公式などを参考にして
作っているけどこの2軸回転プログラムはビュー変換部分は完全に私の独自手法で作って
いる)
これはmkIIでも私が知る限りは2軸回転プログラムに搭載している人はいないにょ。
2軸回転風の360°旋回が可能なゲームなどを作っている人はいてもみんなカメラアングルは
水平固定だからね。
それはビュー変換が不要であるためその方が高速動作を行えるというのもあるためにょ。
ポリゴンやワイヤーフレームが頂点単位でビュー変換を行うのに対してこの2軸回転では
ドット単位でビュー変換を行う必要があるからね。
つまり、表示ドット数が増えれば増えるほど処理負担は大きくなり下手なポリゴン表示よりも
重くなってしまうにょ。
ちなみに今回私が作ったGRP2軸回転プログラムもNew3DSで実行時でさえ全画面表示を行うと
1ドット4pixelのデフォ画質で17fps程度、1ドット2pixelの高画質で5fps程度、1ドット
1pixelの最高画質だと2fps程度の速度しかないにょ。(上記の動画はNew3DSで実行時のもの)
これでもmkII版よりも20倍以上速くなっているにょ。
何せmkIIは1ドット8pixelの低解像度(32x12ドット)で10fps程度しか出ないからね。
プチコン3号ではこの条件だと200fps以上が可能にょ。(New3DSで実行時)
プチコンmkIIでは限界まで処理を最適化して1ドット8pixel表示をデフォの2倍速にしたものの
それでも実際にゲームを作ってみると処理速度が物足りないだけではなく解像度が低いため
スピード感が感じられないという問題が発生して作るのを途中でやめてしまったにょ。
(プチコン)3Dレースゲーム試作品
https://www.youtube.com/watch?v=hLr5VEevY9I
プチコン3号ならばこれは十分可能だろうから気が向いたら作ってみるかもしれないにょ。
もちろん、この2軸回転プログラムは自分のプログラムに組み込んでゲームを作ってもらって
結構なのでどんどん使ってみてにょ。
点検した
異音は解消
マウス効かない現象も解消
ついでにパワーアップしたらしいので見てたらCPU換装おなじcore2でもE6400からE8500になったため周波数も上がってる
レスにょ
天郷思音さんへ
>異音は解消
>マウス効かない現象も解消
それは良かったにょ。
>ついでにパワーアップしたらしいので見てたらCPU換装おなじcore2でもE6400からE8500になったため周波数も上がってる
E8500はCore2Duoの中では最速クラスなのでE6400からだと速度の違いが体感可能なのでは
ないかと思われるにょ。
ちなみに私が7年前に組んだPCにはCore2Duo E8400を使ったにょ。
当時はE8500が最速だったけどそれと数%の違いで価格が2/3だったのでお買い得感が高かった
からね。
ついにWindows8.1タブレット端末をゲット!
以前より購入を予定していたタブレット端末をついに買ったにょ。
https://twitter.com/ochame_nako/status/564406421605728256
買ったのはACERのIconia Tab 8W(W1-810-F11N)にょ。
Windows 8.1搭載だけどいわゆる廉価タブレット端末にょ。
ちなみに税込15980円だったにょ。
最新(昨年12月に発売)のWindows PCが1万円台(New 3DS本体と同じくらいの価格)で
買えるとは良い世の中になったものにょ。
ちなみにスペックはこんな感じにょ。
Iconia Tab 8W(W1-810-F11N)
OS Windows 8.1 with Bing 32bit
CPU Atom Z3735G(1.33GHz、TB1.83GHz)
メモリ 1GB
SSD 32GB
液晶 8インチWXGA(1280x800)
サイズ 128x9.75x214mm
重量 370g
駆動時間 8時間
上記のように廉価タブレットであるためメモリは1GBしか搭載しておらず、カメラも200万画素
とおまけレベルのものしか付いてないにょ。
そして、MS Officeも付いてないにょ。
スマホ(5インチ)とモバイルノートPC(10.4インチ)の間を埋めるデバイスとして今回購入
したのだけどやはり気がかりだったのがスペックにょ。
ということで早速ベンチマークを実行してみたにょ。
まず試したのが好例のCrystalMark2004にょ。
スコアの比較の参考にするのはCore i7-620UM(1.2GHz、TB2.26GHz)を搭載したLet'snote
CF-R9Kにょ。
◎CrystalMark2004R2
Iconia Tab 8W 《参考》CF-R9K
Mark 78624 72477
ALU 19966 21478
FPU 15988 19678
MEM 13544 14069
HDD 20612 8512
GDI ??3612 5749
D2D 2454 1383
OGL 2448 1608
この結果から判断するとIconia Tab 8WはCPU性能は若干劣るもののCore i7を搭載したR9に
近い値が出ているにょ。
これはCore i7とはいえ物理2コアのR9と物理4コアのIconia Tab 8Wの違いにょ。
Atomとはいえ従来のものと比べて高性能化がされているBay Trailコアであるため4コアを
フルに使えるアプリではそこそこ高性能といえそうにょ。
システムドライブはSSDだけあってR9と比べて2倍以上のスコアとなっているにょ。
そのため総合スコアではCore i7を搭載したR9を凌駕しているにょ。
あと昔から恒例のHDbenchを実行してみたにょ。
◎HDBench 3.40
Iconia Tab 8W
?? ALL??Integer?? Float??MemoryR MemoryW MemoryRW??DirectDraw
99189?? 280129??257691?? 115870??101334?? 204840??????????13
Rectangle?? Text Ellipse??BitBlt????Read?? Write?? RRead??RWrite??Drive
????12000??21533?? 22400?? 13059??159750?? 72778?? 82847?? 40943??C:\100MB
《参考》CF-R9K
?? ALL??Integer?? Float??MemoryR MemoryW MemoryRW??DirectDraw
100791?? 349378??382476?? 248918??161228?? 323890??????????14
Rectangle?? Text Ellipse??BitBlt????Read?? Write?? RRead??RWrite??Drive
???? 1139?? 1295????1337???? 112?? 72882?? 75349?? 19475?? 26459??C:\100MB
HDBenchもマルチコアというかマルチCPUに対応したベンチであるため4コアAtomであるが
故にR9Kに匹敵とはいかないけどそこそこ高いスコアが出ているにょ。
これを見るとシステムドライブのシーケンシャルリードは160MB/s程度、シーケンシャル
ライトは70MB/s程度出ているにょ。
これをより正確に測定するためCrystalDiskMark3.0.1を試してみたにょ。
?????????? Sequential Read :?? 168.446 MB/s
??????????Sequential Write :????78.663 MB/s
???????? Random Read 512KB :?? 146.570 MB/s
????????Random Write 512KB :????61.934 MB/s
????Random Read 4KB (QD=1) :????17.430 MB/s [??4255.3 IOPS]
?? Random Write 4KB (QD=1) :????13.323 MB/s [??3252.8 IOPS]
?? Random Read 4KB (QD=32) :????37.210 MB/s [??9084.5 IOPS]
??Random Write 4KB (QD=32) :????11.982 MB/s [??2925.3 IOPS]
シーケンシャルリードは168.4MB/s、シーケンシャルライトは78.66MB/sとなっているにょ。
これは2.5インチHDDと比較するとシーケンシャルリードは最新の5400rpmのHDD(100MB/s
程度)よりも上でシーケンシャルライトはやや下といった感じにょ。
さすがにeMMCとはいえSSDなのでランダムリードは最新のHDDを大きく凌ぐにょ。
それでも単体販売されている昨今のSSDと比べると格段に劣る性能は否めないのでやはり
コストと消費電力の問題でこの性能になっていると思われるにょ。
速度よりも気になるのは空き容量ではないかと思われるにょ。
32GB(これは1GB=1000000000バイト計算によるもの)しか搭載してないためこれで大丈夫
なのか心配の人もいると思うけどリカバリ領域等に使用されているためシステム上からだと
22.5GBしかないにょ。
デフォだと空き容量は14.8GBあるためデータなどはmicroSDを活用すれば何とかなりそうな
感じにょ。(ということで、1780円で32GBのmicroSDを速攻で購入)
これが搭載が16GBだったらほぼ使い物にならないレベルになりそうにょ。
あとSuper πも測定してみたにょ。
◎Super π
Iconia Tab 8W
104万桁 419万桁
1分23秒 5分35秒
《参考》CF-R9
104万桁 419万桁
20秒 1分50秒
Super πは拡張命令を使用しない場合のシングルスレッド性能(+キャッシュ性能)を見る
のに適したベンチにょ。
これを見ると上記と比べてAtomはCore i7と大きく差が開いているにょ。
この結果は概ねULVのPenM並にょ。
つまり、Bay TrailコアのAtomのコア当たりの性能はULV PenMと同レベルと言えるにょ。
Windowsを快適に動かすにはマルチスレッド性能だけではなくシングルスレッド性能が重要に
なってくるけどスペックの割りに動作がもっさりなのは4コアある反面でシングルスレッド
性能が低いためかもしれないにょ。(ベンチ以外はソフトを起動していないのでメモリ不足が
原因というわけではない)
◎3DMark03
Iconia Tab 8W 2976
《参考》CF-R9K 2903
3DMark03はDirect9世代の古いベンチだけどこのGPU性能からすると最新の新しいベンチを
動作させても満足な結果を得るのは難しいためこれで判断すると同じIntel HD Graphics同士
であるためほぼ同じスコアが出ているにょ。(実際はIconiaの方がGPUの世代が新しくGPUの
クロックが低いのだけど)
これを見るとやはり最新の新しいゲームをプレイするにはかなり厳しいにょ。
まぁゲーム用途で買ったわけではないので問題はないにょ。(それなりに高いGPU性能を求める
ならばBay Trailの次の世代となるCherry Trailを搭載した製品がもうすぐ発売されるので
それを待つという方法もある)
さて、CPUやシステムドライブはそこそこの性能というのが分かったけど問題はメモリが
たったの1GBしかない点にょ。
これはデフォルトの状態だと起動時にはメモリが700MB程度使用されているため十分とは
いえない感じにょ。
WinXPでさえメモリ1GBではタブをたくさん開いたらWeb閲覧だけでも1GBでは足らないことを
考えるとWin8.1ではさすがにメモリ1GBの機種はうまく使用していかないとメモリ不足に
悩まされそうな感じにょ。
タブレット端末を実用レベル(個人的にあまり不満を感じないレベル)で使用するならば
CPUはCore M、メモリ4GB、SSD128GBくらいは最低欲しいところだし、液晶の解像度もWUXGA
くらいは欲しいところだけどそんなスペックの8インチタブレットは存在しないしそもそも
あっても高くて手が出せないと思われるにょ。
それを考えるとおもちゃの感覚で買えるこの価格の方がベターだと思ってしまうにょ。
モバイルノートとスマホとの隙間的使用であるためどの程度使用することになるかは分から
ないので試しに買うのに高額なものだと手が出せないにょ。
15980円というと何せ私が買ったNew 3DSと同じ価格だからね(笑)
実際の使い勝手やバッテリ駆動時間などはまた改めて書くことにするにょ。
また試して欲しいベンチマークやなどがあれば受け付けるので遠慮無く言って欲しいにょ。
コンピュータ
Windows8のタブレットがNew3DSと同じくらいの値段で購入できるんですね。
昔は今よりも低性能なコンピュータがものすごく高い値段で売っていたんですよね?
(XP世代だからよくわからないけど。)
レスにょ
みほさんへ
>Windows8のタブレットがNew3DSと同じくらいの値段で購入できるんですね。
>昔は今よりも低性能なコンピュータがものすごく高い値段で売っていたんですよね?
私が買ったのは一番安い廉価機種なのだけどそれでも昔だったら考えられないくらいの
安さにょ。
90年代はキーボードの付いてないタブレット型のPCは業務用しかなくほとんどが高価
だったにょ。
これはWindowsがマウスとキーボードで操作するOSであり、マウスやキーボード無しでは
満足に使えないためにょ。(業務用だとタッチで操作しやすいソフトを開発して入れれば
いいだけなんだけどOSそのものが使いづらい)
XP世代だとXP professionalの派生版であるWindows XP Tablet editionでタッチに対応して
いるもののProよりも高価なOSだし電磁誘導式のペンで操作することを前提となっている
ため高価な業務用のPCにしか対応してなかったにょ。(定価だと20〜30万円クラス)
業務用ではなく個人向けの安価なタブレットPCといえばXP末期となる2006年に発売された
コードネーム「Origami」と呼ばれる機種にょ。
安価で低消費電力なCPUが開発されたもののそれでも安い機種で10万円を切る程度の価格
だったし、性能が低いしタッチで使えるようにソフトウェアキーボードが搭載されていたり
していたものの使い勝手が良いとは言えなかったため全然売れなかったにょ。
タブレットPCの低価格化はiPadのヒットによる影響が大きいと思うにょ。
これによって個人向けへのタブレット市場が開拓されたからね。
Windows8はタッチのみで使えるような仕組みが採り入れられているためそれによって
タブレットPCが売れ始めたにょ。(といっても最新のWin8.1でもタッチのみだとiPhoneで
使われているiOSや多くのスマホで使われているAndroidと比べたら見劣りする)
Win98/2000→XP→Vistaとどんどん重くなっていたOSはVista→7→8とどんどん軽くなって
いきそして安価で低消費電力なCPUであるAtomもBay Trailコア(Z37xxシリーズ)で従来
よりも大幅に高性能となったため2013年にはそこそこ使えるレベルのタブレットPCが4万円
前後で買えるようになったにょ。
そしてさらなるコストダウンによって昨年後半からは2万円を切る機種が登場し始めて
現在に至っているにょ。
ただし、そこそこ使えるレベルといっても性能面でいえばXP末期〜Vista初期の一般的な
ノートPCと同じくらいのものであり決して高性能ではないにょ。
それでも300g台の軽さでそこそこ使えるタブレットPCが1万円台で買えるというのは
良い時代になったにょ。
自作パソコンがほしい
最近作る人いないかもね
(無題)
なるほど。
コンピュータの値段はどんどん下がっているのですね。
3年位したら、もっと値段は下がるのかな。
レスにょ
天郷思音さんへ
>自作パソコンがほしい
>最近作る人いないかもね
90年代は自作PCはコストのメリットが非常に多くてブームになったけど2000年代に入り
年々コスト的なメリットは薄れてきているにょ。
パーツの使い回しが可能というメリットも昨今はケースや光学ドライブ以外は総組み替えが
ポピュラーになってきているにょ。(古いパーツの使い回しをするメリットは小さくなって
きていて場合によっては使い回しを考えることはデメリットになってしまう)
今は自作PCは自分でカスタマイズしたPCを作る(組む)ということに魅力を感じる人のものに
なっていると思うにょ。
単に安いPCが欲しいだけならば出来合い品を買う方が安い場合が多いし、保証の面でも有利に
なっているにょ。
みほさんへ
>コンピュータの値段はどんどん下がっているのですね。
>3年位したら、もっと値段は下がるのかな。
Windows PCは今後も1万円台が限界ではないかと思われるにょ。
昔は高価だったCPUも最新のWindowsが動作する必要最小限のレベルのものならば非常に安価に
なっているためこれ以上価格が下がる余地がほとんど無いし、高価だったOS(Windows)も
そういう低価格PC向けにはタダ同然の非常に安価に卸しているためこれ以上価格を下げる
余地が残っていないにょ。
広義のコンピュータであればAndroidタブレット端末は安い機種ならば5000円程度で購入が
可能であるためWindowsに限定しなければこれくらいの価格までは下がる余地はありそうにょ。
なるほど
確かに、WindowsPCだと一万円台が限界かもしれませんね。
FC2仲間は何人?
そういやFC2でHP作ってる仲間が増えた。(ここにも来てるよ)
私も作っているよ
もし良かったら見てね〜(宣伝)
FC2は広告が無いのが嬉しいですよね(Powered by FC2.com
みたいな文字は入ってしまうけれど)。
http://kusoft.web.fc2.com/
風景撮影
http://f.hatena.ne.jp/ken10ken/20150214121705
なぜか空が鮮やかに写った
http://f.hatena.ne.jp/ken10ken/20150214124745
たいていは微妙な色なんだけど
ついでに、私のホームページも紹介しておこう
http://waaimyroom.web.fc2.com/
※プチコンページ放置
私もだww
私もホームページの「プチコン」のページは放置。
全然更新していないような気がします。
(無題)
僕も流れで ホームページ告知
http://liv0.com
ポケコン系は 長い事 放置してる
プチコンは 前のバージョンまま放置してる
http://liv0.com
なんじゃこりゃww
ホームページの紹介ばかりじゃないか。
http://kusoft.web.fc2.com/
そういえば
書き込むときにURLの欄あったね
http://waaimyroom.web.fc2.com/
レスにょ
天郷思音さんへ
>そういやFC2でHP作ってる仲間が増えた。(ここにも来てるよ)
FC2を使っているプチコンユーザーは結構多そうにょ。
>なぜか空が鮮やかに写った
>たいていは微妙な色なんだけど
デジカメの場合はホワイトバランスなどの設定でいくらでも色が変わるにょ。(twitterで
話題になっているドレスの色もそれを考えれば推測が可能)
空を濃い青で写すならば一眼レフならばフィルターを付けることで変えることもできるにょ。
PLフィルターが最も効果的にょ。
ちなみに私のデジタル一眼レフ(7年前に発売されたPENTAX K200Dと10年前に発売された
Nikon D50)でフィルターを使わず普通に撮影した場合(デフォルト設定)はこんな感じに
なっているにょ。(リサイズ以外は無加工)
K200D http://ochameclub.web.fc2.com/test/koukuusai.jpg
D50 http://ochameclub.web.fc2.com/test/sakura.jpg
PLフィルターを使ったを使った場合の撮影サンプルをSDカードから読み込もうとしたら
SDカードのデータが壊れて読み込めなかったにょ。
HDDにバックアップしたデータがあるはずだけどそれも行方不明にょ(バックアップの意味が
無い)
マリモーマさんへ
>ポケコン系は 長い事 放置してる
>プチコンは 前のバージョンまま放置してる
私もポケコンコーナーを最後に更新したのは1年前にょ。
やはり、実機がすべて壊れてしまったのがかなり影響しているにょ。
PC-E500系は新品の入手がほぼ不可能だし、中古もヤフオクのIDをまた作るのも面倒なので
なかなか入手の機会もないにょ。
みほさんへ
>私もホームページの「プチコン」のページは放置。
>全然更新していないような気がします。
私もプチコン3号講座のページは週に1回更新の予定だったけど忙しくて2週間も更新を
さぼっているにょ。
Webサイトを作る(立ち上げる)のは簡単だけど定期的に更新をするというのはそれより
何倍も難しいにょ。
Win8.1タブレット「Iconia Tab 8W」レビュー
先日購入したWin8.1搭載タブレットPC「Iconia Tab 8W」について書いてみるにょ。
ベンチ結果については前回のものを参照にょ。
ついにWindows8.1タブレット端末をゲット!
http://6407.teacup.com/ochame/bbs/4874
まずバッテリ駆動時間にょ。
公称8時間だけど実際は何時間動作するかおなじみのBBenchで試してみたにょ。
キーストローク、Web巡回あり(軽いWeb閲覧の負荷)で測定したにょ。
まずは輝度最大から見てみるにょ。
90% 1812秒
80% 3612秒
70% 5232秒
60% 6673秒
50% 8004秒
40% 9473秒
30% 10835秒
20% 12260秒
10% 13659秒
5% 14320秒
次は輝度最小にょ。
90% 2412秒
80% 4790秒
70% 7068秒
60% 9389秒
50% 11520秒
40% 13721秒
30% 15963秒
20% 18102秒
10% 20102秒
5% 21096秒
輝度最大ならば約3.98時間、輝度最小ならば約5.86時間となるにょ。
これは公称駆動時間と比べると輝度最大で半分、輝度最小でも約4分の3となるわけだけど
JEITA測定法1.0による公称駆動時間ならば半分〜7割程度しか動作しないためこの結果は公称
駆動時間と比べて特別短いというわけではなく概ね予想通りの結果となるにょ。
実際に普通にWeb閲覧や動画鑑賞をしていて4〜5時間は普通に使える感じだったのでこの
ベンチ結果は実使用とあまり差はない感じにょ。
ただし、バッテリが十分持つかと言われたら微妙な感じにょ。
バッテリ容量は4550mAhとこのサイズのタブレット端末では一般的な容量なのでこんなもの
だと思われるにょ。
まぁスマホでテザリングを行って通信を行えば先にスマホのバッテリが切れると思うので
これだけ持てば普段の使用において困ることはあまりないとはいえバッテリ交換ができない
タブレット端末の場合はバッテリが劣化して駆動時間が短くなったら事実上の寿命となって
しまう(さすがにAC専用で使うのは厳しい)ということを考えると最初は十分に使えるくらい
長い方が製品寿命が長くなるにょ。
ただし、そのためには大容量のバッテリを搭載する必要があり重量とのトレードオフになる
ため難しいにょ。
さて、廉価タブレット端末ということでやはり気になると思われるのは液晶の品質だと
思われるにょ。
しかし、廉価とはいえIPS方式の液晶を採用しているため普通に使うには全く問題がない品質
となっているにょ。
タブレットの場合は視野角も重要になってくるけどIPSのお陰で視野角も十分にあり少し
斜めから見ても見やすさが変わることは無かったにょ。
モバイル専用ということで液晶の品質よりも駆動時間を重視しているモバイルノートPCで
あるLet'snote CF-R9よりは格段に上(視野角が狭くほぼ正面から見ないとまともに見えない
というのは電車の中で使うには逆に都合がよいと言えなくもない)だし、CGシリコン液晶を
採用している私のスマホ(AQUOS CRYSTAL)と比べても発色は上に感じたにょ。
廉価端末ということを考えると十分すぎる液晶だと思われるにょ。
Androidタブレット端末やiPadではフルHDもしくはそれより高解像度が標準的になっている
ため解像度がWXGA(1280x800)と低いのが気になるところだけど8インチという画面サイズを
考えると許容はできなくもないにょ。
縦持ちでWeb閲覧をすると横800pixelしかないため横幅に収まらないWebサイトが多数出て
しまうけどこれは75%くらいに縮小表示をすれば大丈夫にょ。
ただし、その場合は文字が潰れてしまうにょ。
これがフルHD液晶ならば潰れずに済むためタブレットではフルHD以上の解像度の液晶を
搭載したモデルが欲しくなるにょ。
これは電子書籍用として購入する場合にも同じことが言えると思うにょ。
大画面ならば高解像度(フルHDもしくはそれ以上)の液晶はより多くのものを表示する
ことができるけど8インチやそれ以下の画面サイズの場合は高解像度は文字品質を高める
ことが可能になるにょ。
ただし、Win8.1でデスクトップアプリを使用する場合にはデフォのスケーリング設定では
8インチWXGAでも指によるポインティング操作はしやすいとは言えないにょ。
静電容量方式はDSなどで採用されている感圧式とは異なり指による操作はしやすい反面で
精密なポインティング操作には向かないからね。
それを考えると8インチWUXGA(1920x1200)ではデフォのスケーリングではまともに操作を
行うのは困難と言えそうにょ。
ただし、すべてのソフトがそのスケーリング設定通りになるかというとそうではなくやはり
指による操作を行うのは操作性が良いとは言えないにょ。
Windowsストアアプリに関して言えばそれは変わってきていてWin8/Win8.1の真価を発揮する
にはやはりタッチは必要不可欠と感じたにょ。
WindowsストアアプリはAndroid向けのGoogle PlayやiOS向けのApp Storeと比べると
アプリの種類は少ないにょ。(AndroidやiOS用はあるのにストアアプリにはないという
タイトルも少なくない)
「無い物は作る」の精神で自分で作るという選択肢もあるにょ。
Androidタブレット端末やiPadとは異なり低スペックとはいえWindows PCであるためセルフ
開発は可能にょ。(タブレット単体で開発してそれをストアで配布するまでのことが
すべて同一端末上で可能)
ただし、Win8.1用のWindowsストアアプリを作るためにはVisual Studio 2013(無料で
使えるExpress Editionもある)をインストールする必要があるけどこれは11GB以上の
ストレージを要求しているため動作確認をしてないにょ。(ストアアプリを作るので
無ければ開発環境は無数にあるため適当なものを入れればいい)
実際に使ってみて速度面は十分かと言われたら微妙にょ。
少なくとも私が使っている第4世代iPod touchと比べて格段に性能が上なのにもっさり感を
感じてしまうにょ。
これはメモリが1GBと少ないのもあるけどやはりAtom Z3735Gの性能がベンチほど高くはない
というのが原因かもしれないにょ。
ベンチではそれほど差がないCore i7-620UMを搭載したR9の方が体感では格段に上にょ。
それはメモリを6GB搭載しているというのもあるけど遅いデフォのHDDのままなので
システムドライブの速度はIconiaの圧勝だけどCPUのシングルスレッド性能が低いためだと
思われるにょ。(店頭でメモリ2GBのAtom搭載端末を使っても体感でそれほど差がないため)
アプリを複数立ち上げたりWebブラウザでタブを多数開いた時に待ち時間が長くなるのは
間違いなくメモリ1GBの問題にょ。
起動した段階でメモリが700MBくらい使用されているため残り300MBくらいしか自由に使えず
それを超えるとスワップによる速度低下が起きてしまうためにょ。
Windowsである以上は複数のアプリを同時に使用することは日常茶飯事であるためやはり
1GBではよほど工夫をしないともっさりした動作は避けることができないにょ。
スペック的にはやや不満があるもののそれは価格やサイズを考えればやむを得ないにょ。
いくらスペックが高くても10万円以上したりとか1kgを超えたりとか実駆動時間が1時間程度
しかなかったりとかしたら手が出なかったり使い勝手が悪くなったりするからね。
そもそも、買った理由がスマホとモバイルノートPCとの中間的な存在が欲しかったためにょ。
R9もアンダーB5サイズで900g程度とモバイルノートの中では小型軽量とはいえ普段から持ち
運ぶには重いし立った状態では使うことができないので持ち運びに便利な立った状態でも
使用できるPCが欲しかったにょ。
従来はこのポジションはVAIO UXがまかなっていたにょ。
私が持っているVAIO UXは約500gという当時としてはまともにWinXPが動作する世界最小、
最軽量のWindowsPCだったにょ。(CPUにCrusoeを使用しているOQOなどのごく一部の例外を
除けば最小、最軽量)
何せこのサイズ(4.5インチ)でCore Soloを搭載しているわけだからね。(Core Soloは
当時の12インチクラスの一般的なモバイルノートPCの多くの機種に使用されていた高性能な
CPUでありUX発売から3年後にブームとなったネットブックに使用されることになった
Atom N270よりも性能が高い)
ただし、CPU性能はWinXPを動作させるのに十分であってもメモリが512MBしかなかったりとか
デフォの1.8インチHDDが激遅だったりとか、バッテリ駆動時間が短いとかの問題があったにょ。
バッテリ駆動時間は普通に使って連続使用だと1時間少々と短いけれどそれならばこまめに
電源を切るなりすれば改善できそうに思うかもしれないにょ。
ただし、1.8インチHDDのVAIO UXではコールドブートは遅すぎて話にならないし作業を途中で
中断する場合にわざわざ保存して起動した際にそのソフトを立ち上げてそのファイルを開く
なんて面倒なことはできないにょ。
そこで普通は休止やスタンバイを使うと思うにょ。
ただし、VAIO UXでは休止の復帰に40秒もかかるためちょっと使いたいという際にはこの
時間はかなり長く感じるにょ。
スタンバイからの復帰ならば10数秒で可能にょ。
ただし、スタンバイにすると1日で(何もしない状態で)40%もバッテリを消費してしまう
ことになるにょ。
ただでさえバッテリ駆動時間が短いのに何もしないでどんどん駆動時間が短くなるという
のは耐えられないにょ。
ということで、せっかく買ったものの使う機会はどんどん減ってしまったにょ。
では、ガラケーからスマホに買い換えたのでVAIO UXポジションのPCが不要になったかというと
スマホを使ってみてスマホではカバーできない領域を再発見することができたにょ。
したがって、以前よりもこのポジションのPC(モバイルノートとの間を埋めるPC)を強く
欲するようになったにょ。
というわけで普通に使って4〜5時間バッテリが持ち、スリープからの復帰は瞬時(1秒以下)
というのはVAIO UXと比べると雲泥の差にょ。(スマホの起動時間と大差ない速さ)
ポケットに入るかというと厳しいけれどこのサイズならば普段から持ち歩くのにも苦には
ならないし、使おうと思ったときに瞬時に使えるのがうれしいにょ。
これで、XPマシンを1つまた新しいOSに置き換えが完了したにょ。
VAIO UX90S → Iconia Tab 8W
OS WinXP Win8.1
CPU CoreSolo U1400 Atom Z3735G
メモリ 512MB 1GB
ドライブ HDD20GB SSD32GB
サイズ 150.2x38.2x95mm 128x9.75x214mm
重量 520g 370g
公称駆動時間 3.5時間 8時間
実駆動時間 1.5時間程度 5時間程度
Iconiaは約16K円という安さだっため思わず買ってしまったわけだけどスペックにはやや
不満があってもコストパフォーマンスは非常に高くそれなりに満足しているにょ。
ただし、ここ最近はデジタイザ付きモデルも以前より安価になってきているため少し
気持ちがぐらついているにょ。
例えば、VivoTab Note 8はデジタイザにOffice2013が付いてメモリ2GB、SSD64GBと私の
Iconiaの2倍の容量で24800円(税別)だからね。
VivoTab Note 8
http://pc.watch.impress.co.jp/docs/news/20150213_688217.html
ワコム製デジタイザだから簡易液晶ペンタブとしても使えそうにょ。
個人的にはワコム製デジタイザ搭載はかなり魅力的に思えるため24800円は格安に感じて
しまうにょ。(デジタイザ搭載でなくてもスペック的には安い部類)
ここまで安くできる理由はすでに出荷が始まっている次世代Atom(コードネーム:Cherry
Trail)を搭載した新機種の登場が近いからかもしれないにょ。
現状のBay TrailコアのAtom搭載機を売り切るために価格をダウンしたと考えればこの
安さの説明は付くにょ。
Cherry Trailは14nmプロセスによって従来よりも大幅に性能向上している(GPU性能は4倍に
なるらしい)というわけで今すぐ欲しいというわけではないならばCherry Trailを待つと
いう選択肢もありにょ。
ただし、早く買って早く使えるというのは何より大きなメリットになるので別にそこまで
スペックに拘らないならば現行機種を安く買って使い倒すというのがベターではないかと
思われるにょ。(Cherry Trailを搭載でいきなり2万円を切る価格というのは考えにくい)
スマホ「AQUOS CRYSTAL」レビュー
私は昨年末に長年使っていたガラケーからスマホ(AQUOS CRYSTAL 305SH)に買い換えたわけ
だけど2ヶ月余り使ってきたので簡単なレビューを行ってみるにょ。
買った経緯やAQUOS CRYSTALの解説や通信速度に関してはこちらを参照
ついにスマホに買い換え!
http://6407.teacup.com/ochame/bbs/4835
まずは、AQUOS CRYSTALがどんな機種かというと12月28日に書いたようにウリとなっているのは
狭額縁の筐体であるということにょ。
ベゼル幅が1mm以下という過去のスマホでは例がないくらいなのだけど特筆すべきなのはその
程度にょ。
あとは普及モデルかつ海外展開しているワールドワイドモデルということでスペックは2年前の
ハイエンドモデル以下で日本独自のワンセグ、おサイフケータイなどもなく狭額縁の代償と
して防水機能もついてないにょ。
まぁワンセグ機能はそれまで使っていた905SH(ソフトバンクで最初のワンセグ機能搭載機種)
でもほとんど使ってこなかったので問題はないにょ。
スマホに買い換えた理由としてはそれまで使ってきたガラケーのネット機能が非常に弱かった
という点にょ。
まぁこれは2006年モデルという化石機種であるためフルブラウザを使ってもまともに閲覧が
できないサイトが増えてきていたにょ。
そのためiPod touch+モバイルルータでモバイル時のネットを行って来たにょ。
これはこれで悪くなかったのだけどそこで問題になってきたのが使いたい時にすぐには
ネットが使えないという点にょ。
これはどういうことかというとiPod touchはスリープから瞬時に起動するので問題ないの
だけどモバイルルータは電源を入れたままにしていたらバッテリが1日持たないため
普段は電源OFFにしているにょ。
ところが、その状態からだと起動に1分くらいかかるにょ。
そこから無線LANに繋がるまでの時間を考えるとせっかくのiPod touchによるお手軽通信も
台無しになってしまうにょ。
そこで、昨今の新しいモバイルルータを買えば改善ができると考えるかもしれないけど
実はiPod touchも第4世代モデルということでアプリも非対応のものが増えてきてそろそろ
買い換えを感じさせてきていたにょ。
ところが、iPod touchは昨今売れ行きが落ちたせいか新製品が出ないにょ。
それならばiPhoneに買い換えるか・・・と思ったけどそれならばせっかくなのでまだ
持ってないAndroid端末の方がいいかもというわけでAndroid搭載スマホの中から安くて
見た目が良いもの(ピンクがあってデザインも悪くないもの)を選んだらたまたま
AQUOS CRYSTALだったというわけにょ。
ということもあって、スマホを買ってアプリもいくつかダウンロードしたもののほとんど
ネットしか使ってない状態にょ。
ネットといってもそんな特別なことをしているわけではなくtwitterやMiiversやその他
SNSや一般サイトを閲覧している程度にょ。
しかし、回線速度が速いせいかiPod touch+モバイルルータで閲覧していた頃よりは
格段に快適にょ。
ソフトバンクの4G回線も回線状態の良い場所ではベンチでは40Mbpsくらい出ているからね。
それは特別としても町中だとほとんどの場所で10Mbps前後の速度が出ているにょ。
さすがに理論値では100Mbpsを超えているだけのことはあるにょ。
モバイルルータの方は旧世代のHSDPA(理論値3.6Mbps)なので回線速度はせいぜい1Mbps
くらいしか出ていないにょ。
まぁtwitter程度ならば1Mbpsでも10Mbpsでもほとんど差はないけど画像を読み込んだら
体感ではそれなりの速度差を感じるにょ。(回線速度が10倍速くなっても画像の表示が
10倍速くなるわけではないけど)
液晶は5インチながら今となっては低スペックのHD液晶(1280x720)にょ。
フルHDを搭載したミドルクラス以上のものと比べるとさすがに見劣りするにょ。
解像度指定されてないサイトでは横幅980pixelでレンダリングされるため縦長画面で閲覧
する場合には73%に縮小されてしまうにょ。
それだと小さな字は潰れてしまうけどこれがフルHDならば潰れずに読むことが可能に
なるにょ。(もちろん字そのものが小さいのでまともに読めるかは人によるけど)
しかし、それでも960x540のiPod touchよりは高解像度であるためそれなりに快適にょ。
液晶の表示品質は昨今のIGZOではなくCGシリコン液晶であり並以下といった感じにょ。
そんなに悪くはないけど良くはないにょ。
普及クラスの機種なのでこんなものかもしれないにょ。(表示品質は旧世代のiPod
touchの方が上)
アプリを見てみるとダウンロードしたものはtwitterやmixiやpixivといったSNS閲覧用
アプリをはじめゲームや楽器演奏アプリやテキストエディタやファイラーや動画再生
アプリなどにょ。
iPod touchだとPCとデータをやりとりするには専用アプリiTunesが必須だけどAndroidの
場合は動画を始めとするさまざまなデータは普通にmicro USBを接続するだけで転送
できるため便利にょ。
ここで注意する必要があるのはAQUOS CRYSTALで普通にPCと接続した場合にはMTPモードに
なっているため音楽ファイルしか転送ができないということにょ。
これは設定を変えてMTPからUSBマスストレージ接続にしてやれば良いにょ。
設定を変えるとPCとの接続時に画面にドロイド君が表示されるのでそこでUSBマスストレージを
ONにするというボタンを押せばAQUOS CRYSTALがリムーバブルディスクとして認識されるにょ。
これによってPCの中にあるファイルを自由に転送が可能になるにょ。
そうやって、動画などをどんどん転送していったら32GBのmicro SDHCがすぐに埋まって
しまったにょ(笑)
さて、あとはカメラ機能について書いておくにょ。
といっても、800万画素のごく平凡な性能のカメラであり特筆すべきものは何もないにょ。
とはいえ、特筆すべきものがないためカメラの撮影サンプルも本体が売れている割りには
ネット上でほとんど見かけないにょ。
というわけで、地元の梅の名所でまだ咲き始めたばかりの梅を撮影してみたにょ。
比較用として普段持ち歩いているコンデジ(Cybershot WX100)と10年前のデジタル一眼レフ
(Nikon D50)で撮影したものも用意したにょ。
リサイズ以外は無加工となっているにょ。(急いで撮影したのであまり良い写真ではない)
◎AQUOS CRYSTAL
http://ochameclub.web.fc2.com/test/ume_305sh_1.jpg
http://ochameclub.web.fc2.com/test/ume_305sh_2.jpg
◎WX100
http://ochameclub.web.fc2.com/test/ume_wx100_1.jpg
http://ochameclub.web.fc2.com/test/ume_wx100_2.jpg
◎D50
http://ochameclub.web.fc2.com/test/ume_d50_1.jpg
http://ochameclub.web.fc2.com/test/ume_d50_2.jpg
腐っても(?)デジタル一眼だけあってD50は別格なのだけどWX100とAQUOS CRYSTALを比べると
WX100の方が若干上に感じる程度でそれほど大きな差はないにょ。(WX100はピントが合った
部分はシャープだけどボケが汚いのでそれを考えると人によってはAQUOS CRYSTALの方が上に
感じるかもしれない)
WX100は暗所撮影は普及クラスのコンデジの中でトップレベルだけど屋外撮影はコンデジの中
でも下位に位置するレベルなのでそれを考えるとAQUOS CRYSTALはコンデジの中でも下位レベル
クラスに匹敵する性能になりそうにょ。
暗所だと高感度番長のWX100と比べると完敗なのでやはり普及クラスの機種だけあって特筆
すべきカメラ性能ではない感じにょ。
これでも、元使っていたガラケーと比べると桁違いに高画質だけどね。(905SHは発売当時の
ケータイの中でもあまり良い性能のカメラではなくその3年前に発売されたV601SHの方が
性能が上であるくらい)
私がスマホを購入するにあたって最も気にしていたのが画面剥き出しということにょ。
ただでさえ頻繁に落としたり踏みつけたりなどかなりの衝撃を加えているため私の使い方
ではとても厳しいだろうと予想していたにょ。
特にAQUOS CRYSTALは画面は非常にもろいアクリル製なので保護フィルムは必須にょ。
保護フィルムを貼るのは当たり前としてガード用にブックタイプの皮製カバーを購入したにょ。
そもそもAQUOS CRYSTALにはストラップ穴がないのでこういうケースを買わないとストラップ
さえ取り付けることができないにょ。
ケースの効果は抜群で手に持った状態から地面に落下したけどケースの端が割れた程度で
済んだにょ。
これが剥き出しだったら本体が確実に割れていたにょ。
というわけで、とりあえず2年間くらいはこの機種で様子を見ることにしたにょ。
それまで何とか壊れないといいにょ(笑)
プチコン3号 ver.3.1.0がついに公開!
プチコン3号のver.3.1.0にアップデートファイルが公開されたにょ。
バグ修正目的としてすでに公開されていたver.3.0.2と異なるのは新機能(新命令)が使用
可能になったということにょ。
http://smileboom.com/special/ptcm3/debug/update
加わったのは下記の命令、関数、システム変数にょ。
(1)CLASSIFY()関数
(2)GTRI命令
(3)GPUTCHR命令
(4)BGCOLOR命令
(5)システム変数HARDWARE
(1)CLASSIFY関数はinf、-infならば1、nan、-nanならば2、それ以外の数値は0を返す
関数にょ。
プチコン3号では実数型はPOW(2,1024)以上でinfになり整数型でPOW(2,31)以上になった時の
ようにOverflowにはならないにょ。
ただし、infはエラーでない反面一旦infになると正しい演算ができなくなるという問題が
発生するにょ。
あとinf-infはnanになるけどnanになってしまうとこれも正しい演算ができないにょ。
したがって普通はinfやnanになったらそれを判断はできないのでCLASSIFY関数でそれが
できるようになったというわけにょ。
ただし、これは現行でも似たような関数を作ることは可能にょ。
infは2倍してもinfのままなので0以外の数字で2倍して結果が変わらないならばinf(もしくは
-inf)と判断ができるにょ。
また、nanは符号を買えても大小関係が変わらないため0以外でそうなればnanもしくは-nanで
判断が可能にょ。
自作関数で対応できるといってもやはりデフォルトで用意されるメリットは十分にあるにょ。
(2)GTRIとは何かというと塗りつぶし三角形を描画する命令にょ。
要するにGFILLの三角形バージョンにょ。(プチコン3号発売当初は命令一覧表に記載されて
いたため楽しみにしていたけど発売時には削られた命令であり今回それが追加命令として
実装された)
これが最も有効活用できるのは3Dポリゴン表示をする場合だと思われるにょ。
といっても、塗りつぶし三角形は現状でもGLINEで実現が可能にょ。
私はmkIIで塗りつぶし三角形描画ルーチンを作りそれを元にプチコンmkIIとしては最速の
ポリゴン表示プログラムを作ったにょ。
◎塗りつぶし三角形描画ルーチン
http://ochameclub.web.fc2.com/petitcom/tips/routine.htm #triangle
◎プチコン用 ポリゴン表示プログラム
http://ochameclub.web.fc2.com/petitcom/polygon.htm
上記のmkII用の塗りつぶし三角形描画ルーチンをプチコン3号にベタ移植したものは
プチコン3号まとめwikiで公開しているにょ。(移植者:yuy@さん)
◎三角形描画プログラム
http://wiki.hosiken.jp/petc3gou/?Toukou%2F%BB%B0%B3%D1%B7%C1%C9%C1%B2%E8%A5%D7%A5%ED%A5%B0%A5%E9%A5%E0
ベタ移植とはいえプチコン3号は3DSアプリということでDSiからだとハードウェアの進化の分
だけ高速になっているしNew 3DSは旧3DSと比べて3〜4倍高速化されているためmkIIと比べると
New 3DSで実行時には20倍以上高速化されているにょ。
プチコン3号ならば自作関数定義によってGTRIと全く同じ記述が可能になるけれどポリゴン
ゲームなどで活用するならば速度が非常に重要であるためデフォルトで命令として備わって
いるというのは非常に大きいにょ。
では、どの程度の速度なのかを実際に調べてみたにょ。
◎三角形描画速度(1秒間の描画回数)
表示サイズ GTRI使用 3号 mkII 3号との速度比 mkIIとの速度比
64x64 27076 5118 253 5.3倍 107倍
128x96 20560 3601 163 5.7倍 126倍
200x120 15615 2892 126 5.4倍 124倍
256x192 11088 2000 84 5.5倍 132倍
400x240 6947 1505 N/A 4.6倍 N/A
※プチコン3号での速度はNew3DS使用時のもの
画面上の指定範囲にランダムな3点を指定して描画したのだけど表示サイズというのは
その範囲の大きさのことにょ。
プチコン3号ver.3.1.0で加わったGTRI、上記のプチコン3号移植版の三角形描画プログラム、
私がmkIIで作った塗りつぶし三角形描画ルーチンの3つにおいて表示サイズを変えながら
1秒間の描画回数(1秒間の表示ポリゴン数)はGTRI命令を使用時にはプチコン3号移植版の
プログラムと比べて5.5倍前後高速となっているにょ。
これはmkIIで作ったものと比べると120倍前後高速にょ。
面積当たりの速度がGFILLと同程度ならば10倍速以上になるため5.5倍速というのはやや
物足りない感じだけどそれでもポリゴン表示プログラムにおいて描画がボトルネックに
なっているため高速化が期待できるにょ。
ポリゴン表示プログラムはプチコン3号では作ってないのだけどmkIIからの速度向上率を
考えればGTRI命令を使用時の速度は概ね推測できるにょ。
◎ポリゴン表示プログラムの速度
モデル 演算表示fps 演算fps 表示の割合 予想速度向上率 GTRI使用時fps
立方体 18.9fps 45.2fps 58.2% 1.91倍速 794fps
トライフォース 12.4fps 30.9fps 59.9% 1.96倍速 535fps
24面体 13.5fps 25.6fps 47.2% 1.63倍速 484fps
アンドアジェネシス 1.6fps 3.9fps 58.9% 1.93倍速 68fps
上記はmkII版のポリゴン表示プログラムにおけるfpsにょ。
演算表示速度というのはそのポリゴン表示プログラムにおける処理速度にょ。
演算fpsというのはそれから描画部分を省略した場合の速度(ジオメトリ演算、フラット
シェーディング処理、Zソートにかかる速度)で表示の割合というのは全体の処理速度に
おける三角形描画処理の割合を示しているにょ。
モデルによって異なるけど描画だけで概ね6割近くの時間がかかっているためこれが
5.5倍になれば全体の速度も2倍近く高速化されるにょ。
それを元に各モデルを私がmkIIで作ったポリゴン表示プログラムをベタ移植して、表示
部分のみをGTRIにした場合の予想速度が「GTRI使用時fps」にょ。
カクカクだったアンドアジェネシスも68fps程度まで高速化が可能になると予想されるにょ。
(mkII→New3DSの速度向上率は22倍で計算した場合)
24面体で見てみると私がmkIIで作ったプログラムでも13.5fpsなので実効で324ポリゴン/秒と
なっているにょ。
モデルによって異なるけど実効速度で最大300ポリゴン/秒程度は出ているにょ。
これは1秒間に表示できるポリゴン数よりも多いけど陰影消去を行い裏面となっている
ポリゴンは描画しないことで高速化をしているためにょ。
GTRI使用時のプチコン3号だと484fpsということは実効で11616ポリゴン/秒となるにょ。
セガのハードであるSuper 32xが最大20000ポリゴン/秒なのでそれには劣るものの簡単な
ポリゴンゲームは十分に作れるくらいの速度出ているにょ。
30fpsで描画して1フレームあたり387ポリゴンで当たり判定その他に処理時間の半分が
取られたとして最大1フレームあたり150ポリゴンくらいは使用可能にょ。
ちなみに私がモデリングしたアンドアジェネシスが152ポリゴンなので単体ならば
これくらいのモデルが登場するゲームも30fpsで作れるというわけにょ。(15fpsが
許容できれば1フレームあたりのポリゴン数は2倍以上に増やせる)
さて、GTRIでZ座標が指定できないのは残念に思っている人もいると思うにょ。
これはプチコン3号ではGRP面は面単位でしかZ値を指定できないのでどうにもならないにょ。
というのも3DSにネイティブにGRP面というものが存在するわけではなく512x512の平面
ポリゴンに描画したものをGRP面として使用しているだけにょ。
1つのポリゴンなのでZ値は付けられないにょ。(回転ならばできそうだけど現時点では
サポートされてないので自前で作ったのが私の2軸回転プログラム)
もしも、3点のX,Y,Zを指定できる命令にするならばプチコン3号の仕様そのものを大きく
変える必要があるにょ。
PS2用ソフトの「BASIC STUDIO」では塗りつぶし三角形描画にX,Y,Z座標が指定可能だった
けれどその代わり最大で1000個までという制限があったにょ。
実際に使ってみれば分かるけどGグラフィック命令の使い勝手は制限がないプチコンの方が
BASIC STUDIOより圧倒的に良いにょ。
現状のプチコン3号でZ値を指定したいというのであればスプライトで三角形を描画するという
方法があるにょ。
プチコン3号ではスプライトの縦横自由拡大ができるので2つの直角三角形を組み合わせる
ことで自由な三角形の描画が可能になるにょ。
この方法だと最大でも250個の三角形しか描画できないけど1秒間に9000個の表示が可能に
なるにょ。(MAXの250個を使用した場合で表示だけならば30fps以上の速度が出せる)
さすがにGTRIと比べると遅いけどそれでも大きくなってもほとんど速度が落ちないため
GLINEを使った塗りつぶし三角形プログラムと比べると3〜5倍の高速化が可能にょ。
これでZ値と半透明処理ができるのならば使い方によっては悪くない選択にょ。(ただし、
バラバラのZ座標を指定できないためポリゴンの立体視はできずあくまでZソート代わりと
して使用できる程度)
(3)GPUTCHRは初代プチコンおよびmkIIでは地味に支持されてきた命令にょ。
GRP面に文字を表示するというものだけどドット単位の座標で表示できたりとか拡大表示が
できたりとかでコンソールにおける文字表示との差別化が出来ていたからね。
しかし、プチコン3号では命令として搭載されなかったにょ。
もちろん、文字の拡大表示ならばスプライトやBGにはアルファベットと数字や記号が用意
されているためそれを使って自作関数で実現するという方法もあるにょ。
実際私もBG面に任意の文字列を表示する拡大縮小対応のBGPUTCHR関数を作ったにょ。
プチコン3号で使えるすべての文字を使用したいというのならばプチコン3号のフォントが
記録されているGRPFリソースを使うという方法があるにょ。
これは一旦ロードした後にファイル名を付けて保存したら単なるGRPファイルになるため
そこからGCOPY、GSAVE、GLOADなどの命令を使って文字単位でGRP面に描画は可能になるにょ。
ただし、英数字以外は並びがバラバラであり任意の文字列を描画使用とするならば対応する
テーブルを作らなくてはならないという問題があるにょ。
またGRP面に描画する場合には任意の拡大縮小は命令としては存在しないため自前でドット
単位で拡大や縮小を行う必要があるにょ。
その煩わしさを一気に解消できるのがGPUTCHR命令にょ。
これを使えば任意の文字列を簡単に表示できるにょ。
mkII版のGPUTCHRは文字コードを指定して1文字ずつ描画する命令だったので任意の文字列を
表示するためにはFOR〜NEXTを使ったサブルーチンを作る必要があったにょ。
また、GPUTCHRでは拡大表示ができるけどmkII版は縦横同じ倍率のみで1倍、2倍、4倍、8倍
のみしか選択できなかったのがスプライトと同様に縦横自由な倍率で指定できるように
なったのはうれしいにょ。
あと文字色もGRP命令なので当然ながらRGBの32bit論理色に対応しているにょ。
コンソールのCOLOR命令は16色固定でそれ以外の色に変える手段が用意されてないため任意の
文字色で表示できるというのは大きなメリットだと思われるにょ。
というわけで問題は速度がどのように変わったのかを調べてみたにょ。
◎GPUTCHR速度(10000回の実行時間)
プチコン3号 プチコンmkII mkIIと比べて
1x1倍 1文字表示 3.7フレーム 85フレーム 23倍速
5文字表示 13.4フレーム 787フレーム 55倍速
4x4倍 1文字表示 10.3フレーム 271フレーム 26倍速
5文字表示 45.7フレーム 1809フレーム 40倍速
※プチコン3号はNew3DSで実行時のもの
デフォルトの1x1倍(8ドット角)で文字「A」を表示した場合の10000回あたりの実効時間を
見てみると同じGPUTCHR命令でもプチコン3号の方が圧倒的に速い(23倍速)し、4x4倍に拡大
すれば速度差はさらに大きく(26倍速)なっているにょ。
これが5文字表示(「ABCDE」という文字列)を行った場合には速度差がさらに広がっている
けれどなぜかというと上記のようにはmkIIのGPUTCHRでは任意の文字列を表示する機能がなく
FOR〜NEXTでループさせる必要があり、その分だけ遅くなっているためにょ。
GPUTCHRはmkIIでは重い命令の1つだったけどここまで高速ならば気軽に使えそうにょ。
(4)BGCOLOR命令はSPCOLORがあるならばBGCOLORが欲しいということで実装された命令にょ。
かなり期待が大きかった命令だけど実装されている機能はBG面全体にエフェクトをかけると
いう命令でスプライトのように表示キャラ単位で色を変える命令ではないにょ。
全体の色を変えるならば現時点でもスプライトの半透明機能を使えばいくらでも可能にょ。
スプライトのSPCOLOR命令を強力で乗算でしか色を変えられないもののその透過率は自由に
変えることができるにょ。
そのためエフェクトだけではなくスプライトそのものを半透明にするということが可能に
なるにょ。
そういったものをBGCOLORで想像していたから残念に思うけどこれはこれでエフェクト用に
スプライトを1つ使わずに済むということを考えれば歓迎すべき命令にょ。
(5)システム変数HARDWAREはプチコン3号をNew 3DSで実行している場合は1、旧3Dで実行して
いる場合は0の値を取るにょ。
New3DSは旧3DSと比べて3〜4倍速いためゲームを旧3DSでも動くように作った場合はNew3DSは
速度をもてあそぶことになるにょ。
旧3DSでまともに遊べるゲームならばNew3DSで実行時にはフレームレートを上げるとか画面の
クオリティを上げるということを行えるにょ。
逆にNew3DSでないとまともにプレイできないゲームの場合は旧3DSで実行時には警告を出したり
とかが可能になるにょ。
非常に便利なものとはいえ、これはプチコン3号発売当初ver.3.0.0の段階で搭載されている
のが妥当なものだと思われるにょ。
New3DSと旧3DSの速度は大きく異なるというのは発売前から分かっていたことだし、プチコン
3号はNew3DS対応を公式に謳っているわけだからね。
といっても、その機種判別は自作関数で実現可能にょ。
単純に速度を比較して一定以上の速度であればNew3DS、そうでないならば旧3DSという判断を
行えば良いにょ。
これは簡単に実現ができるためプチコン3号が発売された日に機種判別を行うNew3DS関数を
作ったにょ。
http://ochameclub.web.fc2.com/petitcom3/about.htm #new3ds
ver.3.1.0でHARDWAREが実装されたのでNEW3DS関数は不要になったにょ(笑)
さて、ver.3.1.0にバージョンアップしたことでver.3.0.2からどの程度速度が変わったのかを
見てみるにょ。
比較に使用するのは公式ベンチ(SYSフォルダのEX8TECDEMOを実行してOTHERから選択)である
「SPEED TEST」にょ。
◎SPEED TEST
ver.3.1.0 ver.3.0.2
たしざん 512804 ← 469342 9.2%アップ
PRINTぶん 143829 ← 135141 6.4%アップ
スプライトいどう 257266 ← 246157 4.5%アップ
ラインびょうが 60896 ← 66232 8.1%ダウン
SPEED TESTのmkIIやプチコン3号の初期版(ver.3.0.0)での実行結果はこちらを参照
http://ochameclub.web.fc2.com/petitcom3/about.htm #1
数%の測定誤差があるとはいえたしざんは今回のバージョンアップで若干高速化されていて
GLINEは若干ダウンしているといえそうにょ。
誤差程度とはいえ全体的には高速化傾向があるにょ。
ver.3.0.0からver.3.0.2は若干低速化傾向にあったPRINTとスプライトは今回のバージョン
アップで初期バージョン並に高速化されたという感じにょ。
今回のバージョンアップではさらにいろいろな改善点があるにょ。
命令に新たに加わった機能は省略するとして「TOP MENU」が変わったのが大きいにょ。
従来から項目数が増えて「Webプチコン入門」ボタンと「サンプルを見る」ボタンが追加
されたにょ。
プチコン3号では従来と比べて初心者が増えたイメージがあり、Miiverseでも頻繁に
「買ったけど何をしたらいいのか分からない」という質問が出ているにょ。
それは親切な人がその都度教えてあげているけれど公式の対応にも原因があったにょ。
というのも、プチコン3号のバグ修正などに手を取られて公式サイトのプチコン3号の初心者
講座がずっと工事中だったからね。
また、そういう初心者講座があるという存在さえ気づいてない初心者の人もいるにょ。
そういう人にとってはTOP MENUに専用ボタン(公式初心者講座のWebサイトへのリンク)が
用意されたというのは非常に大きいにょ。
(スマイルブーム公式)プチコン3号初心者講座
http://smileboom.com/special/ptcm3/beginner/
今回更新されたのはその講座でプログラミングに入る前の段階でプチコン3号を買ったけど
何をしたらいいのか分からないという人に宛てたものにょ。
http://smileboom.com/special/ptcm3/beginner/intro/
これが発売された当初にあれば買ったけど何をしたらいいのか分からないという質問をする
人は激減したのではないかと思われるにょ。
私が書いたプチコン3号入門講座でも同じように最初に何をしたら良いのかということを
書いているにょ。
プチコン3号入門講座「まず最初に何から始めたらいいの?」
http://ochameclub.web.fc2.com/petitcom3/lecture/first.htm
これはver.3.1.0ではメニュー画面が変わったので近いうちに対応させる予定にょ。
3月6日発売予定だったプチコン3号の公式ガイドブックが3月20日に発売延期になったのも
ver.3.1.0に対応させるためみたいにょ。
ニンテンドー3DSでプログラミング! プチコン3号 -SMILE BASIC- 公式ガイドブック
http://www.amazon.co.jp//dp/4198639272
細かい部分で仕様変更があるためver.3.0.2ベースで書いていたらその違いで初心者は
悩んでしまうからね。
私のプチコン3号入門講座はそれほど影響はないと思うけど内容を精査してver.3.1.0で
問題がないかサンプルプログラムなどをもう一度チェックする予定にょ。
週1回更新予定の入門講座も時間の都合でなかなか更新ができてないので私の入門講座が
完成する前に公式の初心者講座が完成しそうな感じにょ。
とはいえ、公式の初心者講座とは差別化するため私の入門講座はとりあえず多くの情報を
掲載しているにょ。
いろいろな使い方を提示しておいてその中から必要なものは何度も繰り返して強調して
書くことで初心者でも印象に残るようにしているにょ。(「条件判断では比較演算は
省略しないようにしよう」など)
プチコン3号 入門講座
http://ochameclub.web.fc2.com/petitcom3/lecture/
さて、今回の更新は喜ばしいことばかりかというとそうではなく一部のユーザーからはあまり
喜ばれてない部分もあるにょ。
それはスプライトの仕様が厳格化されてSPSETされてないスプライトを使用した場合にエラーを
返すようになったためにょ。
mkIIまではそれが普通だったためmkIIから継続のユーザーならば普通にSPSETを最初に使用
していたと思うけどプチコン3号では新規ユーザーが多いためかスプライト使用プログラムで
ver.3.1.0では動かないというものが多発しているにょ。(mkIIでも仕様変更で今まで作った
プログラムが動かなくなったということもあったので別に驚きはしないけど)
これはver.3.1.0のリリースが案内された時点で分かっていたのでそれ以降に作ったもの
ならば問題ないけど案内されたのが2月27日だからね。
こればかりはどうしようもないので制作者が個別で修正するのを待つしかないにょ。
もちろん、それが待てない場合は自らの手で修正するという方法もあるにょ。
制作者が対応を諦めた場合はプチコン3号ではサーバで公開した時点で改造などの二次使用は
認めたことになり自由に改造を行えるため元作品の著作者、改造作品であることを十分に
アピールした上で改造した作品を発表することはできるにょ。
二次使用がOKといっても著作権を放棄したわけではないので「これは自分で作ったゲームだ」
と発表してはならないにょ。
ということで、ver.3.1.0がリリースされてようやくここからがプチコン3号の真の出発になる
といえそうにょ。
数ヶ月以内に発売されるであろう海外版もこのver3.1.0がベースになると思われるにょ。
機能の追加等は随時行うみたいなので今後の展開も楽しみにょ。
mkIIから大幅に機能が低下したTALK命令も最低でもピッチなどには対応させていくらしいにょ。
(無題)
SPSETの混乱について
「旧来の仕様も残すべきだ」
「仕様が2つあるのはスマブ的に無茶だ」
などと言われているのを見て、思った解決策が
『ver.3.0.3をリリースし、SPSETせずにSPOFSすると
DIALOGで注意書きが出る。注意書きは出るだけ。』
というクッションを1度はさめば良かったんだなーって。
早い話、周知の徹底ってことですけど。
修正を配信する度に京都へ上納金やらが必要なのかとかは知らんけどさ。
「周知の徹底」と言えば多くの場合、法律の時に聞く言葉ですよね。
プログラム言語の仕様も法律のようなものなのか、と思えて
クスリときました。
プチコンについて
私もTALKの機能を追加して欲しいですねぇ。
来ましたね!
プチコン3号の新バージョンが来ましたね!
GTRI命令は諦めてましたが、バージョンアップで来たのが嬉しかったです。
また、性能比較お疲れ様でした。やはり速く動きますね…。
mk2ではエイプリルフールネタだったソルバルウもfpsと外見以外なら実現できるかも知れません。
レスにょ
チラシ裏次郎さんへ
>『ver.3.0.3をリリースし、SPSETせずにSPOFSすると
>DIALOGで注意書きが出る。注意書きは出るだけ。』
>というクッションを1度はさめば良かったんだなーって。
やはり、みんなが分かる状態で告知されたのが2月27日(ver.3.1.0の配布5日前)だったという
のが最大の問題点ではないかと私は思うにょ。
ver.3.0.2をリリースした段階でSPSETの仕様変更(バグ修正?)を行うつもりだっただろうし
2月始め(ver.3.0.2リリース1ヶ月以上前)にはtwitter上でSPSETの仕様変更については
小林社長からアナウンスされているにょ。
しかし、それはすべてのプチコン3号ユーザーが知っているわけではなくtwitterをやっている
人だけが知っている情報だったにょ。
やはり、変更を決定した時点でTOP MENUでのアナウンスをすべきだったにょ。
とはいえ、SPSETをせずに他のスプライト命令を使うというのは本来は正しい使い方では
ないにょ。
プチコン3号の初期バージョンのSPSETのヘルプにも下記のように記載されているからね。
(プチコン3号 ver.3.0.0のヘルプのSPSETの項目から引用)
SPRITEを作成し、キャラクタ定義テンプレートを割り当てる
これにより、作成した仮番号のSPRITEが使用可能になる
※SPSHOW命令にて表示をONにする
SPSETをせずにスプライトの他の命令を使用するというのは本来の動作とは異なるもので
あり、一種のバグにょ。
バグを突いたプログラムを作っておいてバグ修正されたら動かなくなったというのは
さすがにスマイルブームを責めることはできないにょ。(mkIIからのユーザーだと
エラーが出るのが分かっているのでなぜ出ないのか不思議なくらいだったし)
SPSETを使用しないで他のスプライト命令を使わざるを得ない理由としてはSPSETをした
場合には画面の左上にSPSETしたスプライトが表示されてしまうという問題がある
ためにょ。
これは初代から問題になっていてVSYNCの直後にSPSETを実行して即座にSPOFSで座標を
変えるという回避手段で何とかしていたにょ。(私の実験ではスプライトの表示が反映
されるまで0.95フレームの遅延があるため0.05フレーム以内にSPOSFすれば回避できた)
しかし、プチコン3号では上記のヘルプを見る限りではSPSHOW命令を実行するまで
表示されないみたいに思えるにょ。
しかし、実際はそうではなくSPSETをした段階で表示されるにょ。
それを考えるとヘルプが間違っているわけでバグを突くようなプログラムを作った
ユーザーを責めることもできないにょ。
そして、ver.3.1.0のSPSETのヘルプにはSPSHOWに関する記述は無くなったにょ。
SPSETの動作がヘルプ通りになったのだけどSPSETを実行した段階で画面に表示されて
しまうという問題が再び出てきてしまったにょ。
それを回避するためデフォルトではSPHIDEの状態になっていてSPSHOWを実行することで
表示するようにすべきだったけどSPSETの項目からSPSHOWに関する記述が無くなった
ためその対応はしないとのことかもしれないにょ。
確かにお手軽さがプチコンの良いところでSPSETをした段階で表示できるというのは
お手軽さという点ではメリットはあるもののデフォルトでOPTION SPSETの状態に
なっていてOPTION SPHIDEが選べる(SPSETの段階では表示しない選択ができる)
という設定を増やすのがベターだと思われるにょ。
したがって、SPSETの仕様変更そのものは問題ないけどSPSETをあえて最初に使わなかった
ユーザーの気持ちも配慮してもらいたいにょ。(プチコン3号の初期バージョンの
時点でヘルプ通りの動作をしていたならばこんな問題は起きなかったけど)
みほさんへ
>私もTALKの機能を追加して欲しいですねぇ。
確かにTALK命令に関してはmkIIより大幅に機能低下しているので残念なところにょ。
しかし、これはmkIIの時のエンジンが使えなくなり一から作り直しているため将来的には
さらに高機能化の予定になっているにょ。(最低でもピッチには対応するとのこと)
https://twitter.com/notohoho/statuses/571892075836276736
mkIIの音声合成エンジンはライセンスの問題で海外バージョンではTALKによる音声合成が
できなかった(命令自体はあるけど何もしない命令だった)けれど今回はその問題を
解決するために音声合成エンジンを変えたのかもしれないにょ。(既存の音声合成
エンジンのライセンスを受ければ簡単にmkII並のことはできてしまうけどmkIIの時
と同じことになってしまう)
yuy@さんへ
>GTRI命令は諦めてましたが、バージョンアップで来たのが嬉しかったです。
>また、性能比較お疲れ様でした。やはり速く動きますね…。
プチコン3号のGTRIは初期バージョンのマニュアルに掲載されていたときには喜んで使ったけど
実装されてない命令とのことなのですぐにマニュアルの方から削除されてしまったという
経験があるだけに今回の搭載(復活?)はうれしいにょ。
予想(というか理想)では10倍速だったのが5.5倍速だったけどそれでもポリゴンゲームの
実現化にはかなり有用にょ。
Miiverseやtwitterを見るとすでにGTRIを活用したプログラムが発表されているにょ。
>mk2ではエイプリルフールネタだったソルバルウもfpsと外見以外なら実現できるかも知れません。
私がモデリングしたアンドアジェネシスもどきも単体ならば60fps以上で動作すると予想されて
いるため30fpsで動くゲームならば十分に作れそうにょ。
あのモデリングデータは自由に使っていいのでぜひyuy@さんがソルバルウっぽいゲームを
作ってみてにょ!(このアンドアジェネシスもどきはモデリングツールなどを使わず脳内
のみで座標計算をしたのであまり良い出来ではないけど)
(無題)
SPSETとSPHIDEについて、社長の見解はこちら。2014年11月24日
https://twitter.com/notohoho/status/536927678188634112
1つ言えるのは、このSPSETについて公式は「バグの修正」とは言わず
「仕様変更」と言ってることですね。(見落とし等なければ)
様々な意見を目にしますが、どの言い分も
分からなくはない部分を含みます。
ただ、やっぱり言えることは、
それこそ「大きな影響の予想される『 仕 様 変 更 』」だからこそ、
地上デジタルTVの時並に大げさに周知するのが
最善だったよなー、と思えるのが残念でしたね。
CSS初使用
http://waaimyroom.web.fc2.com/bustransferguide.html
もともとWordで作ったけど公開するのにHTMLのほうがよさげな気がしたので作り直す際、ワードアートをCSSに。
http://waaimyroom.web.fc2.com/
jsもやるが
意味不明なエラーで詰む
function PutResult(){
var num
document.write("通過予定時刻は"+PassTime[document.selbox.GetOff.selectedIndex][0]);
num=document.selbox.GetOff.selectedIndex; ←この行でエラー
for (var i=0 ; i<=2 ; i++){
??//デバッグ用
??document.write("FOR実行 i="+i);
};
};
リスト選択で選んだ降りるバス停の時刻を表示する関数
デバック用の「FOR実行」という表示が出てこないのでChromeのチェック掛けたら
Uncaught TypeError: Cannot read property 'GetOff' of undefined
とか言われて詰んでる
しかもちょっと書き換えたらdocument.write("通過予定時刻は"+PassTime[document.selbox.GetOff.selectedIndex][0]);
のほうがエラー源になる
FireFoxだと
TypeError: document.selbox is undefined
どうもブラウザの問題かも(ブラウザによって言うことが違う)
Chrome:GetOffが変だよ
FireFox:selboxが変だよ
って言っているように感じるから
http://waaimyroom.web.fc2.com/
原因が分かった気がする
document.ほにゃらら.selectedIndexの同じものを2回以上呼ぶとだめらしい
ので変数に代入して使います
完成版
http://waaimyroom.web.fc2.com/bus/KawajimaLoopBusTimeSearch.html
http://waaimyroom.web.fc2.com/
作ってはみたいのですが
アンドアジェネシスは出してしまうと明らかにアウトなので遠慮しておきますね。
そういえば、ポリゴンプログラムの移植は三角形描画プログラムを移植してから行おうと
(むしろそのために移植した)しましたが、
色の仕様がmk2と異なっているのでどう変更してやろうかと考えようとして諦めちゃってますね…。
どう変更すればよいのでしょうか?
13日の金曜日 ジェイソンに2ちゃんプラウザが やられた
ギコナビが死んだな この方法で見れるらしいけど面倒だな
http://anago.2ch.net/test/read.cgi/software/1426210184/2
http://liv0.com
レスにょ
チラシ裏次郎さんへ
>1つ言えるのは、このSPSETについて公式は「バグの修正」とは言わず
>「仕様変更」と言ってることですね。(見落とし等なければ)
私のレスではSPSETについて2つの話題が混じっていて分かりにくい部分があったみたい
なので少し補足をしておくにょ。
1つ目はSPSETをした場合には(初期バージョンの)ヘルプの記述通りSPHIDEではなくSPSHOW
状態になってしまう点でこれはその引用している社長のツイートにあるように公式で仕様と
して認識されているためヘルプの方が間違っているわけにょ。
2つ目が今回のSPSETの話題で最も重要だった点でSPSETを使用せずにSPOSFなどのスプライト
命令を使うとエラーを返すようになったという点にょ。
これは、今回はSPSETの「仕様変更」といっているけど実際のところは単なるバグだと
思われるにょ。
仕様とバグというのは第三者には判断ができないけど制作者が認識している不具合(意図
しない動作)がバグ、そうでないものは仕様として使われるにょ。(一見バグのように
見える挙動でも制作側が認知して仕様として判断すれば仕様になる)
http://ochameclub.web.fc2.com/ochamewords.htm #bug
http://ochameclub.web.fc2.com/ochamewords.htm #shiyou
プチコンmkIIでもSPSETをして使うものだったし、プチコン3号のヘルプでもそのように
書いているところからすると「ヘルプにはあのように書いているけどSPSETをしなくても
使えるようにした」とは考えにくいにょ。
そう考えるとこれは制作側の意図とは異なる動作であるためバグと言っても過言ではないにょ。
これは社長のツイートからもくみ取れるにょ。
https://twitter.com/notohoho/statuses/571196910410706945
「今回の調整でSPSETのエラーチェックが厳密になりSPSETでずにSPHIDEやSPOFS等を使っている
プログラムはエラーが出ます」というのは言い換えれば従来はエラーチェックが十分では
なかった(言い換えれば本来ならばエラーが出るような使い方でもエラーが出なかった)と
いうことでやはりこれを上記の意味の仕様ではなく(プレイヤー側の感覚では)バグとして
捉える方が妥当にょ。
ただ、公式でSPSETにはバグがあるとは公式発表してないため「仕様変更」と言っているだけに
すぎないにょ。(SPSETせずにスプライト命令が使えてユーザー側が認知できる問題が発生
するのであればバグとして発表したと思われる)
とはいえ、開発者が意図しないSPSETを使用せずスプライト命令を多用するという使い方が
広く使われている(これを改善するにはデフォルトでSPSHOW状態にするだけではなくSPHIDE
状態にするべきだった)というわけで甚大な影響が出てしまうにょ。
例えばプチコン3号ではOPTION STRICTで変数を定義しないと使えないようにできるけど
これがデフォルトで設定されていて定義無しで使用できるモードがないと仮定したときに
実はヘルプには定義しないと使えないとヘルプには書かれているけど使わずに使えると
言ってみんな定義せずに変数を使っていったみたいな状況が現在のSPSETにょ。(ヘルプには
使う前に定義しなくてはいけないと書いていても定義しなくても使える状態)
変数ならば最初に定義すればいいだけのことなので修正も簡単だけどSPSETの仕様変更は
それだけでは済まないため厄介にょ。
>地上デジタルTVの時並に大げさに周知するのが
>最善だったよなー、と思えるのが残念でしたね。
仕様変更そのものは問題ないけどや先日も書いたようにはり広く告知したのがver.3.1.0の
配信5日前だったというのが問題にょ。
仕様変更が決定した時点で広く告知していればここまで大きな問題にはならなかったにょ。
告知が遅れたのならばver.3.2.0で変更を行うという選択肢もあったはずだけどそれを
やらなかったのは海外verとの兼ね合いもありそうにょ。(恐らく海外版はこのver.3.1.0が
ベースになると思われる)
天郷思音さんへ
>原因が分かった気がする
自己解決したみたいで良かったにょ。
javascriptといえば以前「まったくjsは最高だぜ!」が口癖の男子高校生が講師という
設定(生徒役は5人の女子児童でうっとりするほどキレイなコードを書く子やメガネっ娘
PG(プログラマ)などが登場)で進めていく入門本を作るアイデアがあったにょ。
とはいえ、私はjavascriptは入門本をかじった程度の知識しかないためお蔵入りになって
しまったにょ。(というか、すでに誰かが作ってそうな予感)
yuy@さんへ
>そういえば、ポリゴンプログラムの移植は三角形描画プログラムを移植してから行おうと
>(むしろそのために移植した)しましたが、
>色の仕様がmk2と異なっているのでどう変更してやろうかと考えようとして諦めちゃってますね…。
>どう変更すればよいのでしょうか?
ポリゴンデータはmkIIでは3頂点+パレット色(1〜15)だったのをプチコン3号では
3頂点+論理色コードというデータに変えるだけでいいにょ。
私がプチコンmkII用に作ったポリゴン表示プログラムは処理速度を稼ぐためにあらかじめ
256色パレットに16色x16階調を生成していてそれから選択しているにょ。
平行光源+フラットシェーディングの場合にはポリゴン面の法線ベクトルと光線ベクトルの
成す角度θを使いcosθの値だけでポリゴン面の明るさ(階調)が分かるにょ。
これは16段階のうち何段階目かというプログラムになっているのだけどプチコン3号の場合は
リアルタイムにポリゴン面の設定色のR、G、Bの各成分にcos θを掛ければいいだけにょ。
立方体ならば最大6回cosθの値をR、G、B各成分に掛けるだけなので大して負担増にはならない
はずにょ。
論理色コードが1〜15の時はプチコンmkIIのパレットの色となるようなテーブルを用意して
おけば私が作ったポリゴンデータは修正せずにそのまま使うことも可能にょ。
プチコン3号ならばプチコンmkIIではリアルタイム処理が困難であったテクスチャマッピングを
行うのもありだと思うにょ。
テクスチャ描画速度はmkIIでは最大で6000テクセル/秒程度なのに対してプチコン3号は
20万テクセル/秒程度の速度(mkII比で30倍程度の速度)が得られるので単体モデルを表示
するだけならば十分にリアルタイム処理(タッチに追従して回転が可能な速度)が可能だと
思うにょ。
マリモーマさんへ
>13日の金曜日 ジェイソンに2ちゃんプラウザが やられた
2chの仕様変更によってほとんどの専用ブラウザが使えなくなってしまったからね。
私はここ数年全く書き込んでないし、最近は閲覧はスマホでのみ行っている(使用している
ソフトはAndroid用の「2chMate」)ということであまり影響はないにょ。
冬コミで頒布したプチコン3号入門本を無償公開!
私が昨年末の冬コミ(コミックマーケット87)で頒布したプチコン3号入門本「ハピネス
チャージ プチコン プチコン3号入門」をサイト上で無償公開を開始したにょ。
プチコン3号入門本の紹介(どんな内容か知りたい人はどうぞ!)
http://ochameclub.web.fc2.com/CLUB/image/h_c_p.jpg
プチコン3号入門本の無償公開ページ
http://ochameclub.web.fc2.com/CLUB/petitcom3_guide1/
このプチコン3号入門本はプチコン3号で始めてプログラミングに挑戦する初心者に向けて
作ったものだけどWebサイトで更新を行っているプチコン3号入門講座とは異なる部分と
しては必要最小限の部分をざっくりと書いているという点にょ。
サイト上のプチコン入門講座も同じく初心者向けに書いているのだけどWeb上で行うであろう
公式講座とバッティングしないように私の持ち味(?)として可能な限り詳しく書くという
ものにしているにょ。(ざっくりとしたものが良ければ「公式をどうぞ」というスタンス)
したがって、この入門講座だけでも完結可能だけど公式講座を読んでさらにこの入門講座を
読めば理解が深まるというような内容になっているにょ。
◎プチコン3号入門講座
http://ochameclub.web.fc2.com/petitcom3/lecture/
ただし、「情報量の多さがウリ」というのは逆に「情報量が多すぎる」という問題を
抱えることになるにょ。
それは重要部分は「何度も繰り返して書く」(例えば条件判断において比較演算は
省略せずに書くということは口が酸っぱくなるくらい書いている)ということで少し
読んだだけで内容があまり理解できてない人であってもこれが重要であるということ
くらいは分かると思うにょ。
あと文字色は必要以上に多くしないことで赤字や太字の効果が分かりやすくなって
いるにょ。(あまりカラフルにするとどれが重要なのかが分からない)
とはいえ、そんなプチコン3号入門講座も「情報量を多く」というのがネックになって
更新が遅れ気味となっているにょ。
やっぱり、スプライトやビット演算は重要なのでできるだけ早く書きたいし、モーション
センサーやジャイロセンサーの使い方についても知りたいというという人も多いだろう
からそれならばプチコン3号入門本をネットで公開すれば当面は解決できる問題にょ。
もっともこれは公式講座が本格的に始まったり公式ガイド(3月20日発売予定)が発売
されたらそちらの方を推してしまいたくなるのでどうせ夏コミまでに公開する予定
だったのでこのタイミングで公開するのがベターだと判断したにょ。
夏コミ前に公開予定だったのは夏コミではこの本の後編となる実践編を用意する予定と
しているためこの本(前編)を読んでない人だと理解するのが難しくなってしまう
可能性があるからにょ。(後編だけでも完結する内容にはする予定だけど実際のゲーム
プログラムの作り方をメインとしているためSmileBASICについての基礎知識がないと
厳しいし、このキャラの掛け合いも「こいつら誰?」という状態では感情移入がしにくい
だろうし)
このプチコン3号入門本はざっくりした説明になっているのだけどビット演算に関しては
それなりに詳しく書いているにょ。(といっても、ボタン判定に必要な部分のみ)
表示、入力、ループ、条件判断を網羅しているためこれを読めば簡単なプログラムは十分に
作れるようになるのではないかと思われるにょ。
ただし、ゲームを作るにはボタン入力は書いているけどキャラの動かし方は書いていない
ためやはり後半まで待つ必要があるにょ。
ちなみに今日3月14日はプチコンmkIIが発売されてちょうど3年にょ。
mkIIは最初の1年はQRコードが使えることから初代以上の盛り上がりを見せたものの2年目は
1年目と比べて発表されるプログラム数も大幅に減ったにょ。
3年目はプチコン3号の発売があったため2年目以上に減ってしまったにょ。
確かにプチコン3号はスペック的には魅力的な部分も多いけどmkIIにはQRコードを使って
自由に公開できるというアドバンテージがあるにょ。
QRコード生成も公式でなくてもユーザー作成のソフトで可能になっているためmkIIが入った
本体の寿命が尽きるまでは廃れることは無さそうにょ。
逆にプチコン3号はスマイルブームのサーバ経由の公開しかできないのでサーバでの公開
サービスが終了した時点で公開する手段を失うにょ。
まぁリストで公開(編集画面を公開)という手段もあるものの数KB〜64KBのメモリしか
なかった昔の8bitパソコンとは異なり、最大8MBのメモリが使用可能でサイズが大きく
なりがちなプチコン3号のプログラムではあまりに辛すぎるにょ。
非公式で良いならば音声による通信も可能になったにょ。
ただし、ケーブル接続しても1200bpsというのは遅すぎるにょ。
何せGRP1枚が512KBだからね。
比例計算するならば回線が不安定な1.5MbpsのADSLでCD1枚分のデータをダウンロード
するような感じにょ。
ケーブル接続をしないならば部屋が無音状態を長時間維持する必要があるにょ。
そうなるとQRコードを読み取る方が遙かに簡単に感じてしまうにょ。
したがって、公式サービスが終了した時点でプチコン3号は自分で作るだけのことしか
できなくなるといっても過言ではないにょ。
(無題)
システム変数MICSIZEを使わずに数値262112を直書きしてるのは何か意図があるんですかね?
>(プレイヤー側の感覚では)バグとして捉える方が妥当
>制作側が認知して仕様として判断すれば仕様になる
>公式で(略)「仕様変更」と言っているだけにすぎない
つまり公式が3.1.0より前まではそれが仕様だったと認めているので、
仕様として判断していたので結局、仕様だったわけでしょ。
公式が仕様と言ってるのだから、
プレイヤー側の感覚ではそれをバグとして捉える必要は全然ないので
急で重要な仕様変更に反発とかする人が出るのは当然ですね。
社長のツイートは厳密な公式ではないし。
仕様と認めちゃったのは愚策だったのではないか
バグだったとすれば今より良かっただろうに
説明書の文言が信用できないと感じさせるほど
二転三転したり間違いが多かったりしたのも、とても悪かった
自分よりも詳しいだろう貴方がMICSIZEを使わないのは
何か自分の知らないバグに気づいておられるからに違いない!・・・と思いわざわざ来させる程に。
ちなみにSPSETのデフォルトをSPHIDE状態にするべき
という考え方には、個人的には反対です。
ガラケーだと2ちゃんねるが見にくい
4月の視聴アニメまとめたよ
http://marimooma.blog.so-net.ne.jp/2015-03-20
https://twitter.com/marimooma/status/578744212650246144
今期は 「長門有希ちゃんの消失」と「ハロー!!きんいろモザイク」がメインだよ
http://www.nicovideo.jp/watch/sm25787032
http://liv0.com
レスにょ
チラシ裏次郎さんへ
>システム変数MICSIZEを使わずに数値262112を直書きしてるのは何か意図があるんですかね?
上記のTIMER()関数のことを言っているならばこれは少しでも処理速度を上げるためにょ。
MICSTARTの第2引数を変えない限りはシステム変数MICSIZEの値は固定値を示すにょ。
システム変数はリテラルの数値よりは遅いためこうすることで速度アップができるにょ。
これだと引数を変えた際に柔軟に対応ができないと考えるかもしれないけどそもそも引数を
変えて使うのは考えにくいし、どっちにしろサンプリング周波数を1000で割った32.73も
リテラルで指定しているためMICSTARTの引数を変えることを前提にするとこの32.73についても
言及する必要があるにょ。
つまり、262112の部分をMICSIZEにしてもプラス要素が全くなくて遅くなる分だけマイナス
ということにょ。
では、実際にどれだけ速くなったのかというと測定してみたら約500n秒だったにょ。
まぁほとんど気休め程度にしかならない速度向上にょ。(ちなみに整数加算1回が30n秒
くらいなのでそれと比べたら1桁遅い処理になる)
速度を上げるならばサンプリング周波数を下げるという手もあるにょ。
しかし、それは測定精度を下げることになるにょ。
秒単位の長い時間を計測する場合には32KHzも8KHzも大した差はないけど1フレーム以下の
ごく短時間を計測する場合だと32KHzと8KHzでは誤差が数倍異なるにょ。
したがって、精度を上げるため32KHzにしているにょ。
VSYNCを基準にした場合だと私の環境では32.73ではなく32.81の方が正確な値(VSYNC 60が
ほぼぴったり1000m秒になる)を示すけどそもそもVSYNCはぴったり1/60秒間隔ではないし
プチコン3号はVSYNCそのものが安定していないためVSYNC基準というのはあまり意味がある
とはいえないにょ。
>プレイヤー側の感覚ではそれをバグとして捉える必要は全然ないので
>急で重要な仕様変更に反発とかする人が出るのは当然ですね。
それが普通の感覚かもしれないにょ。
私は、過去のバージョンからの推測でそのような判断を行ったわけなので少なくとも
プチコン3号から入った人だけではなく初代から深く使い込んでいるという人で無ければ
私のような感じにはならないかもしれないにょ。
それに深く使い込んでいてもそれをバグとして捉えるかはまた別問題だしね。
あくまで「バグ」というのは私の個人的な価値観に基づいてのことにょ。
>仕様と認めちゃったのは愚策だったのではないか
>バグだったとすれば今より良かっただろうに
少なくとも最初からバグと公式発表していれば今回のような問題は起きなかったと思うにょ。
そういう意味では判断を誤ったかもしれないにょ。
>ちなみにSPSETのデフォルトをSPHIDE状態にするべき
>という考え方には、個人的には反対です。
私もデフォでSPHIDEになる設定ができればいいかなという感じで購入直後の状態では現状の
SPSHOWになる方が望ましいと思うにょ。
マリモーマさんへ
>ガラケーだと2ちゃんねるが見にくい
ガラケーも通話とキャリアメールだけならばスマホよりも断然に使いやすいけど2ch閲覧という
レベルであってももはや使い勝手が良いとはいえないにょ。
ガラケーで普通にWeb閲覧できていたのはWebサイトがガラケー用に作っていたためなので
スマホが普及してPC用、スマホ用、ガラケー用と管理するのは大変になったのでガラケーの
対応がどんどん無くなってきているにょ。
その結果ガラケーでのWeb閲覧がし辛くなっているにょ。
>4月の視聴アニメまとめたよ
私も来月初頭までにはまとめる予定にょ。
>今期は 「長門有希ちゃんの消失」と「ハロー!!きんいろモザイク」がメインだよ
私もきんモザは楽しみにょ!
プチコン3号のDEFで作った自作関数、命令の解説(上記の続き)
上記の続き
次にフェードイン、フェードアウト命令の解説をするにょ。
フェードイン、フェードアウトに関してはプチコンmkIIでも作ったにょ。
フェードイン/フェードアウト
http://ochameclub.web.fc2.com/petitcom/tips/routine.htm #fadein
このプログラムの原理を簡単に説明するとプチコンmkIIではBG(コンソール共用)、GRP、
スプライトは256色のパレット方式(BG、スプライトは16色x16パレット)であるためその
パレットの色を変化させて段階的に黒に近づければフェードアウト、その逆を行えば
フェードインになるにょ。
しかし、256色パレットを3つ分リアルタイムで書き換えるのはプチコンmkIIであっても
かなり重い処理だったにょ。
そのパレットではなくRGB指定のみになったプチコン3号ではピクセル単位で処理をする
必要があり、さらに重くなってしまうかというとそうではないにょ。
実はSPANIMを使えば超簡単に実現できてしまうにょ。
その前に知っておく必要があるのはスプライトではSPCOLORを使って論理色コードをRGB関数
で指定する際にはA(アルファチャンネル)の値で半透明表示が可能ということにょ。
つまり、画面全体を覆うスプライトを用意しておいて黒から透明に変化させていけば
フェードインの完成ということにょ。
黒だけしか使わないならば適当にSPDEFで400x240ピクセルのスプライトを定義すればいいの
だけど黒以外の色も使いたいならばスプライトのベース色は白がいいにょ。
ならば、GFILLを使ってGRP4の400x240の範囲を白く塗りつぶせばいいかというとそんなことを
する必要はなくデフォルトスプライトの中に8x8のサイズの白い四角があるためそれを
SPSCALEで拡大すればいいだけにょ。
8x8ドットならば画面全体を覆うためには50x30倍すればいいかというとそうではないにょ。
立体視の視差による影響や優先順位を考える必要があるためにょ。
画面全体を覆うためにはスプライトのZ座標は-256にする必要があるにょ。
そのようにしたら覆っているスプライトはすごく飛び出て見えそうだけど均一色であるため
左右視差が発生しないので見え方は全く問題はないにょ。(飛び出て見えるというのは
左右で異なる映像が見えているせい)
では、全く問題がないかというとそうではなく400x240の大きなスプライトが左右異なる
場所に表示されているため左端や右端が欠けて見えてしまうにょ。
つまり、左右視差の分だけ左右のサイズは大きくする必要があるにょ。
プチコン3号では最大視差は8ドットなので左右8ドット分大きくすればこの問題は解決
できるけどかなり余裕を持たせて16ドット分としているにょ。(負担増はほとんどない
のでこうすることのデメリットはない)
これはSPSCALEの拡大率は横方向に54倍になり、SPOFSの表示座標はX座標を-16にすると
いうことにょ。
これで特定の色で画面全体を覆うことはできるのであとはそれを段階的に色を変化させる
だけにょ。
それにはSPANIMの"C"オプションを使うと超簡単にょ。
何せ中間色は自分で計算する必要はなく自動的に線形補間してくれるからね。
しかも、何フレームで色を変えるのかも指定できるのでFADEOUT 180とするだけで180
フレーム(3秒)でフェードアウトが可能になるにょ。
ここで注意すべきはフェードインは黒から透明だけを行えばいいのだけどフェードアウトに
関しては透明から黒とは限らないということにょ。
今回作ったSETCOLOR命令やVARCOLOR命令などによってすでに画面の色が透明ではなく
別の色になっていることを考慮してSPCOLOR OUTで現在の色を取得しているにょ。
「それを言ったらフェードインも黒から透明とは限らないのでは?」という意見もありそう
だけどその場合はフェードインに別途引数を渡す必要があるにょ。
基本的にDEFによる命令や関数は引数を省略した書き方はできないため滅多に使用しない
ような用途のために引数を用意するのはあまり使い勝手が良いとはいえないにょ。
必要になるとすればフェードアウトをする前の色に戻すという場合が大半だろうけど
その場合はグローバル変数にその色情報を入れておく必要があるにょ。
わざわざそのためだけにグローバル変数を定義して云々の注意書きを行う必要があるだけ
ではなくFADEINで自動的に元に戻すためにはFADEOUTを実行時にも元の値を保存するか否かの
オプション設定を行う必要があるけどせっかくシンプルにまとまったプログラムが冗長になる
ためやめたにょ。
またフェードイン、フェードアウトはSPANIMによる自動処理であるためその処理はバック
グラウンドで行われるにょ。
ただし、フェードインとフェードアウトが連続する場合はウェイトを挟まないと正常な
動作ができないにょ。
つまり、FADEIN 300ならばWAIT 300が必要ということにょ。
これは単にFADEIN 300:FADEOUT 300のように連続して書いた場合に誤動作してしまうという
だけなのでそれにさえ注意して使えば問題ないにょ。
SPANIMを使わず段階的に変化するプログラムを自前で用意したり、SPANIM使用時でもDEF内に
WAITを入れたりするとフェードインやフェードアウトが完了するまでは何も行えないにょ。
このフェードイン、フェードアウト命令はそれぞれSPANIMEを使って描画しているのではなく
任意の色から任意の色に変化させるVARCOLOR命令を使っているにょ。
というのもフェードインやフェードアウトは共通部分が多いし、スプライトの初期設定処理を
別途FADEINITなどの命令を作って行うようりも汎用的なVARCOLOR命令を作ってそこで初期化
処理を行う方が短くなるためにょ。
そして、任意の色から任意の色に変化させる汎用命令があればホワイトアウトやレッド
アウトにも対応できるし、それ以外の自由な使い方もできるからね。
ホワイトアウトならばVARCOLOR RGB(0,0,0,0),RGB(255,255,255),300のように透明色から
不透明の白へと変化させればいいだけにょ。
あと変化はさせないけど特定の色に画面全体を変えたいという場合のためにSETCOLOR命令も
用意しているにょ。
これは、SETCOLOR RGB(160,0,64,200)とすれば海中にいるような表現も可能になるにょ。
しかし、この場合は画面の最前面に半透明の青っぽいスプライトがあるためコンソール
文字も青くなってしまい見辛くなるにょ。
コンソールを消さないようにするためにSPOFSでコンソールより後ろに置く必要があるにょ。
これはZ座標を省略した場合コンソール文字はZ座標が0になるためSPOFSで管理番号0の
スプライトのZ座標を1にすればいいだけにょ。
もちろん、その場合は他のスプライトなどがZ座標0以下になればSETCOLORの効果適用外に
なってしまうため自分のプログラムで使用しているZ座標を把握しておく必要があるにょ。
VARCOLOR命令やFADEIN、FADEOUT命令ではDEF内にSPOFSがあるためもしもコンソール文字を
除いてフェードアウトしたいという場合にはVARCOLORのDEF内にあるSPOFSを書き換える
必要があるにょ。
これは画面を覆うスプライトのZ座標を引数で設定できるようにすればプログラムを書き
換えずに対応できるけどそれは上記のように滅多に使わないものに余分な引数を用意したく
ないということで必要な人は各自で対応するといいにょ。
次はSUFFIX()関数について書くにょ。
これは変数の型を取得できる関数で実数型の時は1、整数型の時は-1、文字列の時は0という
値を返すにょ。
この関数が何に使えるかというとDEFで自作関数(命令)を作るときに便利にょ。
というのもDEFではDEF A(B)としたときにはこの時点で変数Bは数値変数か文字列変数かが
確定しないためにょ。
つまり、このSUFFIX()関数があれば引数に文字列と数値のどちらでもOKとなる関数や命令を
作ることができるというわけにょ。(その使用例が下記のBTWAIT命令)
まず、数値と文字列の判別にょ。
これはinfとnanを駆使して判別を行うという方法もあるけど実はプチコン3号(ver.3.1.0)
では、文字列変数への数値の代入はできないけど式の比較演算をした際には「3」という値を
返すにょ。
本来ならプチコン3号の場合は0か1しか返さないのでこれはバグの可能性も高そうだけど
これを使うことで大幅なリスト短縮ができるにょ。
数値か文字列かの判別ができたら数値が整数か実数かの判別にょ。
これは変数Vに0.5を代入して0になるか0.5のままかで分かるにょ。
というわけで、知っていれば簡単に作れるSUFFIX()関数だけど普通に作れば恐らくほとんどの
人が四苦八苦すると思われるにょ。
BTWAIT命令について書くにょ。
これは「Aボタン入力待ち」などのボタン入力待ち状態を書けない初心者のための命令だけど
Aボタン専用では使える範囲が狭いので汎用性を高めているにょ。(専用にして短いリストで
済ませるというのも1つの選択肢ではあるけど今回はせっかく作ったSUFFIX()関数の活用例
としての意味合いもあるため汎用性を高くした)
AボタンとBボタンを両方押すまで待つとかも作れるけどその際にはSUFFIX()関数を用いて
BTWAIT 48 と BTWAIT "AB" のどちらでも動作するようになるにょ。(もちろんリテラル
での指定ではなく数値変数や文字列変数の指定も可能)
文字列で指定した際のBUTTON()関数の値を求めるのがBTNUM()関数にょ。
BTNUM("AB")で48という値を取得できるにょ。(リストが長くなるのでBTNUM()の方は拡張
スライドパッドのZL、ZRには対応していないのでZLやZRを使いたい場合は数値で指定する
必要がある)
このBTWAIT命令のリストを見るとREPEAT〜UNTILが2回使われて冗長に感じるかもしれないけど
これは誤動作防止のためにょ。
Aボタン入力待ちでAWAIT "A"が連続する場合はAボタンを長押ししていたらボタン入力待ちが
有効に働かないため最初のREPEAT〜UNTILでボタンが離されるまで待ち次のREPEAT〜UNTILで
正しく押されるまで待っているにょ。
こんなことをしなくてもBUTTON(2)で解決できると思うかもしれないけど単一ボタンならば
それで良くても複数ボタンの入力待ちは1フレームのずれもなく複数のボタンを入力しなくては
ならないため操作性が非常に悪くなってしまうにょ。
あと本来ならばWAITもしくはVSYNCを入れないと正常動作しないのだけどREPEAT〜UNTILで
離した状態と押した状態の2回入れているためWAITやVSYNCが無くても正常動作が行えるにょ。
これで、私がここ最近にプチコン3号で作った命令や関数についての解説が終わったわけ
だけど多くのものがtwitterやMiiverseで話題として出たものを作ってみただけにょ。
フェードイン、フェードアウトはすでに何人もが同じような処理を行うルーチンを作って
いるけどSPANIMを使えば単純化できるのにと思い今回作ってみたにょ。
「無い物は作る」「あっても作る」(自分でより良いと感じるものができそうならば作る)
というだけなので需要がありそうだからというだけではなく自分で作りたいと思ったから
作っただけにすぎないにょ。
フェードインやフェードアウトはそこそこ使えそうだけどBEEPOFF命令やTIMER()関数などは
使いどころが非常に難しいにょ。
とりあえず欲している人がいたので作ってみたという程度のものなので実用性があるかどうか
という点に関しては疑問があるものであっても使いたい人が使ってくれたらいいと思うにょ。
ちなみにver.3.2.0でも新規命令が増える予定になっているにょ。
ニンドリ5月号を見る限りではフェード系命令とスプライトの加算処理が可能になるっぽいにょ。
今回作ったフェードイン、フェードアウトだけどこれもver.3.2.0が来たら用済みになる
可能性が高いにょ。(ver.3.1.0に搭載された新規命令の大半はすでに似たような動作を
する命令を作っていたので個人的にはありがたみはなかったけど標準で搭載されるという
のは非常に大きな意味を持つので喜ばしいと感じた)
加算処理ができれば現状は乗算しかできず、色を重ねていけばどんどん暗くなる(RGBの
値は0に近づく)けど加算処理ではその逆で色を重ねていけばどんどん明るくなるにょ。
これを使えば発光的な表現も可能になるにょ。
お絵かきソフトであれば乗算だけではなくスクリーン(加算)に対応させることが可能になる
ため表現できる範囲がかなり広がるにょ。
とはいえ、スプライト用GRPは1枚しかないため400x240だと2枚しか確保できないのが難点
だけどね。
キャンバスサイズを256x240にすればレイヤーが4枚が使用でき各レイヤーで不透明度や
乗算、スクリーンが可能になるにょ。(不透明度や乗算やスクリーンをレイヤーごとに
設定しなければスプライト用GRP以外でも問題ないのでレイヤーを10枚以上にすることも
可能だけど)
プチコン3号のDEFで作った自作関数、命令の解説
プチコン3号のDEFで最近作った自作命令、自作命令がたまったのでそれのリストや使い方や
解説などをしてみるにょ。(自作関数のサイトでの正式公開は近いうちに行う予定)
作ったのは本体がスリープしたか否か(簡単に言うと本体の蓋を閉じたか否か)を
取得できるSLEEP()関数と1000分の1秒(1ミリ秒)単位の時間を取得可能なTIMER()関数、
1ミリ秒単位でウェイトが可能なMWAIT命令、BEEPを強制的に停止させるBEEP OFF命令
スライドパッドを十字ボタンの代わりに使える(8方向移動を行いBUTTOON関数における
十字ボタンと同じ値を返す)DSTICK()関数、ネームバトルゲームなどで利用できる発生する
値のバラツキを自在にコントロールできるADAM()関数、フェードイン、フェードアウトを
行うFADEIN、FADEOUT命令、画面に任意の色を重ねるSETCOLOR命令、画面を任意の色から
任意の色に変化させるVARCOLOR命令、変数の型(実数型、整数型、文字列)を取得できる
るSUFFIX()関数、文字列からボタン番号を返すBTNUM()関数、任意のボタン入力待ちを行う
BTWAIT命令などにょ。
◎SLEEP()関数
DEF SLEEP()
VAR CNT=MAINCNT
VSYNC
RETURN MAINCNT-CNT>1
END
https://twitter.com/ochame_nako/status/577079366506573824
◎TIMERSTART命令
DEF TIMERSTART
XON MIC:MICSTART 3,0,0
_TIMER1=0:_TIMER2=0
END
◎TIMER()関数
DEF TIMER()
_TIMER0=MICPOS
IF _TIMER0<_TIMER1 THEN INC _TIMER2,262112
_TIMER1=_TIMER0
RETURN FLOOR((_TIMER2+_TIMER0)/32.73)
END
◎MWAIT命令
DEF MWAIT W
VAR A,B
A=TIMER()
WHILE B-A<W
B=TIMER()
WEND
END
https://twitter.com/ochame_nako/status/577083372708593664
◎BEEPOFF命令
DEF BEEPOFF
FOR I=1 TO 8:BEEP,,0:NEXT
END
https://twitter.com/ochame_nako/status/579287498758598656
◎DSTICK()関数
DEF DSTICK()
VAR A,B,SX,SY
STICK OUT SX,SY
A=(DEG(ATAN(SY,SX))*382.5)MOD 360/45
IF SX*SX+SY*SY>0.2THEN B=VAL("78043519"[A])+1
RETURN B
END
https://twitter.com/ochame_nako/status/572034389917368320
◎ADAM()関数
DEF ADAM(S,P,Q)
VAR A,I
RANDOMIZE 0,S*PO(2,31)
FOR I=1TO P:INC A,RNDF():NEXT
RETURN A/P*(1-Q)*RNDF()*Q
END
https://twitter.com/ochame_nako/status/572035121143926784
◎VARCOLOR命令
DEF VARCOLOR C1,C2,TM
SPSET 0,1480
SPSCALE 0,54,30
SPOFS 0,-16,0,-256
SPANIM 0,"C",1,C1,-TM,C2
END
◎SETCOLOR命令
DEF SETCOLOR C
VARCOLOR C,C,1
END
◎FADEIN命令
DEF FADEIN TM
VARCOLOR RGB(255,0,0,0),RGB(0,0,0,0),TM
END
◎FADEOUT命令
DEF FADEOUT TM
SPCOLOR 0 OUT C
VARCOLOR C,RGB(255,0,0,0),TM
END
https://twitter.com/ochame_nako/status/578954829558501376
◎SUFFIX()関数
DEF SUFFIX(V)
VAR A
A=V==0!=3
IF A THEN V=0.5:A=V*4-A
RETURN A
END
◎BTNUM()関数
DEF BTNUM(B$)
VAR B,I,K
FOR I=0TO LEN(B$)-1
K=INSTR("↑↓←→ABXYLR",B$[I])
B=B+POW(2,K)*(K>=0)
NEXT
RETURN B
END
◎BTWAIT命令
DEF BTWAIT B
VAR BT
IF SUFFIX(B)THEN BT=BTMUM(B)ELSE BT=B
REPEAT UNTIL BUTTON()!=BT
REPEAT UNTIL BUTTON()==BT
END
https://twitter.com/ochame_nako/status/579675181670477825
※各命令や関数の動作確認用サンプルプログラムはリンク先を参照
まず、SLEEP()関数について書いておくにょ。
プチコン3号では本体がスリープした時には動作が停止する仕様になっているにょ
そのためスリープしたかどうかは判断ができないにょ。
それを判断する方法として普通に思いつくのは内蔵時計機能を使ったものにょ。
内蔵時計は常時動作しているため時計の動きをループ内で監視しておいて前回の時刻から
2秒以上経過した場合にはスリープしたかどうかが判断可能になるにょ。
ただし、この方法だとスリープしたかどうかを判断するには本体を開いてから1〜2秒の
時間が必要になるにょ。
しかし、スリープから復帰した直後は処理落ちするというのを知っていれば内蔵時計を使わず
一瞬でスリープしたかどうかを判定可能になるにょ。
それがこのSLEEP()関数にょ。
プチコンmkIIでも似たようなルーチンを作ったけどプチコン3号は自作関数が使えるように
なったためスリープチェック専用ルーチンで判断するのではなくメインルーチンから常時
判断を可能にしたょ。
ただし、その判断を正常に行うためにはSLEEP関数の中にVSYNCを入れる必要があったにょ。
そのためSLEEP()関数を単純にメインルーチンに追加するのではなくメインルーチン内にある
VSYNC 1をSLEEP()関数に置き換えて使うことを想定しているにょ。
もしも、VSYNC 1をSLEEP()関数に入れない場合はあらかじめグローバル変数CNTを定義して
おいてCNT=MAINCNTとSLEEP()の間にVSYNCを入れる必要があるにょ。
それだと初心者だと使い方が分からない(もしくは使い方を誤る)場合があるし、関数その
ものの使い勝手もあまり良くないためこのような仕様になっているにょ。
これを使ってスリープしたか否かではなくスリープしている時間の方を知りたいという人も
いることだと思うにょ。
これは秒単位だと簡単にょ。
というのも、内蔵時計をループ内で監視しておいて単純にスリープ判定が行われた時に
前回との差分を計算すればいいにょ。(当然ながらその結果には±1秒の誤差がある)
このスリープ判定を瞬時に行うSLEEP()関数があるお陰で1〜2秒待つ必要はなく瞬時に
スリープしていた時間を知ることができるにょ。
では、秒単位よりさらに細かい値(フレーム単位やミリ秒単位)で知りたいという場合には
どうするかというと少し工夫が必要になるにょ。
まずは内蔵時計の秒数が変わる瞬間のMAINCNTの値を変数に入れておくにょ。
これはプログラムを起動時に1回だけ行ってもいいけどVSYNC 1はぴったり1/60秒ではない
ため起動している時間が長ければ長いほど誤差が出てくるにょ。
そのため1秒ごとに初期化処理を行うのが望ましいにょ。
スリープから復帰した直後のMAINCNTの値の差分を計算すれば良さそうだけどスリープ中は
MAINCNTの増加は停止しているため差分を計算しても意味はないにょ。
しかし、スリープ中はMAINCNTが停止ているということは次に秒数が変わる瞬間のMAINCNTの
値との差分を取れば1秒未満の部分のスリープ時間は分かるにょ。
あとは秒数の差分をそれに加算すれば1フレーム単位の値が求めるにょ。
といっても、スリープから復帰直後は処理落ちしているためそれで求めた値には数フレーム
(最大で5フレーム程度)の誤差があるにょ。
MAINCNTの代わりに下記のTIMER()関数を使えばミリ秒単位のスリープ時間は分かるものの
誤差が5フレームあったらミリ秒単位で結果を返してもあまり意味はないにょ。
1/1000秒単位(1ミリ秒単位)の時間を取得可能なTIMER()関数の説明をする前にプチコンは
初代からプチコン3号まですべてにおいて取得可能な最小単位が1フレーム(1/60秒)と
なっているにょ。
確かに初代プチコンではそれでも良かったけどプチコン3号(New3DSで実行時)には初代と
比べて45倍くらい高速になっているにょ。(プチコン3号の公式ベンチであるSPEED TESTを
初代プチコンに移植して比較した結果)
これは言い換えればプチコン3号の1フレームは初代プチコンの1秒に近い感覚であるという
ことにょ。
その結果1フレームが最小単位では大きすぎると感じてしまう人も少なくないにょ。
twitter上でも要望として出ていたので作ったのがこのTIMER()関数というわけにょ。
プチコンmkIIでもBGMPLAYを使って1フレームより短い時間の取得は可能だったけど処理の
重さや精度を考えるとほとんど使う意味は感じられなかったにょ。
プチコン3号ではマイク命令を使うことで負荷をほとんど掛けずにそこそこ高い精度で
mkIIと比べて遙かに簡単なやり方で1ミリ秒単位の時間を取得可能になるにょ。
精度を重視するならばサンプリング周波数は最大の32730Hzがベターにょ。
32730Hzで実行時にはMICPOSは約8秒でループしてしまうため最大8秒しかカウントが
できないにょ。
これではさすがに不便なので前回のMICPOSとの値を比較して小さくなっているならば
8秒経過したと判断してMICSIZEである262112という値をインクリメントしているにょ。
これだと8秒に1回はTIMER()関数を実行する必要があるけどループ内で常に実行して
いれば特に気にする必要はないにょ。(8秒を超えてしまったら正しくカウントが
できなくなるためその場合はTIMERSTARTで初期化して使うのがベター)
MICSIZEではなく262112という定数をインクリメントしているのはループ中に常に使用
することを想定しているため速度を重視した結果にょ。(まぁ500ナノ秒くらいの高速化
なのでほとんど気休め程度の高速化だけど)
TIMER()関数の使い方について書いておくにょ。
まず最初にグローバル変数_TIMER0、_TIMER1、_TIMER2を定義しておく必要があるにょ。
これはサンプルプログラム1行目に書いているようにVARで定義しておけばいいだけにょ。
VAR _TIMER0,_TIMER1,_TIMER2
OPTION STRICTを使用してない状態でグローバル変数をわざわざ定義するのはDEF内では
グローバル変数とローカル変数の両方が使えるためにょ。
そのグローバル変数とローカル変数の使い分けは下記の通りにょ。
◎VARで定義された変数の場合
DEF外で定義された変数・・・グローバル変数
DEF内で定義された変数・・・ローカル変数
◎VARで定義されていない変数の場合
DEF外でも使用されている変数・・・・グローバル変数
DEF内でしか使用されてない変数・・・ローカル変数
つまり、定義された場所や最初に使われた場所でローカル変数かグローバル変数かが
決まるということにょ。
したがって、VARで定義してなくても問題ないとはいえ、確実にグローバル変数として
処理をしたい場合(確実にローカル変数として処理をしたい場合)はVARを使って
明示的に処理をしておいた方がいいにょ。(初期バージョンのプチコン3号ではDEFで
使用できる変数の処理にバグがあったためVARで定義したらグローバル変数と同じ変数名の
ローカル変数が使えず事実上ローカル変数としてまともに機能しない状態だったけどそれは
ver.3.0.2で改善されている)
まぁ、DEF外ではローカル変数は使用できないため明示的に処理するというのはあくまで
DEF内に限った話だけどVARによる定義をすべての変数において行うつもりならば最初から
OPTION STRICTを使用しておくのがベターにょ。
TIMER()関数を使用するためにはまずTIMERSTART命令を実行する必要があるにょ。
これによってマイク命令を使用可能にしてカウンタに使用する変数の初期化処理を行って
いるにょ。
TIMER()関数ではこのTIMERSTART命令が実行されてからの時間を取得できるにょ。
そのためTIMERSTART命令は最初に使うか上記のように8秒を超えた場合にまたカウンタを
初期化したい場合に使用することになるにょ。
問題は測定精度だけど32730Hzのサンプリングであっても正確な値ではないにょ。
長い時間(数秒)であればある程度安定した値を示すけど1フレーム以下になると誤差が
それなりにあるにょ。
1フレームは概ね16.6ミリ秒だけどこのTIMER()関数では16ミリ秒前後の値を示すにょ。
17ミリ秒と15ミリ秒の頻度から考えると最大で±0.8ミリ秒くらいの誤差がありそうにょ。
1フレームより短い時間の測定だとさらに誤差が大きくなることが予想されるにょ。
秒単位の測定だと安定しているといってもそれはVSYNCと比較した場合にょ。
ただし、これも私の環境だと常に+0.3%くらいの誤差が発生しているためリスト内の
32.73は32.81の方が正確な値になるにょ。(これだとVSYNC 300が5001ミリ秒前後を示し
VSYNCと比較した場合の誤差は0.1%以下になる)
とはいえ、プチコン3号の場合はVSYNCそのものが正確な値ではないからTIMER()関数は
正確な値を示すと思わない方がいいにょ。(そもそも1フレームはぴったり1/60秒でも
ないわけだし)
MWAIT命令はTIMER()関数を流用して作ったものにょ。
MWAIT 10だと10ミリ秒のウェイトになるにょ。
1フレームより短いウェイトって使う機会があるのかと思うかもしれないけど表示を
あるていどゆっくり行いたいけどWAIT 1では1秒間に60回しか処理できなし、
FOR〜NEXTなどによるウェイトではNew3DSと旧3DSで速度差が出るため機種に依存せず
短いウェイトを行うというのはそれなりに意味はあると思うにょ。
ちなみにMWAIT 1000の実行時間をTIMER()関数で測定するとぴったり1000ミリ秒に
なるにょ。(まぁ当然だけど)
個人的には1フレームより細かい時間を取得しても使う用途が極めて限られると思うにょ。
それはプチコン3号が表示も入力も1フレーム単位で処理されているからにょ。
したがって、それより短いタイマーがあっても何に使うかは私は考えてしまうにょ。
例えば「300fpsのゲームを作りたい」という場合に有用かもしれないけど結局はボタン
入力や表示のタイミングをVSYNCに合わせる必要があるためあまり意味がないにょ。
それならば1フレームに5回実行して擬似的な300fpsと変わらないからね。
むしろ、そっちの方がタイマー制御する必要がない分だけ簡単だし、短くなるためメリット
だらけにょ。
仮に5回の処理を1/120秒(1フレームの半分)で実行できたとしたら擬似的な300fpsだと
挙動がおかしくなりそうだけどそんなことはなく1回の処理をぴったり1/300秒で終わらせた
場合とプチコン3号上では何ら違いはないにょ。
これは上記のように入力も表示も1フレーム単位で処理されているためにょ。
それでも、MWAITの方は機種依存のないウェイト(旧3DSとNew3DSで同じ長さのウェイト)と
いうことでそれなりに使えるのではないかと思うにょ。
次にBEEPOFF命令について書いておくにょ。
プチコンのBEEPは初代から各音色の高さは変えられるけど鳴る長さは変えることができない
けどそれは3号であっても同じにょ。
しかし、鳴る長さを長くすることはできなくても強制的に短くすることはできるにょ。
それが、BEEPOFFにょ。
原理はすごく単純で無音BEEP(音量0のBEEP)を8回鳴らしているだけにょ。
プチコンのBEEPは8音までしか同時に鳴らせないので無音BEEPを8回鳴らせばそれよりも前に
鳴らしているBEEPは強制的に鳴るのを終了させることができるにょ。
さて、これが何に使えるかというとまた微妙な感じにょ。
私が初代で作ったプチコンMMLではこのBEEPOFF命令と同等の機能を使ってスタッカート処理の
実現をしているにょ。
プチコンMML
http://ochameclub.web.fc2.com/petitcom/mml.htm
プチコンを初代から使っている人は分かると思うけど初代ではユーザーが作った曲を鳴らす
機能(MML演奏機能)は備わってなかったにょ。
そのため各ユーザーは自らの手でBEEP命令を駆使してMML演奏プログラムを作っていったにょ。
その1つが私が作った「プチコンMML」にょ。
これはすでに作ったOMPがポケコンで作ったものをプチコンに移植しただけであり処理速度と
プログラムリストの短さを重視したものとなっているためMMLそのものは使いやすいかどうかは
微妙なものになっているにょ。(とはいえ、ポケコンにおいては処理速度が速く短いという
のは極めて大きなメリットだった)
音階演奏ソフト OMP
http://ochameclub.web.fc2.com/petitcom/1page.htm #omp
とりあえず、このBEEPOFF命令の使用例としてはこんなものがあるにょ。
BEEP 78:WAIT 5:BEEPOFF
これを実行すると「や」という掛け声が鳴るにょ。
格ゲーで使えそうな掛け声が欲しいというのがMiiverseであったのだけどこんな感じで既存の
ボイス音を短くするだけでいろいろな言葉を発することができるにょ。
本来はできなかったBEEPを強制的に停止させるというのは便利そうだけど今ひとつ使用する
用途が思いつかないにょ。
単にBEEPで使用されている音色を短く使いたいというだけならばBEEPOFF命令は使用せずとも
プチコン3号の場合はBGMPLAYでBEEPで鳴らせる音色が揃っているため音長とQコマンドを駆使
すればいくらでも可能にょ。
BGMPLAY "@379Q4C"
プチコンmkIIでは逆にBGMPLAYで使用可能な音源はBEEPで鳴らすことができたのでBEEPの方が
圧倒的に音色の数で優位に立っていたにょ。
次にDSTICK()関数について書いておくにょ。
これはMiiverseでスライドパッドを十字ボタンの代用として使用したいという声があったので
作ったものにょ。
十字ボタンの代用にするならばまずは8方向移動をさせる必要があるにょ。
方向はATANで分かるためそれを単純にDEGを使い0〜360°に変換した後に45で割るという方法が
あるけどそれでは真横や真上(真下)への移動は非常に不安定になるにょ。
45°というのは基準点から±22.5°にする必要はあるにょ。
これは簡単で単純にDEGで0〜360の値にした後に22.5を足すか引けばいいだけにょ。
ただし、22.5を足す場合には360を超えたかどうかを判断する処理が必要になるにょ。
それは、「382.5」(360+22.5)を足して「MOD 360」とすればいいだけにょ。
この0〜360の値を45で割れば0〜7という値になるにょ。(実際はこの後FLOORを使って整数化
する必要性があるけど今回のプログラムでは小数部分が無視されるためそれは不要)
この0〜7という値が出てしまえば8方向移動は可能なのだけど0は右側で反時計回りに数字が
増えていくという現状の値は分かりやすいけど十字ボタンの代用にするには使い勝手が
悪いにょ。
というわけでBUTTON()関数における十字ボタンと同じ値を返すことにしたにょ。
それは8通りをIF文で判断する必要なんて全くなくて B=VAL("78043519"[A])+1 でいいにょ。
78043519って何のことか分からないけど1桁ずつ取り出して1をプラスすればこれは各方向の
BUTTON()関数が返す値であることが分かるにょ。
その1桁ずつ取り出すやりかたはmkIIまでだとMID$を使うのが普通だったけどプチコン3号は
文字列を配列のように使えるため1文字ずつ取り出すのは上記のように非常に簡単になって
いるにょ。
DSTICK()関数は返す値がBUTTON()関数と同じ値なのでB=BUTTON() OR DSTICK()とすることで
十字ボタン用として作ったプログラムがそのままでスライドパッドによる動作が可能に
なるにょ。
もちろん、十字ボタンとスライドパッドの好きな方を使えるにょ。
ただし、このプログラムでは十字ボタンとスライドパッドの両方を同時に操作するという
場合は考慮されてない(十字ボタンが上でスライドパッドが右ならば右上と判断されるのは
許容できても本来はできない上と下の同時押しもできてしまうため片方を無効化する必要が
ある)のでその処理をするならばBUTTON() AND 15の値が0かどうか、DSTICK()の値が0か
どうかを判断してやればいいだけにょ。
これはDSTICK()関数内でやるとせっかくの短い処理が冗長になってしまうため必要ならば
各自で実装して欲しいにょ。(同時に押した場合はスライドパッドと十字ボタンのどちらを
優先すべきか各自の判断に任せた方がいいし)
次にADAM()関数について書くにょ。
これは端的に言えば乱数のばらつき方をコントロールできる関数で例えばネームバトルゲーム
とか能力値自動生成のRPGなどを作る際に極端に強い(弱い)キャラの出る確率を減らす
ことができるにょ。
どういうことかというと普通にRND(100)で100通りの乱数を発生して値が大きい方が強いと
した場合には例えば能力値がだとすると能力値50の平均的な能力のキャラであっても能力値
MAXである99のキャラも同じ確率で出てしまうので能力値の高いキャラ(低いキャラ)は
それなりに出にくくした方が強いキャラが出来たときの喜びが段違いになるにょ。
この際に端の方だけ出にくくするというのは簡単そうで難しい(端の値を出にくくすると
中央付近の値しか出にくくなる)ためそれを可能にするのがADAM()関数にょ。
実はこれは昔ポケコン用につくったADAMルーチンを移植しただけにょ。
ネームバトル系ゲームの最終兵器!? ADAMの謎に迫る!!
http://ochameclub.web.fc2.com/E500/TECH/ADAM.HTM
上記ページの解説を読めばこのプログラムの意図や原理は大体分かってもらえるのではないか
と思うにょ。
図で描いているのはあくまで理想的な状況だけど実際に発生させた値を見ても中央付近が
概ね平らになってその周辺(特に端の部分)は出にくくなっているというのは分かると
思うにょ。
https://twitter.com/ochame_nako/status/572035927503060993
ちなみにこのADAM()関数ではシードの値(第1引数)は0〜1の値が選択できるにょ。
つまり、名前などから0〜1の値を計算してそれをADAM()関数に渡せば指定されたばらつき方を
行う0〜1の値を返すというものにょ。(最大値99ならば100倍して整数化すればいい)
1ページに投稿できる最大サイズを超えたので下記に続く
プチコン! DATAについて
プチコン初心者です。
とは、言ってももう買って4ヶ月くらい経ちます。
まえは、ミーバースでシューティングゲームを作ってわかんないところをミーバースで質問したりしていました。
でも、全然分からなくて駄目でした。
なので、分かりやすく色々な命令を解説しているサイトとかを教えてください!
お願いします。
あと、僕は小学生なんですがプチコンは小学生でも出来ますか?
あと、DATA命令で出来ることについて教えてください!
実は私……。
プチコンは一年以上やっていますが、未だに初心者ですよ私(mkIIからやっています)。
私も、DATAがよくわからないので教えていただけると助かります。
DATAって
何かができるというかなんというか
単にデータを書くための命令だからなぁ
READという命令を使うと変数に入れられる
上から順番に読み込む
READ A,B
DATA 123.500
こうするとAが123に、Bが500になる。
DATA "TEXT",256
READ A$,I
1.文字も使えて、数とごちゃ混ぜにできる("で囲んだものは文字になる)
2.READはDATAの前でも後ろでも問題ない
3.後で=を使って別のものを入れても問題ない
というかFOR-NEXTと配列変数、というのが分かるかどうかが重要になる。
データーディビジョン(DATA DIVISION)
RESTORE命令が忘れられてたから 探してきた
http://smileboom.com/special/ptcm2/co_manual/p22.php
http://smileboom.com/special/ptcm3/reference/
http://liv0.com
レスにょ
ゆうきさんへ
>なので、分かりやすく色々な命令を解説しているサイトとかを教えてください!
私が書いているプチコン3号入門講座がオススメにょ!
http://ochameclub.web.fc2.com/petitcom3/lecture/
と言いたいけど予定の半分弱の所で更新が停滞気味なのがネックにょ。
というわけで、私より前にプチコン3号講座を書いているかなだらいさんのサイトをオススメ
するにょ。
http://kanadaraimk2.web.fc2.com/
すでに基本命令はすべて解説済みとなっているにょ。
さすがに私が書いている入門講座ほどは詳しく書いてないけどね。(まぁ私の入門講座は
無駄に詳しいというのがメリットでもありデメリットでもあるけど)
>あと、僕は小学生なんですがプチコンは小学生でも出来ますか?
大人でもできない人はできないし小学生でもできる人はできるので年齢はあまり関係ないと
思うにょ。
最初はできないのは当たり前なので「できるようになりたいかどうか」「やっていて
楽しいかどうか」が非常に重要にょ。
>あと、DATA命令で出来ることについて教えてください!
私のプチコン3号入門講座を読んでね!と言いたいところだけど今の更新ペースだと何ヶ月
後になるのか分からないのが難点にょ。
というわけで、天郷思音さんの解説と私の補足を読んでみてにょ。
みほさんへ
>プチコンは一年以上やっていますが、未だに初心者ですよ私(mkIIからやっています)。
>私も、DATAがよくわからないので教えていただけると助かります。
とりあえず、基本的な部分は天郷思音さんが書いているのでそれを参考にして欲しいにょ。
補足するならばREAD〜DATAの必要性くらいにょ。
例えば5教科分のテストの点数を変数に入れる場合には次のようになるにょ。
TEST1=60
TEST2=85
TEST3=70
TEST4=90
TEST5=75
これをREAD〜DATAを使うと次のようになるにょ。
READ TEST1,TEST2,TEST3,TEST4,TEST5
DATA 60,85,70,90,75
この時点ではREAD〜DATAを使うメリットは何もないにょ。
では、これが5教科、200人分のテストの点数だったらどうなのかを考えてみるにょ。
そうなると変数=数値のように代入を1000回繰り返すことになるにょ。
READ〜DATAを使うとどうなのかというとこれだけではメリットがなくてFOR〜NEXTと配列
変数を使うことで始めてそのメリットが大きくなるにょ。
DIM TEST[200,5]
RESTORE @A
FOR I=0 TO 199
FOR J=0 TO 4
READ TEST[I,J]
NEXT
NEXT
@A
DATA 60,85,70,90,75 ' 1にんめのデータ
DATA 90,76,90,55,80 ' 2にんめのデータ
(中略)
DATA 95,40,65,70,85 ' 199にんめのデータ
DATA 85,90,95,80,95 ' 200にんめのデータ
このようにデータは200行分になるけど変数=数値のような記述よりもトータルの文字数が
減るということだけではなくプログラム本体とデータのリスト上での分離が可能になるため
データの管理がしやすいというのがREAD〜DATAを使う大きなメリットとなるにょ。
入れる変数が変わったら直接代入した場合には1000個の代入をすべて手動で書き換える
必要があるけどREAD〜DATAならばループ内の1箇所を書き換えるだけで済むにょ。
RESTOREによる参照データを変えればプログラムを書き換えることなしに同じプログラムで
別のデータを使うことができるにょ。(@ST1がステージ1のデータ、@ST2がステージ2の
データのようにしておけばデータ作成プログラムでデータを作っておくだけで後から
いくらでも簡単にステージを増やせる)
つまり、ある程度のデータ量がないとREAD〜DATAのメリットは分かりにくいにょ。
配列変数に入れるメリットとしてはデータの再利用や分析をしやすくなるということにょ。
読み出す際もループに入れるだけで済むし、並べ替えや平均値を求めたりとかグラフで表示
したりというのも配列変数に入れておけば簡単にできるにょ。(ちなみに配列変数はDIMでも
VARでもどちらで定義しても全く変わらない)
配列変数に入れるだけならばREAD〜DATAを使用しなくても可能けどただでさえ直接代入
したら長くなるのに配列変数に入れたら添え字の分だけさらに長くなるにょ。
配列変数はループに入れて処理しないと価値が半減だけどそのループに入れて処理するのに
READ〜DATAは必要不可欠になるにょ。
初心者向けの講座のサンプルプログラムとかは大抵はデータは数個止まりだからREAD〜DATAを
使うメリットはあまり感じさせないけど実際は多くのデータを扱えば扱うほどREAD〜DATAは
メリットが大きくなるにょ。
プチコン3号の場合だとDATAさえ記述しておけばCOPY命令で配列変数にデータを入れることが
できるのでループの必要さえないにょ。(READの代わりにCOPYを使うだけなのでDATAは必要)
DIM TEST[200,5]
COPY TEST,@A
@A
DATA 60,85,70,90,75 ' 1にんめのデータ
DATA 90,76,90,55,80 ' 2にんめのデータ
(中略)
DATA 95,40,65,70,85 ' 199にんめのデータ
DATA 85,90,95,80,95 ' 200にんめのデータ
これはあらかじめデータ数が決まってない場合には使えない(配列変数はデータ数と全く同じ
大きさだけ確保しておかなくてはならない)のでそういう面では汎用的に使えるREAD〜DATAを
先に覚えておく必要があるにょ。
天郷思音さんへ
READ〜DATAの解説どうもにょ。
>何かができるというかなんというか
>単にデータを書くための命令だからなぁ
大量のデータを扱うプログラムを書く機会が今までにない初心者だとそのメリットは
伝わりにくいかもしれないにょ。
マリモーマさんへ
>RESTORE命令が忘れられてたから 探してきた
常に先頭からデータを読み込むならばRESTOREは不要だけどそうでないならば必要になって
くるにょ。
プチコン3号は最大4本のプログラムを同時編集、同時実行が可能になっているけどRESTOREも
事前にUSE 1のようにしておけば他のプログラムリストのDATAを読み込むことが可能にょ。
つまり、プログラムとデータのリスト上での完全分離が可能になるということにょ。
第3回プチコン大喜利 ノミネート作品発表
1月末に締め切られた第3回プチコン大喜利のノミネート作品が発表されたにょ。
http://smileboom.com/special/ptcm3/ogiri/
100作品以上の投稿作品の中から一次選考を抜けたノミネート作品の数は各部門ごとだと
下記のようになっているにょ。
◎アイディア賞 ・・・・ 6作品
◎若獅子賞 ・・・・・・ 6作品
◎ユーモア賞 ・・・・・ 6作品
◎社長賞 ・・・・・・・ 8作品
◎技術賞 ・・・・・・・ 6作品
◎芸術賞 ・・・・・・・ 6作品
合計 ・・・・・・・・・ 38作品
私はどうなのかというとプチコンmkIIで作った「3Dポリゴン立体視プログラム」がなぜか
アイディア賞にノミネートされたにょ。
プチコン用 3Dポリゴン立体視プログラム ver.1.1
http://ochameclub.web.fc2.com/petitcom/polygon_stereogram.htm
過去2回を見てみると第1回プチコン大喜利では1画面プログラム「PETIT RUN mkII」で
技術賞に入賞、第2回プチコン大喜利では「3Dポリゴン表示プログラム」で技術賞に
ノミネートという実績から考えて今回もノミネートされるならば技術賞だろうと思って
いただけにかなり意外な感じにょ。
技術賞は全般的に技術者揃い(まぁ賞の内容から言って当然だけど)ということでその
選考から漏れてアイディア賞にノミネートされた・・・のかもしれないにょ。
私がノミネートされたアイディア賞を見てみると6作品は次のようになっているにょ。
アイディア賞ノミネート作品
◎KING AND QUEEN by Mino
◎3Dポリゴン立体視プログラム by おちゃめ
◎くねロボ by Kozakoz
◎PATIAL WORLD この不完全な世界 by yamachan360
◎風神 by jojo3
◎CandyMaze by SakuraCrowd (敬称略)
私が作った作品は技術的に見ると他の作品と比べて決して劣ってはないと思うのだけど
アイディア賞に入賞するならば完全にアイディアで他の作品に対して遅れを取っている
ためノミネート止まりなのが極めて濃厚にょ。(それにに前回ノミネートした作品の
改良版にすぎないわけだし)
もっとも技術賞狙いならばプチコン3号の立体視を使った非常にハイレベルな作品が多い
ため技術的にも困難に感じたにょ。
つまり、どう考えても今回の入賞は最初から無理だったにょ。
海外でプチコン3号の海外版が発売されて数ヶ月後には恐らく第4回が開催されると思うにょ。
それまでにはプチコン3号を今よりも使いこなせるようになっておきたいにょ。
まだ現時点では一部の命令は熟知しているけど他の命令はほとんど使ってない状態だし1画面
プログラムも経験をプチコンmkIIとはかなり勝手が違うので慣れが必要になってきそうにょ。
プチコン3号の1画面プログラムコーナーがサイト上で正式オープンするまでは時間がかかり
そうだけど最近増えてきた自作命令、自作関数に関しては近日中に正式公開の予定にょ。
まぁMiiverseやtwitterですでに書いているし先日も最近増えた分に関しては詳細の解説を
したからサイト上での公開といっても今更感がありそうだけどね(笑)
やつは 天郷思音さんの大切なものを 盗んでいきました それは 謎の公開キーです
山口県 独立だって(エイプリルフールネタ)
https://twitter.com/yamauchi_ken/status/582921495879389184/photo/1
-----------------------
いろいろあって ホームページや ニコ動のコミュと動画 消してきたよ
http://liv0.com
私の暗号化技術を盗みやがったな(嘘)
スマイルブーム.comの謎の公開キーのプログラムで私の暗号化プログラムと同じようなものがあったw(文字コードに文字の位置の値を足す)
まあ誰でも思いつくだろうけど。
親は馬鹿かなぁ
うわあカメラ無効してなくて顔流出するとこだったw
うちのセキュリティは穴に偏りがある
我が家のことだから無効にするなりガムテープするかと思ったらそうでもない。
WPA2-AESの家がやることとは思えない
(無題)
代入など、ごく細かい挙動1つ1つに至るまで
速度を計ってくださるのは大変に参考になるので有難いです。
しかし現状の情報が散乱している状態では非常に参照し辛く、
情報の価値が高められていない状態です。
全てまとめた一覧表を作っていただけることを期待しております。
(もしそのページが出来たら、公式の命令表の横に張り出して
常用重用すること必至ですね・・・)
あと、速度比較は、遅いので見て分かりやすいような差が出やすい
旧3DSで行ってください!(あるいはそれを明記してください)
ログホライズンは 脱税を指摘されるほど儲かってるのか
玄人志向、GeForce GTX TITAN X搭載カード「GF-GTX-TITAN-X-12GB」
http://news.nicovideo.jp/watch/nw1541807?ver=video_q
14万円は 高いな
FC2HP障害発生
このサイトと私のサイトは無事ですが、みほさんのサイトがアクセスできない状態になってます。
直ったみたいね
直ったみたいね。まぁ、無料だからしかたがないのですが。文句は言えませんね。本当はちゃんとお金を払って本格的にやりたいんですけどねえ。お小遣い制ではないんですよ、私。
(無題)
またパソコンが落ちた
bad pool callerだった気がする
どうせイベントビューワではカーネルパワー41としか出ないだろうけど
それに落ちる度違うエラーだからあてにならない
http://waaimyroom.web.fc2.com/
(無題)
たぶん埃による温度上昇だ
http://waaimyroom.web.fc2.com/
更新したほうがいいと思いますよ!
FC2ホームページの無料版は、三ヶ月更新がない場合は広告が表示されてしまうので、更新したほうがいいと思います。最終更新日時は2月の初め頃なので、もうすぐ三ヶ月です。
(無題)
なるほど! LOAD "GRP*:*" で Illegal file format が出ず正常に読み込める条件は、
そのバイナリデータファイルが「2次元配列かどうか」、ということだったんだ。
逆に、1次元配列を保存したファイルを2次元配列に読もうとしてもエラーになる。
ファイルには、配列の次元数まで記録していたのか〜・・・。
リンクの貼り替えお願いします
dosankosoftがサーバー移転しましたので、張り替えお願いします。
新URLは http://dosankosoft.esy.es/ です。
http://yukkuridosanko.web.fc2.com
了解です
実は、私も道産子ソフトさんと同じサーバーに移転しようと思っていますww
レスにょ
マリモーマさんへ
>山口県 独立だって(エイプリルフールネタ)
一瞬でウソと分かるエイプリルフールネタにょ(笑)
>いろいろあって ホームページや ニコ動のコミュと動画 消してきたよ
それは残念にょ。
何かあったのかもしれないけどほとぼりが冷めた頃にまた復活を希望するにょ。
>14万円は 高いな
コストパフォーマンスを重視する人はハイエンドを選んではダメにょ。
2、3割の性能アップに2倍のコストを惜しみなく払える人でないと・・・。
コストパフォーマンス重視派ならばミドルレンジのものを選ぶのがベターにょ。
ローエンドは逆にコストパフォーマンスが悪くなる場合が多いからね。
天郷思音さんへ
>スマイルブーム.comの謎の公開キーのプログラムで私の暗号化プログラムと同じようなものがあったw(文字コードに文字の位置の値を足す)
>まあ誰でも思いつくだろうけど。
暗号化プログラムといえば昔、乱数と組み合わせたものをポケコンで考えたにょ。
プチコン3号もシード値が設定可能になったのでシード値をパスワード代わりに使えば
解読困難な暗号が簡単に作れるにょ。
>たぶん埃による温度上昇だ
これからの季節、どんどん厳しくなるにょ。
埃によって冷却機構は徐々に低下していくため分解清掃をするのがベターだけどそれが
難しいならば冷却台に頼るという方法もあるにょ。
冷却台の代わりに扇風機の風を下から当てるというのも1つの方法にょ(笑)
チラシ裏次郎さんへ
>しかし現状の情報が散乱している状態では非常に参照し辛く、
>情報の価値が高められていない状態です。
twitterやMiiverseは検索性が低くいくら有意義な情報を書いても埋もれがちにょ。
特にMiiverseはタグ検索もできないしすぐに流れてしまうため初心者による同じ質問が繰り
返し行われているにょ。
とはいえ、自サイトよりもお手軽に書き込めるのでふと思ったことをすぐに書けるという
メリットがあるためサイトでまとめる前の段階で私はよく利用しているにょ。
>全てまとめた一覧表を作っていただけることを期待しております。
すべてをまとめるというのは途方もない時間がかかるため変数や四則演算についてのみ現状で
調べたことをこのページにまとめてみたにょ。
http://ochameclub.web.fc2.com/petitcom3/lecture/speedup_nano.htm
これだけでもまとめるまでに3週間もかかってしまったにょ。
>あと、速度比較は、遅いので見て分かりやすいような差が出やすい
>旧3DSで行ってください!(あるいはそれを明記してください)
旧3DSだと処理速度が遅いため同じループ回数でも計測に時間がかかるし、ループ回数を
減らせば計測の精度が落ちるためNew3DSのみのデータ公開としているにょ。
New3DSによる500万回ループならばA=A+1に関しては10回計測であっても誤差は±1ナノ秒に
収まっている(大抵は345という値になり、時々346になる感じ)けれど、旧3DSによる
100万回ループならば±10〜20ナノ秒くらいの誤差が発生するにょ。
さすがにこれだけの誤差が発生するとなると有意的なデータにはならないと思うにょ。
ポケコンや8bitパソコンのようなROM BASICではなくバージョンアップで数字はどんどん
変わってくるため数字そのものに絶対的な意味はなく現状のバージョンで動作させた場合に
どれがどの程度速い(遅い)かという相対比較ができればいいのでNew3DSのみで全く問題は
ないと思うにょ。(New3DSで計測したということはさすがに明記する必要はあるけど)
あと私の旧3DSは各命令の挙動の変化やマニュアル記述の変化の確認用のため初期バージョン
(ver.3.0.0)を入れた状態になっていてこれを基準に計測データを発表するのは無意味だけど
「初期バージョンはこうだった」というを書く場合には活用しているにょ。
>なるほど! LOAD "GRP*:*" で Illegal file format が出ず正常に読み込める条件は、
>そのバイナリデータファイルが「2次元配列かどうか」、ということだったんだ。
twitterでGRPとDATを判別したいという意見があったのでGRPがどのように記録されている
のかを確かめてみたというわけにょ。
みほさんへ
>直ったみたいね。まぁ、無料だからしかたがないのですが。文句は言えませんね。本当はちゃんとお金を払って本格的にやりたいんですけどねえ。お小遣い制ではないんですよ、私
私は月額数100円が払えないわけではないのに多少のお金をケチってFC2にしているわけ
だけど・・・(笑)
>FC2ホームページの無料版は、三ヶ月更新がない場合は広告が表示されてしまうので、更新したほうがいいと思います。最終更新日時は2月の初め頃なので、もうすぐ三ヶ月です。
新しいコンテンツの追加はしてなくても既存コンテンツの修正(発見した誤字脱字の修正や
より分かりやすくするための解説を追加、部分的なコンテンツの追加)は随時行っている
ため全く問題はないにょ。
道産子さんへ
>dosankosoftがサーバー移転しましたので、張り替えお願いします。
了解したにょ。
プチコン3号の処理を1ナノ秒単位で計測する
プチコン3号で変数の型や演算子によってどれくらいの速度差があるのかを調べてみたにょ。
http://ochameclub.web.fc2.com/petitcom3/lecture/speedup_nano.htm
これは先日(4月10日)にtwitterやMiiverseで書いた投稿を正式にまとめたものにょ。
私はtwitterやMiiverseはとりあえず「こんなのを作ってみた」とか「こんなのをやって
みた」というのを書くのに利用しているけど自サイトに書く場合にはちゃんとコンテンツと
して公開する限りは(自己基準で)一定ライン以上のものにしたいと思っているにょ。
そのtwitter上で書いた「A=A+1が345ナノ秒程度になる」といってもこの信頼性というのは
極めて低いにょ。
それは自作TIMER()関数はMICPOS命令を使って実現しているけどこのMICPOSのカウントの
進み方は一定ではなくバラツキがあるためにょ。
そのため1フレームより短い時間の計測に活用できそうなTIMER()関数は1フレーム程度の
短い時間だとバラツキで計測時間が大きく左右される(私が少し調べてみただけだと
1フレームであっても常に15〜17m秒といった範囲で値がばらついていてワーストケース
では1フレームが18m秒と計測され誤差は10%に達してしまう)という問題があるにょ。
したがって、この問題を何とか改善する必要があるにょ。
ただし、TIMER関数は1秒だと3DS本体の内蔵時計と比較してほぼ1%以内の誤差に収まって
いるし長い時間ならばMAINCNTよりも正確な時間を指し示すためMICPOSが大きな値で進む
頻度にそこまで大きなバラツキはないと言えるにょ。
ちなみにMAINCNTも計測結果にはある程度のバラつきが出てしまうためより細かい時間が
計測が可能なTIMER()関数のアドバンテージは十分にあるにょ。
「1ナノ秒単位で計測を行う」となると1000分の1秒単位で計測可能なTIMER()関数でも最低で
100万回ループが必要になるにょ。
100万回ループといってもNew3DSで動作しているプチコン3号ならば1秒もかからないにょ。
ただし、100万回ループでも安定した計測結果が得られるかというとそうでもなく±数%の
バラツキが発生していまっているにょ。(これはTIMER()関数の仕様に加えてプチコン3号では
バックグラウンドで様々な処理を行っている関係でプチコンmkIIと比べて処理速度が安定
しないせい)
今回の結果からA=A+1は345ナノ秒程度かかることが分かっているのだけど100万回ループだと
±5ナノ秒くらいの誤差は普通に発生し、希に+10ナノ秒くらいの誤差まで発生してしまって
いるにょ。
そのため例えば100万回を3回計測して355ナノ秒、340ナノ秒、343ナノ秒という値が得られた
時にこれからどう判断するのかという手腕が問われるにょ。
単純に平均を取ると346ナノ秒となるけどこの結果から「346ナノ秒」と言い切るのは極めて
微妙にょ。
したがって、4月10日にtwitter上で書いた時には結果を5ナノ秒単位で丸めて5ナノ秒単位の
誤差はあるということを伝えたにょ。
つまり、計測結果は1ナノ秒単位で表示されているけど実際は5ナノ秒単位でしか判断が
できないということにょ。(確実に5ナノ秒以内に誤差が収まっているというわけではない)
サイト上で正式コンテンツとして残すならばこの辺を何とか改善したいにょ。
それを改善するにはどうすれば良いのかというと最も単純な改善策はループ回数を増やす
というものにょ。
例えば100万回ループではなく500万回ループにすればで内部(ここでの内部というのは
計測結果を返す前の段階のことでありプチコン3号の内部処理を意味するものではない)では
0.2ナノ秒単位になるため誤差が減るというわけにょ。
しかし、100万回ループを500万回ループにすれば確かにばらつく範囲は狭まるもののばらつく
範囲が1/5になるというという単純なものではないにょ。
ここで問題となるのはどのような値を測りたいのかということにょ。
今回は普通に実行して得られる値が欲しいので平均的な速度はどれくらいなのかという
ものにょ。
それならば素直に平均値を求めれば良さそうだけど上記のように「355、340、343」を
足して3で割るというのは得られた数字の信頼性は極めて低いにょ。
それならば計測回数を増やしてやればいいにょ。
3回ではなく10回とか20回とかにすれば平均的な値から大きく外れた値が出てもその値に
大きく左右されることが無くなるにょ。
それならば「平均的な値から大きく外れた値は最初から除外して平均を求める」というのも
1つの改善策にょ。
ただし、平均的な値がどれくらいなのか事前に分かってないと除外対象が分からないし
除外する値の閾値をどれくらいに設定するのかという問題が発生するにょ。
そもそも、今回私が欲していたのは平均値ではなく平均的な値(普通に実行してよく起こり
うる値)なので、平均値よりもむしろ最頻値の方がこの場合は相応しいにょ。
ただし、最頻値を求めるならば10回程度の計測ではたまたま同じ値が出たらそれに決まってし
まうという結果を招いてしまうためバラツキを考えると最低でも100回、できれば1000回以上
の計測を行う必要があるにょ。(どれがどの程度の確率で発生するのか、どんな確率分布に
したがって分布するのかが分からないため検定はしてないけど1000回ならば最頻値を得るのに
ほぼ問題ない回数だと思われる)
では、実際に1000回計測したらどのようになるのを示したのがこれにょ。
(New3DS、ver.3.1.0での結果なので旧3DSで実行した場合だと同じループ回数であっても
処理速度が遅い分だけ分布する範囲が広くなる)
◎100万回ループ 1000回計測
平均 345.532ナノ秒
335ナノ秒 5回
340ナノ秒 13回
341ナノ秒 39回
342ナノ秒 68回
343ナノ秒 113回
344ナノ秒 133回
345ナノ秒 162回 最頻値 ← 平均付近
346ナノ秒 141回
347ナノ秒 115回
348ナノ秒 78回
349ナノ秒 46回
350ナノ秒 37回
351ナノ秒 16回
352ナノ秒 16回
353ナノ秒 10回
354ナノ秒 2回
355ナノ秒 3回
356ナノ秒 1回
357ナノ秒 1回
358ナノ秒 1回
◎500万回ループ 1000回計測
平均 345.041ナノ秒
342ナノ秒 9回
343ナノ秒 93回
344ナノ秒 248回
345ナノ秒 297回 最頻値 ← 平均付近
346ナノ秒 230回
347ナノ秒 98回
348ナノ秒 24回
349ナノ秒 1回
100万回ループを見ると平均を基準に小さい値はバラツキ幅が小さく、大きい値はバラツキが
大きなべき分布気味の形になっているにょ。(A=A+1は比較的安定した結果が得られているの
だけど他の処理でもそこまで大きな差はない)
100万回ならばそこまでではないけどこの傾向はループ回数を減らせばさらにはっきり出て
くるにょ。(10万回ループまで減らすと320〜380くらいの値に分布して最頻値から大幅に
外れた大きな値が出やすくなる)
しかし、これが500万回ループになると傾向が変わり大きい値のバラツキがかなり抑えられる
ため正規分布、ガウス分布に近い形になるにょ。
べき分布であれば「平均を取る」ということに意味はないけど500万回ループならばガウス
分布にかなり近くなるため平均とのずれは気になるレベルではないにょ。(正確なべき
分布であれば対数を取ることで直線的なグラフになるけど今回の結果だけだと正確なべき分布
とは言い難いし、ループ回数を増やせば対数を取る必要性はなくなる)
そして、最頻値も平均とほぼ同じ値を示すにょ。(これと同じ1000回計測を他にもいくつか
試してみたけど誤差は0〜1ナノ秒だった)
A=A+1の1000回計測においては500万回ループに限らず100万回ループでも1ナノ秒単位で見た
場合には平均値と最頻値は一致しているにょ。
「最頻値=平均値」ではないけど100万回以上のループを行えば両者に大きな差異はないため
正確な平均を求めればほぼ正確な最頻値が求まるというわけにょ。(この辺は実際に多数の
ものを計測してヒストグラムを出さないと分からない)
ここで問題は先ほども書いたように正確な平均を求めるのが難しいということにょ。
100万回ループだと1000回計測で実際に335〜358の値が出ているにょ。
A=A+1は何度も計測しているため345がほぼ平均値(≒最頻値)であることが分かっている
けど358というのはそれよりも13も大きい数字であり、それが実際の計測に出た場合には
それ1つで結果が大きく左右されるにょ。
ならば、簡単な方法は1つでループ回数を増やせばいいにょ。
500万回ならば上記のように最大でも349(最悪のケースで4ナノ秒の誤差)で収まるため
その値1つで平均が大きく変わるようなことにもなりにくいにょ。
それでも、TIMER()関数を使う以上はくらループ回数を増やしてもバラツキを1ナノ秒以下に
抑えるのは難しいし8秒以内という制限を考えるとNew3DSでも500万回が限界にょ。(ループ
だけならば700万でも対応できるけど実際に計測したい処理(ほとんどのものが200〜600ナノ
秒程度)を考えると500万が限界ということ)
したがって、一発計測ではなくある程度の計測回数を行いそれを平均することになるにょ。
何回計測すれば90%程度の信頼性を得られるかとかは正規分布ならば計算は可能だけど今回の
分布ではそれが面倒なので実際に数をこなしすでに分かっている値に近い値を出すには何回
くらい必要かを計測回数を変えながらいろいろと試してみたにょ。
その結果がこの10回という数字にょ。
確かにこれを50回とか100回に増やせばさらに信頼性はアップするけど計測にかかる時間を
考えると微妙だし、計測する処理によって値がばらつく範囲が変わるため一概には言えない
ものの「1〜2ナノ秒程度の誤差はある」と最初から言っておけば問題ないと感じたにょ。
(私の感覚では500万回ループで実行したものに関しては±2ナノ秒の範囲で90%以上の
信頼性があると思うけど後者のように些細な環境による計測値の変化の影響があるため
2ナノ秒以下の誤差で90%以上の信頼性というのは計測結果の信頼性であって掲載している
表の信頼性はそこまでないかもしれない)
それに10回ならば全結果が表示可能なのでそこから判断も可能だしね。
後からみてあまりにバラツキが大きい場合は再計測を行うことも可能だし、空ループを
計測してプラスの値やマイナスの値ばかり出ているならば補正値の変更を検討する必要が
あるにょ。(変数宣言や代入の順番やそれが整数型か実数型かでも結果が数%変わるため
実は同じ条件で計測するというのは思っている以上に困難で空ループを計測して補正値を
変えて対応するしかない)
TIMER()関数の精度の問題よりも計測プログラムに使われている変数処理の順番で変わる
ことの影響が大きいくらいにょ。
このことに気づいたのは今回の結果を粗方計測し終わった後だったのでまた再計測し直した
けれど再計測されてないものもいくつかありそうなので補正値の誤差がほぼゼロ、500万回
ループで実行時でこの表から5ナノ秒以上ずれている結果が表示された場合にはぜひ報告
して欲しいにょ。(100万回ループでもほとんどの場合は5ナノ秒以内の誤差に収まって
いると思うけどそこまで確信は持てない)
その際は環境による違いか、私の記載ミス(要は誤植)かをこちらで判断するけど記載ミス
というのもそれなりにありそうなのでこちら側で記載ミスを発見した場合はこっそり修正
させてもらうにょ(笑)
注意すべき点としてはこれは、リンク先のページ内でも何度も書いていることだけど
各演算処理に「○○ナノ秒かかる」というのは絶対的な数字ではなく覚えてもあまり意味が
ない数字にょ。
というのもこの数字は環境によって変化する値だからにょ。
しかし、「乗算は加算の○○倍遅い」というのは知っておけば高速化をする時に役に
立つにょ。
そのためできるだけ環境を揃えて相対比較が十分に行える精度で計測しているにょ。(この
「環境を揃える」というのが後述のように思っている以上に難しい)
それでも、下記にあるようなTIMER()関数の仕様や計測回数が10回という仕様によって
500万回ループであっても1〜2ナノ秒程度の誤差が出る可能性があるにょ。
絶対的な数字ではないというのは単に「誤差がある」という意味ではなく実際にはTIMER()
関数に使われているMICPOSが正確に32/32730秒周期で増加しているのではない(これは
ループ数を増やすことで許容誤差の範囲になるようにしている)のに加えて各種割り込み
処理が加わる関係上、実際の処理速度(プログラム実行速度)というのは確定している値
ではないためにょ。
例えば私が使っているポケコン(PC-E650)においては、INKEY$による割り込み処理の
関係上、キーを押している時はすべての処理速度が15%くらい遅くなるにょ。(キー割り込み
無効化はBASIC上からもPOKE命令で可能なのでINKEY$を使わず直接キーポートを読み取る
ことで約15%の高速化が可能になる)
プチコン3号ではバックグラウンド上では多数の処理が行われているため純粋な命令の
実行速度というのはこのプログラムでは計測ができないにょ。
しかし、これも環境を可能な限り統一することで割り込み等を含んだ実行速度を計測
しているにょ。
もちろん、これは「この計測プログラム上における実行速度」だけどプチコン3号でそこ
まで遅くなる(計測値が数10%変わる)ことはあり得ないにょ。(A=A+1が345ナノ秒と
いうのもあくまでこの計測プログラムにおける値にすぎないけどほよどのことがない
限りはここから大きく変わる値が計測されることもない)
もちろん、処理に影響を与えるプログラムであれば私の計測値より数%変化する可能性は
十分にあるためこの数字は絶対的なものではなく相対比較用のものでしかないにょ。
しかし、プログラムを公開することで統一環境の元、各自で相対比較を行えるので問題は
ないにょ。
といっても、このプログラム自体は決して特殊なものではないにょ。
自作TIMER()関数を使わなくてもMAINCNTでも簡単に作れるためにょ。
M=MAINCNT
FOR I=1 TO 16710000
NEXT
?MAINCNT-M;"ナノ秒"
たったこれだけで私が作ったものとほぼ同等の1ナノ秒単位の値を計測が可能になるにょ。
空ループの時間を計測して、FOR〜NEXTの間に計測したい処理を入れてその実行時間を計測して
差分を取ればOKにょ。
1フレーム(1/60秒≒16.666666ミリ秒)のループ回数が16666666回でないのは私の計測に
おいてプチコン3号での1フレームは平均で1/59.835秒(≒16.712626ミリ秒)程度であるためで
それならば厳密には16712626回ループにすべきだけどそこまでの精度で計測できない(計測
精度はせいぜい3桁しかない)ためこれでほとんど問題はないにょ。
どうしても、これでは精度が足りないと思う人は下4桁を「2626」にすればいいけど各自の
手元のプチコン3号を使って計測してもらうのが一番にょ。(とりあえず、私のNew3DSと
旧3DSでは複数回計測して1/59.835秒になったけど他のものでも同じになることが保証でき
ないため)
これだけのプログラムで「A=A+1が345ナノ秒前後」というのが計測できるにょ。
つまり、これは特殊なことをせずに誰もが確認できる値といえるにょ。
ならば、「私が作ったものっていったい何なのか?」
自作TIMER()関数を使いたかった・・・というのもあるけど「1ナノ秒単位で計測」というのを
アピールするためにはMAINCNTだと最低1671万回のループが必要だけどTIMER()関数ならば
100万回のループで済むというメリットがあるにょ。
もっとも、1671万回ループのMAINCNTの方がTIMER()関数の100万回ループのTIMER()関数よりも
誤差が少なく計測が可能にょ。(MAINCNTも1/59.835秒を正確に刻んでいるかというとそう
ではなく3DS内蔵時計が最も正確に時間を刻んでくれるので時間に余裕があるならば内蔵
時計で計測するのが最も誤差の少ない実行速度計測が可能になる)
では、私が作った処理速度計測プログラムはTIMER()関数を使い100万回という少ない(?)
ループ回数でも「1ナノ秒単位で計測」をアピールしているというだけでそれ以外は
何も考えてないというわけではないにょ。
プチコン3号においてはFOR〜NEXTのループは常に終了値と刻み値を評価しているけど
終了値は定数で置くよりも変数で置いた方がループの速度が安定するため変数で置いて
いるにょ。
その変数はOPTION DEFINTでの実行を考慮して実数型を示す「#」を付けているにょ。
ループ回数が2の31乗回を超えることはこのプログラム上ではあり得ないので整数型でも
いいのだけど実際によく使われるのが実数型なのでそれに合わせているにょ。(それを
考えるとループの終了値にも変数が使われることが多いし)
整数型だろうと実数型だろうとループにかかった時間を引くわけだから関係ない(むしろ
整数型ならばループが速く終わるというメリットさえある)と思うかもしれないけど
実際はループ内処理を含んだループ全体の時間をからループにかかる時間を単純に
マイナスしてもループに使われている変数が整数型か実数型かでループ内の処理にも
影響を与えるため一般的に使われている実数型を選択しているにょ。
これは命令の順番や直前に処理しているのが実数型か整数型かで処理速度が変わるためで
実際にどれくらいの影響があるかというとこの計測プログラムにおいてループの終了値の
変数(K)を実数型から整数型に変えるだけでA=A+1の速度が345ナノ秒から344ナノ秒へと
速くなり(ただし、これはこのプログラム上は誤差の範疇)、ループのカウンタ変数(I)を
実数型から整数型へと変えると380ナノ秒へと約10%も遅くなるにょ。(ちなみにK#を定数
5000000で計測したら341ナノ秒へと高速化される)
ループ外の代入処理でさえループ内に影響を与えるにょ。
というわけで、一般的に使われている環境(と想定されるもの)に合わせることで誤差を
極力少なくしているのがこのプログラムというわけにょ。
やっていることは大したことはない誰でも考えつくような内容のプログラムだけど「誤差を
少なくする」というのはここまで考える必要があるというのが分かってもらえたらいいにょ。
(1ナノ秒単位での計測だと非常に些細なことでも影響を与えてしまう)
《 プチコン3号で処理時間計測をする場合の最大の問題点 》
FOR I=1 TO 1000000
A=A+1
NEXT
の実行時間から
FOR I=1 TO 1000000
NEXT
の実行時間を差し引いても
A=A+1
の正しい実行時間が出るというわけではない!
どのような処理を行おうと得られるのは絶対的な値ではなく
その実行時の環境に依存した実行時間でしかない。
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
この場合だとFORの前に何も処理がなく、カウンタ変数は実数型、終了値は1000000の
場合という特定環境下の「A=A+1」の実行速度が分かるだけ。
ならば、実行時の理想環境を想定して得られた数字は相対比較用の数字とすればよい。
これが今回のプログラムとなっている。
したがって、この理想環境内では誤差の少ない「正しい値」が出ている。
その代わり理想環境は一般的によく使われるであろうものにする必要がある。
つまり、それを計測したプログラムも一緒に公開しないとその値はほとんど意味を
持たない数字になってしまう。
あと、TIMER()関数の仕様で最大8秒までしか計測できないならば一定回数ではなく8秒間に
実行できる回数を計測した方が良いという指摘も戴いたけどこれは上記のようにループを
単純化させることで安定した誤差の少ない結果を得ることができるというのを優先した
結果にょ。(ちなみにMAINCNTで600フレームを計測するよりTIMER()関数で10000ミリ秒を
計測する方が10秒に近い値が出やすいけどMAINCNTの方が値は安定している)
ちなみにTIMER()関数そのものは「275197044141185ミリ秒(≒8726年)」までカウント
可能だけど8秒間に1回は呼び出さないと8秒を超える時間はカウントできないという仕様に
なっているだけにょ。
約8秒を計測するだけならば本プログラムでやっているようにMAINCNTが480以上増加したか
どうかを判断すればいいので簡単にょ。(MAINCNTも上記のように正確に1/60秒を刻んでいる
わけではないので480で8秒というのは本当は正しくはないけど)
もっとも、TIMER()関数を使用しないのならば8秒の制限はないので10秒でも20秒でも好きな
時間に設定できるし、その改造も簡単なので「一定時間の方が良い」と思う人は自由に
改造して使って欲しいにょ。
ただし、その場合にはこの理想環境から外れる上に誤差が出やすくなり、上記ページで
記載されている時間と単純比較ができなくなる恐れがあるにょ。(5ナノ秒以上のずれが
あっても環境による違いかプログラムの処理方法による違いかの特定ができないということ)
私はNew3DSで動作するプチコン3号と比べて数千、数万倍遅いポケコンで0.1ミリ秒、0.01
ミリ秒単位の高速化(ベーマガなどの雑誌に掲載のゲームで平均3倍、最高で9倍の高速化を
実際に行った)をしてきたけどこれは言うならばプチコン3号で1ナノ秒単位での高速化に
匹敵するレベルにょ。(これは改造というよりまったく同じ動作をするプログラムを1から
作り直した上でさらに演算子の実行速度を加味して限界まで高速化している)
高速化の効果をリニアに体感できるポケコンとは異なり、プチコン3号でそこまで高速化
しなくてはならないという機会はないし、あってもポケコンほどは体感するのが難しく
苦労の割りにはメリットは少ないにょ。(リニアに体感できる高速化を得ようとするならば
このような1ナノ秒単位の変数の演算子の速度の違いに拘るのではなくアルゴリズム等の
改善をするべき)
限界までの高速化を行うならば先ほども書いたように演算子や変数使用の順番やそれらが
実行される確率などで変わってくるため最速プログラムを作りたいならば単命令の速度では
なくその命令を含む実測値が重要になってくるにょ。(速い命令を並べたらそれが最速に
なるというわけではない)
つまり、BASICというブラックボックス上で動いている以上は自分が書いたプログラムが
プチコン3号にどのように解釈されるのかというレベルまで考えてはじめて最速の
プログラムが書けるということにょ。(これがコンパイラならばよりコンパイルされた後に
どのようになるのかを考えた上でソースを書く必要がある))
したがって、命令や演算子の速度はどれがどの程度速いのかという相対値を知っておけば
十分ということにょ。(そのためその相対値として使える数字の誤差が出にくいプログラム
というのが私の作ったプログラム)
しかし、ポケコンなどのROM BASICとは異なり、プチコン3号で1ナノ秒単位の処理の最適化は
バージョンが変われば無に帰すためver.3.1.0でのみ最速を目指すので無ければほとんど
意味がないにょ。
さて、今回上記の1000回計測の結果をヒストグラム表示してこの計測値がどのような分布に
なるのかを視覚的に確認できるようにしてみたのだけどこの傾向というのは10回程度では
分からないにょ。
かといって、分布の確認表示をするため計測回数を増やしループ回数を減らしてしまう
(New3DSでさえ500万回ループを1000回実行するならばそれこそ2時間近い作業になるため
厳しい)というのは本末転倒となってしまうにょ。
ヒストグラム表示に意味を持たせるならば計測回数を最低でも100回できれば1000回以上に
する必要がありこの機能が欲しい人は各自で対応して欲しいにょ。(ヒストグラム表示
そのものは単純だけど100回計測、1000回計測なんて滅多に使わない用途でリストの長さが
倍増してしまうのも個人的にはあまり気に入らないため)
ちょっとやってみようと気軽に始めた今回の計測だけど実際にやってみると単に「平均を
出す」というだけでも様々な条件が絡んでくるため思った以上に困難だったにょ。
そして、誤差をいかに減らすのかが難題になったにょ。
そのため、たったこれだけのことをまとめるのに3週間かかったにょ。
まぁ計測中は放置で済むとはいえ、書きたいことが最初から分かっている講座と異なり
測定しながら新たな問題点が見つかりその改善策を考える必要があるため予想以上に時間が
かかってしまうにょ。
ちなみに500万回ループ、1000回計測をデフォにすれば正確な平均値や最頻値が求まるの
だけどすでに書いているように実行速度は様々なものが影響を与えるにょ。
しかし、値を左右する様々な要因について今回分かり私自身多くのことが勉強できたにょ。
これくらいならば数日で終わるだろうと思っていたものが3週間もかかってしまったため
私のサイトのプチコン3号コーナー制作の予定もかなり遅れているにょ。(遅れたのは他にも
twitterやMiiverseで公開しているような自作関数を作っていた影響も多少はあるけど)
次はその自作関数をまとめたページを作る予定にょ。
今まではほぼリストのみの公開だったけど1つのプロジェクトフォルダにまとめるので
入力するのが面倒だから使ってなかったという人もこれを機会にぜひ使ってみて欲しいにょ。
どれだけの需要があるか分からないコーナーだけど今まではtwitterやMiiverseで単発発表
してきたものをまとめるだけなのでそれほど難しい作業ではないにょ。(今回の計測結果を
まとめる作業と比べたら格段に簡単)
とはいえ、実際やってみると今回のように「思っている以上に面倒な部分」も見つかると
思うのでとりあえず連休中(5/6まで)には何とかしたいにょ。
それが、終われば入門講座の再開にょ。
スプライト関係は書くことがあまりに多くて後回しにしている状態なので次はWHILE〜WEND、
REPEAT〜UNTILあたりを書く予定にょ。
他にもやりたいことが溜まっているので連休中はこれくらいで終わりそうにょ。
まぁ作りたいものが見つかったらそちらを優先してしまうのでこの予定はあくまで未定
と思って欲しいにょ。
まぁ仕事でやっているわけではなく趣味として自己満足でやっていることだから自分が
やりたいようにやらせてもらうにょ(笑)
代入が重いといえば
圧縮プログラム(解凍)の2進数に変換するルーチンが1bitずつ代入していたので重かった。
そこで8bit分まとめて配列変数に入れて呼び出すようにして、代入回数を1/8にしたら結構早くなった。(ただしその配列がある分out of memoryがでやすくなる)
レスにょ
天郷思音さんへ
>そこで8bit分まとめて配列変数に入れて呼び出すようにして、代入回数を1/8にしたら結構早くなった。(ただしその配列がある分out of memoryがでやすくなる)
ループで処理しているならばそのループ内で多数使われている場合にはかなりの高速化効果が
期待できそうにょ。
配列変数の演算を少しでも減らすことができればさらに高速化できそうにょ。
最終的にはアルゴリズムを変えるのが一番という感じになるにょ。
実際Miiverseで円の塗りつぶしプログラムを作っていたときも私が昔考えたアルゴリズムを
限界まで速くしても速いアルゴリズムに対しては太刀打ちできなかったからね。
ネット用のノートPCを買い換えた
自宅のネット用のノートPCを買い換えたにょ。(まぁいつものごとく中古だけど)
さすがに購入して4年経ちあちこちガタが来始めているというのもあるし、昨今はネット
メインで使っていてもパワー不足を感じることもあるためにょ。(4年前に買った当時は
Core2Duo 2GHzあればVistaがサポート終了する2017年までは全然問題ないと思ったけど
そんなに甘くはなかった)
といっても、購入したのは2ヶ月前で全然弄る時間が無かった(1ヶ月保証の関係で必要
最小限の動作確認を行っただけ)けどようやく時間ができたので簡単な紹介をしてみる
ことにするにょ。(R9も換装用SSDを買ったまま放置状態だし)
昨年12月に購入したLets'note R9、今年2月に購入したIconia Tab 8Wに続く通算23台目の
ノートPCにょ。
機種はFMV-E780/AでCPUはCore i5-520M(2.4GHz、TB2.9GHz)、15.6インチフルHD液晶で
中古で16800円(税込)だったにょ。
買い換えるならばCore i5以上、フルHD以上にしたいという希望があったため一応その
条件を満たしているにょ。
Core i5を希望するのはCore i3よりも性能が高くCore i7と比べてコストパフォーマンスで
有利であるためにょ。(もちろんi7搭載機がi5搭載機と同レベルの価格で入手可能ならば
そちらがベターなのは言うまでもない)
Core i3はHTTもTBもないためHTTとTBのあるi5と比べるとピーク性能ではかなりの差が
出てくるにょ。
i7はノートPCの場合は「Q」が付くSKU以外はすべて2コアしかなくi5と同じで単にクロックが
高くL3キャッシュが多いというくらいの差しかないにょ。
第2世代Core iシリーズ(Sandy Bridge)搭載機は中古市場でようやく増え始めた段階でまだ
選択肢が少なく初代Core iシリーズ(Arrandale)から選んだのでCore i3を選んでしまうと
現状で使っているノートPC(FMV-A8255)と比べて体感速度での向上はあまり期待できない
というのが理由にょ。
液晶解像度も現状のノートPCはWSXGA+(1680x1050)という解像度なのでそれより上といえば
もうフルHD(1920x1080)しかないにょ。
16:9が主流になってきているためフルHDの1つ下はHD+(1600x900)となってしまい現状より
解像度が小さくなってしまうにょ。
解像度が現状より小さくなるのは論外なので最低でもフルHD以上は欲しかったにょ。
したがってCore i5、フルHDというのは次に買うノートPCの最低条件として掲げていたにょ。
今回買ったノートPCと現状で使っているノートPCのスペックはこんな感じにょ。
◎新しいPC(2010年夏モデル)2015年3月購中古で入
FMV-E780/A
OS Windows 7 professional(32bit)
CPU Core i5-520M(2.4GHz、TB2.9GHz)
メモリ 4GB
HDD 1TB
液晶 15.6インチフルHD(1920x1080)
(※デフォではメモリ1GB、HDD160GBだったのでそれから増設している)
◎現状のPC(2008年春モデル)2011年3月中古で購入
FMV-A8255
OS Windows Vista Business(32bit)
CPU Core2 Duo T7200(2GHz)
メモリ 4GB
HDD 500GB
液晶 15.6インチWSXGA+(1680x1050)
(※デフォではメモリ1GB、HDD250GBだったのでそれから増設している)
見ての通り発売時期は2年の差だけど購入の時期は4年経っているにょ。
その分、購入価格は前回27800円だったのが今回16800円へと1万円以上安くなっているにょ。
というわけで、早速ベンチを行ってみるにょ。
◎Windows エクスペリエンス インデックス
FMV-E780/A
プロセッサ 6.4
メモリ 5.5
グラフィックス 3.8
ゲーム用グラ 4.8
ハードディスク 5.9
《参考》
FMV-A8255
プロセッサ 4.9
メモリ 4.8
グラフィックス 3.5
ゲーム用グラ 3.5
ハードディスク 5.7
◎HDBench 3.40
FMV-E780/A
?? ALL??Integer?? Float??MemoryR MemoryW MemoryRW??DirectDraw
156751?? 605186??592308?? 379391??203572?? 411339??????????19
Rectangle?? Text Ellipse??BitBlt????Read?? Write?? RRead??RWrite??Drive
????40400??73741?? 67860?? 27703?? 94990?? 92418?? 23104?? 29425??C:\100MB
《参考》
FMV-A8255
?? ALL??Integer?? Float??MemoryR MemoryW MemoryRW??DirectDraw
77560?? 281881??187158?? 154879??103627?? 225484??????????60
Rectangle?? Text Ellipse??BitBlt????Read?? Write?? RRead??RWrite??Drive
?? ??27358??19155????8420???? 308?? 75294?? 76133?? 15674?? 35408??C:\100MB
◎CrystalMark2004R2
FMV-E780/A A8255と比べて
Mark 106929 1.5倍速
ALU 31655 1.6倍速
FPU 31435 1.6倍速
MEM 19057 1.8倍速
HDD 12011 1.7倍速
GDI 8819 1.7倍速
D2D 1695 0.4倍速
OGL 2257 1.4倍速
《参考》
FMV-A8255 CF-R9K
Mark 70567 72477
ALU 19239 21478
FPU 20724 19678
MEM 10651 14069
HDD 8782 8512
GDI 5049 5749
D2D 4456 1383
OGL 1666 1608
◎Superπ
104万桁 419万桁
FMV-E780/A 16秒 1分26秒
A8255比 1.8倍速 ??1.7倍速
《参考》
FMV-A8255 29秒 2分28秒
ベンチ結果を見てみるとまずエクスペリエンスインデックスはCPUは順当に伸びていてメモリは
搭載量は同じであるもののDDR2からDDR3へと高速化されているためスコアが伸びているにょ。
グラフィック関係も伸びているもののCPUなどと比べて低い値となっていてそこがボトルネック
となっているけどこれは普通にWindowsを使う限りはほとんど気になるレベルではない(OSの
画面描画が遅くて気になるとかはない)ので問題はないにょ。
HDBenchは古いベンチであるもののCPUに関してはマルチコア(というかマルチCPU)に対応
していてコア数に比例するようなスコアが出るにょ。
そのためHTTの効果が実使用よりも高めに出るためCore2Duo 2GHzを搭載のA8255の2〜3倍の
すごいスコアが出ているにょ。
メモリも先ほどと同じくDDR3の効果で伸びているにょ。
グラフィック(GDI)の結果がやたら高いのは画面がバグったせいにょ。
したがって、総合スコアは単純比較はできないにょ。
CrystalMarkもマルチコアCPUに対応しているけどHDbenchほどの差はないにょ。
CPU性能は概ね1.6倍程度の向上といった感じでマルチコア対応のソフトならばこんな感じ
かもしれないにょ。(Windwosは常に多数のスレッドが動作しているためマルチコア対応
でなくてもその向上を実感することができる)
私の過去の経験から速度の向上を体感するならば3割以上の速度向上が必要で明確な速度差を
体感する(使っていて全然違うと感じるレベル)のには2倍以上が必要となるにょ。
それを考えると体感できるレベルの差はあるのでこのベンチ結果も納得できるにょ。(まぁ
CPUだけ速くなっても他の部分が遅かったらそのせいで体感速度の向上を実感にしくいけど)
HDDが1.7倍速になっているのは容量が500GB→1TBへと向上に伴うプラッタ密度の向上の効果が
大きいにょ。
D2Dが下がっているのは同じArrandale世代のR9と同じ傾向にょ。
たまたま低いのかこの世代のGPUはスコアが振るわないのかはこれだけでは何とも言えない
感じにょ。
CPUの(基本命令のみを使用した)シングルスレッド性能を見るならばやはりSuper πにょ。
これから判断すると拡張命令を使用しない場合のシングルスレッド性能は1.7〜1.8倍くらいは
ありそうな感じにょ。
TB時2.9GHzでCPUのクロックは1.45倍なので効率化とキャッシュ性能のアップが影響している
と思われるにょ。
Core iシリーズは従来のCoreシリーズ(CoreDuo、Core2Duoと比べて大幅にキャッシュの
仕組みが変わっているからね。(端的に言えば従来はすべてのコア共有の高速L2キャッシュ
から超高速だけど容量の小さなL2キャッシュが各コアに用意され、そこまで速くないけど
大容量の共有L3キャッシュが用意されている)
さて、私のネット用ノートPCの推移を見てみると次のようになっているにょ。
LaVie NX LV16C・・・・MMX Pen166MHz、64MB、Win98
↓
LaVie NX LW30H・・・・セレロン300MHz、256MB、Win2K
↓
VersaProNX VA46H・・・セレロン466MHz、256MB、Win2K
↓
VersaPro VA80J・・・・Pen3 800MHz、256MB、Win2K
↓
FMV-7130MG・・・・・・PenM1.3GHz、768MB、Win XP
↓ ※768MBはネット用として使用していた時でTV録画用にして1.5GBへと増設
FMV-S8305 ・・・・・・PenM740(1.73GHz)、2GB、Win XP
↓
FMV-A8255 ・・・・・・Core2Duo T7250(2GHz)、4GB、Vista
↓
FMV-E780/A ・・・・・Core i5-520M(2.4GHz、TB2.9GHz)、4GB、Win 7
ネット用のノートPCとしてはトータルで8台目となるにょ。(最初はNECばかりだった
けどここ最近は富士通ばかりになっている)
あとはモバイルノートPCやゲーム用ノートPCなどがあるためノートPC全体(ここでの
ノートPCの定義はデスクトップPCを除いたWindows搭載PCを示す)の累計購入台数は
23台目となるにょ。(一番台数が多いのはモバイル用)
といっても、23台のうちほとんどが中古にょ。(上記の機種で1.6〜3万円くらいなので
ネット用ノートPCとしては今回買ったものが今までで一番安い部類)
新品のWindwosノートPC(非Atom)は3万円台から入手可能でAtom搭載機ならば1万円台から
入手可能になっている今中古PCを買う理由は何かというと「新品が安くなっても中古は
それよりも安い」「元々廉価品ではなく高価だったものが安価に入手できる」「あこがれ
ていたけど当時は手が届かなかったもの」などの多くの理由があるにょ。
私が今回中古を買ったのも新品のノートPCが3万円台で購入可能といってもそれらの機種は
WXGA(1366x768)ばかりで据え置きノートPCとしては使う気にはなれないためにょ。
フルHDならば安くても4〜5万円は必要になってくるにょ。
それを考えるならば今回のノートPCが16800円というのは十分お得といえるにょ。
唯一残念な部分といえばOSが32bit版であるということくらいにょ。(R9はリカバリから
32bitと64bitが選択できたため64bitをインストールし直したため搭載の6GBのメモリをフルに
使えているけど32bit版だと4GBから増やしてもRAMディスクにしかならない)
私が見る限りは中古ショップにおける最安レベルの価格でCore2Duo搭載でVistaモデルならば
5000円くらいから入手可能になっているにょ。(あくまで最安レベルというだけであって
特売品ならこれより安く買える可能性もある)
Win7が良いというのであればCore2Duo搭載で機種を問わずで8000円からといった感じにょ。
これが、初代Core i5/i7になると1.2万円くらいになり、第2世代Core i5/i7だと2万円弱にょ。
特定メーカーへの拘り、特定機種への拘り、特定スペックへの拘り、状態や付属品への拘り
などがあればこれよりどんどん高くなっていくため中古を購入する場合には「これは欲しい
けどこれは妥協する」というのがないと結果として高い買い物になってしまう恐れがあるにょ。
あと中古で問題なのは保証で多くのショップでは1〜3ヶ月程度の保証となっているにょ。
長期保証を付けているショップもあるけどそういうショップは概ね高めの価格設定となって
いるにょ。
無保証で良いならばヤフオク等で購入するという方法もあり、その場合だと上記最安レベルの
価格よりもさらに安く購入も可能だけどリスクもあるということに十分に注意しておく必要が
あるにょ。(部品取り用としてヤフオクで安く入手してニコイチで組み立てたことは何回か
あるけど)
PC初心者ならば中古には手を出さずちゃんとサポートや長期保証のある新品を買うのがベター
なのは言うまでもないけどね。
(無題)
配列が遅いと言うことで
S$[I+0]
S$[I+1]
S$[I+2]
S$[I+3]
的な、ありがちな処理を
S$=MID$(S$,I,??)
SHIFT(S$)
SHIFT(S$)
SHIFT(S$)
みたいに変えたら、加算も無くなるしワンチャン!?
と思ったけどやっぱりSHIFTの方が遅かった。
もっと文字数が増えたり、増えた文字の後ろのほうを扱う(Iの値が増える)場合には
まだワンチャンあるんかな〜 いや無いか〜
レスにょ
チラシ裏次郎さんへ
>もっと文字数が増えたり、増えた文字の後ろのほうを扱う(Iの値が増える)場合には
>まだワンチャンあるんかな〜 いや無いか〜
私があの表を作った時にSHIFTもUNSHIFTもPUSHもPOPも調べたけどどれも遅かったにょ。
やはり、これらを使えるように配列変数の仕組みが従来(mkIIまで)と比べて根本的に
変えられているためだと思われるにょ。
プチコンmkIIでは配列変数よりGSPOITの方が速かったのでプチコン3号でもその手を使おう
と思ったけどGSPOITで読み出してもRGB描く5bitに丸められた値しか読み出すことができず
16bit整数として使うならばその変換処理のせいで結局配列変数よりも遅くなってしまうにょ。
お絵かき用にタブレットPCを買ってみた
お絵かき用のPCとしてタブレットPCを買ってみたにょ。
買ったのはHP Elitebook 2740pにょ。(といっても、買ったのは先月で買ってからろくに
使ってなくてGWにようやくお絵かきに挑戦してみた)
コンバーチブルスタイルのタブレットPCでワコム製デジタイザ、タッチパネル、Core i7、
SSD搭載で中古で22800円にょ。
◎HP Elitebook 2740p
OS Windows 7 professional(32bit)
CPU Core i7-620M(2.66GHz、TB3.33GHz)
メモリ 4GB
SSD 160GB (Intel製)
液晶 12.1インチWXGA(1280x800)マルチタッチ対応
(※デフォではメモリ2GBそれから増設している)
初代(Arrandale)とはいえ通常版Core i7を搭載だし、標準でIntel製のSSD(Micro SATA
接続)を搭載しているので5年前の機種とはいえ性能はそこそこ高そうにょ。
というわけで、早速ベンチを計測してみたにょ。
比較対象は一昨日に書いたネット用に購入したノートPCのFMV-E780/A、現行のお絵かき用の
ノートPC(モバイル用兼任)のLet'snote CF-R9にょ。
いずれも第1世代のCore iを搭載しているにょ。(E780/Aは通常電圧版i5、R9は超低電圧版の
i7を搭載)
◎Windows エクスペリエンス インデックス
HP Elitebook 2740p
プロセッサ 6.5
メモリ 5.5
グラフィックス 3.8
ゲーム用グラ 4.7
ハードディスク 7.4
《参考》
FMV-E780/A
プロセッサ 6.4
メモリ 5.5
グラフィックス 3.8
ゲーム用グラ 4.8
ハードディスク 5.9
CF-R9K
プロセッサ 5.4
メモリ 5.5
グラフィックス 3.3
ゲーム用グラ 4.6
ハードディスク 5.7
◎HDBench 3.40
HP Elitebook 2740p
?? ALL??Integer?? Float??MemoryR MemoryW MemoryRW??DirectDraw
165196?? 622915??603664?? 405247??275196?? 519372??????????21
Rectangle?? Text Ellipse??BitBlt????Read?? Write?? RRead??RWrite??Drive
???? 2550?? 1933????1733???? 139??142618?? 42881??102502?? 17787??C:\100MB
《参考》
FMV-E780/A
?? ALL??Integer?? Float??MemoryR MemoryW MemoryRW??DirectDraw
156751?? 605186??592308?? 379391??203572?? 411339??????????19
Rectangle?? Text Ellipse??BitBlt????Read?? Write?? RRead??RWrite??Drive
????40400??73741?? 67860?? 27703?? 94990?? 92418?? 23104?? 29425??C:\100MB
CF-R9K
?? ALL??Integer?? Float??MemoryR MemoryW MemoryRW??DirectDraw
100791?? 349378??382476?? 248918??161228?? 323890??????????14
Rectangle?? Text Ellipse??BitBlt????Read?? Write?? RRead??RWrite??Drive
???? 1139?? 1295????1337???? 112?? 72882?? 75349?? 19475?? 26459??C:\100MB
※GDIの項目は正常動作していないので比較はできない
それと同時に総合スコアも比較できない
◎CrystalMark2004R2
HP Elitebook 2740p
Mark 128344
ALU 32762
FPU 32410
MEM 21156
HDD 27906
GDI 9509
D2D 2040
OGL 2561
《参考》
FMV-E780/A
Mark 106929
ALU 31655
FPU 31435
MEM 19057
HDD 12011
GDI 8819
D2D 1695
OGL 2257
CF-R9K
Mark 72477
ALU 21478
FPU 19678
MEM 14069
HDD 8512
GDI 5749
D2D 1383
OGL 1608
◎Superπ
104万桁 419万桁
HP 2740p 13秒 1分18秒
《参考》
FMV-E780/A 16秒 1分26秒
CF-R9K 20秒 1分50秒
◎CrystalDiskMark 3.0.1
?????????? Sequential Read :?? 223.149 MB/s
??????????Sequential Write :?? 107.425 MB/s
???????? Random Read 512KB :?? 180.639 MB/s
????????Random Write 512KB :?? 105.882 MB/s
????Random Read 4KB (QD=1) :????14.382 MB/s [??3511.2 IOPS]
?? Random Write 4KB (QD=1) :????21.190 MB/s [??5173.3 IOPS]
?? Random Read 4KB (QD=32) :?? 153.123 MB/s [ 37383.5 IOPS]
??Random Write 4KB (QD=32) :????89.821 MB/s [ 21928.9 IOPS]
まず、Windowsエクスペリエンスインデックスを見るとCPUに関してはCore i7といっても
QがつくSKU以外は2コアであり、i5と同じであるためCore i5と比べた場合にはキャッシュ
とクロックが多少多いという程度なのでE780/Aとの差はあまりないにょ。
R9はCore i7といっても超低電圧版でクロックが低い(通常1.2GHz、TB時2.26GHz)ため
他の2機種と比べると大きく劣るにょ。
2740pのポイントとなるSSDはエクスペリエンスインデックスの上限値となる7.9には届か
なかったものの7.4という極めて高いスコアがでているにょ。
CrystalMarkにおいてもエクスペリエンスインデックスと同様の傾向となっているにょ。
クロック差は1割もないためCPUのスコアはCore i5搭載のE780/Aと比べて微増となって
いるにょ。
その代わりHDDのスコアは3倍以上の素晴らしいスコアが出ているにょ。
Super πはシングルスレッドベンチであるため2740pがTB3.33GHz、E780/AがTB2.9GHz、
R9がTB2.26GHzでほぼ順当な結果にょ。
SSDの速度は別途CrystalDiskMarkで計測してみたにょ。
READが223MB/s、WHITEが107MB/sで両方とも500MB/s程度出る最新のSSDと比べると劣る
もののこの世代(5年前)のものとしては十分に高速だと思われるにょ。(というか、
SATA2.0の規格上限値が300MB/sなのでそこまで速いSSDは当時作られなかっただけ)
さて、2740pの性能が概ね分かったところで私のお絵かき用PCの変遷を見てみるにょ。
PC-9821V10・・・・Pentium 100MHz(→MMX Pen 233MHz)、16MB(→64MB)、Win95→98SE
↓
自作PC初号機・・・セレロン 800MHz(→セレ1.4GHz)、256MB(→512MB)、98SE→2K
↓
VersaPro VA11J・・PentiumIII-M 1.13GHz、64MB(→512MB)、Win2K
↓
CF-R2 ・・・・・・PenM 1GHz、256MB(→768MB)、Win2K
↓
CF-R3 ・・・・・・PenM733(1.1GHz)、256MB(→768MB)、WinXP
↓
CF-R5 ・・・・・・CoreSolo U1400(1.2GHz)、512MB(→1.5GB)、WinXP
↓
CF-R9 ・・・・・・Core i7-620UM(1.2GHz、TB2.26GHz)、2GB(→6GB)、Win7 64bit
↓
2740p ・・・・・・Core i7-620M(2.66GHz、TB3.33GHz)、2GB(→4GB)、Win7 32bit
※デフォルトから増設、換装している場合は両方を記述している
お絵かき用のPCとしては7台目、ノートPCとしては24台目となるにょ。
上記の変遷ではお絵かき用のPCは8台書いているのに7台というのは変に思うかもしれない
けどそれはPC-98ではお絵かきはほとんどしてないため除外しているにょ。
というのも、まともに描くならばスペック不足だし、USBもないためペンタブが使えず
マウスで描く必要があったためにょ。
私は下記の講座でも書いているように公開サイズの3倍くらいのキャンバスサイズで
書いて公開時にそれを縮小しているにょ。
私の絵ができるまで 〜初心者向けのデジタル絵講座〜
http://ochameclub.web.fc2.com/CG/making.htm
私のPC-98はWin95と同時発売の機種であり、デフォでは16MBしかメモリを搭載してなかった
けどそれではWin95もやっと動いていた感じであり、Win98だと全然足らないためメモリを
16MB→48MB→64MBと増設していったにょ。
ハードウェア(チップセット)の上限値が128MBなのでそこまで増やせば多少は変わると
思うけどさすがに4スロットすべてのメモリを交換になるため当時の価格でリテール品で
4〜5万円(メーカー側がPC-98での動作保証をしているメモリの場合)、バルク品で1〜2万円
かかりとても増やす気にはならず自作PCを組むことにしたわけにょ。
CPUもデフォルトでは発売当時は高速な部類だったPentium 100MHzもWeb閲覧や動画再生を
する場合には全然足らないためMMX Pentium 233MHzに差し替えたにょ。
画面表示も遅いためデフォルトのVGA(当時は「Windowsアクセラレータ」と呼んでいた)で
あるGD5440(VRAM 1MB)からVirge(VRAM 2MB)へと変えてさらにSavage4pro+(VRAM 32MB)
へと変えたにょ。
最強とは言わないけど最強に近いレベルまで強化したもののそれでも640x480の3倍である
2000x1500くらいでお絵かきするのは厳しかったにょ。(もちろん、640x480で描けば十分
問題はなかったけど)
あと拡張スロットはPCIバスはWindowsアクセラレータ、Cバス(PC-98用の汎用拡張スロット)
にはモデム(33.6Kbps)、SCSI-2ボードが挿されておりUSBポートを増設する余裕なんて
なかったにょ。
まぁ当初のUSB1.0は相性が出まくりだったし、規格最大速度で1.5MB/sだったのでSCSI-2の
10MB/sにも劣るためUSB1.0ポートを増設したいとは思わなかったにょ。(ちなみにSCSI-2は
PCカードリーダ、MOドライブを接続していて大活躍していた)
そんなわけでSCSI-2接続のスキャナEPSON GT-5500を手に入れてアナログ絵のスキャンをする
程度に止まったにょ。(スキャンは高速なSCSI-2のお陰で当時ポピュラーだったパラレル
ポート接続のスキャナを圧倒する速度だった)
というわけで、まともにPCによるデジタル絵を描き始めたのは自作PCを組んだ2001年から
になるにょ。(デジタル絵そのものはザウルスで描いていたため96年から描いているし
ポケコンで描いたドット絵や友人宅のパソコンで描いたものを含めると80年代からになる)
当時はPC-98でスキャンした下絵を自作PCに転送して塗っていたのだけど転送するにも当時は
LANを構築してなかったし、FD1枚(1.44MB)には収まらなかったのでCF(コンパクト
フラッシュ)経由で転送していたにょ。
ペンタブを購入して色塗りのみペンタブで行っていたにょ。
USB2.0規格のスキャナが発売されたとき(2002年)に買ったのが未だに現役のGT-8300UFにょ。
(しばらく使ってないけどWin7用のドライバがないため使用するならばXP modeを使うしか
無さそう)
このお陰でPC-98を使うことなく自作PCのみで完結することが可能になったにょ。
ただ、自作PCで描いていて突然の停電や電源コードを引っかけたなどのトラブルが何度も
経験したためそれからはノートPCで描くことにしたにょ。
そこで、それなりにハイスペックなノートPCとしてVA11Jを2003年に中古で購入したにょ。
最新の3Dゲームもプレイ可能なmobility RADEON搭載して発売当時の価格は定価50万円
だったにょ。
http://kettya.com/notebook/ranking/2001summer/recommend_2001summer.htm
これによって突然ACアダプタが抜けても問題ない上にデスクトップPCを置いている場所で
しか描けなかったという制約も無くなり飛躍的に楽になったにょ。
しかし、2005年にPenMを搭載のLetnote CF-R2を購入してモバイルノートが私の所持PCで
最高性能になってしまったにょ。(同年にゲーム用ノートとして当時ノート用としては
ハイエンドとなっていたRADEON X700を搭載のPCを購入し、さらに同年末には自作PCの2号機
によってそれをさらに超えたわけだけど)
そのためモバイルノートで絵を描くという今までは考えなかったことにチャレンジしてみた
ところ小さいためテーブルに2台並べて置くことが可能で15インチのメインノート(ネット
用ノートで資料を表示しながら描くということもできるようになったにょ。(もちろん
資料を丸写しだと単なる模写なのでそれをあくまで参考にして描くというだけなんだけど)
2006年にR2からR3に買い換えてもそのままモバイルノートで描くというのを続けていたの
だけど問題は描いている絵の解像度が高くなったためメモリ768MBでは足らなくなって
しまったにょ。
そのため、2009年にR5に買い換えてメモリを上限の1.5GBへと増設したにょ。
それでずっと描いてきたけど1.5GBでさえ足らなくなってきたし、XPのサポート終了に
伴い昨年末にR9に買い換えてメモリは上限の6GBへと増設したにょ。
ただし、Let'snoteのRシリーズは小型軽量で堅牢性が高く長時間駆動ということでモバイル
用としては優れている反面で液晶の品質はそれほど良いものではなく今回買ったR9も経年
劣化があるためさらにあまり良い感じではないにょ。
それに今時XGA(1024x768)というのは狭すぎるにょ。
個人的には4:3液晶は嫌いではなく16:9よりも縦に大きいため好きなんだけどXGAだと左右に
ツールとレイヤー一覧を表示したら実作業スペースが極めて小さくなってしまうからね。
その問題に加えてお気に入りだったピンクのbambooの調子が悪くなってしまったにょ。
いつものごとくコネクタ部分の接触不良にょ。
最初は認識はしているけど描いているうちにペンタブを動かしたら認識しなくなって
しまうため次第にお絵かきをする頻度も下がってしまったにょ。(最近はラフからすべて
デジタルとなるフルデジタルで描いていてアナログでは一切描いてないため)
さらに仕事が忙しくなったり、プチコン3号に夢中になったりして絵からどんどん離れて
いったにょ。
これではいけないと思い新しいペンタブの購入を考えたけどまたbamboo(というか今は
無印Intuosが旧bambooの後継となっている)を買うというのも何だし、液タブに興味が
あったけど液タブ(Cintiq)はいかんせん高価であり、さすがに手が出せないにょ。
12インチのCintiqの中古を買うという方法もあったけど中古ショップで見かけることが
ほとんどないためそれならば「タブレットPCで液タブっぽいことができるのでは?」と
いうことで安価でそこそこ高性能なワコム製デジタイザを搭載したタブレットPCを探して
いたところ今回購入した2740pが見つかったということにょ。
というわけで、2740pを手に入れるまでの20年近い道のりを大ざっぱに書いてきたけど
やはり問題は液タブとして使えるか否かという点だと思うにょ。
ワコム製デジタイザとはいえ、筆圧検知はたったの256段階にょ。
これは初期のFAVOレベルにょ。(後期のFAVOで512段階、bambooやその後継のIntuosだと
1024段階、現Intuos Proだと2048段階)
とはいえ、タブレットPCで筆圧256段階という機種は最新機種の中にも結構多いにょ。
256段階で問題か、問題ないかは自分が描いている絵のタイプにもよるため実際に使って
みないと分かりにくいため256段階だからダメという単純なものではないにょ。
少なくともアニメ塗りならばそこまで繊細なタッチは不要なのでそれほど問題は無さそう
に感じたにょ。
実際に描いてみるとどうだったかというと256段階云々の前に次の4つの問題があったにょ。
(1)カーソルがずれる問題
(2)表面がつるつる問題
(3)タッチとペンの誤動作問題
(4)お絵かきブランク問題
(1)まずはタブレットPCを使う場合にはカーソルが正確に動くように設定を行う必要がある
けどそれでも3mm程度のずれが生じてしまうにょ。
お絵かきをする時はキャンバスを回転させる(自分が線を引きやすい向きにする)という
ことは頻繁に行うけどタブレットPCや液タブで描く場合には物理的に回転ができるという
メリットがあるにょ。
しかし、物理的に回転させてしまうとせっかく合わせた初期設定が台無しになってしまい
5、6mmくらいカーソルがずれてしまうにょ。
つまり、タブレットPCならばアナログ感覚で描けるかというとそうではなくペンタブと
同じくカーソルを追って描く必要があるにょ。(描画される長さと手を動かす長さが等しい
というメリットがあるだけ)
(2)アナログで描く場合にはペンと紙との間には適度な摩擦があり、それでスムーズな書き味を
実現しているにょ。
ペンタブではそれなりには摩擦があるものの気に入らなければペンタブの上に紙を敷いて
描けば感触だけはアナログと同等になるにょ。
しかし、タブレットPCや液タブではその裏技は使えないにょ。
敷くとしても透明のシートに限られるけど自分の感触にマッチしたそんな都合のよいシートは
なかなか手に入らないにょ。
(3)2740pはデジタイザ機能だけではなくマルチタッチ機能も備えているにょ。
デジタイザ機能が働いている時は自動的にタッチを無効化しているため画面に手を置いて
描くということが可能になっているもののペンを一定以上の高さまで上げた際にはタッチが
有効になってしまい手を置いている場所に描画されてしまうにょ。
それを克服するためには手袋を着けて描くというのも1つの方法だけど2740pはなぜか手袋を
付けて描いても誤動作してしまうにょ。(布製手袋なので感圧式ではなく静電容量方式の
タッチパネルで誤動作するはずがないのになぜ・・・?)
(4)これが結構大きくて3、4ヶ月全く描いてなかったため完全に自分の絵を忘れているにょ。
これは数枚描けばすぐに思い出せるのだけど上記(1)〜(3)の問題によって未だに1枚も描けて
ない状態にょ。
というわけで、筆圧256段階は関係なくこれらの問題によってかなりの慣れが必要に感じて
いるにょ。
そして、筆圧256段階というのはアニメ塗りの場合は塗りの際にはほとんど影響が無さそう
だけど線画においては結構繊細なので少し物足りないという感じがするにょ。(1024段階の
bambooが比較対象だから仕方がないけど)
しかし、256段階の旧型FAVOで素晴らしい絵を描いてきた人はたくさんいるためこれもある
程度は慣れで克服は可能だと思われるにょ。
ということで、お絵かき用途としては現時点ではまだ評価保留とさせてもらうにょ。
ある程度慣れてみないと何とも言えないからね。(ペンタブも最初は全然使うことができず
塗り専用としていたけど10年描いてきてようやく線画が描けるようになり4年前からフル
デジタルに移行したくらいだからね。(私は普通の人と比べて慣れるまでにかかる時間が
長い気がするくらい)
それを考えると数時間使ってイマイチというのは仕方がないにょ。
R9から唯一のパワーダウンとなるのがOSが32bit版であるということにょ。
64bit版ならば4GB以上のメモリが使用できるため64bitで動作するソフトならばメモリを
すべて有効活用できるし、32bit用ソフトであっても重量級ソフトを複数立ち上げたときの
安定感に優れるにょ。(1アプリ2GB制限があるけど32bitOSだと全部で2GBの制限となる)
私が現状で描いている絵ならば32bitと64bitで明確な差は出なさそうなので問題ないけど
これから新規にデジタル絵を始めようとする人だとOSは64bit版をオススメするにょ。
モバイルノートとしてみると2740pは1.7kgと重いため個人的には論外の重さ(R9の約2倍の
重さ)だけど上記のように標準電圧版Core i7を搭載していて性能は十分に高いし(まぁ
最新の第4世代Core i7と比べると超低電圧版にさえ劣るレベルの性能だけど)、ポイン
ティングデバイスはタッチパッドだけではなくアキュポイントのような感圧式のデバイスも
付いているし有線LAN、(今時使うか分からないような)モデムポート搭載だし、拡張用に
ExpressCardスロットも搭載しているにょ。
モバイルノートとして考えると駆動時間と重量以外は悪くない機種だと思うにょ。
個人的にはそこがモバイルノートの非常に重要なポイントだと思うので2740pをモバイル用
として使うことは無さそうにょ。
22800円あれば機種を選ばなければ第2世代Core i5(SandyBridge)搭載のノートPCを買う
ことは可能だったような気もするけど何でもいいからノートPCが欲しいというわけでは
ないにょ。
15インチでWXGAのノートPCを買っても現状では使い道がないからね。
とはいえ、次に買い換える時には確実にSandyBridge以降になると思うにょ。(さすがに
同世代の機種に買い換えは普通はありえないので)
とはいえ、R9に関しては後継機そのものがないため難しそうにょ。(個人的にはRZ4あたり
となるけどさすがに高価で手が出せない)
テレビ録画用ノートPCをゲット!
さて、ノートPCとしては21台目のCF-R9(2014年12月購入)、22台目のIconia Tab8(2015年
2月購入)、23台目のFMV-E780/A(3月購入)、24台目のHP Elitebook 2740p(4月購入)と
きてさらに先月通算25台目のノートPCを購入したにょ。
買ったのはThinkPad X200にょ。
購入価格は6800円と非常に安価で状態はそれほど良くないもののこの価格ならばお買い得と
言えそうにょ。
ちなみにスペックはこんな感じにょ。
◎ThinkPad X200
OS Windows 7 professional(32bit)
CPU Core2Duo P8600(2.4GHz)
メモリ 2GB
HDD 250GB
液晶 12.1インチWXGA(1280x800)
(※デフォ状態のまま全く増設していない)
◎Windows エクスペリエンス インデックス
ThinkPad X200
プロセッサ 5.9
メモリ 5.5
グラフィックス 3.9
ゲーム用グラ 3.4
ハードディスク 5.9
◎HDBench 3.40
ThinkPad X200
?? ALL??Integer?? Float??MemoryR MemoryW MemoryRW??DirectDraw
97797?? 338943??340751?? 182713??114668?? 230604??????????17
Rectangle?? Text Ellipse??BitBlt????Read?? Write?? RRead??RWrite??Drive
????25361??44968?? 46187?? 18442?? 83049?? 78108?? 26249?? 25141??C:\100MB
※GDIの項目は正常動作していないので比較はできない
◎CrystalMark2004R2
ThinkPad X200
Mark 78261
ALU 23442
FPU 20194
MEM 11062
HDD ??9905
GDI 7011
D2D 1683
OGL 1964
これも先月購入したわけだけどTV録画用PCとして考えているにょ。
現在のTV録画用は現役で常時使用している機種の中で唯一のPenM搭載機であり最後のXP搭載機
となるFMV-7130MGにょ。
これを何とかしたかったにょ。
ネット用のPCを買い換えたので元使っていた(というか、まだリプレイスしていないため
現状でまだ使っているけど)FMV-A8255をTV録画用にするという考えもあったけど現在使って
いるPCが13.3インチ4:3液晶であるため現在のスペースに収めようとするならばワイド液晶で
あれば12.1インチになってしまうためにょ。
またA8255はCPUがCore2DuoなのはいいけどHD動画の再生支援機能を持たないにょ。
地デジのMPEG2ならば何とか再生できてもBlu-rayは厳しいにょ。(ちなみに私のデジカメ
WX100で撮影したフルHD動画もコマ落ちしまくる)
しかし、GM45以降はH.264の再生支援機能が備わっているにょ。
HD動画の再生支援機能としては初代であるため再生支援機能そのものはおまけレベルだけど
それでもないよりはずっとマシにょ。(その次の世代である初代のIntel HD Graphicsでその
再生支援機能は大幅に改善された)
というわけで、GM45以上、Core2Duo 2GHz以上の安価な12.1インチのノートPCを探していたにょ。
12.1インチクラスというのはリースアップ品が大量に出回るため比較的安価になりやすいの
だけど国内メーカーのものだとほとんどが低電圧版もしくは超低電圧版のCPUであるため動作
クロックが低いものばかりにょ。
そうなると必然的に外資系メーカーとなるにょ。
それで、HP、Dell、Lenovoを探してみたところ見つかったのが今回購入したX200だったにょ。
モバイルノートは多数買っているもののThinkPadを買うのは今回が初めてにょ。(ちなみに
多いのはLet'snoteで25台中7台がLet'snoteとなっている)
状態はそんなに良くないけど最初からモバイル用に使うというわけではなく狭い空間に設置
できるUPS内蔵の小型PCとして考えているため問題ないし、液晶品質が低い(X200の性能が低い
というのではなく中古のための経年劣化)という問題も動画再生用として使う場合には
フルHDモニタに接続するため全く問題はないにょ。
環境構築するにはしばらく時間がかかりそうだけど試しに私がデジカメで撮影したフルHD
動画(H.264)を再生するとA8255ではコマ落ちしまくっていたけどX200ではコマ落ちすること
なく再生ができたにょ。
Blu-ray再生も視野に入れているけどこれならば全く問題は無さそうにょ。
モバイルとして使うならばX200のサイズ、重量でも個人的にはやや厳しいし、標準バッテリ
での駆動時間も短めなので最初からモバイル用途には使う気はなかったけどこれは
「省スペースPC+UPS」で6800円と考えれば格安にょ。
TV録画用PCとしてうまく活用ができるか否か(要するに安定して動作するか否か)はしばらく
様子を見てみないと分からないけどその前にまずは環境構築をしないといけないにょ。
チューナーと外付けHDD(ドライブ+USB3.0ケース)はすでに買ってあるのでそれを接続して
設定をすれば終わりなんだけどTS録画で録画ししたデータは重いため外付けHDDに転送するには
USB2.0では荷が重いためExpressCard接続でUSB3.0ポートを増設する必要があるにょ。
そのため上記では記載していないけどExpressCardスロットがあるというのもX200の重要な
ポイントとなっているにょ。(最初からUSB3.0ポートがあるPCを買えば済むだけの話だけど
それだと高価になってしまう)
WinXPからの移行が遅れたため常用しているノートPCは半年前には「XPが3台+Vistaが1台」
という構成だったけど最近買ったすべてのPCの環境の移行が終了すれば、「7が4台+8.1が
1台」という構成に変わるにょ。
XPはおろかVistaの切り捨ても完了してしまうにょ(笑)
使われない「積みノートPC」がどんどん増えていくのが一番の難点にょ。
これは昨今はノートPCを処分するにもお金がかかるため本当に部屋の隅に積むだけにょ。
ヤフオクなどを活用すれば多少のお金にはなるかもしれないけど買い換えるからには何らかの
問題を抱えているわけなのでヤフオクに出す手間を考えるとあまり割りは良くないにょ。
それにまた会員登録するのも面倒だしそれを維持するのにも余分なコストがかかってしまう
からね。
まぁ欲しい人がいれば自宅まで来たら無料であげるけど今時PenM、もしくはそれより古い
世代のノートPCなんて欲しがる奇特な人はあまり無さそうにょ。
普通に動作する機種は欲しい人にその都度あげているため残っている機種は上記のように
何らかの問題を抱えている機種ばかりだし・・・。(というか、起動さえしない機種も
結構あるためそれを欲しがる人なんてまず居ないと思う)
私の家にも5台位使わないPCが
そういえば、私の家にも5台位使わないPCがありました。
Meが1台とXPが4台かなあ……。そのうちのいくつかは使えるけど危ないから使わないPCで、残りは物理的に壊れてしまったPC。
使わなくなったPCの利用法……Linuxくらいですかね。PC本体が壊れていたら話しになりませんが。
うちの兄は
パソコンをもらってくることがある
最近古くて破棄するパソコンもらってきたが古すぎていろいろめんどくさかったらしいが、どうにかして使ってるようだ
XPとかいう次元じゃなくて九十いくつだっけな
いまはまさか7入れたとかないよね?
(無題)
配列が遅いと言うことで
BGPUTを乱発するのと
配列に値をセットしたのちBGLOADするのを比較したら
BGPUTの方が遅かったが
差は大きくなく、
BGデータは同じ値が連続することが多いので
BGFILLを併用するように作れば逆転するかも?な印象。
それだけ配列が遅いと言うことだろうが
範囲指定で配列に同じ値をセットする命令があればいいなーもちろん機械語で動く
・・・なんだその需要の無い命令
将来の夢
の1つ、自作パソコンを作ること
きっかけは、何度か言った気がするけど、中学校にASCII.PCがあってそれに話が載ってたから。
ただ一つ懸念。はたして数年後に自作パソコンなんてものは存在するのだろうか。
http://waaimyroom.web.fc2.com/
初心者のプログラムを改造してるけど
あんまりこういう言葉もよくないが、酷い。
スペルミスくらいなら微笑ましいけど、
変数SPDの値が-100=速度0
とか、もはや理解不能
(無題)
天郷思音さん:
>の1つ、自作パソコンを作ること
今時、嬉しい心意気です。安ければ、5万円かかりませんのでチャレンジしてみてください。
>きっかけは、何度か言った気がするけど、中学校にASCII.PCがあってそれに話が載ってたから。
私の場合は、信じられないかもしれませんが、「自作の方が安かったから」です。
当時Windows95、98時代は完成品で30万円くらいしました。これがパーツをかき集めて作れば20万そこそこで出来ました。そのために台湾へいこう!なんてツアーもあったくらい。
また、当時のPCはマザーボード上には音源もGPUも乗っておらずいろいろ拡張する余地があって、カード追加の楽しみもあったんですが、
今はマザーボード上にほとんど実装されていて、グラボとCPUくらいが追加の楽しみみ
なっちゃいましたね。それでも、自分で選んだパーツを好きな構成で組み上げるのは
楽しいです。渡しの場合メモリとストレージに思い切り予算を割いた構成です。
>ただ一つ懸念。はたして数年後に自作パソコンなんてものは存在するのだろうか。
今の最新GPUクラスのグラボがCPU内蔵になればいわゆるAT互換機というパソコンは
既製品ばかりになるかもしれませんが、
コンピューターの仕組みを勉強する目的でraspberryPIとかichigojamみたいな
むき出しの基盤コンピューターはこれからも出続けるでしょうからまだまだ、あるんじゃないでしょうか?
これらは名刺くらいの大きさなので、3Dプリンターやプラバン、木や紙でケースすら自作できます。
http://jp.techcrunch.com/2015/02/03/20150202raspberry-pi-2/
http://ichigojam.net/
自作の値段
その雑誌だと頑張れば3万って書いてあった。まあ私は高性能がほしいけどね。
http://waaimyroom.web.fc2.com/
(無題)
天郷思音さん:
3万円はかなり厳しいラインですね。
今だと、mini-itxのceleronJ1800クラスとかNUCのceleronN2800クラスになっちゃいますね。
省電力が売りのAtom系celeronですが
これでもCore2duo程度のパワーが有ります
http://www.gigabyte.jp/products/product-page.aspx?pid=4881 #ov
http://pssection9.com/archives/dn2820fykh.html
昨年、corei7マシン組んだときは7万円かかりました。
流用出来たのはケースとBDドライブだけでほかは
マザボ、メモリー、HDD、CPU、電源まで新規に買わざるを得なくなりました。ほとんど買い直しに近いですね。
とはいえ、全体のパフォーマンスは前のCore2duoと比べ物にならないくらい上がりました。
こんばんは。
ワンポイントテクニックに1KEY入力判定を投稿させていただきました。
1KEY GAMEはもちろんですが、カーソル移動等通常のプログラムにおいても基本は1度に1つのキーでしょうから実用性のあるテーマだと思い選びました。
元々は【基本形】の前に【従来型】があったのですが、少しでも記事を短くしようとして切り捨てました。
その結果、before〜after形式のbeforeの部分が無くなってしまったために、いきなり解答から始まってしまって、何がテクニックなのか分からないものになってしまいました。
「こんな事をすれば処理速度やシンプルさに重点が置かれたプログラムになりますよ。」と言うことを伝えたかったのですが…
こんな事の例
・条件式をINKEY$のみに
・論理式(INKEY$
うわあ
i5だとCPUだけで2万円・・・
i3の一番安いのでやっと13980円とか
http://waaimyroom.web.fc2.com/
い・かえる
天郷思音さん:
安くて高パフォーマンスなCPUなら、pentiumG3258はどうでしょうか?
一応Coreiアーキテクチャ第5世代なんで省電力でハイパワー。
しかもオーバークロック可で、最大4GHZ超も可能です。
それでいて価格は8000円台という超お得CPUです。
http://www.itmedia.co.jp/pcuser/articles/1408/05/news117.html
こうやまさんについて
こうやまさんの自作自演の発覚で2chやミーバースの空気が悪くなって皆が困っています。
こうやまさんの自作自演がばれるのはこれで3回目です。
本人のためにもそういった事をやめさせるように対応しましょう。
問題行動を見てみぬふりをして相手をしている人も同罪です。
証拠など詳しくは
http://wktk.2ch.net/test/read.cgi/handygame/1428055634/19-
2chの信ぴょう性
に疑問有り。
URLのところ見たけど、どれがあなたの言う「証拠」なのかわからない。
まあ、wikipediaでもどうにかなっているので何かまずいことしてる可能性は否定しないけど。
天郷思音さんへ
2chの信憑性と表現している時点で、あなたの情報を読む能力に疑問を感じますね。
そのスレッドで検証されている状況証拠とその考察の論拠となる材料は、
すべてミーバースやツイッターに残されており、それには2chや匿名等という言葉は関係ありません。
あなたの信憑性に対する考え方を適用するならば、このサイトの管理者であるおちゃめ氏も匿名なので信憑性に欠けるという事になってしまいますよ。
(無題)
165番の書き込みみました?
http://waaimyroom.web.fc2.com/
少し詫びる
信ぴょう性については該当の書き込みを踏まえてではなく、単なるイメージとして言った。
それと、「165番の書き込みみました?」のほうは勢いで返信した側面がある、申し訳ない。
しかし、その板をじっくり見たけどリンクなき引用が多いね。
それに、あなたの言う「こうやま氏の悪事」に懐疑的な意見もある。この件にはどう思うかな。
それと、2chの外に証拠があるなら、なんでそこにリンクを張らないのですか。
(無題)
そうか、これは論争じゃなかったのか。
論争だと早とちりして返信を書いてしまった。
おちゃめさんすみません。
http://waaimyroom.web.fc2.com/
スマートフォン版
掲示板管理者へ連絡
無料レンタル掲示板