SDLスレ

**login:Penguin** · 01/11/11 17:59

マルチプラットホームな汎用ゲームライブラリの
SDLについてのスレッドです。
最新情報、参考になるソース、質問等

とりあえず、本山
http://www.libsdl.org/

**名無しさん＠お腹いっぱい。** · 01/11/11 18:15

1.2.3 リリース!

SDL関係のニュースはSDL Watchで
http://www2.jan.ne.jp/~zinnia/sdl/watch/cur/rent/

**名無しさん＠お腹いっぱい。** · 01/11/11 23:04

恐らくこの板の住人のほとんどがWindowsオンリーのプログラマであるためか
こういうものに見向きもされないね・・・。

**名無しさん＠お腹いっぱい。** · 01/11/11 23:26

いや、実はつい最近知って手を出してみようとは思っているのだが
まだ何もやってないのでなんとも書けないのだ

**名無しさん＠お腹いっぱい。** · 01/11/12 01:18

>3

そんなことないよ。

**名無しさん＠お腹いっぱい。** · 01/11/12 01:57

linux板より

煽り for 1 with SDL
http://pc.2ch.net/test/read.cgi/linux/999430299/107-108

及び、そのパッチ
http://pc.2ch.net/test/read.cgi/linux/999430299/152

**名無しさん＠お腹いっぱい。** · 01/11/12 11:59

うあ、結構簡単に作れるんだね。萌える。なにかやってみようかな

01/11/12 18:59

こういうものをうまく使ってマルチプラットホームのゲーム出そうなんて
奇特な国内メーカーいないかな

**名無しさん＠お腹いっぱい。** · 01/11/12 19:20

前使ったときはアルファブレンディングのパフォーマンスが悪かったのですが
改善されたのでしょうか？ちなみにWindowsの話です。

**名無しさん＠お腹いっぱい。** · 01/11/12 20:48

えここでファイトの作者はこれ使ってたような…
だからいろんな機種に対応できるのかな。

**名無しさん＠お腹いっぱい。** · 01/11/12 21:32

>>10
PS2のLinuxにも対応してたしなー。ま、そんなに速度は出なかったようだが。

**名無しさん＠お腹いっぱい。** · 01/11/12 21:47

>>9
Win版のソース見たこと無いけどライブラリ内でDirectX使ってるんじゃないかな？
もしかしたら前使ったバージョンってのがソフトでやってたのかもしれないけど・・・。

**名無しさん＠お腹いっぱい。** · 01/11/12 22:09

SDLはDirectXが入ってる環境では自動的に使ってくれるらしい。
ソース見てないけど。

**名無しさん＠お腹いっぱい。** · 01/11/13 10:53

日本のSDL関係のリンクを書いておこう。

SDL library documentation(japanese)
http://www.wakhok.ac.jp/~momma/SDL/

Adas' Linux ゲームプログラム
http://www.geocities.co.jp/Berkeley/2093/

ruby/SDL
http://www.kmc.kyoto-u.ac.jp/~ohai/

Just Another Ruby/SDL
http://www6.tok2.com/home/tamura/rubysdl/index.php3

**名無しさん＠お腹いっぱい。** · 01/11/13 20:04

グラフィックはOpenGLベースでジョイパッド対応やオーディオのみ
SDLみたいな使い方を解説しているHPとかないでしょうか？

**名無しさん＠お腹いっぱい。** · 01/11/13 20:26

>>15
解説も何も、そうすれば良いじゃん

**名無しさん＠お腹いっぱい。** · 01/11/14 22:16

SDL-fan-jp(メーリングリスト)
http://www.freeml.com/ml_info.php?ml=sdl-fan-jp

>SDLはDirectXが入ってる環境では自動的に使ってくれるらしい。
ヘッダとライブラリは必要。

既出の
Adas' Linux ゲームプログラム
http://www.geocities.co.jp/Berkeley/2093/
に解説あり。

**名無しさん＠お腹いっぱい。** · 01/11/15 00:58

>ヘッダとライブラリは必要。
開発環境にはってこと。
実行時にはDirectXを自動的に使ってくれる。

**名無しさん＠お腹いっぱい。** · 01/11/18 08:00

MacOS X / ProjectBuilderで使おうとしたら準備に3時間かかった。
変なディレクトリ構成でインストールしちゃったり、
SDL.hがフレームワークに入ってなかったり
PBProjects.tar.gzの最新版が壊れて(?)たり
鬱だ、、、

