• Content count

  • Joined

  • Last visited

About foxblock

  • Rank
    Mind over body
  • Birthday 01/15/90

Contact Methods

  • MSN you may ask me personally for that info
  • ICQ you may ask me personally for that info
  • Skype you may ask me personally for that info

Profile Information

  • Gender Male
  • Location Aachen, Germany
  1. I like this idea. I think we definitely need a standard regarding buttons for menu interaction. The Pandora as an open console and ecosystem naturally does not support one mandatory way of doing things, instead promotes choice and customisation. I really liked the idea of giving the user full control over which button he wants as "accept", as "cancel", etc, however on second thought (as explained in this thread) this is not a good idea and just leads to more problems.   So I think this simplified approach could work for both sides. It has to be available (in the OS) from the very beginning though! Maybe even get some major porters to support and use it right away, to give it some traction.   Further: I think it makes sense to have some documentation of "de-facto standards" available for developers at launch, which also includes recommendations for other buttons (like some sort of Pyra-Button-sequence to instantly exit a program, ESC as default exit button, a home button, button for emulator menu, etc. - whatever makes sense or is used in many applications). This might be a whole different topic though.
  2. Yup, I totally get it. However most people here either lack the skill, the time or both to help. Money could "fix" the time problem. I mean most people working on the Pandora's OS did so voluntarily and as you said, you cannot rely on that! Why not hire a few men to work on it full-time. Yup, that is a lot of money, maybe it's worth it, maybe not, depends what you are aiming for. I would love to see people getting paid for some great software after the release of the Pyra, so thanks for planning on doing so. However doing an investment before the release could avoid some of the problems the Pandora had imo. It like when you move into a new house, if you don't do all work, like painting walls in the colour you like, while you are moving in, you will never do so, because people are inherently lazy and good at accepting stuff as status-quo and just living with that.   I also said the exact same thing some time ago when the Pyra was just announced, so it's not like I am crying just now when the project enters the final stretch. I just feel like the attitude has not changed since then.   Concerning the dev hub: I totally agree the standards need to be laid out first, but coding has to happen eventually or it will just be a lot of arguing about nothing of value in the end. Concerning SDKs: Not just talking about compiling on the Pyra/Pandora. There also should be an easy way and "officially" supported way to compile from a desktop PC (of any OS). There is a nice VM image for Linux now, if this had existed from the start, the entry to development for the Pandora would have been much easier for many people.   I know this is a lot of complaining coming from somebody who did not put much time into working on the Pandora core, but when I see a valid concern from an experienced developed (who did put in a lot of time) simply get waved away, I become concerned. Maybe it is coming across as more negative than it is intended, sorry for that. I appreciate the time and money you and all contributors like aTc put into this humongous project. I just fear mistakes could be repeated and I would hate for the Pyra to be plagued by the same problems the Pandora had.   Thanks for your reply.
  3. NO NO NO NO This attitude is part of the reason the Software on the Pandora is such a mess. Sure we got tons of PNDs, but as a developer as well as a user there are so many inconsistencies and pitfalls. We don't have a unified control scheme - leading to confused users and an overall messy experience until you get used to it. A lot of PNDs depend on old or new libs (which need to be packed along) - it took forever to get away from the completely hacked OS and kernel and get some sort of compatibility with standard packages. There is no central game hub. We have C4A now (after how many years), but no common lobby/chat/etc. (granted this is not essential, however we are such a small community, you need to make it as easy as possible for people to meet and interact with each other) There is no official SDK or devkit, everybody just hacked their own. It is pretty straightforward now, but it was a mess in the beginning. It took quite a while for a central repo to appear and now that we got one it is basically dead development wise and not open-source. Stuff like this happens and work hours get wasted because everything just gets rushed to a barely working state, then improved later.   I mean don't get me wrong, I am not trying to say everything is shit with the Pandora, but the Pyra could be so much more. Doing things right from the beginning is essential to give users and developers a better experience. Sitting a few skilled people down with coordinated tasks could save so many man-hours in the end.   I do get that you have to make money and don't have the time to spend on "extra" tasks (since many people here probably don't even care for these things). I am not saying doing all this is easy and straight-forward. I don't really know what to do about it, just please keep this in mind and consider giving the OS and Software side of the Pyra before launch more attention than the Pandora's OS got back then.
  4. Out of Order

    OOoh, I loved this game on the PC back in the day. Amazing, unique storyline and some challenging puzzles. Great adventure game all around! Thanks a lot for the port, too bad CC get left in the dust again, but there is nothing you can do about that (I know the struggle...). Maybe I will give it a try anyway, just to see whether I remember all the puzzles
  5. ~~ Super JumpKick Turbo ~~

    Woo, amazing stuff. Glad to see this in the wild, finally.   You guys should try it out. It's really fun! (Esp. Playing on LAN or two people on one Pandora)
  6. Which player is the AI in the video? I really cannot tell...   (those friendly fire kills are hilarious and amazing at the same time)
  7. Current Keyboard Layout

    Just a quick note: I am also very much in favour of putting the F-keys on the number keys. For one most compact keyboards (I own) do it like that and it seems more intuitive (to me at least, but that is personal preference as has been already discussed). For another, this would put € on E where it belongs and opens up Tab or Q for ESC, which is a better choice in my opinion, since it feels more natural (ESC on Q=Quit / ESC on Tab as the opposite of tabbing through input fields = exit current form).   In the end it looks like the layout will be a custom, non-standard one no matter what we do. So in my opinion every key in a non-standard or unexpected (to most users) position should make sense from the context and not just be placed there because there was still room. This is especially important with often used keys like the F-keys, ESC, shift, control, etc. I agree with Linux-SWAT: I feel like having special symbols like the French accents or German umlauts in the "correct" position is nice for a single group of people, but we should not sacrifice the position of keys important to ALL users for that.   Finally this is all just theory crafting. Nobody here can actually predict whether this layout works or layout X is better than Y (given that both are reasonable, but all in here seem to be). What we need is some prototyping or rather people creating this custom layout for their keyboard at home (as closely as possible), test drive it for a week or longer and report back with problems/suggestions/ideas. It's the same with the action buttons really. Nobody can objectively say greek-smbols are better/worse than ABXY, (though some people are making quite an effort), both have pros and cons. To find out what works best you gotta let a larger group of people test it. And since ED does not have the money to prototype a thousand keymats or cases with buttons we gotta find some cheap alternatives to properly test it I think. (instead of just arguing about single button placements) Some makeshift prototypes (like a keyboard layout for you at home) could be especially helpful, since you can invite outsiders to test it, too. We are all just way too used to the Pandora's keyboard and special workarounds/problems. Get some novices in the mix and find out what is really bothering them with this layout.
  8. Diablo

    Well for the majority of Windows users -no-recovery and -noappend make sense to avoid confusion and additional data they don't need. I don't know why I use nopad, I guess I extracted a few PNDs back then, packed them again and compared to the original and that's how most of them were built. You are much more knowledgeable about this kind of stuff, so it probably makes sense to remove it now.   EDIT: Looking at the documentation/explanation of this option some more, it indeed seems risky to include it for very little gain. Although it should be allright for standard PNDs and as the past shows it apparently is. Still removing this option makes sense.
  9. PNDTools

      I found a compiled version of squashtools 4.3 with lzma (and xy) compatibility, which I am currently testing. If no regression bugs show up, I will release a new version. (This one does open the Diablo PND)   You can find a beta version with the new squashtools attached (and nothing else changed). You can help me test for bugs by opening and creating a few (test) PNDs with that version (see if PNDs that could be opened before cannot anymore or if there are errors creating your PNDs, etc.). That would save me some time.
  10. Diablo

    Just out of interest and to optimize the PNDs created with PNDTools a bit (default options): What does your typical mksquashfs call look like for a PND? I am currently just using "-nopad -no-recovery -noappend", which seem to be the necessary ones and probably could be optimized.
  11. Hmm... I might be able to stream this event. (since I have that twitch account set up, I never use). Maybe Ziz would be willing to join in on doing some commentary. I will ask him about that. Only downside is my rubbish internet connection, so the Stream won't be high quality or anything
  12. Some thoughts about the board

    Thanks for expressing your feelings and writing this post, Ziz.   I feel similarly, I want to go into detail, but I lack the time at the moment. Someone remind me in a week...
  13. PNDTools

    I released an update for PNDTools (Version 0.7.3): Fixed errors in the PXML created by the PXMLCreator, discovered by namco in this thread Added a few licenses Changed PXMLCreator to follow the PXML specification more closely in terms of optional elements: things like leaving out the description will now throw a warning instead of an error (PXML may still be created. The program just urges you to include a description for your own good) Fixed error when loading GIF images as icon or screenshot Other minor improvements to the PXMLCreator and other parts of the app DOWNLOAD
  14. My windows dev setup for the Pandora

    @namco, The problems you had with your PXML file were indeed related to a bug in PNDTools (multiple icon nodes) and a missing warning/check (empty description tags). Needless to say, I have fixed these bugs and will upload a new build tomorrow when I tested the changes a bit.
  15. My windows dev setup for the Pandora

    Okay a few notes from my end: I had a Windows toolchain working for a while now, people asked me to write a guide on it, I never did and now I feel bad. So, thanks for the updated information. I will try to add what else I know and maybe eventually we can cleanly package all this information in a wiki page or something.   I will follow namco's steps and add my comments. Step 1: Downloading the toolchain. You can definitely use a newer version than the 2010q1. There is list of all versions here: As noted in the document, I had trouble getting the newer versions of the toolchain to run on the Pandora, probably because of outdated libs. I am successfully using the 2011.09-07 build, which includes GCC 4.6.1. This is still ancient, yet much better than the 2010 release though. As you can see though the document was last updated in 2013 and the Pandora's kernel and libs have been updated since then, so this might not be a problem any more. This document really needs an update anyway. Some guides say to install directly on C:/ or a path with no spaces. I have not done that and it works fine.   Step 2: Compiler flags This boils down mostly to personal preference really. Most of the defines in the original GP32x post are very project/code specific and you probably don't need them. The cflags are good though. In general I think the makefile posted by namco looks pretty good. I use CodeBlocks on Windows to build everything, which works fine as well. For reference here are my compiler flags for Greyout (my other projects look similar): Disable exceptions and RTTI, since I don't need it (10% performance gain in Greyout): -fno-exceptions -fno-rtti Arch-specific flags: -mcpu=cortex-a8 -march=armv7-a -mfpu=neon -mfloat-abi=softfp I have made a few speed comparisons of my SDL apps and have found -O3 to be always faster than -Os. This might not always be the case, but it has been for me. -Os usually gives better results than -O2 though. (Try it yourself!): -O3 Math optimisations (I have not profiled these specifically, everybody just seems to use them): -ftree-vectorize -ffast-math -fsingle-precision-constant Linker flags: Since the 2011-toolchain I need this flag or the binary would not run on the Pandora (probably due to a change in the ABI). This will just link libstdc statically (makes the binary a bit bigger in size). You might not need this nowadays due to updated libs on the Pandora: -static-libstdc++ TTF fonts: -lfreetype OGG music: -lvorbisidec Mp3 music: -lmad Touchscreen: -lts PNG-Images: -lpng -lz SDL libs (pick which your application needs): -lSDL_image -lSDL_mixer -lSDL_ttf -lSDL_gfx -lSDL Step 3: The lib package This is the tricky step, really. (which says a lot about how easy this process actually is) I rely on pre-packaged libs, very much like the ones linked in the gp32x post. Only my package was provided by PokeParadox with love. You can get it here: I never had problems, like the one namco described, but that does not mean my package is better. It's probably worse. You should really just copy the libs off your Pandora!   Step 4: The PXML file PNDTools should work fine here. I am investigating whether the problems namco described were caused by PNDTools and/or can be prevented by it. Note: You don't need to package your application as a PND to be able to run it on the Pandora, if you just want to test it. You can just copy your whole app and execute the binary manually from the console or file manager. (you might need to call chmod +x on the binary beforehand though)   And that is it, really. If I can think of anything else, I will add it.