画像とかを表示するのは、また今度。それについては「グラフィックモジュール」のところでおはなしするよ。
でも実は、ウィンドウをいじるやり方と、ほとんど同じなんだ。だからこのページをしっかり読んでおくと絶対役に立つよ!
SFMLのウィンドウは sf::Windowクラスで定義されてます。
コンストラクタを呼ぶだけでウィンドウを作れるよ!
上のサンプルでは、800×600ピクセルのウィンドウを作ってるってわけだね。
sf::VideoModeクラスには便利な関数が用意されてて、デスクトップの解像度を取得したり、 フルスクリーンモードに使えるビデオモードのリストを取得したりできるんだ。 面倒くさがらずにドキュメントを読むとトクするよ!
2番目の引数は、もちろんウィンドウのタイトルです。
さて、実は3番目の引数も指定することができます。ウィンドウのスタイルです。
下記の表にあるスタイルを組み合わせて指定できるよ。
もう1つ! 4番目の引数もあるのです。
OpenGLを使うための引数です。それについては「OpenGL を使う」のところでおはなしするね。
さて、コンストラクタで直接ウィンドウを作る方法を書いてきたわけですが、 実は Create という関数もあったりします。 コンストラクタを呼んだ後とか、別のビデオモードやタイトルでウィンドウを作り直したいときに使うとよいですよ。
使い方は全く同じです。
コンストラクタを呼ぶだけでウィンドウを作れるよ!
#include <SFML/Window.hpp> int main() { sf::Window window(sf::VideoMode(800, 600), "My window"); ... return 0; }最初の引数はウィンドウのサイズです。 タイトルバーとか境界線とかを除いたクライアントエリアのサイズだよ。
上のサンプルでは、800×600ピクセルのウィンドウを作ってるってわけだね。
sf::VideoModeクラスには便利な関数が用意されてて、デスクトップの解像度を取得したり、 フルスクリーンモードに使えるビデオモードのリストを取得したりできるんだ。 面倒くさがらずにドキュメントを読むとトクするよ!
2番目の引数は、もちろんウィンドウのタイトルです。
さて、実は3番目の引数も指定することができます。ウィンドウのスタイルです。
下記の表にあるスタイルを組み合わせて指定できるよ。
sf::Style::None | お飾りなし。ぺったんこモード。こんなのいつ使うかって? す、スプラッシュウィンドウ、とか…? ちなみにこのスタイルは他のスタイルと組み合わせ不可です。 |
sf::Style::Titlebar | タイトルバーつきのウィンドウ。 |
sf::Style::Resize | サイズ変更可能なウィンドウ。最大化ボタンもつくよ。 |
sf::Style::Close | 閉じるボタンつきのウィンドウ。 |
sf::Style::Fullscreen | フルスクリーンで表示されるよ。 これも他のスタイルと組み合わせ不可。 これを使うときには、もちろん、フルスクリーン可能なビデオモードが必要です。 |
sf::Style::Default |
デフォルトスタイル。「Titlebar」と「Resize」と「Close」を指定したのと同じになります。
というか、ヘッダーファイル内で「Default = Titlebar | Resize | Close」と定義されてます。 |
OpenGLを使うための引数です。それについては「OpenGL を使う」のところでおはなしするね。
さて、コンストラクタで直接ウィンドウを作る方法を書いてきたわけですが、 実は Create という関数もあったりします。 コンストラクタを呼んだ後とか、別のビデオモードやタイトルでウィンドウを作り直したいときに使うとよいですよ。
使い方は全く同じです。
#include <SFML/Window.hpp> int main() { sf::Window window; window.create(sf::VideoMode(800, 600), "My window"); ... return 0; }
上のサンプルコードをコピーして実行すると、ウィンドウが表示される……と、見せかけて、実は表示されません。
いや、表示はされるんですけど、サンプルの「…」のところに何も書かないままだと、見た目、何にも見えないのです。
えーっと、理由は2つあって、まず1つめは、プログラムがすぐに終了してしまう。 2つ目は、イベントを1つもお世話してない。 なので、今のままでも無限ループにすればプログラムは終了しなくなるからウィンドウは見えるようになるのだけれど、 固まったまま、というわけです。動かせない、サイズ変えれない。閉じれない。
そんなわけで、ちょっと手を加えて、かわいくしてあげましょう。
まず、ウィンドウがリフレッシュ・更新されるようにループしてます。 このループはウィンドウが閉じられるまで続けます。 ほとんどの SFMLプログラムでは、こういう感じのループを書くことになると思うよ。 いわゆる「メインループ」とか「ゲームループ」ってやつだね。
で、そのゲームループ内で何をしてるかと言うと、 どんなイベントが発生したのかをループ内で見張ってます。
「while (window.pollEvent(event))」を使っているところに注目。 つまり、処理されずにたまってるイベントをここで全部処理してます。
たまってるイベントがあれば pollEvent関数の戻り値が true、なければ falseです。
イベントを取得したら、まず、その種類を確認です (ウィンドウ閉じる? キー押下? マウス? パッド接続? などなど…)。 そんで、イベントごとに、適切に処理してあげます(いらないイベントは無視すればいいよ)。
上のサンプルでは、Event::Closedイベントだけ、お相手してあげてますね。 閉じるボタンを押したときに飛んでくるイベントです。 この時点では、まだウィンドウは開いたままです。 close関数を呼んであげることで、実際に閉じます。
え、何? 閉じるボタンを押したんだから、その場で自動的に閉じてくれればいいのにって? なんでわざわざこんな回りくどい仕様になってるのかって?
よくぞ訊いてくれました。それはですね、それはですね、 ウィンドウを閉じる前にデータをセーブしたり、確認メッセージを出したりもできるよ! ってことです。
ここで気づいたと思うけど、まだウィンドウに何も描画してませんね? 最初に言ったように、何かを描画するのは、ウィンドウモジュールじゃなくてグラフィックスモジュールの仕事です。 なので、スプライトとか文字とか図形とかを描画したいときは、グラフィックスモジュールのチュートリアルを読んでね。
描画のときには SFMLのグラフィックスモジュールを無視して、OpenGLを使うこともできます。 実は、SFMLのウィンドウモジュールは内部では OpenGLを使ってます。なので、OpenGLとは仲良しです。 詳しくは 「OpenGL を使う」を見てね。
そんなわけで、ここで扱ってるウィンドウそのものには、過度な期待はしないでね。
いや、表示はされるんですけど、サンプルの「…」のところに何も書かないままだと、見た目、何にも見えないのです。
えーっと、理由は2つあって、まず1つめは、プログラムがすぐに終了してしまう。 2つ目は、イベントを1つもお世話してない。 なので、今のままでも無限ループにすればプログラムは終了しなくなるからウィンドウは見えるようになるのだけれど、 固まったまま、というわけです。動かせない、サイズ変えれない。閉じれない。
そんなわけで、ちょっと手を加えて、かわいくしてあげましょう。
#include <SFML/Window.hpp> int main() { sf::Window window(sf::VideoMode(800, 600), "My window"); // メインループ:ウィンドウが開いている限り、実行しつづける while (window.isOpen()) { // イベントループ:たまってるイベントを全部取り出す。 sf::Event event; while (window.pollEvent(event)) { // イベントの種類が「閉じるボタンが押された」だったら? if (event.type == sf::Event::Closed) { // ウィンドウを閉じる。 window.close(); } /* if文を列挙して、他のイベントも捕まえられるよ */ } } return 0; }上のサンプルは、ウィンドウを開いて、ユーザーが閉じるボタンを押すと閉じる、というものです。 では、詳しく見ていきましょう。
まず、ウィンドウがリフレッシュ・更新されるようにループしてます。 このループはウィンドウが閉じられるまで続けます。 ほとんどの SFMLプログラムでは、こういう感じのループを書くことになると思うよ。 いわゆる「メインループ」とか「ゲームループ」ってやつだね。
で、そのゲームループ内で何をしてるかと言うと、 どんなイベントが発生したのかをループ内で見張ってます。
「while (window.pollEvent(event))」を使っているところに注目。 つまり、処理されずにたまってるイベントをここで全部処理してます。
たまってるイベントがあれば pollEvent関数の戻り値が true、なければ falseです。
イベントを取得したら、まず、その種類を確認です (ウィンドウ閉じる? キー押下? マウス? パッド接続? などなど…)。 そんで、イベントごとに、適切に処理してあげます(いらないイベントは無視すればいいよ)。
上のサンプルでは、Event::Closedイベントだけ、お相手してあげてますね。 閉じるボタンを押したときに飛んでくるイベントです。 この時点では、まだウィンドウは開いたままです。 close関数を呼んであげることで、実際に閉じます。
え、何? 閉じるボタンを押したんだから、その場で自動的に閉じてくれればいいのにって? なんでわざわざこんな回りくどい仕様になってるのかって?
よくぞ訊いてくれました。それはですね、それはですね、 ウィンドウを閉じる前にデータをセーブしたり、確認メッセージを出したりもできるよ! ってことです。
イベントループを書き忘れる、というのはよくあるミスです。
リアルタイム入出力を使うとしても、イベントループがないと、ウィンドウが反応してくれません。
イベントループには、ユーザー(プログラマー)にイベントをハンドリングできるようにするだけではなく、
ウィンドウ自身が内部で必要なイベントを処理するタイミングを与える、という意味もあるのです。
それがあってこそ、ウィンドウを動かしたりサイズを変更したりできるようになる、というわけですね。
以上、ためになるお話でした。
ウィンドウが閉じられた後は、メインループが終了して、プログラムも終了します。ここで気づいたと思うけど、まだウィンドウに何も描画してませんね? 最初に言ったように、何かを描画するのは、ウィンドウモジュールじゃなくてグラフィックスモジュールの仕事です。 なので、スプライトとか文字とか図形とかを描画したいときは、グラフィックスモジュールのチュートリアルを読んでね。
描画のときには SFMLのグラフィックスモジュールを無視して、OpenGLを使うこともできます。 実は、SFMLのウィンドウモジュールは内部では OpenGLを使ってます。なので、OpenGLとは仲良しです。 詳しくは 「OpenGL を使う」を見てね。
そんなわけで、ここで扱ってるウィンドウそのものには、過度な期待はしないでね。
もちろん、ちょっとぐらいは SFMLで遊べます。
サイズを変えたり、位置を変えたり、アイコンを変えたり、猫耳をつけたり、みたいな必要最低限の基本的な機能はサポートされてるよ。
でも、いわゆる、GUIアプリケーションを作るための専用のライブラリ(Qt とか? wxWidgets とか?)と違って、
SFMLのウィンドウそのものは、ハイテクな機能を持ってません。
SFMLのウィンドウは、あくまでも、何かを描画するためのベース、です。
(で、その描画には SFMLのグラフィックスモジュールや、OpenGLを使う、と)
さて、どうしても、もっといろんな機能が欲しかったら、他の GUIライブラリでウィンドウを別個に作って、 そこに SFMLを埋め込めばいいじゃない。ふん。
// ウィンドウの位置を変更(デスクトップ上の座標) window.setPosition(sf::Vector2i(10, 50)); // ウィンドウのサイズを変更 window.setSize(sf::Vector2u(640, 480)); // ウィンドウのタイトルを変更 window.setTitle("SFML window"); // ウィンドウのサイズを取得 sf::Vector2u size = window.getSize(); unsigned int width = size.x; unsigned int height = size.y; ...sf::Windowクラスのメソッドについては、APIドキュメントに全部載ってるよ。
さて、どうしても、もっといろんな機能が欲しかったら、他の GUIライブラリでウィンドウを別個に作って、 そこに SFMLを埋め込めばいいじゃない。ふん。
sf::WindowHandle handle = /* 別個に作ったウィンドウのウィンドウハンドルを代入 */; sf::Window window(handle);SFMLにない機能を1つ追加したいだけ、という場合は、逆に、 SFMLのウィンドウからウィンドウハンドルを取り出すこともできます。 取り出したウィンドウハンドルを使って、 そのウィンドウに何でもお好きなように機能を追加すればいいでしょー。
// こんな感じで、SFMLのウィンドウがあったとして、 sf::Window window(sf::VideoMode(800, 600), "SFML window"); // ウィンドウハンドルがあれば、あとはもう、やりたい放題 sf::WindowHandle handle = window.getSystemHandle();SFMLと他のライブラリを混ぜて使うのは、ちょっとした一苦労というかなんというか、 ここでは解説しないので、別の解説サイトとかを探してね。掲示板で質問するとか。
アプリケーションが高速で動作しているときとか、ティアリングが発生することがありますよね。
アプリのリフレッシュレートがモニターの垂直同期と合ってないのが原因です。
つまり、1フレーム前の画面が現在の画面と混じってしまう、ということです。
この問題は、ウィンドウの垂直同期を有効にすることで解決できます。
setVerticalSyncEnabled (true) を実行しておくと、 ビデオカードが自動的に対処してくれるようになります。
setFramerateLimit関数で夢を実現だ!
そんなわけで、100%は信頼できません(特に高いフレームレートのとき)。
sf::sleep の解像度は OS に依存してて、大体10~15ミリ秒です。 正確なタイミングは期待しないでね。
この問題は、ウィンドウの垂直同期を有効にすることで解決できます。
setVerticalSyncEnabled (true) を実行しておくと、 ビデオカードが自動的に対処してくれるようになります。
// ウィンドウを作成した後、1回だけ実行 window.setVerticalSyncEnabled(true);これを1回実行しておくと、キミのアプリケーションはモニターと同じフレームレートで動くようになるよ。 大体 1秒間に60フレームです。
setVerticalSyncEnabled(true) を実行しても何も効果がないときがあります。
よくある原因は、グラフィックドライバーの設定で、垂直同期が「off」になっていることです。
この設定を「controlled by application」にしておく必要があります。
フレームレートを好きな値にしたいときもありますよね。モニターと同じにするんじゃなくて。setFramerateLimit関数で夢を実現だ!
// ウィンドウを作成した後、1回だけ実行 window.setFramerateLimit(30);setVerticalSyncEnabled関数と違って、この関数は SFML内部で独自に実装されてます。 内部では sf::Clock と sf::sleep を組み合わせて動作させてます。
そんなわけで、100%は信頼できません(特に高いフレームレートのとき)。
sf::sleep の解像度は OS に依存してて、大体10~15ミリ秒です。 正確なタイミングは期待しないでね。
SFMLのウィンドウで「できること」「できないこと」を簡単にまとめておきます。
そんで、メインループで全部まとめて面倒みてもいいし、 ウィンドウごとに別スレッドにするのもアリです(ただし……下記参照)。
ウィンドウごとにイベントループを実装するのを忘れないでね!
SFMLちゃんは、マルチモニターのことをよく知りません。 なので、ウィンドウがどのモニターに出現するかは、やってみてのお楽しみです。 フルスクリーンを2つ以上つくることもできません。 未来の SFMLちゃんの成長に乞うご期待。
これはですね、ほとんどの OSでそういう制限がありまして、イベントループ(つまり pollEvent関数 or waitEvent関数) は、そのウィンドウを作ったスレッドで実行してあげる必要があります。 たとえば、イベントハンドリング専用のスレッドを作る場合、 ウィンドウも、そのスレッドで作っておく必要があります。
スレッドを使って処理を分離したいときは、イベントハンドリングはメインスレッドに残しておいて、 他の処理(レンダリング、物理演算、ロジックなどなど)を別のスレッドに移動させるとよいです。
この実装方式は、次に説明するもう1つの制限事項とも相性がよいですよ。
残念ながら、そうなのです。
Mac OS X は、なんか、メインスレッド以外のところで ウィンドウを作ったりイベントをハンドリングしたりするのを、許してくれないのですね。
ウィンドウズさんはデスクトップより大きいサイズのウィンドウがお嫌いのようです。
「デスクトップより大きいサイズ」には、VideoMode::getDesktopMode()で作ったウィンドウも含まれます。 タイトルバーや境界線を含むとデスクトップよりちょっとだけ大きくなってしまう……。
そんで、メインループで全部まとめて面倒みてもいいし、 ウィンドウごとに別スレッドにするのもアリです(ただし……下記参照)。
ウィンドウごとにイベントループを実装するのを忘れないでね!
SFMLちゃんは、マルチモニターのことをよく知りません。 なので、ウィンドウがどのモニターに出現するかは、やってみてのお楽しみです。 フルスクリーンを2つ以上つくることもできません。 未来の SFMLちゃんの成長に乞うご期待。
これはですね、ほとんどの OSでそういう制限がありまして、イベントループ(つまり pollEvent関数 or waitEvent関数) は、そのウィンドウを作ったスレッドで実行してあげる必要があります。 たとえば、イベントハンドリング専用のスレッドを作る場合、 ウィンドウも、そのスレッドで作っておく必要があります。
スレッドを使って処理を分離したいときは、イベントハンドリングはメインスレッドに残しておいて、 他の処理(レンダリング、物理演算、ロジックなどなど)を別のスレッドに移動させるとよいです。
この実装方式は、次に説明するもう1つの制限事項とも相性がよいですよ。
残念ながら、そうなのです。
Mac OS X は、なんか、メインスレッド以外のところで ウィンドウを作ったりイベントをハンドリングしたりするのを、許してくれないのですね。
ウィンドウズさんはデスクトップより大きいサイズのウィンドウがお嫌いのようです。
「デスクトップより大きいサイズ」には、VideoMode::getDesktopMode()で作ったウィンドウも含まれます。 タイトルバーや境界線を含むとデスクトップよりちょっとだけ大きくなってしまう……。