01/11/18 13:46

Allegroのほうが使いやすいと思う。

**名無しさん＠お腹いっぱい。** · 01/11/18 14:16

>>20
Kore Kai?
http://www.talula.demon.co.uk/allegro/index.on.html

**名無しさん＠お腹いっぱい。** · 01/11/21 02:04

allegroをBCBで使ってる人っています？
インストールの段階でつまづいて困ってるんですけど…

22 · 01/11/21 23:16

結局mingwに逃げちゃいました。
とりあえずインストールまで完了。

22 · 01/11/23 10:39

http://www.grandgent.com/gfoot/vivace/
とりあえずここのチュートリアルを一通り読んでみました。

**名前は開発中のものです。** · 01/11/23 21:49

>>22が使ってるVerおよび環境は？
ウチはver3.9.40 +Win2k でmakefile.bcc の記述ミスによる
コンパイルエラーを確認したが。

※出力を良く見たら、ソースのパスから\が抜けていたので、
　エディタで行末以外の\を\\に置き換えてやったらうまくいった。

22 · 01/11/24 21:25

自分もver3.9.40+w2kです。

all3940.zipを解凍してfix.bat bcc32と実行するところまではOKなんですけど、
その後makeしようとすると「指定されたファイルが見つかりません」って出てしまいます。
\を\\で置き換えるのもやってみましたけど、同じでした。

mingwでインストールできちゃってるので、あんまり深くは追求しないことにします。
すいません。

25 · 01/11/25 01:32

後学の為にももう少し追及すべし!!
…とは言わん。対応するコンパイラの多さもAllegroのウリだし。

ところで「指定されたファイルが見つかりません」等と下手に
翻訳するより、原文載せた方が原因判明しやすいと思うヨ。
何となく BCC32DIR のパス指定ミスとか、
GNU make じゃなくてBCC付属のmake使ってるとか、
必要なファイルの不足とかいった原因が思い浮かぶが、
実際のエラー文を見てみないと良くワカラン。

22 · 01/11/25 02:13

BCBは、f:\w2k\Borland\CBuilder5にインストールされてます。
BCC32DIRの設定は
> set BCC32DIR=f:\w2k\Borland\CBuilder5
とやりました。

make しようとすると、

H:\temp\all3940\allegro>f:\w2k\mingw\bin\make.exe
process_begin: CreateProcess((null), echo Compiling Allegro for BCC32, optimised
. Please wait..., ...) failed.
make (e=2): 指定されたファイルが見つかりません。
f:\w2k\mingw\bin\make.exe: *** [msg] Error 2

と出てしまいます。
もうちょっと調べてみます

25 · 01/11/25 14:57

>>28
内部用コマンドであるはずのecho が外部コマンドとして
実行されようとして、結果エラーになってるみたいですナ。

自分もヘタレ何でよくわからんけど、もしかしてdos上で
cygwin用make実行してるとか、逆にcygwin上でdos用makeを
実行してない？

一応DOS/Win用のGNU-Makeの在処を。
　http://sourceforge.net/projects/mingw/

22 · 01/11/26 07:45

うーん、上のmakeはcygwinのじゃなくてmingwのdos用のなんですよね。
cygwinのmakeを使うと
copy: not found
って出ます。

一応makeだけ落としなおしてみましたけど結局同じでしたんで、
今回はあきらめることにします。
どうもありがとうございました。

22 · 01/11/26 07:45

上のmake＝28で使ったmake　ってことです。

**名前は開発中のものです。** · 01/12/05 01:12

sage

**名前は開発中のものです。** · 01/12/23 23:10

このスレ盛り上がらないね

**名前は開発中のものです。** · 01/12/24 00:27

最近はSDLを使いつつ、OpenGLで2D描画するのがはやってるらしいよ。

**名前は開発中のものです。** · 01/12/24 01:51

うーん、まぁ Ruby/SDL とか見てみて思ったのが、
やっぱ型付けが強い言語がゲームとか複雑な実装には
向いているのかなぁと。

（Rubyとかは業務機関とか単純な実装に使うのがいいやね。）

**名前は開発中のものです。** · 01/12/24 02:08

Cマガの来月号に何か載るらしい

**名前は開発中のものです。** · 01/12/24 02:47

以前SDL+OpenGLは遅いと聞いたけど、改善されたん？>>034

**名前は開発中のものです。** · 01/12/24 05:10

