7 ms·

> There's no harm in using/coding against the windows api It needlessly restricts your platform though. For example, I was very interested in the handmade hero

> There's no harm in using/coding against the windows api It needlessly restricts your platform though. For example, I was very interested in the handmade hero tutorials linked elsewhere here, but was dismayed that the first few lessons are all windows api. I don't have a windows machine anymore, so I have no use for those lessons. I'm sure I can still learn from the later lessons, but I won't be able to simply follow along with his code. A significant number of people, especially people who would play Indie games, are now using macbooks nowadays. Maybe still not the windows gamers numbers, but enough that I wouldn't ignore it, and I've passed on quite a number of promising looking Indie games because they were windows only. Windows API is also notoriously clunky, at least, compared to the wrapper libraries. Obviously if you only have a windows machine, by all means, focus on making it work for that, but why put roadblocks in your way for potential future ports when nowadays you really don't have to because great cross platform abstractions exist (SDL2, GLFW, SMFL, ...) > There's nothing wrong with learning a platform. Sure. If that's your goal. If its just a means to an end, why not use a library to do the hard work so you can focus on what you actually want to do (and not locking you out of other platforms later without a ton of work is an added bonus).

quincunx 9y ago
http://store.steampowered.com/hwsurvey/ http://store.steampowered.com/hwsurvey/ Steam measures 98% Windows, 1.56% OSX.
- partycoder 9y ago
  To make it more even, add Google Play and App Store statistics. Google Play would be all Android software, which is Linux.
cturner 9y ago
"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.
ygra 9y ago
Honestly, though, it's not like the Windows API parts of those examples are clunky or hard to understand. It's extremely straightforward code (effectively probably just using parts of the Windows API that go back to 1985). The entry point simply creates the window and the WndProc callback handles a few window things (create, resize, close) and otherwise handles input and the game loop. From an educational standpoint I wouldn't see any harm in that code.
- partycoder 9y ago
  Well, you said it yourself. "WndProc". These abbreviations is something you will see frequently and you will have to spend time memorizing them. Better identifiers are possible. e.g: https://wiki.libsdl.org/SDL_CreateWindow https://wiki.libsdl.org/SDL_CreateWindow . CreateWindow, not "WndProc" or some ambiguous abbreviation. If you want to turn your job into playing hangman all day and guess what the hell the actual abbreviated words are, use the Windows API.
  - Tobba_ 9y ago
    If almost your entire userbase is running Windows you're gonna end up needing to deal with it anyways, one way or another. You can at least be glad to be dealing with Win32, which other than user32 (which is a bit crazy for compatibility reasons, though I'm not sure if X11 is much better) is actually far more reasonable than it's contemporaries. Compare doing fast async file I/O on Win32 vs POSIX. On Win32 it just boils down to creating an IOCP pipe, creating some worker threads, setting up the file handles and using the right flags in read/write calls. It's a bit obtuse, but the code that does it ends up reasonable, and it's the same drill for sockets. Doing that on POSIX? You get blocking, uncancelable I/O calls and threads to work with, that's it. Good luck, though the documentation involved is far simpler (or just use something like libuv if you value your sanity). Using a library here would be preferable, but I really don't see why using Win32 would be the problem and not the fact that it's non-portable.
    - partycoder 9y ago
      Yes, you can use libuv. It's a crossplatform async I/O, with a sane API. Then, guess what: Android, iOS, macOS, Linux, BSD... all of them are in some way or another, similar at the low level. Windows API is unique, like TempleOS. But even the TempleOS API makes more sense, is more consistent and is better thought than the Windows API.
