Pandora Software/sdk Suggestions, And Etc.


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 :)
 
Hey there, here's my take on your concerns:

1) I agree with you completely. A much more usable SDK is the plan. To be honest, right out of the box (no pun intended) the focus will likely be on providing a usable system you can start enjoying from day one and then a programmer's friendly guide will ramp up immediately following that. No one will be left in the dark and thankfully, this isn't a company that will ignore the people who use their hardware and just go off in pointless directions despite the obvious applications that need the most attention. Random strangers will be welcome to contribute but there will be organization to this chaos! :)

2) Good points, although no AA batteries apply here. Craig intends to have a suitable DC adapter included or at least a USB cable as Pandora can be charged via USB. As a customer, I would rather not have some crappy headphones included just to say they are there and up the cost though. How about you? Maybe keep the core pack with just the essentials? (like the PSP)

3) Yeah, I'd like specs to be completely honest myself. If I put 40 hours of MP3 playback on the box, then I better have several log files showing those results repeatedly occurring. As for the Gigabit thing, it's just a direct quote from the RAM datasheet. I wondered if people would get confused and I was corrected by Squidge who told me that it was okay for flash cartridge capacity, but not for RAM :)

4) Yeah, the Dpad isn't done. It is supposed to look more like a Sega Genesis with the circle built up and the dpad cross embedded into it but I think ED is still trying to change it without wrecking his render files. When Render 2.0 is ready in the new year, things like this (plus other forum user suggestions) will be present.
 
This is mostly very good news! Thanks for providing it.

Regarding #1, that sounds OK but I would hope developers are paid to work on the proper SDK for exploiting the system's accelerated graphics and other functionality through standardized libraries. Just depending on them to invest their own time for nothing in return isn't really something you can depend upon. Also I would hope if this is to be done after release, that everyone wouldn't still be expected to use software graphics only or write directly against the metal even 6+ months on. Probably the best approach would be to get 1 or more dedicated individuals solely for the task of developing a custom SDL lib and a custom general lib for system functionality (adjusting CPU speed, backlight, input from the D-Pad, Analog sticks and Keyboard as standard SDL joystick and keyboard), same as for using external controllers from USB when in TV-Out mode.

Re: 2. I agree no headphones should be needed with onboard speakers. The customer can supply their own and I already have some I'd prefer to use.

Re: 3. Glad to hear it, odd they listed it in Gigabits at all. Very peculiar.

Re: 4. That's excellent news. With such a d-pad there should scarcely be any software these controls can't support.
 
Related to number 2; for the gp2x I really found it annoying that no s-video to composite adapter was included. The shop I bought it from did not sell those and the internet shops I found them either charged outrageous shipping costs or sold wholesale only. So for TV-out provide all necessary cabling for connecting with s-video and composite.

Regarding software; what (official) software can we expect? Will there be an effort to have a large part of the gp2x library (or new linux apps/games) ported before release?

With all discussions on hardware I get the impression that at the moment software gets little attention (which worries me a bit)
 
MWeston said:
4) Yeah, the Dpad isn't done. It is supposed to look more like a Sega Genesis with the circle built up and the dpad cross embedded into it but I think ED is still trying to change it without wrecking his render files. When Render 2.0 is ready in the new year, things like this (plus other forum user suggestions) will be present.
I think you're doing a great job, and you seem to be someone who understands how communities work.
Could you tell us in what way the design is open for changes? I still see some very vocal people wishing and pleading for adjustments that probably (and hopefully) will not be done.
By clarifying what surely will not be changed, discussion like this probably will not stop, but I think it will help. Looking forward to hear fa the clamshell design + keyboard is one of the decisions that will not be changed by some weak swivel joint or a detachable keyboard.

The majority of this board, the early adaptors, want to buy handheld as it is now. Maybe it is time to make some bold statements.
 
Last edited by a moderator:
Stealth Bagel said:
Regarding #1, that sounds OK but I would hope developers are paid to work on the proper SDK for exploiting the system's accelerated graphics and other functionality through standardized libraries. Just depending on them to invest their own time for nothing in return isn't really something you can depend upon.
Might I suggest, and I know this is far from a perfect system, since SDKs are invariably downloaded fewer times than the things made with them, that the one-click-install-system has some unintrusive ads built in, and that the developer who made whatever it is is then given a %age of the ad revenue?

Ok, might not work, but hey, it's an idea. Personally, I'd be happy with an unobtrusive ad being served up if it meant that the dev automatically got something for their work.
 
Last edited by a moderator:
For 3D graphics there's always the PowerVR OpenGL ES SDKs available here:
http://www.imgtec.com/PowerVR/insider/toolsSDKs/index.asp

If you want to start playing around with OpenGL ES you can download one of the PC Emulation SDKs (available for both Linux and Windows XP). Obviously performance depends on your graphics card and is not indicative of the real thing, though.

