2015/08/27(木) [n年前の日記]
#1 [dxruy] DXRubyのImage.load_tilesの不具合
DXRuby の Image.load_tiles を使っていたのだけど、もしかすると不具合に遭遇したかもと思えてきたので一応メモ。
ちなみに、Image.load_tiles というのは、タイル状に並んだ画像を一枚読み込んで、ソレを指定個数で分割して画像として持てる、みたいな機能。というかメソッド。
症状としては、Image.load_tiles で大きな画像を読み込むと不正終了してしまう、みたいな感じ。例えば、394x406ドットのpng画像を32枚、横一列に並べて、12608 x 406ドットの画像を作って読み込ませてみたら不正終了してしまったわけで。
もしかして4096とか8192とかの制限があるのかなと思えてきたので、4096ドットや8192ドットを超えた時は横一列に並べるのをやめて縦方向も使って並べた画像にしてみたり。つまり、横にめちゃくちゃ長い画像じゃなくて、できるだけ正方形に近い画像を読み込ませて分割させてみたらどうなるかと。…これだと不正終了しない。
と思ったけど、そういった感じの画像を、おおよそ90ファイル前後読ませてみたら、また不正終了。
ちなみに、画像をバラバラにして、Image.load で1枚1枚読み込ませたら不正終了しなかった。 *1
件のメソッドには画像サイズ等に関して何か制限か仕様があるんじゃないかとドキュメントを眺めてみたけど、それらしい記述は見つからず。まあ、こんなに巨大な画像を大量に読み込むことは想定してない、そんな予感も…。
ちなみに、Image.load_tiles というのは、タイル状に並んだ画像を一枚読み込んで、ソレを指定個数で分割して画像として持てる、みたいな機能。というかメソッド。
症状としては、Image.load_tiles で大きな画像を読み込むと不正終了してしまう、みたいな感じ。例えば、394x406ドットのpng画像を32枚、横一列に並べて、12608 x 406ドットの画像を作って読み込ませてみたら不正終了してしまったわけで。
もしかして4096とか8192とかの制限があるのかなと思えてきたので、4096ドットや8192ドットを超えた時は横一列に並べるのをやめて縦方向も使って並べた画像にしてみたり。つまり、横にめちゃくちゃ長い画像じゃなくて、できるだけ正方形に近い画像を読み込ませて分割させてみたらどうなるかと。…これだと不正終了しない。
と思ったけど、そういった感じの画像を、おおよそ90ファイル前後読ませてみたら、また不正終了。
ちなみに、画像をバラバラにして、Image.load で1枚1枚読み込ませたら不正終了しなかった。 *1
件のメソッドには画像サイズ等に関して何か制限か仕様があるんじゃないかとドキュメントを眺めてみたけど、それらしい記述は見つからず。まあ、こんなに巨大な画像を大量に読み込むことは想定してない、そんな予感も…。
*1: というか今までそういうやり方で処理していたのだけど。
この記事へのツッコミ
[ ツッコミを読む(3) | ツッコむ ]
#2 [dxruby] 画像読み込み処理を修正中
今まで、画像を読み込み終わるまで表示が一切変わらない仕様で作ってたのだけど、それではさすがにアレだなと思えてきたので、試しに Thread を使って、別スレッド内で画像の読み込みをして、メインスレッドで結果の表示をするようにしてみたり。結構それっぽい感じの表示になって少し満足。後は、表示メッセージの種類や割合表示を増やしていけばどうにか。
昔の DXRuby は Thread を使うとおかしなことになったらしいけど、Ruby 2.0 + DXRuby 1.4.1 を使ってる分にはそういうこともないようで、というかスンナリ動いてるので、ありがたいことだなと…。
それはともかく。やっぱり画像が多過ぎる・大き過ぎる気がする。1280x720ドットの画面サイズに加えて、Spriter で作成・エクスポートしたベタ画像をそのまま丸々読み込んでるから、なのだけど。どうしたもんか。やっぱり、パーツ画像 + Spriterファイルを読んで、DXRuby上で多関節で表示したほうがいいのだろうか。でもソレだと後から画像だけ差し替え、とかできなくなるし…。処理速度も間に合うか疑問だし…。
昔の DXRuby は Thread を使うとおかしなことになったらしいけど、Ruby 2.0 + DXRuby 1.4.1 を使ってる分にはそういうこともないようで、というかスンナリ動いてるので、ありがたいことだなと…。
それはともかく。やっぱり画像が多過ぎる・大き過ぎる気がする。1280x720ドットの画面サイズに加えて、Spriter で作成・エクスポートしたベタ画像をそのまま丸々読み込んでるから、なのだけど。どうしたもんか。やっぱり、パーツ画像 + Spriterファイルを読んで、DXRuby上で多関節で表示したほうがいいのだろうか。でもソレだと後から画像だけ差し替え、とかできなくなるし…。処理速度も間に合うか疑問だし…。
[ ツッコむ ]
#3 [anime][neta] 本当のファンとそうじゃない人が居そうな気がする
GOD EATERの特番を視聴しながら ―― 特番と言っても、そもそも最初の特番内でアニメスタジオの社長さんが「この作りは大変なので特番を入れてスケジュールをどうにかしたい」と発言してたから不測の事態として仕方なく入れてるわけじゃなく最初から入れる気満々むしろ入れるならココかな等狙いながら入れてそうだから特番と言っても実質「TV放映版 GOD EATERを構成してる各話」「TVシリーズの1話」という扱いじゃないのかしらと思うけどそれはさておき ―― まあ、特番を視聴しながら Twitter のタイムラインも眺めてみるとどいつもこいつも「放映に間に合ってない」「放映が」「放映が」ばかりつぶやいていてかなりウンザリしたのだけど、それらを眺めてるうちに、この人達はまずそもそもこのアニメのファンじゃないのではないか、と気がついたわけで。と言うのも、同じような状況になってた「蟲師」「血界戦線」とは反応が全然違うわけで。
たぶん、おそらく、以下のように分類できそうな予感。
「蟲師」「血界戦線」の時のタイムラインはほとんどAだった印象なのですけど。どこで差がついたんだろう…。何故だろう…。
たぶん、おそらく、以下のように分類できそうな予感。
─┬── 放送に間に合わなくてもいいよ派
│ │
│ ├─ A. じっくり時間かけていいの作ってよじっと待ってるよ俺これ結構好きだし派
│ │
│ └─ B. ちゃんと見てないからどうでもいいよ派
│
│
└── 放送に間に合わないのは許せないよ派
│
├─ C. 本編面白くて楽しみなんだから毎週見せろよ見せてくださいおながいします派
│
├─ D. 叩ける対象が見つかったぜヒャッハー！ ぶっ殺せえええ！派
│
└─ E. 俺が地獄を見てるのにコイツラ許せないああそうだよ俺は他社の制作進行だよ派
他にも色々ありそうだけど…。「放映」「放映」言ってるのは、ほとんどがD、たまにE、だと思うんで、とりあえず無視していいんじゃないかなと…。「蟲師」「血界戦線」の時のタイムラインはほとんどAだった印象なのですけど。どこで差がついたんだろう…。何故だろう…。
[ ツッコむ ]
以上、1 日分です。
http://d.hatena.ne.jp/t_tutiya/touch/20131108/1383871461
参考になればー。
load_tilesはメインメモリで画像分割してるものと思い込んでましたが
一旦VRAMに渡してそこで画像分割してる、からVRAM容量を超えると落ちるのかしらん…。
となると、ビデオカードがどの程度のメモリを持ってるか・扱えるかで、
load_tilesで強制終了したりしなかったりする場合もありそうですね…
何にしても画像サイズを小さくしないとマズイなあ…
https://osdn.jp/projects/dxruby/scm/svn/commits/402
確か、DirectXの画像データ作成限界とかだったかと思います。