2024/06/05(水) [n年前の日記]
#1 [prog] 自作スクリーンセーバを修正した
以前作ったOpenGLを使うスクリーンセーバと同様の描画処理をするデモプログラムを、Lenovo IdePad S10-2上でも動くように修正した。
_mieki256/ssp3droadgl
元のプログラムは、4096x4096のテクスチャ画像を使っていたけれど、IdeaPad S10-2 (Intel Atom N270, Mobile Intel 945GSE Express)の最大テクスチャサイズは2048x2048だったので、テクスチャが読み込めなくて正常な描画にならなかった。今回、1024x1024のテクスチャ画像も用意して、GL_MAX_TEXTURE_SIZE が 4096 より小さい場合はそちらのテクスチャ画像を読み込むように修正してみた。
動作確認したところ、小さいテクスチャを拡大しながら描画してるせいか、カメラに近いビルボードや路面はボケボケになってしまった。でもまあ、描画されないよりはマシかなと…。
ちなみに、30 - 50FPSぐらいで動いてくれた。結構善戦している。20FPS に固定すれば処理落ちせずに済む感じ。
_mieki256/ssp3droadgl
元のプログラムは、4096x4096のテクスチャ画像を使っていたけれど、IdeaPad S10-2 (Intel Atom N270, Mobile Intel 945GSE Express)の最大テクスチャサイズは2048x2048だったので、テクスチャが読み込めなくて正常な描画にならなかった。今回、1024x1024のテクスチャ画像も用意して、GL_MAX_TEXTURE_SIZE が 4096 より小さい場合はそちらのテクスチャ画像を読み込むように修正してみた。
動作確認したところ、小さいテクスチャを拡大しながら描画してるせいか、カメラに近いビルボードや路面はボケボケになってしまった。でもまあ、描画されないよりはマシかなと…。
ちなみに、30 - 50FPSぐらいで動いてくれた。結構善戦している。20FPS に固定すれば処理落ちせずに済む感じ。
◎ 1024x1024以下しか使えないGPUはあるのだろうか :
GL_MAX_TEXTURE_SIZE が 2048 どころか 1024 を返してくるハードウェアはあるのだろうか。以下のページを眺めてみたけれど…。
_OpenGL capabilities report: GL_MAX_TEXTURE_SIZE
大半のGPUは最低でも2048を返してくるように見える。1024を返してくるGPUは数えるほどしかない。
ただ、VIA/S3G UniChrome Pro が1024を返すようではある。ググったところ、VIA K8M800チップセットに統合されていたGPUらしい。
_S3 Chrome - Wikipedia
一応、MSI K8MM-V という、VIA K8M800 + VT8237R が載ってるM/Bを持ってるから、テストしてみようか…。
でも、あのM/Bは Linuxのデスクトップ環境すら真っ当に表示できないほどに動作が遅かったはず。ウインドウを移動するだけでも、ベロンベロンと書き換えてる様子が分かるぐらいに遅かった。あのハードウェアでOpenGLを動かそうと思う人はもう居ないんじゃないか…？ そもそも今の時代に使ってる人はどれほど居るのか…。いや、それを言ったら、今の御時勢、スクリーンセーバ自体を動かす人が一体どれだけ居るのかと言う話にもなりそうだけど。
_OpenGL capabilities report: GL_MAX_TEXTURE_SIZE
大半のGPUは最低でも2048を返してくるように見える。1024を返してくるGPUは数えるほどしかない。
ただ、VIA/S3G UniChrome Pro が1024を返すようではある。ググったところ、VIA K8M800チップセットに統合されていたGPUらしい。
_S3 Chrome - Wikipedia
一応、MSI K8MM-V という、VIA K8M800 + VT8237R が載ってるM/Bを持ってるから、テストしてみようか…。
でも、あのM/Bは Linuxのデスクトップ環境すら真っ当に表示できないほどに動作が遅かったはず。ウインドウを移動するだけでも、ベロンベロンと書き換えてる様子が分かるぐらいに遅かった。あのハードウェアでOpenGLを動かそうと思う人はもう居ないんじゃないか…？ そもそも今の時代に使ってる人はどれほど居るのか…。いや、それを言ったら、今の御時勢、スクリーンセーバ自体を動かす人が一体どれだけ居るのかと言う話にもなりそうだけど。
[ ツッコむ ]
以上です。