Addin Usability Guidelines
Throughout the OS and official add-ins, Casio maintains some amount of coherency regarding the User Experience. This includes not just the appearance of the graphical interface, but also the way the user interacts with it and the way it responds. Whether the User Experience is effectively good or bad is a whole other subject, and add-ins can definitely try to improve on it. However, they should not provide a experience that's worse than that of the OS, and when improving, they should do so in ways that do not break user habits, namely in terms of how to navigate the interface, turn off the calculator, switch apps, etc.
Read the original discussion topic on the Cemetech forum
Icons are a part of Prizm add-ins that are usually considered unimportant. They don't affect the add-in itself, but it's still a good idea to create a nice set of icons for your game/program. Users will see it even when they aren't playing the game/running the program, and if the Main Menu is full of icons that don't adhere to a few guidelines, it may become confusing. Independently of how beautiful the icon is believed to be, this actually makes the user experience even worse. To make sure that the icons work well, there are a few things to take into consideration.
The object that's the main focus of the icon shouldn't take up all of the 92x64 pixels that it has access to - it should generally be a bit smaller since the background also needs a bit of space (and the things that the Prizm OS will place on it, which will be explained later). The official icons from Casio are somewhat colorful, somewhat 3D-looking, have shadows and are slightly translucent. You can follow the style of these if you want to, or create your own kind of icon! 2D sprites work well if they aren't too similar to the backgrounds. If you do something that's different from how things are usually done, please check that it looks good and that things work well.
In all add-ins, two icons must be provided - the selected icon, and the unselected icon. The two icons should show the same object(s) with different backgrounds - not two objects that are completely different from each other or the same object(s) with minor variations. There is one exception, though. When placing text in the icon (this is not recommended!), the text in the unselected icon should be white with a black outline and the text in the selected icon should be black with a white outline. Run-Matrix and Equation are examples of this. The unselected icon needs to have a pure black background, and the selected icon needs to have this background:
If you don't have an icon for your program, please use the background with nothing on top of it for the selected icon. Don't make the selected icon pure black!
Areas drawn by the OS
The Prizm OS is a bit quirky when it comes to icons. The main problem when creating a icon (apart from the fact that not one, but two bitmaps are needed) is that some areas of it will be drawn on in the Main Menu. Those areas are marked in red here:
The square on the top right area of the icon will always be completely unseen, and anything that might be important should never be placed there. However, hiding defects or other odd things there is not recommended, since it's always possible to use something that isn't the OS to view the icons. The larger area on the bottom is where the name of the add-in will be placed. The main focus of the icon shouldn't be under it, but since it doesn't cover it completely, things that aren't very important can be placed there. For example, a small part of the ruler in the icons of Conversion and Geometry is placed there, and an unimportant part of one of the images in the Picture Plot icon is also placed there. The name of the add-in should never figure in the icon since the OS takes care of including it.
For projects in development
If you have an in-dev project and do not have time to/are too lazy to make an icon, there is salvation!
KermMartian made these icons for in-dev projects:
As discussed in an earlier thread, until recently most Prizms could safely overclock to around 95 MHz, but not all. More recently, the development of a tool called Ptune2 made overclocking to higher frequencies, in possibly more devices and in a eventually safer way, possible. Rather than make assumptions that can easily cause not just instability, but also an undesired increase of the power consumption and higher hardware wear-out, any modification to the system clocks should not be done without the user's permission or, at the bare minimum, knowledge.
The best way to handle overclocking is to simply not do it, by either optimizing the program, or reducing the amount of processing required. Drawing things to VRAM tends to be quite slow compared to computation, so optimizing the drawing in a program can offer significant speedups.
If the additional speed offered by overclocking is indeed important, to the point where the program will not work correctly without it, be sure to notify the user before doing anything and allow for backing out. There are some cases where this guideline could be safely ignored (such as an add-in designed specifically to allow the user to modify the clock settings), but in most cases the user should be notified before the program does anything that could negatively impact the calculator's stability (namely, overclocking).
In addition to keeping the user informed, an add-in that modifies the clock settings should also revert to the previous (stock or not) clock speed on exit by hooking the [MENU] key. Using SetQuitHandler to register a function that reverts the clock speed back to the default one will work fine in most cases.