animal531 9y ago
Let's see, we'll use Steam stats for October 2017 as reference. Windows: 98.04% OSX: 1.56% Linux: 0.32% That's not a significant number in the least. Now the numbers may be skewed by developers vs players, mobile vs desktop etc, and yet even then it's still not worthwhile in general. As to the 2nd part, I far more agree with that. There's no reason not to use SDL. But by that metric you should be using Unity/Unreal etc. anyway, unless if your focus is really on becoming an engine programmer.
- partycoder 9y ago
  And the reason for this is because back in the day, in 2003, Microsoft ran a Fear/Uncertainty/Doubt (FUD for short) campaign mostly based on false claims, such as that OpenGL would be put behind a compatibility layer with a significant performance cost. Simultaneously, Microsoft left the OpenGL Architecture Review Board giving a strong signal they were not supporting OpenGL anymore. Everyone freaked out and moved to Direct3D. http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-an... http://chrishecker.com/images/3/33/Gdmogl.pdf http://chrishecker.com/images/3/33/Gdmogl.pdf Despite the technical differences, if you think this is morable acceptable, by all means do you all your development on Windows. Allow someone else to build a monopoly with no real gain for you.
  - animal531 9y ago
    I've never bothered to seriously use DirectX, I've always used some flavour of OpenGL (quite successfully on Windows). But speaking for other devs, a long time ago DirectX was indeed really crap. It took for example 16+ pages of code just to initialise. But in later iterations MS did a lot of work to clean it up and improve it and its performance, which is a large contributing factor as to why people started using it (along with of course having to deal with countless OpenGL extensions, which became a really tiring exercise). Again I'm with you, I dislike the modern Microsoft practice of tying specific DX versions to specific OS versions, in trying to force people to upgrade. Sadly the solution to the problem isn't either of OSX or Linux. Apple is too closed off and expensive in general, and Linux perhaps too abstract to be bothered with by the average gamer.
Tobba_ 9y ago
For the purposes of gamedev; Windows, consoles and possibly Mac are the only platforms are the only platforms that absolutely matter. If it runs on Linux, that's nice, but if it doesn't run on some common buggy setup you aren't going to see a response beyond "fix your machine". For Windows users you would see crazy workarounds (i.e API hooking) being broken out real fast. Nothing beyond a simple 2D indie game would consider Linux support more than a non-critical "bonus" feature. You'll also find that people who work on high-performance games (i.e complex 3D) are pretty allergic to using existing libraries, and while it would make sense to use SDL in an example project like this, it's not unreasonable for someone to default to the "proper" way. Beyond things like the basic GL loader, linear algebra and font loading / text rendering libraries, anything that's available is almost guaranteed to be woefully insufficient, more effort than it's worth or loses you too much control. Not to mention you'll inevitably wind up with your own library that provides an equivalent of half the C++ std (even if most of it is implemented using the normal std), which often makes using anything that depends on the usual C++ std pretty painful. For the above reasons, things like SDL or even libev/Boost.ASIO would only be considered suitable for toys. I can't say I'm too happy about having to re-implement things that have already been written a thousand times over already though.
- deleted 9y ago
  [deleted]
- partycoder 9y ago
  Maybe in 2009 but now you've got also iOS and Android. Android is technically Linux, with a lot of APIs built on top of it. Windows on phones is no longer a thing and phone games are a significant market. Plus, people use Android more than they use Windows.

quincunx 9y ago

http://store.steampowered.com/hwsurvey/ http://store.steampowered.com/hwsurvey/ Steam measures 98% Windows, 1.56% OSX.

partycoder 9y ago
To make it more even, add Google Play and App Store statistics. Google Play would be all Android software, which is Linux.

cturner 9y ago

"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.

ygra 9y ago

Honestly, though, it's not like the Windows API parts of those examples are clunky or hard to understand. It's extremely straightforward code (effectively probably just using parts of the Windows API that go back to 1985). The entry point simply creates the window and the WndProc callback handles a few window things (create, resize, close) and otherwise handles input and the game loop. From an educational standpoint I wouldn't see any harm in that code.

