Yuniframeで採用したいプラットフォーム抽象化ライブラリのメモ
今のところWebGL-Native活動で使ってるのはSDL一本だけど、世間的なサービスとしては様々なプラットフォーム抽象化ライブラリを実運用してフィードバックしたい。
Yunibase( https://github.com/okuoku/yunibase/ )では大量のScheme処理系を毎週テストして必要に応じてバグ起票しているのでそういう感じに。
SDL
- デスクトップ: Windows、Mac、X11、Wayland
 - モバイル: Android、iOS
 - その他: WinRT(XboxOne)、Emscripten、RaspberryPi(KMS)
 
まぁ説明不要だよね。イベントシステムが非効率なのとオーディオが2chしかないのが欠点と言えば欠点か。
SFML
- API: C++
 - デスクトップ: Windows、Linux、Mac
 - モバイル: Android、iOS
 
いわゆるOpenALを統合しているのが珍しい。ただしそのために一部プラットフォームではLGPLなライブラリを抱えることになる。また ライブラリのバイナリ配布に依存 している。LGPLを一緒に配布していないため、LGPL要件を満たしていない可能性が高い。
公式のCバインディング有。
GLFW
- API: C
 - デスクトップ: Windows、Mac、Linux、Cygwin
 - その他: (Emscripten -- 専用品が付属)
 
SDLやSFML等と違い、オーディオや画像読み込み等は付属してこない。OpenGLやVulkanを使ったGUIアプリ + ゲームパッド入力に必要な最低限の抽象化のみ提供する。GLにAPIが似ていてコーディングの制約も少いので割と人気がある。
GLFM
- 
API: C
 - 
モバイル: iOS、Android
 - 
その他: Emscripten
 
基本的にはGLFMのモバイル版といった赴きで、提供している機能セットも近い。ソースコードも各プラットフォームで1個づつと非常にシンプル。
Sokol
- API: C
 - デスクトップ: Windows、Mac、X11
 - モバイル: iOS、Android
 - その他: Emscripten、WinRT?
 
Cのヘッダとして実装されている。オーディオの統合を持っていたりと機能的にも充実している。
SFMLはまぁ良いかな。。
My main reason for porting to SDL was my engine’s preservation and future.
開発の方向性自体がちょっと怪しいというのもある。例えば:
MessageBoxのような細かいUIも却下してしまっている。
そもそもOpenGL ES自体も標準なので、まずは標準ベースのプログラミングを行える環境を提供するOS wrapperにフォーカスしましょうということで。。SDL、GLFW、GLFM、Sokolが残ることになる。SFMLは、OpenFrameworks https://github.com/openframeworks/openFrameworks とかThe Forge https://github.com/ConfettiFX/The-Forge とかraylib https://github.com/raysan5/raylib のような自前の描画抽象化を持っているライブラリの枠に入れた方が良いだろう。
TinyWindow
Macが無いな。。