StealthBagel
Member
- Joined
- Oct 17, 2007
- Messages
- 251
I'd like to take this topic to voice a few concerns and suggestions I've had for Pandora's design. While I think the whole project is moving in a positive direction there's a few features that could really improve final professional appeal and well rounded nature of the finished product, with regard to usability and how it comes across to the consumer and not just the enthusiast... in addition to the experience it gives the developer.
So without further ado here they are, in no particular order.
1. The SDK released with the gp2x was pretty unimpressive overall... the site showed, and still does what look like 3d model editors, sprite editors, and an IDE.... what people really got if anything was a CD with just a basic set of standard ARM linux platform libraries and a compiler/linker set. The site also offered 'source code and guides to getting started' which were never provided... A community member (paeryn) had to create an SDL lib accelerated for the 2x hardware. This should NOT be the case with Pandora. Out of the box aspiring developers should be provided (either with the unit or online somewhere) all libs needed to develop for the hardware with full acceleration in mind. In particular there should be libraries to take advantage of the PowerVR graphics hardware in the unit and not rely in any way on the kindness of random strangers to make the development process as painless as possible.
2. The 2x had some issues that made it come across more like a toy than a serious handheld... examples, the consumer had to buy new batteries, and a power brick, and a charger at their own expense to make a truly functional unit to the extent of say a DS or PSP or other professionally built handheld. Compounded with no battery springs, the inability to use off the shelf alkaline AAs and no instruction manual to explain these confusing aspects of the design. Anything that can be done to make Pandora a product that can be used to its fullest right out of the box, and present itself as a truly polished machine rather than a "gift to the homebrew scene" with forgivable flaws.
3. This ties into #1 above... honesty to the consumer is critical. The gp2x has been sold with invalid specs for a long time now, like haphazardly changing the rated CPU speed from 200 to 240 to 270 MHz and back when users couldn't achieve those speeds, or claiming 5-10 hours on 2 AAs when in actuality around 3-4 hours is far more common even with high end NiMH AAs and a good charger. I noted the Pandora specs listing RAM in Gigabits, not Megabytes, which is not a convention for any portable device (the only real places I see 'bit' used in marketing a product is in ISP transmission speed or those GBA flash carts which are of questionable legal nature to begin with.) It deceives the customer into thinking they're getting more than they are and is absolutely the wrong approach. I see this info was pulled and hopefully such events don't repeat themselves with this new handheld.
4. The use of 'real d-pads' is a very positive step and I'm thrilled to see it. While I think the positioning of the analog sticks could be better I don't see myself using them. However I must ask why a cross-shaped D-Pad would be used instead of something round. Games that rely on heavy diagnol use, especially shooters, are difficult to play with a d-pad designed for only the 4 cardinal directions. Something more similar to the circular d-pad used on the Sega MegaDrive/Genesis controllers might provide a more versatile surface for a wider range of games. What this system can run will be an enormous selection, so why let the controls limit that?
And that is the end of my little list... hopefully someone associated with the project will find them interesting and take them into consideration. Thanks
So without further ado here they are, in no particular order.
1. The SDK released with the gp2x was pretty unimpressive overall... the site showed, and still does what look like 3d model editors, sprite editors, and an IDE.... what people really got if anything was a CD with just a basic set of standard ARM linux platform libraries and a compiler/linker set. The site also offered 'source code and guides to getting started' which were never provided... A community member (paeryn) had to create an SDL lib accelerated for the 2x hardware. This should NOT be the case with Pandora. Out of the box aspiring developers should be provided (either with the unit or online somewhere) all libs needed to develop for the hardware with full acceleration in mind. In particular there should be libraries to take advantage of the PowerVR graphics hardware in the unit and not rely in any way on the kindness of random strangers to make the development process as painless as possible.
2. The 2x had some issues that made it come across more like a toy than a serious handheld... examples, the consumer had to buy new batteries, and a power brick, and a charger at their own expense to make a truly functional unit to the extent of say a DS or PSP or other professionally built handheld. Compounded with no battery springs, the inability to use off the shelf alkaline AAs and no instruction manual to explain these confusing aspects of the design. Anything that can be done to make Pandora a product that can be used to its fullest right out of the box, and present itself as a truly polished machine rather than a "gift to the homebrew scene" with forgivable flaws.
3. This ties into #1 above... honesty to the consumer is critical. The gp2x has been sold with invalid specs for a long time now, like haphazardly changing the rated CPU speed from 200 to 240 to 270 MHz and back when users couldn't achieve those speeds, or claiming 5-10 hours on 2 AAs when in actuality around 3-4 hours is far more common even with high end NiMH AAs and a good charger. I noted the Pandora specs listing RAM in Gigabits, not Megabytes, which is not a convention for any portable device (the only real places I see 'bit' used in marketing a product is in ISP transmission speed or those GBA flash carts which are of questionable legal nature to begin with.) It deceives the customer into thinking they're getting more than they are and is absolutely the wrong approach. I see this info was pulled and hopefully such events don't repeat themselves with this new handheld.
4. The use of 'real d-pads' is a very positive step and I'm thrilled to see it. While I think the positioning of the analog sticks could be better I don't see myself using them. However I must ask why a cross-shaped D-Pad would be used instead of something round. Games that rely on heavy diagnol use, especially shooters, are difficult to play with a d-pad designed for only the 4 cardinal directions. Something more similar to the circular d-pad used on the Sega MegaDrive/Genesis controllers might provide a more versatile surface for a wider range of games. What this system can run will be an enormous selection, so why let the controls limit that?
And that is the end of my little list... hopefully someone associated with the project will find them interesting and take them into consideration. Thanks