partycoder 9y ago
Well, you said it yourself. "WndProc". These abbreviations is something you will see frequently and you will have to spend time memorizing them. Better identifiers are possible. e.g: https://wiki.libsdl.org/SDL_CreateWindow https://wiki.libsdl.org/SDL_CreateWindow . CreateWindow, not "WndProc" or some ambiguous abbreviation. If you want to turn your job into playing hangman all day and guess what the hell the actual abbreviated words are, use the Windows API.
- Tobba_ 9y ago
  If almost your entire userbase is running Windows you're gonna end up needing to deal with it anyways, one way or another. You can at least be glad to be dealing with Win32, which other than user32 (which is a bit crazy for compatibility reasons, though I'm not sure if X11 is much better) is actually far more reasonable than it's contemporaries. Compare doing fast async file I/O on Win32 vs POSIX. On Win32 it just boils down to creating an IOCP pipe, creating some worker threads, setting up the file handles and using the right flags in read/write calls. It's a bit obtuse, but the code that does it ends up reasonable, and it's the same drill for sockets. Doing that on POSIX? You get blocking, uncancelable I/O calls and threads to work with, that's it. Good luck, though the documentation involved is far simpler (or just use something like libuv if you value your sanity). Using a library here would be preferable, but I really don't see why using Win32 would be the problem and not the fact that it's non-portable.
  - partycoder 9y ago
    Yes, you can use libuv. It's a crossplatform async I/O, with a sane API. Then, guess what: Android, iOS, macOS, Linux, BSD... all of them are in some way or another, similar at the low level. Windows API is unique, like TempleOS. But even the TempleOS API makes more sense, is more consistent and is better thought than the Windows API.

animal531 9y ago

Let's see, we'll use Steam stats for October 2017 as reference. Windows: 98.04% OSX: 1.56% Linux: 0.32% That's not a significant number in the least. Now the numbers may be skewed by developers vs players, mobile vs desktop etc, and yet even then it's still not worthwhile in general. As to the 2nd part, I far more agree with that. There's no reason not to use SDL. But by that metric you should be using Unity/Unreal etc. anyway, unless if your focus is really on becoming an engine programmer.

partycoder 9y ago
And the reason for this is because back in the day, in 2003, Microsoft ran a Fear/Uncertainty/Doubt (FUD for short) campaign mostly based on false claims, such as that OpenGL would be put behind a compatibility layer with a significant performance cost. Simultaneously, Microsoft left the OpenGL Architecture Review Board giving a strong signal they were not supporting OpenGL anymore. Everyone freaked out and moved to Direct3D. http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-an... http://chrishecker.com/images/3/33/Gdmogl.pdf http://chrishecker.com/images/3/33/Gdmogl.pdf Despite the technical differences, if you think this is morable acceptable, by all means do you all your development on Windows. Allow someone else to build a monopoly with no real gain for you.
- animal531 9y ago
  I've never bothered to seriously use DirectX, I've always used some flavour of OpenGL (quite successfully on Windows). But speaking for other devs, a long time ago DirectX was indeed really crap. It took for example 16+ pages of code just to initialise. But in later iterations MS did a lot of work to clean it up and improve it and its performance, which is a large contributing factor as to why people started using it (along with of course having to deal with countless OpenGL extensions, which became a really tiring exercise). Again I'm with you, I dislike the modern Microsoft practice of tying specific DX versions to specific OS versions, in trying to force people to upgrade. Sadly the solution to the problem isn't either of OSX or Linux. Apple is too closed off and expensive in general, and Linux perhaps too abstract to be bothered with by the average gamer.

Tobba_ 9y ago

For the purposes of gamedev; Windows, consoles and possibly Mac are the only platforms are the only platforms that absolutely matter. If it runs on Linux, that's nice, but if it doesn't run on some common buggy setup you aren't going to see a response beyond "fix your machine". For Windows users you would see crazy workarounds (i.e API hooking) being broken out real fast. Nothing beyond a simple 2D indie game would consider Linux support more than a non-critical "bonus" feature. You'll also find that people who work on high-performance games (i.e complex 3D) are pretty allergic to using existing libraries, and while it would make sense to use SDL in an example project like this, it's not unreasonable for someone to default to the "proper" way. Beyond things like the basic GL loader, linear algebra and font loading / text rendering libraries, anything that's available is almost guaranteed to be woefully insufficient, more effort than it's worth or loses you too much control. Not to mention you'll inevitably wind up with your own library that provides an equivalent of half the C++ std (even if most of it is implemented using the normal std), which often makes using anything that depends on the usual C++ std pretty painful. For the above reasons, things like SDL or even libev/Boost.ASIO would only be considered suitable for toys. I can't say I'm too happy about having to re-implement things that have already been written a thousand times over already though.

deleted 9y ago
[deleted]
partycoder 9y ago
Maybe in 2009 but now you've got also iOS and Android. Android is technically Linux, with a lot of APIs built on top of it. Windows on phones is no longer a thing and phone games are a significant market. Plus, people use Android more than they use Windows.