SDL日本語リファレンスついに完成 15
ストーリー by wakatono
おつかれさまです 部門より
おつかれさまです 部門より
mera曰く、"あのクラスプラットフォームマルチメディアライブラリ、SDLのリファレンスの翻訳が一段落し、sdldoc-jp-1.2.4-rev01が公開されました。 SDLとは、Linux, Win32, BeOS, MacOS, Solaris, IRIX, and FreeBSDで利用可能なゲーム開発に適したライブラリで、SDLを利用してゲームを開発する事によって、多数のOS上でゲーム等を容易に開発する事が出来るわけですが、私がSDLをさわりはじめた頃は日本語の情報が非常に少なくてソースコードを読みつつ難儀しながら遊んでたものでした。 翻訳チームのみなさん、ありがとう！！！！！！
個人的にはゲーム開発ではなくて、やたらめったら描画速度の速いUMLモデリングソフト等作ってみたいと妄想してたりするわけですが、あなたならこのライブラリを使って何を作ってみたいと思いますか？"
ご苦労様～ (スコア:2, すばらしい洞察)
（とは言え、リファレンスだけでは不足なので結局ソースを読む必要はあると思いますが(^^;)）
ところで
とのことですが、これってSDL Video向きじゃないような気がするんですけど…。
SDL VideoのフォローはサーフェスのBltと矩形塗りつぶしぐらいで、あとは直接サーフェスのメモリにアクセスしなきゃなりませんから。
SDLの利点って、速さじゃなく対応プラットフォームの多さですよね。（私の環境では）X11だと相当に遅いです。
（オフスクリーンサーフェスは単なるShared Imageみたいだし）
Re:ご苦労様～ (スコア:1)
うち(FreeBSD 4.5-STABLE, XFree86 3.3.6, Matrox G200)では Windows とほとんど同じ速度出てるようです。厳密に速度を計測したわけじゃないですけど(^^;。
もしかして Windows でも SDL 使わず DirectX ネイティブで組めばそっちの方が速いのかな？
まぁ、SDL のメリットが対応プラットフォームにあるというのは、確かにそうですね。
Re:ご苦労様～ (スコア:1)
あ、失礼。自分の場合はOpenGLと合わせて使ってるって事で。ちなみに今の自分の環境は W2K Cygwin + SDL です。グラフィックボードが結構いい仕事してくれるのでかなり快適です。
すらど宴会SNS開放中 [e-meet.jp]
Re:ご苦労様～ (スコア:1)
>SDLの利点って、速さじゃなく対応プラットフォームの多さですよね。（私の環境では）X11だと相当に遅いです
確かにXmameでSDL化前はPenIII500MHzでサクサク動いていたやつ(例えばGigandes等)がSDL化後は定常的に処理落ちするようになりましたから, 生の場合と比べて少なくとも数10%程度, 悪ければ50%程度のロスが発生している可能性はありますね.
重いもの (スコア:1)
>やたらめったら描画速度の速いUMLモデリングソフト等作ってみたい
UMLかあ。逆にいえば、Rational Roseとか使っていると、
「たかがUMLを」描くためのソフトが、なんでこんなに
重くならにゃならんのだ?と落涙したくなってきます。
なんなんでしょうね、これ…(T_T)
SDLみたいな(って、俺は使ったことは無いですが)しかるべき描画ライブラリを
使わないかぎり、道は拓けないものなんでしょうか?
速度を出すには、最初かつ最大に関心を払うべきはアルゴリズムの改善だ、と言いますよね。
ライブラリの適用より前にやるべきことは、本当に無いんでしょうか?
描画の手順自体をライブラリに命じるアルゴリズムは、本当に改善の余地が無いんでしょうか?
…と思ってしまいます。
#つまり逆にいえば、SDLを適用してもUMLツールはあんまり速くならないのではないか?と…
Re:重いもの (スコア:1)
＞「たかがUMLを」描くためのソフトが、なんでこんなに
＞重くならにゃならんのだ?と落涙したくなってきます。
Roseとか一度しか使った事が無いので大して覚えてないのですが、Algo UML とか IIOSS とかはとっても遅くて泣けてくる程でした。
＞速度を出すには、最初かつ最大に関心を払うべきはアルゴリズムの改善だ、と言いますよね。
＞ライブラリの適用より前にやるべきことは、本当に無いんでしょうか?
＞描画の手順自体をライブラリに命じるアルゴリズムは、本当に改善の余地が無いんでしょうか?
＞
＞…と思ってしまいます。
＞
＞#つまり逆にいえば、SDLを適用してもUMLツールはあんまり速くならないのではないか?と…
私がSDLに注目してるのは
・ハードウェアに描画を任せられる（早い）
・コードが書きやすい（使いやすい）
・移植性が高い（複数のOS用のが作れる）
だったりするわけで、HWによる描画が可能ならなんだっていいわけです。以前はDirectXを使ってましたが(5の時だけど)、初期化がものすごく面倒で息切れしてしまいました。もちろん、この辺は人それぞれなのでまた違う意見があるかもしれません。
又、SDL(又はハードウェアアクセラレーションが可能な)を利用すれば早くなるか？ という事については私は十分に可能だと思います。 モデリングで各オブジェクトを追加する時以外は関連チェックを行わない様にすれば笑っちゃう程早いものが出来そうな気がします。 ただ、それを作る時間を搾り出すのが困難なのでタレコミで書いた通り妄想の域は出ていません。
余談ですが、K6-2 300MHz なマシンでプレステをエミュった時、笑っちゃう程遅かったです。やっぱりCPUよりもアクセラレータに描画させるのは非常に有効だと思います。
クラス図で１ポリゴン、クラス名や属性をテクスチャにしたら早くなりそうだ(笑)
すらど宴会SNS開放中 [e-meet.jp]
Re:重いもの (スコア:1)
俺も少しIIOSSも使いました。あれも遅かったなあ。しみじみ。
(その頃求めてた機能が無かったんで、その後Roseに行ったのだが、以下同文)
>初期化がものすごく面倒で息切れしてしまいました。
ところでこういうのって、なんかの言語のクラスライブラリで
ラップできないものなんでしょうか?
borland delphiの説明で聞いたような気がするんですが、
delphiのGUIクラスって、windowsのwindow handleに生で一対一対応
しているのではなく、時にhandleをキャッシュしたり、時に
handleでは表現不可能な変化を(handleを捨てて作りなおすことで)
可能にしたり、というふうにして、使いやすくかつ性能も上がるように
している、のだそうです。
そういう感じに。
>関連チェックを行わない様にすれば
>クラス図で１ポリゴン
あっそうか。そういうハード(を包むライブラリ)を、
たとえば「重なりぐあいアクセラレーター」だと思えばいいのか!
上位ソフトは安直な描画手順としてしか命じず、
足まわりが動的に最適化しながら表示してくれる、と。
ただ、あーいうツールの絵って、どっちかってーとそれ以前の段階の
「レイアウトをどう決定するか(beautifyっていうんでしょうか?)」で
時間を食ってるような気もしないでもないですが。
beautifyアクセラレータってのは存在しないもんなんでしょうかね?(^^;;
有ればワープロ類とかでも重宝するような気がする。字の並べかたを決定するのがそもそも重いもんね。
あとwebブラウザでもtableとか…
>クラス図で１ポリゴン
パラッパラッパーを思いだしちゃった(^^;
Re:重いもの (スコア:0)
クラス図やら、協調図やらを立体的に眺められるとある意味便利そうですね。 紙に出すと訳わからくなりますが。
Re:重いもの (スコア:1)
trueOne
Re:重いもの (スコア:1)
そういや、シーケンス図とコラボレーション図って、
1つの3次元図を違う確度から見ただけの図ですよね。
つまりUMLが3次元において定義されていたならば、
図の種類はとりあえず1つ減っていたはずなわけだ。
そういう意味で、2次元に拘泥してしまったUMLには、
いろいろ不安を感じています。
>紙に出すと訳わからくなりますが。
XPの名を出すまでもなく、紙は「捨て」でしょう。
あれほどIT(情報技術)をふるう対象として不適切なものは(我々の身近には)あんまり無いです。
将来、紙がCVSに保存できるようになったら、俺も少し考えますけども。
2次元コンプレックス(ぉ)なUMLに感じるのと同じ不安を、
紙(に描かれてしまった死んだ情報)に対して感じます。
計算機で表現できる世界って、ややもすると無限次元だよね。
てゆーかNetwork構造とかをやりだしたら次元なんて事すら言ってられなくなる。
これを紙とかの2次元に乗せようってのがまず無理。
Undocumentedみたいだが (スコア:1)
Motif+xlibで動画を表示なんて無茶なことを頼まれたときに、
って感じで、アプリケーションのウィンドウにSDLのウィンドウを張り付けて 使ったことがあります。
Xの拡張機能とか自動的に見つけてくれるんで、下手に自分でゴリゴリやるより よほど速いだろうし、重宝します。
終わりのない作業 (スコア:1)
最初の翻訳のときには、勢いがあるので、いいのですが、 古くなってしまった翻訳を更新する作業って、地味な作業です。 最初の翻訳をしたときのメンバーがあまり動けなくなってしまったり、 などの事態も予想されます。これで終わり、ではなく、 むしろ、これからが正念場かもしれません。
といいながら、Debian Woody 用文書の翻訳 (古～い書の更新) にひーひー言ってるところです。なんとかリリースまでに間に合わせないと。
翻訳というのは、このような地味でしんどい世界ですが、 どうせ自分が読むために翻訳するのなら、その苦労をみんなで分担して しまうほうがずっといいですので、各方面での翻訳作業にご協力ください。
Re:終わりのない作業 (スコア:1)
こうやってプロジェクトに参加して、成果物を公開した以上は
飽きたとか疲れたとか、そういう理由で古いドキュメントをいつまでも
見せつづけるようなことはないようにしたいものだと思っています。
実際に原文の追跡などをしてゆくと、翻訳の作業そのものよりも、
ドキュメント管理や作業状況の管理などが大変だなーと思ったりしました。
まだ初回のリリースから日がたってないため、翻訳の品質向上などにも
気を配ってゆきたいところです。
実用例 (スコア:0)
ゲーム作成ツールを妄想 (スコア:0)
他、
#ええ、わたしゃ馬鹿ですとも…。