SDL日本語リファレンスついに完成

mera曰く、"あのクラスプラットフォームマルチメディアライブラリ、SDLのリファレンスの翻訳が一段落し、sdldoc-jp-1.2.4-rev01が公開されました。 SDLとは、Linux, Win32, BeOS, MacOS, Solaris, IRIX, and FreeBSDで利用可能なゲーム開発に適したライブラリで、SDLを利用してゲームを開発する事によって、多数のOS上でゲーム等を容易に開発する事が出来るわけですが、私がSDLをさわりはじめた頃は日本語の情報が非常に少なくてソースコードを読みつつ難儀しながら遊んでたものでした。　翻訳チームのみなさん、ありがとう！！！！！！

個人的にはゲーム開発ではなくて、やたらめったら描画速度の速いUMLモデリングソフト等作ってみたいと妄想してたりするわけですが、あなたならこのライブラリを使って何を作ってみたいと思いますか？"

ご苦労様～

[T.Sawamoto (4142)]

私も英語リファレンスとソース、サンプルを読みながら利用しましたが、やっぱり日本語リファレンスがあると便利ですね。
（とは言え、リファレンスだけでは不足なので結局ソースを読む必要はあると思いますが(^^;)）
ところで

…やたらめったら描画速度の速いUMLモデリングソフト等作ってみたいと妄想してたりするわけですが…

とのことですが、これってSDL Video向きじゃないような気がするんですけど…。
SDL VideoのフォローはサーフェスのBltと矩形塗りつぶしぐらいで、あとは直接サーフェスのメモリにアクセスしなきゃなりませんから。

SDLの利点って、速さじゃなく対応プラットフォームの多さですよね。（私の環境では）X11だと相当に遅いです。
（オフスクリーンサーフェスは単なるShared Imageみたいだし）

Re:ご苦労様～

[eruchan (2221)]

俺は SDL-1.0.3(だったかな？) の頃の日本語リファレンス [wakhok.ac.jp]で SDL を大体把握してから、後は英語のドキュメントとソースとヘッダーファイル郡を読みました。というか今でもヘッダーファイルがリファレンス代わりです(笑)。

SDLの利点って、速さじゃなく対応プラットフォームの多さですよね。（私の環境では）X11だと相当に遅いです。

