Plays well on my CC Pandora, quite an interesting game .. fun for a while. But I agree with Fusion_Power - there's something thats sort of 'off' in the graphics of this game, some kind of polish is missing - maybe its just too clean looking. Nevertheless, a fabulous port, thank you ptitSeb! Once again you have proved a mastership of the Pandora that one can only aspire to achieving one day after a lot of hard work ..
Hi folks, I'v been a bit quiet lately and am coming out of the woodworks again to see whats up .. ED, any chance you can update us on the situation with the iCP2 orders - if I recall correctly there was some plan to credit the iCP2 backers somewhat towards the Pyra project - is this still on the table, and if so what does it involve? I remember being asked if I wanted a refund for the iCP2 or if I would be satisfied with crediting the iCP2 funds towards the Pyra - please correct me if I'm wrong or have the details confused. Would very much like to have been a Pyra backer all along.
There are actually good reasons for a lot of the decisions made about how the filesystem is laid out.
/bin has traditionally been for binaries/tools that are necessary to use the system when it is in single-user mode - i.e. no /usr mounted .. in the bad ol' days of Unix, /usr was only mounted after the system came up successfully and became a multi-user system. So /usr/bin contains stuff that is mostly for the users whereas /bin is stuff that the administrator *must* have onboard in order to resuscitate a system that is in single-user mode.
Over time, the filesystem layout has become the subject of many different cultures - some use /opt for things, some use /usr/local/, and so on - each of these have their own reasoning and it requires a bit of historical understanding to glean why.
I wouldn't recommend Python for a beginner - its a language that stretches from one end of the complexity scale to another and you can easily get overwhelmed with some of its peculiarities ..
The fact is though, as a beginner you have a wide range of languages and programming environments to choose from. Remember though that programming is not just about typing code and hoping it runs - you also have to have some skills with regards to administering your computer and understanding how it works at a systems level as well as at the front-end stage of things. Pick an environment that is: a) easy to use, in terms of tooling, and approachable for you, yourself, personally.
Python may well be what you choose - but there are other great tools too. For me, I'd pick Lua to teach a newbie programmer - it has all the power you need and is very easy to use, and it will interface with a lot of things, as it is based on a C-language framework that can interact with any other system library out there. If you learn Lua well you can then use the skills to learn C and C++ - there are tons of Lua-based environments out there with a foot in both the Lua and C++ worlds, and you can gain a lot of valuable wisdom from following this path: Lua -> C -> C++ -> Everything else.
I wish they'd set it up so that headphone and main audio output were independently assignable as output channels - this would make it quite nice for synthesizer/music software to give the user the ability to use headphones to monitor what they're playing before mixing their new output with the master output ..
You put the SSD on it? So now this means you can run swap and do massive builds. I'm very keen on knowing if you're doing that, how that works out for you...
EDIT: BTW, can you guys tell me which is the 'closest to Pyra' ARM devboard to get? I need a small/light ARM machine for another project, and if the one that you guys are using as a "Pyra testbench" is suitable, I'll nip two buds with one swipe and get it. The specs aren't super-important for my project - but Pyra compatability would mean it would be good for a bit of future work too ..