5 ms·

I do not recommend learning the Windows API. There are convenient crossplatform alternatives to it for this use-case.

by partycoder 9y ago

deleted 9y ago
[deleted]
nice_byte 9y ago
It's software rendering, whether the implementation uses winapi or something else is irrelevant.
- longhairedhippy 9y ago
  Using something else does potentially widen the audience. Being able to compile/run on a variety of platforms alone has value.
chii 9y ago
There's no harm in using/coding against the windows api, provided that you know what's a windows api quirk vs what's normal coding idiom. Granted, beginners may not be able to differentiate, but that's due to inexperience, which will be fixed in time. There's nothing wrong with learning a platform.
- dkersten 9y ago
  > 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
  There's harm. It's called "vendor lock-in". https://en.wikipedia.org/wiki/Vendor_lock-in https://en.wikipedia.org/wiki/Vendor_lock-in Windows API is carefully designed to maximize costs of switching to another platform. Every single thing is different to every other OS.
  - daemin 9y ago
    I don't buy that argument. Each platform has similar but different functions for doing all common things, the graphics API's are converging on a similar design as well. To make it clear, the main platforms for more AAA-like titles are Windows/PC, PS4, XboxOne, and now the Switch. The main platforms on mobile are iOS and Android. Each of these requires an adaptation layer to be written because they are all different to each other, some more than others though. So you can "lock" yourself into one of these platforms, "lock" yourself into using an engine or existing library which covers some subset of those platforms, or write your own adaptation layer and engine. For learning and experimenting it's quite easy and convenient to focus on a particular platform, Windows/PC in this case is a good simple default since it's available and doesn't require NDAs, licensing, etc.
cabaalis 9y ago
I think the intention of this is to get closer to "on the metal" as a teaching tool of the math and low-level graphics rendering. Using SDL or others would abstract all that away.
lostgame 9y ago
Unfortunate this is downvoted so much. Especially from the perspective of the beginner there is much to be wasted by learning proprietary API’s.

I do not recommend learning the Windows API. There are convenient crossplatform alternatives to it for this use-case.

deleted 9y ago

[deleted]

nice_byte 9y ago

It's software rendering, whether the implementation uses winapi or something else is irrelevant.

longhairedhippy 9y ago
Using something else does potentially widen the audience. Being able to compile/run on a variety of platforms alone has value.

chii 9y ago

There's no harm in using/coding against the windows api, provided that you know what's a windows api quirk vs what's normal coding idiom. Granted, beginners may not be able to differentiate, but that's due to inexperience, which will be fixed in time. There's nothing wrong with learning a platform.

dkersten 9y ago
> 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
There's harm. It's called "vendor lock-in". https://en.wikipedia.org/wiki/Vendor_lock-in https://en.wikipedia.org/wiki/Vendor_lock-in Windows API is carefully designed to maximize costs of switching to another platform. Every single thing is different to every other OS.
- daemin 9y ago
  I don't buy that argument. Each platform has similar but different functions for doing all common things, the graphics API's are converging on a similar design as well. To make it clear, the main platforms for more AAA-like titles are Windows/PC, PS4, XboxOne, and now the Switch. The main platforms on mobile are iOS and Android. Each of these requires an adaptation layer to be written because they are all different to each other, some more than others though. So you can "lock" yourself into one of these platforms, "lock" yourself into using an engine or existing library which covers some subset of those platforms, or write your own adaptation layer and engine. For learning and experimenting it's quite easy and convenient to focus on a particular platform, Windows/PC in this case is a good simple default since it's available and doesn't require NDAs, licensing, etc.

cabaalis 9y ago

I think the intention of this is to get closer to "on the metal" as a teaching tool of the math and low-level graphics rendering. Using SDL or others would abstract all that away.

lostgame 9y ago

Unfortunate this is downvoted so much. Especially from the perspective of the beginner there is much to be wasted by learning proprietary API’s.