リアルタイムに更新するグラフの描画

[田中]

こんにちは．
３度目の書き込みとなります．

ジョイステッィック等のセンサから信号電圧を読み取り，
その結果を縦軸が電圧，横軸が時間のグラフとして，
リアルタイムで描画したいと考えています．
CかC++が良いです．

そこで質問なのですがCかC++を用いた場合に，
リアルタイムで更新されるグラフを描画する方法としてどのようなものが有りますでしょうか？

[みけCAT]

Win32 API、DXライブラリ、OpenGLなどの方法が考えられます。
対象のOSは何ですか？

[田中]

すみません追記です．

どのような方法があるかというか，
・　どの方法が一般的か
・　どの方法を学んでおくべきか
ということを一番知りたいです．

だから方法の数を知りたいわけではなく，
オススメの方法を知りたいです．

[田中]

＞みけCAT様

追記書いている間にかぶってしまいました．

OSは，Windows７の32ビットです．
開発環境はVisual studio 2008 Express editionを利用しています．

[みけCAT]

「リアルタイムで更新」は、どのくらいのリアルタイムを必要としていますか？
10分、5分、1分、30秒、10秒、1秒、100ms、20ms、10ms、1ms、1μs、1nsなどなど…

[田中]

そうですねー
そこまで具体的には考えてませんでした．

今回利用するAIOデバイスは
http://www3.contec.co.jp/B2B/ConIWCatPr ... ct_Id=1664
でして，
A/D変換速度 10μsec/ch(max.);
とのことです．
4ch読み込もうと考えておりますので最速で40μsec

ただそこまでの速さは必要はないのです
アニメとかは1秒で30フレームでしたっけ（33ms）
そう考えると100msくらいで更新できれば十分だと思います．

[みけCAT]

ただそこまでの速さは必要はないのです
アニメとかは1秒で30フレームでしたっけ（33ms）
そう考えると100msくらいで更新できれば十分だと思います．

でしたら、DXライブラリを使えばいいと思います。

[softya（ソフト屋)]

こういうライブラリもありますよ。
「三輪空司研究室　群馬大学理工学研究院電子情報部門　」
http://www.el.gunma-u.ac.jp/~miwalab/mlib.html

[田中]

＞みけ様
やはりDXライブラリですか．
あれは使いやすくていいですね．

ちなみにもう少し早い処理が必要な場合（1msとか），
何が良かったのでしょうか？

＞ソフト屋様
ご紹介ありがとうございます．
確認してみます．

[softya（ソフト屋)]

ちなみにもう少し早い処理が必要な場合（1msとか），
何が良かったのでしょうか？

ＰＣが毎秒６０回の画面更新しか出来ませんので、専用のハードウェアが必要になります。
つまりオシロとかを使うしか無いです。

【補足】
まぁ、人間も秒１０００回は視認できませんけどね。
それでも1ms周期の処理はWindowsOSなどの非リアルタイムＯＳには向きません。

[田中]

＞ソフト屋様
PCの画面の更新速度は60hzなんですね
知りませんでした，勉強になります

[softya（ソフト屋)]

＞ソフト屋様
PCの画面の更新速度は60hzなんですね
知りませんでした，勉強になります

正確に言えばモニターの機器の仕様に準じます。
高価なゲーマー用の120hzを超えるものもあります。
普通に売っているのは６０ｈｚです。

「【ゲーマー必見】120Hz、144Hz対応モニターの価格表 | びすた無限のオンラインゲームブログ」
http://vistainfinity.blog.fc2.com/blog-entry-200.html
240hzのモニターもある様です。

【補足の補足】　高価といえるほどの値段ではなくなって来てましたね。

[田中]

＞ソフト屋様

人の目の時間分解能は約50ms～100ms程度
（ソース：http://mh.rgr.jp/memo/mz0386.htm）
らしいですね．


＞それでも1ms周期の処理はWindowsOSなどの非リアルタイムＯＳには向きません。
周期が処理に対して大きくなれば，非リアルタイムOSでも良いのですよね？

[田中]

＞ソフト屋様

なるほど．
ゲーマーともなるとそこまでこだわるんですね．
恐るべし・・・

[softya（ソフト屋)]

10msまで視認できるなら、それを超えている方が滑らかに見えるということでしょう。
240まで行くと自己満足のような。

>周期が処理に対して大きくなれば，非リアルタイムOSでも良いのですよね？

WindowsＰＣで実用的なサンプリング周期は10msより大きい必要が有ると思います。
常時別のプロセスがバックグラウンドで走っているので、それが周期を阻害する場合もあります。
WindowsUpdateとかがバックグラウンドで走るとロギングを落としそうです。
何も操作していないＰＣだとしても1ms周期で何週間もロギングが実用レベル出来るのかは疑問です。
Windowsなどはそれが向いていないから、リアルタイムＯＳ(RTOS)が、そのために存在するんですけどね。

デジタル計測機器とか、家電とか、車載マイコンはRTOSが走っています。

[ISLe]

100ms周期程度ならWin32 APIのほうが良いのではないでしょうか。
描画命令も豊富にあって線種に凝ったりもできますし、同じコードを使って印刷も可能です。
おおむかしにWin32 APIでゲーム作った経験から秒間60コマでも十分対応できるはず。

DXライブラリだと、VSYNCより速くても遅くても不都合が出ると思います。
センサのサンプリングを並行して処理するならなおさら。


ちなみにアニメは劇場用で滑らかに動いているときでも秒間24コマ、日本のテレビアニメだと秒間8コマも多くあります。

ゲームでフレームレートが高い必要があるのは、ユーザーの操作に対する反応速度の問題です。
アニメーションが滑らかに見えるかどうかとは(まったく関係がないわけではありませんが)根っこが異なります。