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
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.
What do you mean by that? Is that the functionality of files in pandora/appdata/[pnd_id] overwriting the same files inside the pnd?
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.
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. PNDTools.zip
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.
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
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
@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.
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: https://docs.google.com/document/d/1xAaPRafox5XPy_TtXdYwPb9_ocMyOrKGmsq4eXRWAsc/edit?usp=sharing
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):
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!):
Math optimisations (I have not profiled these specifically, everybody just seems to use them):
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:
SDL libs (pick which your application needs):
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: http://foxblock.pirategames.co.uk/dropbox/Pandora_libraries.zip
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.
Hey, thanks for the encouragement (I also read the posts mentioning Greyout in the Pyra Killer App discussion), it means a lot!
I am currently working on finishing my bachelors degree and will be doing so for the rest of the year. Sadly this means I don't have the time to work on anything besides that, including Greyout.
Expect some more updates in 2015 though!
EDIT: To add to that, some less vague infos about the actual state of development:
It has been coming along nicely. I have added so much stuff to the game and improved the existing ideas and technology, it basically is a Greyout 2 at this point.
A few levels are still missing and some overall polish, not much, but it has been like that for a long time (it's always harder to tie the loose ends together, than get started in the first place).
It will not be a random collection of levels, too, but tied in some kind of story (although I am certain not everybody will like that, you will have to judge for yourself I guess).
I hope to get some more original music by Nick May, but I really want to finish the game before I bother him about it, so I have not talked to him yet. (The few tracks he made for the demo are easily one of the best parts about the whole thing)