Game Development with SDL 2.0 (Steam Dev Days 2014)

This is a cool project! - CMake, yay! These make generating build files for a variety of platforms (even Windows) a breeze. It also works with code completion stuff (CLion IDE, KDevelop both have CMake-based projects) - I like how it splits stuff up as well ( [link] ). - As for vendorizing SDL2, there is an opportunity for optimization: The shared libraries and header files can be scanned through CMake scripts. Example: [link] . - I see the .clang-format file, nice! (This is for clang-format: [link] ) Unfortunately, license is going to be a real barrier to most game developers. The ironic thing is this engine includes SDL 2 which prides itself on being on a permissive license. ( [this video] , 6:40 to 7:30) If it's the intention to create an open source library to be helpful as possible to developers. If it's the intention to have a library just for use in the GPL ecosystem of games (which isn't bad: OpenTTD is GPL!) then this is okay. The reason why is a private game developer want to retain control of their intellectual property, even throughout the prototyping phase. As for open sourcing, I'd approach it in a different way: I'd release reusable components under a permissive license (e.g. MIT, BSD, ISC, zlib, etc.) and keep any creative work product code/source files private. Similar SDL2 framework for 2D games (I made some CMake contributions a while back): [link]

Incredible! The sphinx docs look great. Also, the logo! Not to mention, the translations: - [link] - [link] - [link] One reason of why I wouldn't use it yet: LGPL. This is the issue pygame had when I tried it. The license made it very difficult to incorporate and use in practice, and I ended up playing with kivy instead ( [link] ). The reasons why: 1. Writing anything commercial would be a gamble. I've wrote at length on why this license isn't meant for scripting languages, but even if it's a compiled language, SDL moved away from LGPL here: [this video] . 2. LGPL and scripting languages just don't work from an open source perspective. It's not copy-paste and vendorize friendly. Functions can't be copied a la carte. I'd rather write something from scratch than link an LGPL library in one of my MIT licensed projects. I'm just not willing to open downstream users to the risk. What ends up happening is 5/10 years on, someone ends up writing a new MIT/BSD library to get around a viral one (e.g. GCC -> Clang/LLVM).