mieki256's diary

_昨日 は、Windows用バイナリの入手先すら見つけられなくて、githubから _pygame_sdl2のソース を落としてきてビルドして、とかやってたのだけど。

その後ググってたら、 _pygame_sdl2 2.1.0 : Python Package Index で .whl(wheel形式のパッケージ)公開ページを発見。公式の _PyPI(Python Package Index) では公開されてないけど、 _テスト版を公開してるPyPI にはアップロードされてた模様。わざわざビルドしなくても、コレを落としてインストールすれば、ひとまず試せたのかもしれない…。

でも、アップロード日が2016/01/24と結構古い。githubからソースをDLしてビルドするほうが最新の…。ってわけでもないか。githubの各ソースもアップロード日がそこそこ古いし、ビルドすると 2.1.0 という同じバージョン番号になるし。どっちが新しいのか、あるいは両方同じなのか、ちと分かりませんな。

ちなみに、一応インストールの仕方を書いとくけど。 _pygame_sdl2 2.1.0 : Python Package Index の下のほうから、自分の環境に合った .whl をDLして、

pip install 〜.whl

でインストールできますよ、とメモ。

昨日作った _pygame_sdl2-2.1.0-cp27-cp27m-win32.whl を、VMware Player + Windows10評価版上で、Python 2.7 32bit版をインストールしてから pip install 〜 をしたら一応インストールできたし動いてくれた。

ただ、VMware Player上では、30FPSちょっとしか出ない…。

pip uninstall 〜 でアンインストールしてから、TestPyPI で公開されてる .whl を入れ直して確認してみたけど、そちらでも30FPSちょっとしか出ない…。

VMware Player上だから遅くなるのか、それともわざわざ遅くなるようなスクリプトの書き方をしちゃっているのか。何にせよ、これじゃ話にならない。

pygame_sdl2 は、「pygameって便利だよね」「pygameのAPIはそのままに、SDLを使ってるところをSDL2に置き換えた版が欲しいよね」という考えで作られたライブラリなので、スクリプトの最初に2行ほど追加するだけで、後は pygameとほぼ同じ書き方で使えるようになっていて。

import pygame_sdl2
pygame_sdl2.import_as_pygame()

import pygame
from pygame.locals import *

SCR_SIZE = (640, 480)

pygame.init()
pygame.display.set_mode(SCR_SIZE)
pygame.display.set_caption("SDL2 render test")
...

これはこれでおそらく便利だろうけど。逆に、「コレって本当に pygame_sdl2 を使ってるのかな？」「実は pygame が呼び出されてたりしないのかな？」という不安もあり。

そういう時は、pygame.hoge と書かれてる部分を pygame_sdl2.hoge で置き換えて書けばいいようで。

import pygame_sdl2
from pygame_sdl2.locals import *

SCR_SIZE = (640, 480)

pygame_sdl2.init()
pygame_sdl2.display.set_mode(SCR_SIZE)
pygame_sdl2.display.set_caption("SDL2 render test")
...

ただ、pygame にはあるけど pygame_sdl2 では実装されてないAPIがあるらしいので…。もし、実行して「そんなメソッドはないよ」とエラーが出たら、「ああ、コレは実装されてないのか」と諦めながら別の方法を探す、みたいなことになるだろうなと。

pygameはソフトウェアレンダリングを前提にした作りなので、画面に何か描画する際も、メインメモリ上に画像に相当するバッファを持って、領域を書き換えて、書き換えて、最後に画面表示用の領域に転送して、てな作りになってるはずで。例えば screen.blit() のように blit という単語が出てくるあたりからして、おそらくそうであろうと。

なので、pygame_sdl2 を使った場合も、pygame と同じノリで描画指定をしていくと、パフォーマンスが出ないどころか、逆に pygame より余計なことをしている分、かえって遅くなる可能性もありそうだなと。もちろん、pygame_sdl2 の作者さんは、遅くならないようにそのあたり気づいた範囲で工夫しているはずではあるけれど…。

で。そのあたり、スクリプトソースを書く側でも、速度が出るよう意識しつつ書きたい場合は、ひょっとすると pygame_sdl2.render を使うといい、のかもしれない。いや、ちょっと自信無いけど。たぶんそうじゃないのかなと。

pygame_sdl2.render を使う場合は、例えば画像ファイルを読み込む際も、pygame.image.load() ではなく load_texture() を使うようだし。名前からして、テクスチャとかレンダリングとか、つまりはGPUを意識した機能っぽい…よなと。外してるかもしれんけど。

ただ、pygame_sdl2.render について、使い方を説明したドキュメントが全く存在していなくて…。使用例として見つかったのは、以下のソースぐらいで。

_pygame_sdl2/test_render.py

• r = pygame_sdl2.render.Renderer(vsync=False) で、画面全体を描画するための何かを確保して。
• bg = r.load_texture('paper.jpg') で、テクスチャ画像を読み込んで。
• r.clear((0,0,0)) で、全体を消去。
• bg.render() で、描画。
• r.render_present() で、描画内容を画面に反映。

このくらいしか予想できなかった。

しかし、このやり方だと、画像が画面全体に引き延ばされた形で描画されてしまう…。例えば、96x96の画像が、640x480の画面一杯に拡大表示されてしまったり。

_render_test.py
_ufo.png
_bg.png


位置やサイズの指定はどうすればいいのやら。

おそらく pygame_sdl2 の作者さんは、「pygame をそのまま pygame_sdl2 に置き換えて高速に動くのが理想」みたいなノリで作ってるはずだから、pygame には存在していない pygame_sdl2.render については積極的に解説されない可能性もあるわけで。「pygameに無い機能をガンガン使われてしまうようでは pygame_sdl2 の存在理由が怪しくなる」と思っていてもおかしくないよなと…。

pygame の中身をSDL2に置き換えれば更にグッドなライブラリに、という発想は一見するとヨサゲに思えるけれど。SDL2の何を使ってその処理が行われるのか、てなあたりが見えにくくなるというデメリットもあるなと。結果、SDL2には合ってない、パフォーマンスが出ない書き方をしているのでは、という不安が拭えない。

もちろん、pygame時代に書かれた膨大な既存スクリプトを最低限の手直しでひとまず一応は動かせるように、という目的が最優先で、パフォーマンスが出る出ないは優先順位として低いのだから、これはこれで全然アリなライブラリ、ではあるのだけど。しかし欲を出して、せっかくSDL2を使ってるのだからソレに見合ったパフォーマンスを…と思った場合は、ちょっと筋が悪いライブラリに思えるかもしれないなと。

まあ、そういう時は、pygame_sdl2 じゃなくて pysdl2 を選ぶべきかもしれず。

とは言えこのへん、「そうまでしてPythonでゲーム書かなくてもいいじゃん。どうせ使い物にならねえだろ」「ゲーム作りたいならまずは Unity でも触るべき」と身も蓋も無いことを言われそうでもあり…。 *1

このあたり、「ゲームを作りたい」のか、それとも「ゲーム制作を通じてせめて少しは楽しくプログラミングを学びたい」のか、てな違いもありそうな。