Stealth Bagel said:
Re: 3. Glad to hear it, odd they listed it in Gigabits at all. Very peculiar.

All memory manufacturers list their chips in mega/gigabits (more accurately, mebi/gibibits).
 
Last edited by a moderator:
Tobriand said:
Personally, I'd be happy with an unobtrusive ad being served up if it meant that the dev automatically got something for their work.
I would not, the only ads I would be happy to be served is one asking for a donation for the dev of the application.
 
Last edited by a moderator:
Tobriand:

Ads! ADS?!? What were you THINKING!!

NO ADS AND NO DRM FOR PANDORA OR ELSE!!!

Just imagine if we had messages popping up

"This app was compiled with gcc, please consider making a donation to the FSF"

Every time when ran a program, which is just a bit more ridiculous than what you're suggesting. The whole point of FOSS is that you don't have people/corporations hassling you for cash every time you want to do something on your computer. If you like that then may I recommend you forget Pandora/Linux and get an iPhone or some Vista UMPC device.

This reminds of those hopeless types you hear on the radio/TV sometimes (probably not 'real' people) who WANT more taxes, believing that our government can be trusted and that they'd actually do something good with that tax money. I'm not saying pandora devs are involved in anything bad, good devs deserve some kind of reward but this idea stinks.
 
Tobriand said:
Ok, might not work, but hey, it's an idea. Personally, I'd be happy with an unobtrusive ad being served up if it meant that the dev automatically got something for their work.
I would hate it, and apparently I am not the only one. Furthermore, our community is way too small to generate a significant amount of cash from ads.

I think donations are a good way to make developers earn money.
 
Last edited by a moderator:
Stealth Bagel said:
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.)
Just to refresh your memory (or serve up a brief videogaming history 101, depending on your age), Nintendo has always marketed their cartridge games in bits as opposed to bytes, so it's not strange that accessories used for cart-based Nintendo devices are also advertised in this manner. Though I agree that for a device like the Pandora, it's completely and utterly wrong but luckily it was caught quickly by the generally computer-savvy community (who of course wouldn't have been "fooled" by it anyway). :)

emphy said:
Related to number 2; for the gp2x I really found it annoying that no s-video to composite adapter was included. The shop I bought it from did not sell those and the internet shops I found them either charged outrageous shipping costs or sold wholesale only. So for TV-out provide all necessary cabling for connecting with s-video and composite.
Craigix stated early on that everything needed for proper TV-out (or A/V-out as TV-out is not the limit of the Pandora's capability) will be included in the base package.
 
Last edited by a moderator:
Well, I think people have misinterpretted my suggestion in some instances at least: I am not suggesting that ads are included with programs, that ads are displayed before programs are run, or anything remotely similar to that.

All I'm suggesting is that, when you're using the on-board wifi to use to one-click install system, if you were connecting to the archive in a browser there would be a banner at the top of the page. It seems fair to cover bandwidth costs to display that inside the one-click install system *after* you've clicked on a specific program.

Given that the traffic wouldn't be generated in the first place without that dev's program, it then makes sense to reward those devs for bringing in the traffic.

I would be pissed off with ads as part of games and such too. But not too much by one small banner being displayed at the same time as a button saying "click here to download/install NAMEOFGAMEHERE".

Put it like this: I'm not pissed off with gp32x.de or .de having a banner add when I'm using their bandwidth up in a web browser, so why doesn't that logic hold when translated to a handheld?

Or do you all block all banner ads regardless of whether you feel a website deserves to be supported by something other than donations?
 
Last edited by a moderator:
That is an excellent idea Tobriand, I really hope it will turn to reality. However, there is a problem that happened before around here with ad-based donations. Do you remember EvilDragon's Clicks for devs, where the money earned from Google AdSense would go to a dev voted for by the community in a monthly poll? Some asshat, jokingly (or not), reported him to Google for suggesting people purposely click the ads, and he got kicked out of the program.

Now, these Pandora ads would also be provided by a 3rd party company, correct? It wouldn't make much sense otherwise, since both webmasters and developers would need to see a profit. So what would stop the same mishap from repeating? Most people would click the ads for the sole purpose of making small donations, and this will become obvious to the advertisement company in no time. :-/
 
Stealth Bagel said:
Re: 3. Glad to hear it, odd they listed it in Gigabits at all. Very peculiar.
Not at all, if you look at every RAM or ROM datasheet, their size are always given in bit unit instead of byte unit. It was at least the case when I worked at Archos.

But I totally agree that we shouldn't give the ram size in bit unit but in byte unit for the final product because it is too much confusing for us as consumers. Anyway, who would complain about 128 MB(ytes) to demand 1 GB(its) ?
 
Last edited by a moderator:
Back
Top