>>35
よろしければ具体的な理由(そう感じた決定打?)を教えてください｡
Ruby/SDLのサンプル見た感じではそんなに悪い印象を感じませんでしたが、
Cとかの方が有利な点があればぜひ知りたいです｡

**名前は開発中のものです。** · 01/12/24 09:14

SDLってGPLだかLGPL縛りじゃん。
感染しちゃうよ。ソース公開だとかどうしてるの？みんな

**名無しさん＠Ｅｍａｃｓ** · 01/12/24 09:56

>>34
SDL_OPENGLBLITのことでしょうか？今でも遅いですよ。
SDL_OPENGLでハードウェア使える環境なら、少なくとも2Dでは充分な速さが出ます。

>>39
SDLはLGPLです。ソースは公開しなくても良いです。
ただ再リンクが可能なようにオブジェクトも配布しないといけないんだっけか？
ヘタレなので詳しくはわかりませぬ。調べて下され。

**名前は開発中のものです。** · 01/12/24 10:31

SDL_OPENGLBLITは気の迷いなので使うなってことになってるらしいよ。
OpenGL使うのは、Windows以外の2D描画でハードウェアアクセラレーションを
利用する手段が無いことじゃなかったかな。

**名無しさん＠Ｅｍａｃｓ** · 01/12/24 12:17

重箱の隅つつきですけど。

Windowsの2Dで提供されているぐらいのハードウェアアクセラレー
ションならSDLの各環境でも可能なら利用するように実装されてま
すね。

**名前は開発中のものです。** · 01/12/24 13:54

>>38
Ruby はＣよりはよっぽどいいんですけども、ただ、
JavaやC++は型が間違っていると実行前に気づかせて
くれるので、ゲームのようにテストのしづらいものを
作る場合は型づけが強いほうが楽かなー。と思ったん
ですけども。

**名前は開発中のものです。** · 01/12/24 23:08

>>43
ということは、以下のスレと関連する話って事ですか｡

型なし言語逝ってよし
http://pc.2ch.net/test/read.cgi/tech/986355498/

実際にRuby/SDLなりその他のバインディング(っていうんでしたっけ?)での
ゲームの実例があればもう少し話を広げられそうなんですが、
詳しく知らないです｡

**名前は開発中のものです。** · 01/12/25 14:58

> 実際にRuby/SDLなりその他のバインディング(っていうんでしたっけ?)での
> ゲームの実例があればもう少し話を広げられそうなんですが、

いろいろ考えてみたんですけど、まぁ、型づけが強くないとテスト
しづらいっていうのは、もともとテストしづらい設計で、こ
のまま作っていても、あんまりよくないっていうことを暗に
示しているのかなと思うようになりました。

型づけの強い言語でもそうだけど、型づけの弱い言語ならなおさら、
徹底した XP 張りのテストが必要になるなぁ、と。

**名前は開発中のものです。** · 01/12/27 05:06

だんだんスレ違いなレスになってしまって申し訳ありません｡

>>45
XPといってもRubyUnitをほんの少し触ったことしかありませんが、
単に型に注目するだけでしたら、引数の型が正しいかどうかを
確認するテストを各メソッド毎に用意する、みたいな。
C等のプロトタイプ(宣言?)をテストで補う感じでしょうか｡

それとは別にゲーム…特にリアルタイム系のゲームにに特化した
テストがあると良いのかもしれませんね｡
例えば入力機器(マウスとかジョイスティックとか)が吐き出すデータを
仮想的に生成して、それをリアルタイムにテストしていく…
なんか自分で書いてて良くわかりませんが｡

**名前は開発中のものです。** · 01/12/27 14:35

>>46

> 単に型に注目するだけでしたら、

つまりたとえば、シューティングゲーム作るときに、ステージの最期に
ボスシーンがあるわけですが、多分、多くのゲームプログラマは、
ステージの構成を Scene クラスとして、それを継承して BossScene クラス
みたいなものを作ると思うんですけども。

もし、間違えて Scene オブジェクトじゃなく int オブジェクトを
渡してしまっても、その間違いに気づくには、ボスシーンまで辿り
つかないといけないという、、、。ちょっと、これは、、、、うーん。

（まぁそれを未然に防ぐ手だてはいくつかあると思うんですけどもね。）

Ruby のような気軽に使われることを想定しているプログラミング言語
の場合は型なんて無いほうがメリットが多いので、それはそれでいいん
ですけども、ちょっと複雑なものになってしまったとき、Ruby じゃなく
C++ や Java の方がいいんじゃないかなと。