5 ms·

"It needlessly restricts your platform though" Not necessarily. Casey discusses this issue well into his series, but it would be twenty or thirty hours in. Th

"It needlessly restricts your platform though" Not necessarily. Casey discusses this issue well into his series, but it would be twenty or thirty hours in. There are two general approaches to multiplatform. Approach 1: the SDL way. Have an abstract system that represents a generic desktop environment (e.g. QT suite). Build your apps into that. The upside of this is that you can build once, run everywhere. Some downsides are that it will not necessarily feel like it fit into the ecosystem, and you need to learn an abstract platform. That platform may have license overhead. When they do version upgrades, you might not like what they do, but you are stuck with them. Approach 2: native wrappers. Build your codebase in generic C/C++. Then write endpoints interface wrappers for each platform you deliver to. In this case, you could create a Windows codebase that #includes your game code, and calls into it from WinAPI. For linux, you can create a ncurses or GTK frontend, and then #include into the samre game codebase. Your product will feel like it was built for your target platform. Yes, you need to learn platform-specific ways of doing things. But once you have, your end-users get native feel. If you want to call a Windows voice API for the Windows version of your product, you can do it without depending on a vendor. If you were building a forms application, Approach 2 would be painful. But if you are building a game, Approach 2 is viable. You probably need a single-window wrapper. It would need to have a menu system, to be able to display an image, and to be able to consume keystrokes and mouse events. I don't have much audio experience, but the little experience I have is that the moment you want to do something remotely sophisticated with audio (e.g. creating a music sequencer) you want to be working against native APIs. I would rather build something from first principles on a robust system API than debug bizarre threading behaviour in the SDL mixer library.