うち(FreeBSD 4.5-STABLE, XFree86 3.3.6, Matrox G200)では Windows とほとんど同じ速度出てるようです。厳密に速度を計測したわけじゃないですけど(^^;。
もしかして Windows でも SDL 使わず DirectX ネイティブで組めばそっちの方が速いのかな？

まぁ、SDL のメリットが対応プラットフォームにあるというのは、確かにそうですね。

Re:ご苦労様～

[mera (2504)]

ところで

…やたらめったら描画速度の速いUMLモデリングソフト等作ってみたいと妄想してたりするわけですが…

とのことですが、これってSDL Video向きじゃないような気がするんですけど…。
SDL VideoのフォローはサーフェスのBltと矩形塗りつぶしぐらいで、あとは直接サーフェスのメモリにアクセスしなきゃなりませんから。

あ、失礼。自分の場合はOpenGLと合わせて使ってるって事で。ちなみに今の自分の環境は W2K Cygwin + SDL です。グラフィックボードが結構いい仕事してくれるのでかなり快適です。

--
すらど宴会SNS開放中 [e-meet.jp]

Re:ご苦労様～

[SteppingWind (2654)]

>SDLの利点って、速さじゃなく対応プラットフォームの多さですよね。（私の環境では）X11だと相当に遅いです

確かにXmameでSDL化前はPenIII500MHzでサクサク動いていたやつ(例えばGigandes等)がSDL化後は定常的に処理落ちするようになりましたから, 生の場合と比べて少なくとも数10%程度, 悪ければ50%程度のロスが発生している可能性はありますね.

重いもの

[G7 (3009)]

そういや俺もゲームそのものにはあまり関心は無いんだけど、

>やたらめったら描画速度の速いUMLモデリングソフト等作ってみたい

UMLかあ。逆にいえば、Rational Roseとか使っていると、
「たかがUMLを」描くためのソフトが、なんでこんなに
重くならにゃならんのだ?と落涙したくなってきます。

なんなんでしょうね、これ…(T_T)
SDLみたいな(って、俺は使ったことは無いですが)しかるべき描画ライブラリを
使わないかぎり、道は拓けないものなんでしょうか?

速度を出すには、最初かつ最大に関心を払うべきはアルゴリズムの改善だ、と言いますよね。
ライブラリの適用より前にやるべきことは、本当に無いんでしょうか?
描画の手順自体をライブラリに命じるアルゴリズムは、本当に改善の余地が無いんでしょうか?

…と思ってしまいます。

#つまり逆にいえば、SDLを適用してもUMLツールはあんまり速くならないのではないか?と…

Re:重いもの

[mera (2504)]

＞UMLかあ。逆にいえば、Rational Roseとか使っていると、
＞「たかがUMLを」描くためのソフトが、なんでこんなに
＞重くならにゃならんのだ?と落涙したくなってきます。

Roseとか一度しか使った事が無いので大して覚えてないのですが、Algo UML とか IIOSS とかはとっても遅くて泣けてくる程でした。

＞速度を出すには、最初かつ最大に関心を払うべきはアルゴリズムの改善だ、と言いますよね。
＞ライブラリの適用より前にやるべきことは、本当に無いんでしょうか?
＞描画の手順自体をライブラリに命じるアルゴリズムは、本当に改善の余地が無いんでしょうか?
＞
＞…と思ってしまいます。
＞
＞#つまり逆にいえば、SDLを適用してもUMLツールはあんまり速くならないのではないか?と…

私がSDLに注目してるのは

・ハードウェアに描画を任せられる（早い）
・コードが書きやすい（使いやすい）
・移植性が高い（複数のOS用のが作れる）

だったりするわけで、HWによる描画が可能ならなんだっていいわけです。以前はDirectXを使ってましたが(5の時だけど)、初期化がものすごく面倒で息切れしてしまいました。もちろん、この辺は人それぞれなのでまた違う意見があるかもしれません。

又、SDL(又はハードウェアアクセラレーションが可能な)を利用すれば早くなるか？　という事については私は十分に可能だと思います。　モデリングで各オブジェクトを追加する時以外は関連チェックを行わない様にすれば笑っちゃう程早いものが出来そうな気がします。　ただ、それを作る時間を搾り出すのが困難なのでタレコミで書いた通り妄想の域は出ていません。

余談ですが、K6-2 300MHz なマシンでプレステをエミュった時、笑っちゃう程遅かったです。やっぱりCPUよりもアクセラレータに描画させるのは非常に有効だと思います。

クラス図で１ポリゴン、クラス名や属性をテクスチャにしたら早くなりそうだ(笑)

--
すらど宴会SNS開放中 [e-meet.jp]

Re:重いもの

[G7 (3009)]

>IIOSS とかはとっても遅くて泣けてくる程でした。

俺も少しIIOSSも使いました。あれも遅かったなあ。しみじみ。
(その頃求めてた機能が無かったんで、その後Roseに行ったのだが、以下同文)

>初期化がものすごく面倒で息切れしてしまいました。

ところでこういうのって、なんかの言語のクラスライブラリで
ラップできないものなんでしょうか?

borland delphiの説明で聞いたような気がするんですが、
delphiのGUIクラスって、windowsのwindow handleに生で一対一対応
しているのではなく、時にhandleをキャッシュしたり、時に
handleでは表現不可能な変化を(handleを捨てて作りなおすことで)
可能にしたり、というふうにして、使いやすくかつ性能も上がるように
している、のだそうです。
そういう感じに。

>関連チェックを行わない様にすれば
>クラス図で１ポリゴン

あっそうか。そういうハード(を包むライブラリ)を、
たとえば「重なりぐあいアクセラレーター」だと思えばいいのか!

上位ソフトは安直な描画手順としてしか命じず、
足まわりが動的に最適化しながら表示してくれる、と。

ただ、あーいうツールの絵って、どっちかってーとそれ以前の段階の
「レイアウトをどう決定するか(beautifyっていうんでしょうか?)」で
時間を食ってるような気もしないでもないですが。

beautifyアクセラレータってのは存在しないもんなんでしょうかね?(^^;;
有ればワープロ類とかでも重宝するような気がする。字の並べかたを決定するのがそもそも重いもんね。
あとwebブラウザでもtableとか…

>クラス図で１ポリゴン

パラッパラッパーを思いだしちゃった(^^;

Re:重いもの

[Anonymous Coward]

>クラス図で１ポリゴン、クラス名や属性をテクスチャにしたら早くなりそうだ(笑)

クラス図やら、協調図やらを立体的に眺められるとある意味便利そうですね。 紙に出すと訳わからくなりますが。

Re:重いもの

[trueOne (134)]

UMLじゃない ＆ Smalltalkだけど、SRAのObjectOrrery [sra.co.jp]なんてどうよ。

--
trueOne

Re:重いもの

[G7 (3009)]

>協調図やらを立体的に眺められる

そういや、シーケンス図とコラボレーション図って、
1つの3次元図を違う確度から見ただけの図ですよね。

つまりUMLが3次元において定義されていたならば、
図の種類はとりあえず1つ減っていたはずなわけだ。

そういう意味で、2次元に拘泥してしまったUMLには、
いろいろ不安を感じています。

>紙に出すと訳わからくなりますが。

XPの名を出すまでもなく、紙は「捨て」でしょう。
あれほどIT(情報技術)をふるう対象として不適切なものは(我々の身近には)あんまり無いです。
将来、紙がCVSに保存できるようになったら、俺も少し考えますけども。

2次元コンプレックス(ぉ)なUMLに感じるのと同じ不安を、
紙(に描かれてしまった死んだ情報)に対して感じます。

計算機で表現できる世界って、ややもすると無限次元だよね。
てゆーかNetwork構造とかをやりだしたら次元なんて事すら言ってられなくなる。
これを紙とかの2次元に乗せようってのがまず無理。

Undocumentedみたいだが

[hirata (3986)]

個人的にはゲーム開発ではなくて、やたらめったら描画速度の速いUMLモデリングソフト 等作ってみたいと妄想してたりするわけですが、あなたならこのライブラリを使って何 を作ってみたいと思いますか？"

Motif+xlibで動画を表示なんて無茶なことを頼まれたときに、

{

char window_id[32];
sprintf(window_id, "SDL_WINDOWID=%ld", img_win);
putenv(window_id);

}
SDL_Init(SDL_INIT_VIDEO);

って感じで、アプリケーションのウィンドウにSDLのウィンドウを張り付けて 使ったことがあります。

Xの拡張機能とか自動的に見つけてくれるんで、下手に自分でゴリゴリやるより よほど速いだろうし、重宝します。

終わりのない作業

[kubota (64)]

翻訳は、終わりのない作業です。というのは、原文がアップデートされたら、 翻訳もアップデートさせないといけないからです。

最初の翻訳のときには、勢いがあるので、いいのですが、 古くなってしまった翻訳を更新する作業って、地味な作業です。 最初の翻訳をしたときのメンバーがあまり動けなくなってしまったり、 などの事態も予想されます。これで終わり、ではなく、 むしろ、これからが正念場かもしれません。

といいながら、Debian Woody 用文書の翻訳 (古～い書の更新) にひーひー言ってるところです。なんとかリリースまでに間に合わせないと。

翻訳というのは、このような地味でしんどい世界ですが、 どうせ自分が読むために翻訳するのなら、その苦労をみんなで分担して しまうほうがずっといいですので、各方面での翻訳作業にご協力ください。

Re:終わりのない作業

[Zinnia (2900)]

成果物をダウンロードして読んでくださった皆様ありがとうございます。

こうやってプロジェクトに参加して、成果物を公開した以上は
飽きたとか疲れたとか、そういう理由で古いドキュメントをいつまでも
見せつづけるようなことはないようにしたいものだと思っています。

実際に原文の追跡などをしてゆくと、翻訳の作業そのものよりも、
ドキュメント管理や作業状況の管理などが大変だなーと思ったりしました。
まだ初回のリリースから日がたってないため、翻訳の品質向上などにも
気を配ってゆきたいところです。

実用例

[Anonymous Coward]

2chで1を煽る [2ch.net]のに使いました。

ゲーム作成ツールを妄想

[Anonymous Coward]

Plugin方式で、

• 対応ファイルフォーマットの追加
• ミニゲームのインポート
• チップ素材のインポート(属性付き：セット導入可)
• 素材セットのエクスポート(属性付き：セットPack可)
• エフェクト追加
  
  他、
• 透明化PNGでマスク画像いらず？
• WRDやMASLでムービー
• KISSで装備画面
• 3D/2Dマップチップ
• 初心者用作成ウィザード機能
  
  #ええ、わたしゃ馬鹿ですとも…。