2013/05/02(木) [n年前の日記]
#1 [prog] DXRubyその他の動作速度を確認した結果をメモ
以下の処理をするスクリプト。
スクリーンショットはこんな感じ。
一応スクリプトも、zipでまとめて置いておくです。exe化してあるから、Ruby や Python が入ってなくても動くです。
_fullscrtest_20130502.zip (21MB)
それを3台のPCで動作確認。
以下のような結果に。
感想というか、思ったことをメモ。
- ウインドウサイズ 640x480
- BG x 2枚を描画
- 64x64ドット x 512枚を描画
- oggをループ再生
- DxRuby 1.4.0 + Ayame.dll
- HSP 3.32 + hgimg3
- StarRuby 0.3.3
- Ruby/SDL 2.1.1
- PyGame 1.9.2pre
- Ruby 1.9.3 p392 mingw版
- Python 2.6.6。
スクリーンショットはこんな感じ。
一応スクリプトも、zipでまとめて置いておくです。exe化してあるから、Ruby や Python が入ってなくても動くです。
_fullscrtest_20130502.zip (21MB)
それを3台のPCで動作確認。
種類 | CPU | コア数 | クロック | Video | Memory | OS | 備考 |
---|---|---|---|---|---|---|---|
メインPC | Core i5 2500 | 4 | 3.3GHz | GeForce 9800GTGE | 8GB | Windows7 x64 | 自作PC |
録画用PC | Athlon II X4 605e | 4 | 2.3GHz | Radeon HD 4200 (AMD785Gオンボード) | 8GB | Windows7 x64 | 自作PC |
ネットブック機 | Atom N270 | 1 | 1.6GHz | Intel GMA950 (オンボード) | 2GB | Windows XP Home SP3 | Lenovo IdeaPad S10-2 |
以下のような結果に。
ライブラリ | 描画内容 | 表示種類 | ネットブック機 | 録画用PC | メインPC |
---|---|---|---|---|---|
HSP | 全て | ウインドウ | 14 FPS | 60 FPS | 60 FPS |
フルスクリーン | 54 FPS | 60 FPS | 60 FPS | ||
StarRuby | 全て | ウインドウ | 19 FPS | 60 FPS | 60 FPS |
フルスクリーン | 19 FPS | 60 FPS | 60 FPS | ||
BGのみ | ウインドウ | 41 FPS | 60 FPS | 60 FPS | |
フルスクリーン | 41 FPS | 60 FPS | 60 FPS | ||
DXRuby | 全て | ウインドウ | 11 FPS | 60 FPS | 60 FPS |
フルスクリーン | 13 FPS | 60 FPS | 60 FPS | ||
BGのみ | ウインドウ | 20 FPS | 60 FPS | 60 FPS | |
フルスクリーン | 30 FPS | 60 FPS | 60 FPS | ||
PyGame | 全て | ウインドウ | 11 FPS | 20 FPS | 60 FPS |
フルスクリーン | 11 FPS | 20 FPS | 60 FPS | ||
BGのみ | ウインドウ | 25 FPS | 60 FPS | 60 FPS | |
フルスクリーン | 25 FPS | 60 FPS | 60 FPS | ||
Ruby/SDL | 全て | ウインドウ | 1 FPS | 2 FPS | 60 FPS |
フルスクリーン | 1 FPS | 2 FPS | 60 FPS | ||
BGのみ | ウインドウ | 2 FPS | 60 FPS | 60 FPS | |
フルスクリーン | 2 FPS | 60 FPS | 60 FPS |
ライブラリ | フルスクリーン表示 | oggループ再生 | 言語仕様 | 処理速度 |
---|---|---|---|---|
HSP | ○ | × *2 | △ | 速い *4 |
StarRuby | ○ | × *3 | ○ | 速い |
DXRuby | × *1 | ○ | ○ | 速い |
PyGame | ○ | ○ | ○ | 遅い |
Ruby/SDL | ○ | ○ | ○ | 非常に遅い |
- *1 環境によっては激しく点滅・ちらつく。
- *2 ノイズが入る。
- *3 音が途切れる。
- *4 ネットブック上ですら、フルスクリーン表示ならそこそこスルスルと動く。
感想というか、思ったことをメモ。
- ネットブック機上ではどれも話にならないので、さすがにサポート外にしたほうがヨサゲ。ただし、HSPのフルスクリーン表示時だけは、かなりスルスル動いてしまった。HSP + hgimg3 だけ、何か特殊なことをしているのかもしれない。
- PyGame は遅い。Ruby/SDLはもっと遅い。しかし、BGのみを描画 ―― 大きな画像を数枚だけ描画するなら速度が異様に上がるので、細かい画像を大量に描画する処理は向いてないだけ、かもしれない。
- 上の実験結果には書いてないが、StarRuby も試しに回転描画等をすると、PyGame や Ruby/SDL 並みに遅くなった。おそらく、PyGame と Ruby/SDL は、自由度は高いが速度が遅い描画方法をどの状態でも使っていて、StarRuby は、回転等をしない場合だけ高速な描画方法が使われるのかも。
- SDLを使ったライブラリ、PyGame、StarRuby、Ruby/SDL は、フルスクリーン表示時に速度面の恩恵が受けられそうな気配はなかった。その代わり、おかしな表示にもならなかった。
- DXRuby は、フルスクリーン表示すると、環境によっては表示がおかしくなる。録画用PCでは問題なかったが、メインPCとネットブック機では画面が激しく点滅してしまい、使えそうにない状態になった。フルスクリーン表示にも対応させたいなら、現バージョンの DXRuby は選択から外れる。
- ogg等をループ再生したいなら、HSP と StarRuby は不具合があるので選択から外れる。
◎ 2013/05/14追記。 :
DXRuby でフルスクリーン表示が上手くいかない問題ですが、DXRuby1.5開発版を使ったら改善されたことを追記しておきます。
ただ、同梱の、Atame/Ruby 0.0.2 に不具合があるようで…。一つ前の Ayame/Ruby 0.0.1 と組み合わせて使ったほうがいいのかもしれず。
ただ、同梱の、Atame/Ruby 0.0.2 に不具合があるようで…。一つ前の Ayame/Ruby 0.0.1 と組み合わせて使ったほうがいいのかもしれず。
◎ 2017/03/19追記。 :
Dropboxのpublicフォルダが死んだのでファイルの置き場所を変更。
[ ツッコむ ]
#2 [prog] 今時のPCゲームのウインドウサイズってどのくらいが適切なんだろうか
仮にフルスクリーン表示ができなくても、デスクトップ解像度を800x600等にすれば、640x480のウインドウ表示も大きく見えるだろうし…。何が何でもフルスクリーン表示に対応しなきゃ、というわけでもないのかもと思えてきたり。
しかしそもそも、640x480、800x600といった4:3のサイズで作るのは適切なのだろうか…。ワイド液晶ディスプレイを使っている事例が増えてきたのだから、16:9等のサイズのほうが ―― 640x360、854x480、1280x720、1366x768等のほうが良かったりしないか。でも、4:3のディスプレイを使っている環境では、メリットがないだろうし…。
メインPC上で、フルスクリーンにできそうな16:9の画面解像度を調べてみたら、1280x720、1366x768 はあったけど、640x360、854x480は一覧に無かった…。
Windows8 は、1024x768 が最低解像度なんでしたっけ? そこにも対応しようとすると…640x480というウインドウサイズは適切ではないのだろうか…? Windows8上で、640x480の画面をフルスクリーン表示しようとすると、一体どうなるんだろう…。
ネットブックのように、1024x600の液晶を使っているPCだって存在するだろうし。となると、縦600ドットより大きいサイズは無理、なのかな。
どのウインドウサイズで作っておくのが妥当なのだろう? わからんなあ…。
_画面解像度 - Wikipedia を眺めつつ、悩んでしまったり。
しかしそもそも、640x480、800x600といった4:3のサイズで作るのは適切なのだろうか…。ワイド液晶ディスプレイを使っている事例が増えてきたのだから、16:9等のサイズのほうが ―― 640x360、854x480、1280x720、1366x768等のほうが良かったりしないか。でも、4:3のディスプレイを使っている環境では、メリットがないだろうし…。
メインPC上で、フルスクリーンにできそうな16:9の画面解像度を調べてみたら、1280x720、1366x768 はあったけど、640x360、854x480は一覧に無かった…。
Windows8 は、1024x768 が最低解像度なんでしたっけ? そこにも対応しようとすると…640x480というウインドウサイズは適切ではないのだろうか…? Windows8上で、640x480の画面をフルスクリーン表示しようとすると、一体どうなるんだろう…。
ネットブックのように、1024x600の液晶を使っているPCだって存在するだろうし。となると、縦600ドットより大きいサイズは無理、なのかな。
どのウインドウサイズで作っておくのが妥当なのだろう? わからんなあ…。
_画面解像度 - Wikipedia を眺めつつ、悩んでしまったり。
[ ツッコむ ]
#3 [prog] HSPの感想をメモ
あらかじめ、意見には個人差があります、と言っておきますです。
ほんのちょっとだけHSPも勉強したわけだけど。サンプルスクリプトをコピペして修正した程度の作業だったのに、なんだか…何かがツライ。言語仕様がしっくりこない。
なんでツライのか考えてみたけど、このへんかなあ…。
ところが、よくよく調べてみると、どうもその印象は勘違いだったようで。
どうして前述のような勘違い・思い込みを持ってしまったのかと言えば、おそらくサンプルスクリプト群のほとんどが、そういう書き方をしているから、なのだろうなと思えてきたり。
おそらくサンプルスクリプトは、古い言語仕様でも動くように書いてあるのかもしれない。あるいは、古い言語仕様で書いてあったソレを少し手直しして、HSPに同梱しているのかなと。
ただ、初心者がHSPを勉強する際に、頼りにするのはサンプルスクリプト群…。その、お手本ともいうべきサンプルスクリプト群が、そういう書き方を続けていると、他の言語を全く知らない人は、「こういうことをしたかったら、こういう風に書くものなんだな」「これがプログラミングなんだな」と思い込んで、それが後々面倒なことに繋がらないか…と少し不安になったりもして。
例えばですが。Perl の世界では、「今時のPerlならこういう風に書くのがモダンだぜ」みたいな話があったりしたのだけど。おそらくHSPも、モダンなHSPソースの書き方がありそうだなと。
その、モダンな書き方に基づいた、初心者向けのチュートリアル記事なり解説記事が存在していて、それをお手本にしながら勉強するのであれば、HSPの印象も結構変わるのかもしれないなあ、と思ったりしましたよ、とメモ。
まあ、「動けばいいじゃん」で済ませるのもアリなのだろうけど。
ほんのちょっとだけHSPも勉強したわけだけど。サンプルスクリプトをコピペして修正した程度の作業だったのに、なんだか…何かがツライ。言語仕様がしっくりこない。
なんでツライのか考えてみたけど、このへんかなあ…。
- 変数は、全てグローバル変数。
- サブルーチンを呼ぶ際、引数という概念がない。
- goto使いまくり。
ところが、よくよく調べてみると、どうもその印象は勘違いだったようで。
- モジュールその他を使えばローカル変数も使える。
- 引数を渡すサブルーチンの呼び出し方も、後になって追加された。
- 実は goto を使わなくても書けるらしい。
どうして前述のような勘違い・思い込みを持ってしまったのかと言えば、おそらくサンプルスクリプト群のほとんどが、そういう書き方をしているから、なのだろうなと思えてきたり。
おそらくサンプルスクリプトは、古い言語仕様でも動くように書いてあるのかもしれない。あるいは、古い言語仕様で書いてあったソレを少し手直しして、HSPに同梱しているのかなと。
ただ、初心者がHSPを勉強する際に、頼りにするのはサンプルスクリプト群…。その、お手本ともいうべきサンプルスクリプト群が、そういう書き方を続けていると、他の言語を全く知らない人は、「こういうことをしたかったら、こういう風に書くものなんだな」「これがプログラミングなんだな」と思い込んで、それが後々面倒なことに繋がらないか…と少し不安になったりもして。
例えばですが。Perl の世界では、「今時のPerlならこういう風に書くのがモダンだぜ」みたいな話があったりしたのだけど。おそらくHSPも、モダンなHSPソースの書き方がありそうだなと。
その、モダンな書き方に基づいた、初心者向けのチュートリアル記事なり解説記事が存在していて、それをお手本にしながら勉強するのであれば、HSPの印象も結構変わるのかもしれないなあ、と思ったりしましたよ、とメモ。
まあ、「動けばいいじゃん」で済ませるのもアリなのだろうけど。
[ ツッコむ ]
#4 [prog] gotoについて思うところをつらつらと
HSPを勉強してるうちに、「gotoって…どうなんだろうなあ…」と思えてきたので、そのあたりをなんとなくメモ。ま、何十年も前に、gotoの是非については熱い議論があったらしいので、お前いまさら何言ってんだって感じの話ですが。
以下は自分の勝手な想像その他諸々なので事実とは大きく異なる可能性が高いです。
どんな高級言語で書かれたソースも、コンピュータ上で動くときにはバイナリになる・機械語レベルになるわけで。そして機械語レベルでは、ジャンプ命令 ≒ goto だらけになるわけですよ。そのことを考えれば、「gotoさえ知っていれば全てのプログラムは書けるんだ」という考えは正しいよなと。実際、全てのプログラムは、最終的にはそういう形で動いているのだし。
でも、それぞれの goto には、目的があって。
そこで先輩達は思いついた。「この goto はこういう目的で使っているんだよ、とソースにあらかじめ書いておくことにしようぜ」と。
ところが、今度は色んな命令を覚えないといけなくなった。今までは、goto だけ覚えておけばどうとでもなったのに…。
そこで誰かが言い出すのです。「プログラミング初心者に、こんなにたくさん命令を覚えさせるのはよくない。絶対混乱するよ…。だから、goto だけ教えとこう!」
ということで。このあたり2つの主張が成立しそうだなと。
後者の考え方がないと、高級言語なんてものは、生まれてこなかったであろう気もしてきたり。
以下は自分の勝手な想像その他諸々なので事実とは大きく異なる可能性が高いです。
どんな高級言語で書かれたソースも、コンピュータ上で動くときにはバイナリになる・機械語レベルになるわけで。そして機械語レベルでは、ジャンプ命令 ≒ goto だらけになるわけですよ。そのことを考えれば、「gotoさえ知っていれば全てのプログラムは書けるんだ」という考えは正しいよなと。実際、全てのプログラムは、最終的にはそういう形で動いているのだし。
でも、それぞれの goto には、目的があって。
- ループ処理をさせたくて、goto を使っているのか。
- ループ処理から抜けたくて、goto を使っているのか。
- ループ処理の頭に戻りたくて、goto を使っているのか。
- サブルーチンを呼び出したくて、goto を使っているのか。
- etc。
そこで先輩達は思いついた。「この goto はこういう目的で使っているんだよ、とソースにあらかじめ書いておくことにしようぜ」と。
- ループ処理をさせたくて、goto を使っているなら、「for」「while」と書いておく。
- ループ処理から抜けたくて、goto を使っているなら、「break」と書いておく。
- ループ処理の頭に戻りたくて、goto を使っているなら、「continue」と書いておく。
- サブルーチンを呼び出したくて、goto を使っているなら、サブルーチン名だけ書いておく。
ところが、今度は色んな命令を覚えないといけなくなった。今までは、goto だけ覚えておけばどうとでもなったのに…。
そこで誰かが言い出すのです。「プログラミング初心者に、こんなにたくさん命令を覚えさせるのはよくない。絶対混乱するよ…。だから、goto だけ教えとこう!」
ということで。このあたり2つの主張が成立しそうだなと。
- 「goto を覚えれば、全てのプログラムは書けるのだから、goto だけを覚えさせる・使わせるのが、初心者向きのプログラミング言語だ」
- 「goto は色んな目的を持って使われるのだから、あらかじめ、その目的別で命令を覚えたほうが混乱しない。goto を使わないのが初心者向きのプログラミング言語だ」
後者の考え方がないと、高級言語なんてものは、生まれてこなかったであろう気もしてきたり。
◎ PythonとRubyにもそういうノリを感じたり。 :
Python は、「gotoだけ覚えてればいいんだよ!」みたいなノリを感じますし、Ruby は、「何をやろうとしているか明確にしないとダメだよ!」みたいなノリを感じますな…。
例えば、「n回ループさせる」てな処理を書きたいとき。
Python なら、たぶんこうなるのかな。
Ruby なら、こうでしょうか?
Python は、range() を使って一旦配列 *1 を作って、0から4まで数値を入れて、その配列個数分取り出しながらループをしろ、てなことを指示するわけで。…プログラマーは、配列を作りたいわけじゃないのですがね。n回ループさせたいだけなのだけど、なんで配列を作らなきゃいかんのか…。しかし、Python は、「命令の種類はシンプルに」「色んな書き方ができたらダメ」という信条で作ってる言語だから、「この方法でループ処理は書けるんだからコレ使え」「コレさえ覚えとけば、配列に対して処理をしたいときも同じように書けるだろ? 何にでも使えて便利じゃねえか」で済ませてる。それは、「goto使えば全部書けるんだから、gotoだけ使え」てな思考と結構近い気がします。
Ruby は逆に、n回ループさせたいと思ってるなら、一目でそれが分かる書き方じゃないとダメだろう、という信条があるんじゃないかと。だから、times というメソッドが登場するのかなあ、と。その代わり、どんなループ処理をさせたいかによって、書き方やメソッドがどんどん変わってくる。覚えなきゃいけないことが増えてくる。…まあ、「for i in 0..4 do puts i end」「(0..4).each do |i| puts i end」みたいな書き方もできるから、この例はあまり適切ではないんでしょうけど。
Ruby を覚えた人が、他の言語を触った時になんかしっくりこないのは、そのへんが関係してるのかな…と勝手に想像してみたり。プログラマーがその時何をしたいと思っていたのか、その思考のログがソースに残りやすいのが Ruby、なのかもしれないと。他の言語は、「このソースを書いた時の俺は、こう書くことで、一体何をしようとしていたのか…?」みたいな推測作業が細かいところでちょこちょこ要求されて、それが微妙に苦痛なのかなあ、と。
まあ、自分、プログラミング言語は全然詳しくないので、実際どうなのかは分かんないですけど。
色んな言語を触ってる人なら、もっと適切な事例を出して、各思想の違いをしっかり解説できると思うので、「お前が言ってることは違うよ! 全然違うよ!」と思ったら、自身のblog等で解説してくれるとありがたいです。
例えば、「n回ループさせる」てな処理を書きたいとき。
Python なら、たぶんこうなるのかな。
for i in range(5): print i
Ruby なら、こうでしょうか?
5.times do |i| puts i end
Python は、range() を使って一旦配列 *1 を作って、0から4まで数値を入れて、その配列個数分取り出しながらループをしろ、てなことを指示するわけで。…プログラマーは、配列を作りたいわけじゃないのですがね。n回ループさせたいだけなのだけど、なんで配列を作らなきゃいかんのか…。しかし、Python は、「命令の種類はシンプルに」「色んな書き方ができたらダメ」という信条で作ってる言語だから、「この方法でループ処理は書けるんだからコレ使え」「コレさえ覚えとけば、配列に対して処理をしたいときも同じように書けるだろ? 何にでも使えて便利じゃねえか」で済ませてる。それは、「goto使えば全部書けるんだから、gotoだけ使え」てな思考と結構近い気がします。
Ruby は逆に、n回ループさせたいと思ってるなら、一目でそれが分かる書き方じゃないとダメだろう、という信条があるんじゃないかと。だから、times というメソッドが登場するのかなあ、と。その代わり、どんなループ処理をさせたいかによって、書き方やメソッドがどんどん変わってくる。覚えなきゃいけないことが増えてくる。…まあ、「for i in 0..4 do puts i end」「(0..4).each do |i| puts i end」みたいな書き方もできるから、この例はあまり適切ではないんでしょうけど。
Ruby を覚えた人が、他の言語を触った時になんかしっくりこないのは、そのへんが関係してるのかな…と勝手に想像してみたり。プログラマーがその時何をしたいと思っていたのか、その思考のログがソースに残りやすいのが Ruby、なのかもしれないと。他の言語は、「このソースを書いた時の俺は、こう書くことで、一体何をしようとしていたのか…?」みたいな推測作業が細かいところでちょこちょこ要求されて、それが微妙に苦痛なのかなあ、と。
まあ、自分、プログラミング言語は全然詳しくないので、実際どうなのかは分かんないですけど。
色んな言語を触ってる人なら、もっと適切な事例を出して、各思想の違いをしっかり解説できると思うので、「お前が言ってることは違うよ! 全然違うよ!」と思ったら、自身のblog等で解説してくれるとありがたいです。
*1: 配列じゃなくてリストと呼ぶべき?
[ ツッコむ ]
以上、1 日分です。