partycoder 9y ago
No, on Windows, SDL will interface directly with the Windows API, not GTK or Qt. And will give you a native window, the same as if you do it by hand. Proof: http://hg.libsdl.org/SDL/file/35da714ed287/src/core/windows http://hg.libsdl.org/SDL/file/35da714ed287/src/core/windows If you don't like SDL that is your opinion or choice, but don't come here presenting false facts to influence other people into having your same preferences (e.g: over half of what you said was technically incorrect and not true). You should really do 1 minute of research before making ill-intentioned accusations like these. Strictly speaking, SDL does all the Windows API boilerplate for you. And also does it on macOS, and on Linux with no substantial cost since SDL itself is very lightweight. It also does more stuff for you, like loading fonts, images, sounds, etc... and again, in a crossplatform manner. All of this was provided to the community as open source, for free. Sam Lantinga is a hero. If you don't like a specific part of SDL or whatever project, find an alternative project, submit a bug report, submit a fix, or fork it. That benefits everyone. That's how open source works.
- cturner 9y ago
  I introduced Qt because it is an example of a high-quality, full-system framework that you can chose to live in. I did not mean to imply that SDL used Qt, but I can see how it reads that way. When I was following Handmade Hero, some of the fanbase were maintaining a linux version of the project in SDL, and moving them forward at the same pace as Casey's project. > It also does more stuff for you, like loading > fonts, images, sounds, etc... and again, in > a crossplatform manner. I found it to be awkward for audio. When you pick a library, it can steer the direction of your software. You can end up having to do things the library-way instead of the you-way. As a general rule, the more the library does for you, the more likely this is to happen. This is going back a bit, but I remember SDL media having background threads. If you let SDL draw you into a multithreaded approach, you would lose tuning options you might need later, because you would not be able to reason cache behaviour. > If you don't like a specific part of SDL or > whatever project, find an alternative project Through your forceful words, here and elsewhere, I get the impression that you think that this is the "one true approach". But I think there is a respectable alternative: suck up the native-integration cost in order to forgo the dependency cost. Bedrock against the system where it is non-horrific to do so, in order to own your codebase. I don't think a hacker should have to apologise for choosing that approach.
  - partycoder 9y ago
    I respect if you wish to develop at a lower level, or use target only a specific platform. And I understand if you ran into issues with an open source library. I personally ran into multi-monitor issues with SFML in the past. Maybe it has been fixed now. But a different thing is to ask others to not use a project. Think that SDL is non-profit, ran by volunteer work mostly. In the past, cross-platform game development has been the target of many FUD campaigns so the tone is mostly out of frustration at this point. Then one point I didn't mention was licensing. Some open source projects may have licenses that are incompatible with a proprietary license. I think this was the case of SDL 1.x but SDL 2.0 uses the zlib license which is pretty compatible.
  - dkersten 9y ago
    I haven't used SDL for audio in many years, but most games nowadays use FMOD or Wwise and not platform native audio API's and they work just as well with SDL (or GLFW or whatever) as without. Both FMOD and Wwise offer a free version[1]. Note also, in case you're not already aware, that SDL 2 is quite a different beast than SDL 1.x and is much improved in many ways, although I can't speak for addon libraries (I don't know what SDL media is like, for example). [1] The free version of Wwise has a limit of 500 sounds and your budget must be under $150K; while FMOD is free as long as your budget under $500k and you can only publish one game a year under this license -- either way, both are financially accessible to Indies and both are free during evaluation/development.
dkersten 9y ago
SDL does allow you to grab the platform specific window handle (HWND on windows), so you can still do platform specific logic while letting SDL do the boilerplate for you. SDL_SysWMinfo info; #ifdef _WIN32 if(SDL_GetWindowWMInfo(window, &info)) { assert(info.subsystem == SDL_SYSWM_WINDOWS); HWND hwnd = win.window; HDC hdc = win.hdc; HINSTANCE hinstance = win.hinstance; ... } #endif

partycoder 9y ago

No, on Windows, SDL will interface directly with the Windows API, not GTK or Qt. And will give you a native window, the same as if you do it by hand. Proof: http://hg.libsdl.org/SDL/file/35da714ed287/src/core/windows http://hg.libsdl.org/SDL/file/35da714ed287/src/core/windows If you don't like SDL that is your opinion or choice, but don't come here presenting false facts to influence other people into having your same preferences (e.g: over half of what you said was technically incorrect and not true). You should really do 1 minute of research before making ill-intentioned accusations like these. Strictly speaking, SDL does all the Windows API boilerplate for you. And also does it on macOS, and on Linux with no substantial cost since SDL itself is very lightweight. It also does more stuff for you, like loading fonts, images, sounds, etc... and again, in a crossplatform manner. All of this was provided to the community as open source, for free. Sam Lantinga is a hero. If you don't like a specific part of SDL or whatever project, find an alternative project, submit a bug report, submit a fix, or fork it. That benefits everyone. That's how open source works.

cturner 9y ago
I introduced Qt because it is an example of a high-quality, full-system framework that you can chose to live in. I did not mean to imply that SDL used Qt, but I can see how it reads that way. When I was following Handmade Hero, some of the fanbase were maintaining a linux version of the project in SDL, and moving them forward at the same pace as Casey's project. > It also does more stuff for you, like loading > fonts, images, sounds, etc... and again, in > a crossplatform manner. I found it to be awkward for audio. When you pick a library, it can steer the direction of your software. You can end up having to do things the library-way instead of the you-way. As a general rule, the more the library does for you, the more likely this is to happen. This is going back a bit, but I remember SDL media having background threads. If you let SDL draw you into a multithreaded approach, you would lose tuning options you might need later, because you would not be able to reason cache behaviour. > If you don't like a specific part of SDL or > whatever project, find an alternative project Through your forceful words, here and elsewhere, I get the impression that you think that this is the "one true approach". But I think there is a respectable alternative: suck up the native-integration cost in order to forgo the dependency cost. Bedrock against the system where it is non-horrific to do so, in order to own your codebase. I don't think a hacker should have to apologise for choosing that approach.
- partycoder 9y ago
  I respect if you wish to develop at a lower level, or use target only a specific platform. And I understand if you ran into issues with an open source library. I personally ran into multi-monitor issues with SFML in the past. Maybe it has been fixed now. But a different thing is to ask others to not use a project. Think that SDL is non-profit, ran by volunteer work mostly. In the past, cross-platform game development has been the target of many FUD campaigns so the tone is mostly out of frustration at this point. Then one point I didn't mention was licensing. Some open source projects may have licenses that are incompatible with a proprietary license. I think this was the case of SDL 1.x but SDL 2.0 uses the zlib license which is pretty compatible.
- dkersten 9y ago
  I haven't used SDL for audio in many years, but most games nowadays use FMOD or Wwise and not platform native audio API's and they work just as well with SDL (or GLFW or whatever) as without. Both FMOD and Wwise offer a free version[1]. Note also, in case you're not already aware, that SDL 2 is quite a different beast than SDL 1.x and is much improved in many ways, although I can't speak for addon libraries (I don't know what SDL media is like, for example). [1] The free version of Wwise has a limit of 500 sounds and your budget must be under $150K; while FMOD is free as long as your budget under $500k and you can only publish one game a year under this license -- either way, both are financially accessible to Indies and both are free during evaluation/development.

dkersten 9y ago

SDL does allow you to grab the platform specific window handle (HWND on windows), so you can still do platform specific logic while letting SDL do the boilerplate for you. SDL_SysWMinfo info; #ifdef _WIN32 if(SDL_GetWindowWMInfo(window, &info)) { assert(info.subsystem == SDL_SYSWM_WINDOWS); HWND hwnd = win.window; HDC hdc = win.hdc; HINSTANCE hinstance = win.hinstance; ... } #endif