The Allegro Wiki is migrating to github at https://github.com/liballeg/allegro_wiki/wiki

Difference between revisions of "Addon writer's guide"

From Allegro Wiki
Jump to: navigation, search
m (AddonWritersGuide moved to Addon writers guide: Twiki -> MediaWiki title format)
m (Addon Writers' Guide: link update)
Line 3: Line 3:
 
For now, just some things you definitely should do:
 
For now, just some things you definitely should do:
  
* Test the build process on at least Windows, Linux and OSX. Of course, you probably can only do this yourself on one platform, so ask on e.g. http://www.allegro.cc, the [[AllegroMailingList|AllegroMailingList]] or in the [[AllegroIRC|AllegroIRC]] channel for testers.
+
* Test the build process on at least Windows, Linux and OSX. Of course, you probably can only do this yourself on one platform, so ask on e.g. http://www.allegro.cc, the [[Allegro mailing list]] or in the [[Allegro IRC]] channel for testers.
  
 
* Add documentation. It may be some work, and you can argue that reading the .h files provides just as much info, but it makes the addon much more useable.
 
* Add documentation. It may be some work, and you can argue that reading the .h files provides just as much info, but it makes the addon much more useable.
Line 14: Line 14:
  
 
* If the addon is written in C, which it likely is as Allegro addon - use a proper prefix for all public symbols. This will make name-clashes with other libraries much more unlikely.
 
* If the addon is written in C, which it likely is as Allegro addon - use a proper prefix for all public symbols. This will make name-clashes with other libraries much more unlikely.
 
Back to [[AllegroDev|AllegroDev]].
 
  
 
[[Category:Development]]
 
[[Category:Development]]

Revision as of 19:15, July 31, 2007

Addon Writers' Guide

For now, just some things you definitely should do:

  • Add documentation. It may be some work, and you can argue that reading the .h files provides just as much info, but it makes the addon much more useable.
  • Add at least one example. It just makes evaluating the addon for someone who is not sure if he/she wants to use it much easier - even if the example seems trivial.
  • For file-type addons, provide packfile versions of the load/save routines, so someone reading from .dat or .zip or other archives, or from memory data, will not be left out.
  • For driver/packfile/font addons, try to implement a reasonable amount of the vtable. The more, the better, generally :)
  • If the addon is written in C, which it likely is as Allegro addon - use a proper prefix for all public symbols. This will make name-clashes with other libraries much more unlikely.