mieki256's diary



2013/05/02(木) [n年前の日記]

#1 [prog] DXRubyその他の動作速度を確認した結果をメモ

以下の処理をするスクリプト。 さらに、それをいくつかの言語+ライブラリで書いた。 使ってるRubyとPythonのバージョンは以下の通り。 どちらもWindows版。

スクリーンショットはこんな感じ。

DXRuby版のSS

一応スクリプトも、zipでまとめて置いておくです。exe化してあるから、Ruby や Python が入ってなくても動くです。

_fullscrtest_20130502.zip (21MB)

それを3台のPCで動作確認。
種類CPUコア数クロックVideoMemoryOS備考
メインPCCore i5 250043.3GHzGeForce 9800GTGE8GBWindows7 x64自作PC
録画用PCAthlon II X4 605e42.3GHzRadeon HD 4200 (AMD785Gオンボード)8GBWindows7 x64自作PC
ネットブック機Atom N27011.6GHzIntel GMA950 (オンボード)2GBWindows XP Home SP3Lenovo IdeaPad S10-2

以下のような結果に。
ライブラリ描画内容表示種類ネットブック機録画用PCメインPC
HSP全てウインドウ14 FPS60 FPS60 FPS
フルスクリーン54 FPS60 FPS60 FPS
StarRuby全てウインドウ19 FPS60 FPS60 FPS
フルスクリーン19 FPS60 FPS60 FPS
BGのみウインドウ41 FPS60 FPS60 FPS
フルスクリーン41 FPS60 FPS60 FPS
DXRuby全てウインドウ11 FPS60 FPS60 FPS
フルスクリーン13 FPS60 FPS60 FPS
BGのみウインドウ20 FPS60 FPS60 FPS
フルスクリーン30 FPS60 FPS60 FPS
PyGame全てウインドウ11 FPS20 FPS60 FPS
フルスクリーン11 FPS20 FPS60 FPS
BGのみウインドウ25 FPS60 FPS60 FPS
フルスクリーン25 FPS60 FPS60 FPS
Ruby/SDL全てウインドウ1 FPS2 FPS60 FPS
フルスクリーン1 FPS2 FPS60 FPS
BGのみウインドウ2 FPS60 FPS60 FPS
フルスクリーン2 FPS60 FPS60 FPS

ライブラリフルスクリーン表示oggループ再生言語仕様処理速度
HSP× *2速い *4
StarRuby× *3速い
DXRuby× *1速い
PyGame遅い
Ruby/SDL非常に遅い

感想というか、思ったことをメモ。 まあ、スクリプトの書き方が間違ってる可能性もあるので…。もし、「そんな結果になるはずがない」と思った方は、スクリプトソースの添削をしていただけると助かるです。

2013/05/14追記。 :

DXRuby でフルスクリーン表示が上手くいかない問題ですが、DXRuby1.5開発版を使ったら改善されたことを追記しておきます。

ただ、同梱の、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 を眺めつつ、悩んでしまったり。

#3 [prog] HSPの感想をメモ

あらかじめ、意見には個人差があります、と言っておきますです。

ほんのちょっとだけHSPも勉強したわけだけど。サンプルスクリプトをコピペして修正した程度の作業だったのに、なんだか…何かがツライ。言語仕様がしっくりこない。

なんでツライのか考えてみたけど、このへんかなあ…。 プログラミングをちょっとかじった人なら、「ああ、それは筋が悪いプログラミング言語だね」と言いそうな。

ところが、よくよく調べてみると、どうもその印象は勘違いだったようで。 そうなると、「アレ? 結構フツーのプログラミング言語じゃね?」と思えてきたわけで。

どうして前述のような勘違い・思い込みを持ってしまったのかと言えば、おそらくサンプルスクリプト群のほとんどが、そういう書き方をしているから、なのだろうなと思えてきたり。

おそらくサンプルスクリプトは、古い言語仕様でも動くように書いてあるのかもしれない。あるいは、古い言語仕様で書いてあったソレを少し手直しして、HSPに同梱しているのかなと。

ただ、初心者がHSPを勉強する際に、頼りにするのはサンプルスクリプト群…。その、お手本ともいうべきサンプルスクリプト群が、そういう書き方を続けていると、他の言語を全く知らない人は、「こういうことをしたかったら、こういう風に書くものなんだな」「これがプログラミングなんだな」と思い込んで、それが後々面倒なことに繋がらないか…と少し不安になったりもして。

例えばですが。Perl の世界では、「今時のPerlならこういう風に書くのがモダンだぜ」みたいな話があったりしたのだけど。おそらくHSPも、モダンなHSPソースの書き方がありそうだなと。

その、モダンな書き方に基づいた、初心者向けのチュートリアル記事なり解説記事が存在していて、それをお手本にしながら勉強するのであれば、HSPの印象も結構変わるのかもしれないなあ、と思ったりしましたよ、とメモ。

まあ、「動けばいいじゃん」で済ませるのもアリなのだろうけど。

#4 [prog] gotoについて思うところをつらつらと

HSPを勉強してるうちに、「gotoって…どうなんだろうなあ…」と思えてきたので、そのあたりをなんとなくメモ。ま、何十年も前に、gotoの是非については熱い議論があったらしいので、お前いまさら何言ってんだって感じの話ですが。

以下は自分の勝手な想像その他諸々なので事実とは大きく異なる可能性が高いです。

どんな高級言語で書かれたソースも、コンピュータ上で動くときにはバイナリになる・機械語レベルになるわけで。そして機械語レベルでは、ジャンプ命令 ≒ goto だらけになるわけですよ。そのことを考えれば、「gotoさえ知っていれば全てのプログラムは書けるんだ」という考えは正しいよなと。実際、全てのプログラムは、最終的にはそういう形で動いているのだし。

でも、それぞれの goto には、目的があって。 goto だらけのソースをプログラマーが読んで理解するときは、「はて、この goto は、どんな目的で使われているんだ?」と、goto が出てくるたびに推測しないといけない。…goto が出てくるたびに、毎回必ず、ですよ。これはシンドイ。面倒臭い。当然、勘違いも頻発する。バグの温床になる。

そこで先輩達は思いついた。「この goto はこういう目的で使っているんだよ、とソースにあらかじめ書いておくことにしようぜ」と。 そのうち気付くわけです。「アレ? goto なんか使わなくてもプログラム書けたぞ?」「gotoが残ってるということは、そのプログラミング言語・ソースの書き方は、何か間違ってねえか?」みたいな。

ところが、今度は色んな命令を覚えないといけなくなった。今までは、goto だけ覚えておけばどうとでもなったのに…。

そこで誰かが言い出すのです。「プログラミング初心者に、こんなにたくさん命令を覚えさせるのはよくない。絶対混乱するよ…。だから、goto だけ教えとこう!」

ということで。このあたり2つの主張が成立しそうだなと。 どっちもアリといえばアリですが。まあ、何十年も前から、後者の考え方が主流のような気がします。

後者の考え方がないと、高級言語なんてものは、生まれてこなかったであろう気もしてきたり。

PythonとRubyにもそういうノリを感じたり。 :

Python は、「gotoだけ覚えてればいいんだよ!」みたいなノリを感じますし、Ruby は、「何をやろうとしているか明確にしないとダメだよ!」みたいなノリを感じますな…。

例えば、「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 日分です。

過去ログ表示

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