Game Development with SDL 2.0 (Steam Dev Days 2014)
Steamworks Development1 HN recommenders · 2015–2020
235K views · talk · dated · Uploaded 2014-02-11
Ryan Gordon (Icculus) gives a high-level overview of SDL 2.0 at Steam Dev Days 2014. He covers its features and how it eases building, porting and maintaining games, including Linux ports.
HN commenters link it when people ask about cross-platform game development and for details like SDL's licensing change.
47:18The Tragedy of systemd
linux.conf.au
1:04:04Overwatch Gameplay Architecture and Netcode
GDC Festival of Gaming
45:35The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013)
Mladen Mijatov
42:30RustConf 2018 - Closing Keynote - Using Rust For Game Development by Catherine West
Rust Programming Language
1:10:00A Deep Dive into Nanite Virtualized Geometry
SIGGRAPH Advances in Real-Time Rendering
31:37How Crash Bandicoot Hacked The Original Playstation | War Stories | Ars Technica
Ars Technica
1:04:04LISA11 - Fork Yeah! The Rise and Development of illumos
USENIX
1:10:15Tech Talk: Linus Torvalds on git
Google
4 comments from Hacker News
SDL. It is solidly cross-platform (supports Haiku, which makes me smile, as well as Linux, Win, iOS, Android and so on and so on) and zLib licensed (pay nothing; use it, distribute it, static link, dynamic link, whatever you want - the zLib licence fits on a postcard). Here's someone talking about it at a steam dev day: [VIDEO]
Most of those ports are being done by one lone developer named Ryan C. Gordon who runs icculus.org Here's a talk he did about porting games to Linux with SDL 2.0 during a Steam Dev Days event: [VIDEO] One interesting thing to note is that most of those Linux ports can only be purchased through a Humble Bundle. (Playdead's Limbo is a case in point.) It goes without saying that the grand majority of those ports would have never happened if it weren't for Humble Bundle in the first place.
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. ( [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: [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).