Linux-Based Gaming Handheld To Rely On Low Material Cost, Indie Apps

dartttt writes "Robert Pelloni and his team are working to develop an indie handheld gaming console, the 'nD,' which will run a number of indie games. The device will support 2D games only, and will run a custom-developed, embedded Linux firmware. It will have its own Game Store, which will allow users to download games. The SDK will be released soon, and is based on open source gaming standard SDL. Developers are being told that they can actually start making and compiling games on Windows, Mac and Linux using a 320x240 resolution."

SDL... :(

[Prune]

It's unfortunate that a library as bloated and weakly optimized as SDL is becoming a "standard". I started using it a few years back and then, after I was not happy with the performance, I looked at the source and noticed gems such as, under Windows the fact that SDL_SemWait() was always calling WaitForSingleObject() (which is every time a kernel call with huge switching overhead) and had no atomic read-write-modify fast-path. I'm reminded of a comment on gamedev.net by someone that "SDL killed my parents" and it struck a note of harmony with me despite the overdramatization. Look, if one is writing for games, one should be striving for efficiency. SDL is too big and tries to do everything; jack of all trades and master of none. For example, instead of using an SDL event queue, you should be using a lock-free, cache-optimized queue such as https://sourceforge.net/projects/mc-fastflow/ [sourceforge.net] Similar points go for other areas of the framework. The best policy is to find the best libraries to use for each domain within your project. Here's a fantastic highly optimized math library for games, for example: http://www.cmldev.net/ [cmldev.net] For some areas, it may even make sense to roll your own, such as writing custom synchronization primitives which can beat what's provided by the OS/threading libraries: see http://locklessinc.com/articles/ [locklessinc.com]

Re:SDL... :(

[gman003]

Here's the thing - SDL is easy. It's easy to pick up, easy to use, and easy to debug. And, surprisingly, most indie games don't stress the hardware to anything resembling a limit. Even the 3D ones - my two-year old laptop can max out Magicka. So optimization isn't usually a problem.

Sure, if you find that it is too slow, using something more optimal, or even rolling your own, might make sense. But what was it someone once said? Is not premature optimization the root of all evil?

Re:SDL... :(

[elucido]

Here's the thing - SDL is easy. It's easy to pick up, easy to use, and easy to debug. And, surprisingly, most indie games don't stress the hardware to anything resembling a limit. Even the 3D ones - my two-year old laptop can max out Magicka. So optimization isn't usually a problem.

Sure, if you find that it is too slow, using something more optimal, or even rolling your own, might make sense. But what was it someone once said? Is not premature optimization the root of all evil?

Ease of use is more important than optimization for indie games. If a programmer has years of experience making games why wouldn't they just make games for the PC or for something else? But when a programmer is just starting out the last thing they will want is to have to deal with assembly and all the hardcore shit. What is more important is that the indie games are fun, the frame rates can be optimized in the sequel.

The kit should make developing games as easy as possible because if one thing has changed since the 1980s golden era of game development its that the process has become so goddamn complicated that you need 20 or 30 experienced programmers to write a decent game while in the 1980s you only needed one programmer. We need to go back to only needing one programmer to write the entire game, and we need to make the graphics engines as templates which can be reused by many different linux developers which means BSD license.