mieki256's diary



2013/05/10(金) [n年前の日記]

#1 [nitijyou] 部屋の温度が30度以上に

数日前は、夕方なのに5度前後の気温だった記憶が…。どうなってんだろ…。

この温度差を、発電に使えないものか。…どうやって?

#2 [prog] DXRuby1.5系開発版を試してみたり

1.5開発版は、フルスクリーン表示が改善されてるとの記述が。Ayame/Ruby も同梱されてるらしい。これは試してみないと…。

_DXRuby プロジェクトWiki - ファイル置き場 からDL。Windows7 x64 + ruby 1.9.3p392 mingw32 環境にインストール。先日書いたスクリプトをちょこちょこ修正して動作確認。

DXRuby 1.4 では、メインPC上でフルスクリーン表示をすると激しくチラついてしまったのだけど。DXRuby 1.5 ではそのような不具合は発生せず。しかも、メインループ中でいきなりウインドウ/フルスクリーン表示を切り替えてみても一見問題無し。素晴らしい…。ありがたや…。

しかし、別PCでも動作確認を、と思ったところでつまずいたり。

ocraでexe化できない問題。 :

ocraを使ってスクリプトをexe化しようとしても、エラーが出てexe化できず。以下のようなエラーメッセージが表示される。
> ocra --windows fullscrtestdxruby.rb
=== Loading script to check dependencies
C:/ruby193mingw/lib/ruby/1.9.1/uri/common.rb:860:in `block in <module:URI>': 内部エラー - DeleteAyameList (AyameError)
        from C:/ruby193mingw/lib/ruby/1.9.1/uri/common.rb:858:in `times'
        from C:/ruby193mingw/lib/ruby/1.9.1/uri/common.rb:858:in `<module:URI>'
        from C:/ruby193mingw/lib/ruby/1.9.1/uri/common.rb:12:in `<top (required)>'
        from C:/ruby193mingw/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:45:in `require'
        from C:/ruby193mingw/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:45:in `require'
        from C:/ruby193mingw/lib/ruby/1.9.1/uri.rb:104:in `<top (required)>'
        from C:/ruby193mingw/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:45:in `require'
        from C:/ruby193mingw/lib/ruby/site_ruby/1.9.1/rubygems/core_ext/kernel_require.rb:45:in `require'
        from C:/ruby193mingw/lib/ruby/site_ruby/1.9.1/rubygems/dependency_resolver.rb:5:in `<top (required)>'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:474:in `const_get'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:474:in `block (3 levels) in attempt_load_autoload'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:468:in `each'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:468:in `block (2 levels) in attempt_load_autoload'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:466:in `each'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:466:in `block in attempt_load_autoload'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:460:in `loop'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:460:in `attempt_load_autoload'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:694:in `build_exe'
        from C:/ruby193mingw/lib/ruby/gems/1.9.1/gems/ocra-1.3.1/bin/ocra:1153:in `block in <top (required)>'
「AyameError」なる文字列が気になる。DXRuby1.5開発版に同梱してあった Ayame/Ruby 0.0.2 で、Ayame/Ruby 0.0.1 を置き換えたのだけど、それが絡んでる…?

いくつか実験。
  • DXRuby は1.5開発版のままで、Ayame.dll、Ayame.so を、0.0.1 に戻してみた。 → ocra でexe化できた。
  • Ruby 1.9.3 ではなく、Ruby 1.9.2p290 mingw32版で、DXRuby 1.5開発版 + Ayame/Ruby 0.0.1 を使用。 → スクリプトは動作するし、ocra で exe化もできた。
  • Ruby 1.9.2p290 mingw32版で、DXRuby 1.5開発版 + Ayame/Ruby 0.0.2 を使用。 → スクリプト終了時に不正終了する。
ocra がエラーを出すだけならまだしも、スクリプトが不正終了してしまうわけだから、おそらく Ayame/Ruby 0.0.2 に何かしらの不具合がありそうな予感。

ちなみに。
  • スクリプトソース中のフラグ(?)一つで、Ayame/Ruby 0.0.1、0.0.2 に合わせて、ちゃんと処理が変わるようにして実験。0.0.2 は、prefetch、predecode が無くなったのですな…。
  • Ruby 1.9.3 と 1.9.2 の切り替えには pik を利用。gem list で表示される一覧が全然違うので、切り替えはちゃんとできているのだろうと思う。

それにしもて、Ruby 1.9.3 上では不正終了しないのに、1.9.2 上で不正終了するのは…なんでだろ…。自分の環境に何か問題が…? mingw版は速いという話をどこかで見かけて、 _RubyInstaller for Windows からDL・インストールしてるけど。 _ActiveScriptRuby を入れたら、結果が違ってくるのだろうか…?

別PC上でも動作確認。 :

とりあえず、当面、Ayame/Ruby 0.0.1 で実験をすることに。録画用PCとネットブック機に、Ruby 1.9.3 mingw版 + DXRuby 1.5開発版 + Ayame/Ruby 0.0.1 でexe化したファイルをコピーして動作確認。

どちらのPCでも、フルスクリーン表示時にチラつき無し。メインPCも含めて、自分の手元にあるPC3台では、どれも見た目問題無し、であります。

一応FPSもメモ。録画用PCは、ウインドウ表示もフルスクリーン表示も、60FPS。低消費電力CPU + AMD785Gチップセットのオンボードビデオでこれだけ動けば充分のような気もする。

ネットブック機は、ウインドウ表示が11FPS前後。フルスクリーン表示は30FPS前後。ふと思いついて、ネットブック機の画面色数を16ビットにして動かしてみたら、ウインドウ表示が16FPSぐらいに向上。フルスクリーン表示は結果変わらず。なんだかちょっとWin95時代を思い出したり。あの頃はPCスペックが低すぎて、そんな感じのアレコレをたまにやってたっけ…。

動作確認に使ったスクリプト。 :

2017/03/19追記。 :

Dropboxのpublicフォルダが死んだのでファイルの置き場所を変更。

#3 [prog] pygame + PyOpenGLでフルスクリーン表示が上手くいかない

色々試してるけど、どうにも…。

pygame + PyOpenGLでフルスクリーン表示できない問題。 :

フルスクリーン表示をすると、画面の上部にウインドウ枠が残ったり、そこだけ黒い表示のままになったりする。メインPC上では症状が発生しないが、録画用PC上ではそういう症状が起きる。

以下の2点を加えたところ、症状は見られなくなったけど…。
  • フルスクリーン表示とウインドウ表示を切り替える際、pygame.display.set_mode() を呼ぶ直前に、pygame.display.quit()、pygame.display.init() を呼んでおく。
  • pygame.display.set_mode() を呼んだ後、glutInit() を呼んでおく。
他のPC上では違った結果になるのかもしれないので、このあたり、なんとも怪しい…。

glut32.dll がバグ持ちなのかと思って、glut32.dll を freeglut.dll で差し替えてみたけど、これは関係なかった模様。ただ、freeglut.dll で置き換えた際に、「glutBitmapCharacter() を使いたかったら glutInit() を事前に呼んでおけ」とエラーが表示されたので、glutInit() を呼べるなら呼んでおいたほうがいいのだろう。たぶん。

ちなみに、freeglut.dll は、 _freeglut Windows Development Libraries から入手できる。freeglut.dll を glut32.dll にリネームしてスクリプトのあるフォルダに置けば使えるみたい。

フルスクリーン表示すると画面の書き換えの様子が見えてしまう問題。 :

pygame + PyOpenGL でフルスクリーン表示をすると、画面内に横線が入っているかのような見た目になることに気付いた。おそらく、ダブルバッファを切り替えるタイミングが見えているのではないかと。ティアリングと呼ぶのでしたっけ?

メインループの書き方がよろしくないのだろうか。それとも、垂直帰線期間だか vsync だかそのへんが関係しているのだろうか。OpenGL関係でフルスクリーン表示をすると、画面書き換え(バッファ切り替え?)のタイミングが vsync で固定される、てな話を海外掲示板で見かけたりもしたわけで。

症状が出ている録画用PCは、液晶ディスプレイにHDMI接続しているのだけど、まさか、HDMI接続の場合はvsyncが正確に得られない、等の問題があったり…したら手の打ちようがないのだろうな…。そもそも液晶ディスプレイでvsyncがどうこうってのもなんだかおかしい気もするけど。ブラウン管なら原理からして、そのへんが絡んでくるけれど…。液晶ディスプレイの場合は、どういう仕組み・やり取りになってるんだろうか…。

pygame + DirectX利用時に不正終了する問題。 :

pygame は SDL を使って描画している。その SDL は、Windows 上で動く際、windib とやらを使って描画している。環境変数 SDL_VIDEODRIVER に 'directx' を指定することで、windib ではなく、DirectX が使われるはず、なのだけど…。

Ruby/SDL上ではそのあたりの切り替えが上手くいかなかったのだけど、pygame 上では反映されるようで、喜んで(?)設定してみたり。しかし、ウインドウ表示中はともかく、directx で一度でもフルスクリーン表示をすると、その後、スクリプトの終了時に、必ず不正終了してしまう。

検索してみたところ、海外掲示板でも同様の不具合報告を見かけた。しかし、どの報告でも、「pygameでDirectXを使うな。OpenGL使え」で話が打ち切られてるようで。…たしかに、マルチプラットフォームを意識すれば、DirectXを選択肢に入れるのはおかしい。でも、ちょっと前までは、SDLもDirectXを活用してた記憶があるわけで。

pygame の標準描画(= SDL = windib による描画)は結構遅いので、directx にして速くなるなら使ってみたい。が、directx にすれば必ず速くなるわけでもないようで。自分のメインPC上で、directx + フルスクリーン表示をすると、画面の書き換えが「ペロン、ペロン」という状態に。たぶん、1FPSすら出ていない…。pygame.HWSURFACE や pygame.DOUBLEBUF を指定してみても劇的変化は無く。

pygame だけで60FPSのゲームを、と考えること自体が無謀なのだろうか。かもしれん…。

pyglet とやらを使えば、また違ってくるのかな。どうなんだろ。

#4 [prog] pygameはナシな気がしてきた

pygame + PyOpenGL では 50MB・3,000ファイルになる処理を、DXRuby や StarRuby でやると 4MB・数ファイルで済んでしまう。これはちょっと…あまりにも差があり過ぎる気が。

PyOpenGL を使わずに pygame だけでやれば、ファイル数は少なくできるけど。pygame だけでは描画が遅いから、DXRuby や StarRuby と同じ処理ができないだろうなと。

そのあたりを考えると、真っ当な言語仕様のLL(Lightweight Language、軽量プログラミング言語)で、かつ、そこそこの速度で動く2Dゲームを、と思ったら、pygame (+ PyOpenGL) は選択肢としてナシではないかとうっすら思えてきたり。DXRuby や StarRuby を選んだほうが…。

まあ、pygame は、ヌルヌル動くリアルタイム系ゲームを作ることなんて最初から考えてないのかもしれないけれど。各種解説ドキュメントにもそのような忠告をチラチラ見かけるし。

以上、1 日分です。

過去ログ表示

Prev - 2013/05 - Next
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project