Slashdot Mirror
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."
Maybe this one won't eat batteries...
It consists of a 4 x 13 orthogonal matrix of 2d symbolic tokens. With these, one can play an almost limitless variety of games - even 3D ones! People are free to develop their own games. No batteries or source of electricity needed, it runs off of mechanical energy provided by the player(s). It can be produced for less than $1, with very low tech (no chip fab needed).
I call it "cards."
"National Security is the chief cause of national insecurity." - Celine's First Law
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/ 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/ 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/
"Politicians and diapers must be changed often, and for the same reason."
We can only hope that this device or a different version of it gets a small GPIO connector for the connection of external sensors, devices, etc. With a $10 device with display and a 400 MHz cpu is really incredible in my opinion. After looking into Arduino, Beagleboard and similar inexpensive and relatively easy to program and use boards I am still looking for something that already comes in a case, is more powerful than an AVR and has a builtin display.
Almost all test and measurement devices that I currently use in our research laboratory have much less computing power which limits their capabilities and increase their price quite a bit. A couple of years ago developing embedded applications looked like black magic to me, fiddling around to save a few bytes, using a lot of tricks to get it done somehow but today you can easily throw a much more powerful processor at the problem and instead of tuning you can just program in whatever language you like and it will probably be fast enough.
If they can keep up to their announced sales price I will order a couple as nice presents another couple to take apart.
...anything Robert Pelloni says.... :)
"One day you will be able to hurt your smart phone's feelings." - Mahhshall
Will it be possible to buy one of these without having to go online? A lot of kids' parents won't let the kids spend their allowance online; they have to spend it in a local brick-and-mortar store because only a local brick-and-mortar store takes cash.
It's all about volume, not portability (Smartphones are a bad example to compare to because the prices are artificially inflated to prop up the scummy cell business model).
Near as I figure it, they kitchen-sinked the engineering of the thing with all the wizz-bang features of 8 years ago, then took too long in getting it out, so now it's just a another portable game system that costs more than any two of its competitors. Combine that with the lack of big-title support, the ever-increasing smartphone saturation and, in some cases, memory of the nightmarishly bad hardware used in its spiritual predecessor (GP2X), and you end up with not a bang for the buck as a gaming machine.
Failing that, you can look at the handheld computer angle of it. Again, the price is too high, and for many of the same reasons: the pocket-sized IM, SSH client, email-checker, VLC remote, etc... All filled better by smartphones now. If Pandora could beat them on price, they might have something (although it would be a hard sell since that would still put it up against the iPod Touch), but clearly, they can't.
So their target market is pretty much shorn down to the geek who has the disposable income to afford one, the desire for a conversation piece/genital extension, and the lack of creativity to come up with anything better to do with that $500.
The GP2X had 2x200 MHz chips and the SNES emu on that was a disaster.
The Super NES has two CPUs that need to be kept in cycle-for-cycle sync all the time, or some games will fail. (Back then, synchronization was more primitive than modern mutexes.) Some games even used a third CPU on the cartridge. But in a native game, all the game logic can be compiled to native code or at least to JITable bytecode. Nor do native SDL games need to emulate the weird bit-planar tile format that Super NES games use. Answer me this: How many MHz did the original StarCraft need?
Unless this offers something my smartphone doesn't (incredible battery life, better games, etc) there's no way it is going to end up being carried around with me. Which means its not going to work as a mobile gaming platform.
I like the prospect of an open gaming platform as much as the next guy, but unless you get a decent market onboard it is going nowhere.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
May I suggest the Dingoo A320? It's cheap, it's powerful enough for 2D games, it can run Linux and it is actually available. Or if you want something more powerful but also more expensive, the Caanoo.
The nD looks nice on paper, but if you've followed the Pandora story you'll know it's far from easy to get a device produced, especially if you've never done such a thing before. Also the $10 price point does not sound very realistic to me.
Please note that this gentleman is probably not entirely sincere. He's been running a hoax about "Bob's Game" for years now. It's pretty entertaining stuff, intended as entertainment rather than deception, but it would be foolish to assume that he's got any plans to actually follow through on creating this handheld.
SDL is actually pretty modular. You can tell SDL_Init() which subsystems you want to use. For example, you could use SDL for video and input, use libao for audio and use pthreads for threading.
"From my experience, I noticed, that nearly 100% of those things called "framework", are things that should be avoided. Works for me."
Works for you how, exactly? Not for writing games without any "framework", I'd wager.
You don't know what you're talking about. SDL provides only pretty low-level stuff - blitting, an event queue, joystick support etc. And you only init the things you use. If you want drawing primitives or text, you need separate libraries. Contrary to what the prune says, SDL is very well suited for its purpose (cross-platform, mostly 2d games), as it's popularity suggests.
Sam Lantinga, the architect and maintainer of SDL, was lead software engineer on a little game called World of Warcraft. I kind of trust the most senior person in the open source gaming world to know what he's doing.
xkcd is not in the sudoers file. This incident will be reported.