Pyra Developers.

[Wrath Of Khan]

I understand Ed is handing out a few prototypes to certain devs for specific duties.

Aside from this, who amongst us regular pre-orderers is a developer or wishes to develop for the Pyra?

Who is interested in porting or indeed maintaining existing pandora emulators or software.

I'm just curious has anybody got stuff in the pipeline?

I added a simple poll. 

 

[lunixbochs]

I'm working on Pyra graphics drivers, glshim to help with both source and binary porting, fast software 3d rendering for weirder graphics workloads, and secret stuff that should eventually help with newer x86 games.

 

[TrashyMG]

Testing OS images aTc builds, making videos to keep the hype going...

I plan on moving the ports I have done on the Pandora over to the Pyra. I have OpenTyrian is already done and in DBP form, it may have been the first DBP game bundled. I have a few unique ports that are not in the debian repo, I plan on porting those closer to release date. I intend on keeping my Pandora PNDs as up to date as possible, not too hard when I have so few of them.

 

[FelixNemis]

Not sure how much I'll end up doing, but at the very least I'll probably make some .dbp es and maybe actually release a crappy game.

 

[slaeshjag]

I guess I'll attempt to get the dbp system in servicable shape in time for launch, although that's seeming less and less likely as my TODO-list is only getting longer…

 

[Wally]

I plan on assisting with documentation / testing said DBP system and compiling some applications for distribution

 

[ible]

is there anyone who's planning to work on the following?

• Hardware interface GUI via the Pyra button, shortcuts via Pyra+W (for wifi toggle), Pyra+B (for BT toggle), etc., also keyboard LEDs
• Volume control via the analog wheel (I'm not following the discussion too closely)
• screen-tearing issues (is this a kernel issue?)
• standard buttons (user-configurable) for applications (like flipBX)

thanks lunixbochs for working on the GPU stuff, and TrashyMG for updating your profile picture to another Crow.  (the intermediate ones just didn't feel right.) 

 

[Wally]

Probably the usual, aTc, lunixbochs, notaz for everything.

I have a couple of basic scripts I can contribute to build DBPs on the fly but nothing special.

 

[ekianjo]

I will probably port a few things (in case other porters are not taking care of them) and write a couple of small things on my own, too. 

 

[bzar]

I'm doing FunKeyMonkey for the few cases it could be handy for and looking into potentially getting a nicer first boot wizard done.

 

[pmprog]

I'm currently working on "If... Then Do..." which is a tool where you let's you get the Pyra (as well as the Pandora, laptops and desktops) to do certain things based on other things. It uses plugins to describe all it's functionality, but some examples are (I'm hoping most of these will be implemented by release)

• If Time is Between [Start] and [End]
• If Battery is [Less than Percentage | On Charge]
• If connected to WiFi SSID [SSID]
• If [Process] is running
• Do Execute [Executable [Parameters]]
• Do Set Volume [Percentage]
• Do Turn [On | Off] WiFi

 I intend to have some GPS and Cell/Modem options too later (ie, "If you are within [n] miles of [location]"). Any plugin suggestions and pull requests are welcome.

I also have my Tournament Hub Mk2 planned for after, which will (hopefully) provide a way of chatting with friends, finding multiplayer games and highscores... Assuming once it's ready I can convince any other developers to implement it.

 

[hns]

is there anyone who's planning to work on the following?

• Hardware interface GUI via the Pyra button, shortcuts via Pyra+W (for wifi toggle), Pyra+B (for BT toggle), etc., also keyboard LEDs
• Volume control via the analog wheel (I'm not following the discussion too closely)
• screen-tearing issues (is this a kernel issue?)
• standard buttons (user-configurable) for applications (like flipBX)

thanks lunixbochs for working on the GPU stuff, and TrashyMG for updating your profile picture to another Crow.  (the intermediate ones just didn't feel right.) 

Some known Kernel issues (like tearing) are already collected here:

http://projects.goldelico.com/p/gta04-kernel/issues/label/1799/open/

If you find more, please add them there.

 

[ptitSeb]

I plan to port on Pyra (who doesn't want to anyway?). I for now continue my porting work on the Pandora, but most of my work should be easily usable on the Pyra. I will also work on glshim, and the 3D Driver if needed. I'll also hope to see the Rotator (maybe) integrated in SDL (1) to have a behavour similar to the omapdss driver (unless the ompadss driver is supported on Pyra alone).

I have a few game/emus that runs or barrel runs on the Pandora and that I'm eager to see on the Pyra (like DooM III, PPSSPP, Reicast, Mupen64, SpeedDream, Minecraft, FlightGear, VDrift, VegasStike, Hammerwatch...)

 

[Eight Bit]

As the pyra is running Debian and its repository is so big, Is it necessary to port stuff specifically to the Pyra? Or is the porting more like packaging into DBP?

 

[sebt3]

As the pyra is running Debian and its repository is so big, Is it necessary to port stuff specifically to the Pyra? Or is the porting more like packaging into DBP?

Indeed, few apps will requiere porting (it sound like chromium and xmbc arent in the debian arm repo)  but most game will still

 

[_jr_]

And not many non-commandline tools available in the repository will have adequate defaults.

 

[undexsym]

I plan on developing more vaporware and complaining on IRC. I might make some games too.

 

[PokeParadox]

I will try to go through my Pandora apps and games and make a native Pyra port for each. I will also ensure Penjin and PenjinTwo can be used. I hope to be able to progress some stuff more... But who knows?

 

[Pickle]

I plan to port/create and generally work on things I like to use, but thats when pyra is around and I can somehow afford one.

 

[ekianjo]

As the pyra is running Debian and its repository is so big, Is it necessary to port stuff specifically to the Pyra? Or is the porting more like packaging into DBP?

optimized ports will not be in the debian repo anyway...