Google Summer Of Code

From devkitPro
Revision as of 18:34, 12 March 2009 by Kraln (talk | contribs) (Another in-progress edit)
Jump to navigation Jump to search

Summer of Code

devkitPro is the suite of toolchains of choice for (homebrew) game development, currently available for Nintendo's GameBoy Advance, DS, GameCube, and Wii, and additionally the GP32 and Playstation Portable consoles.

There are actually three sets of toolchains--

  • devkitARM for the DS, GBA, and GP32
  • devkitPPC for GameCube and Wii
  • devkitPSP for PSP

Further information and discussion of these toolchains can be found in the devkitPro forums, located at [1], and additionally there are several IRC channels dedicated to homebrew development:

  • #gbadev, #dsdev and #wiidev on irc.blitzed.org.
  • #gp32dev and #gp2xdev on irc.efnet.org.
  • #pspdev on chat.freenode.net.

devkitPro is applying to become a mentoring organization for the 2009 Google Summer of Code. You can find more information about GSoC 2009 at the 2009 GSoC page.

Overall Expectations and Goals

Our organizational goal in participating in the Google Summer of Code is to encourage growth and community contribution for devkitPro, the toolchains and the support libraries, and to better support our end users. For students, we hope to increase your skills and give you experience working on a large project, while not totally drowning you in responsibility or isolating you from help.

We have split our project ideas into three categories, based on difficulty. If you aren't sure if you can tackle one of the more difficult ones, it may be in your best interests to pick a less challenging idea, but we will support whatever you think you can handle. Please feel free to hop on irc (blitzed/#devkitPro) and have a chat with one of the mentors if you need help deciding (or for any reason, really. we won't bite!)

For all of these projects, we'd like to emphasize not just programming skill, but also design, planning, and documentation. At the very least, we expect you to follow good programming practices, but in addition we'd like to see good inline comments as well as end-user documentation, tutorials, and sample code where applicable. It is just as important to learn good documenting as it is to learn good programming--it often does not matter as much who has the better solution, as much as it matters who can explain it better.

Project Ideas

Potential projects that would benefit the homebrew scene in general. Please note that this list is not exclusive; if you have something you want to do, please please feel free to apply to do it and we will assign an appropriate mentor to you.

Beginner-Friendly Ideas

These are ideas that are probably best for someone who hasn't worked on a project with other people before, and may need a higher degree of assistance. These may require less programming than other ideas, but are still very useful.

devkitPro updater/installer enhancements

  • The web based installer is currently a little difficult to add packages, it would be greatly enhanced with the ability to add packages through an external configuration file.
  • The MinGW project uses an earlier version of this code and would benefit from a more configurable installer.
  • Other SourceForge based projects have expressed an interest in this kind of enhancement.
  • We have a license of Install4J that can be put towards this idea

Improve the PernEdit map editor

  • PernEdit is a free, open-source 'map editor' for creating game maps for tile-based games (most GBA and many NDS games are tile-based or at least have tile base components).
  • Unfortunately PernEdit currently only runs under the .NET 2.0 framework via windows. Porting it to Mono would allow it to run on more platforms, and be useful to more people.
  • There is a lengthy list of features which are slated for addition from trivial to more advanced image processing.
  • Much work remains on usability and layout of the editor.
  • A long term goal of PernEdit is to provide a means to organize and manipulate all common game resources. While it currently only handles 2D tiled maps it would be beneficial if it also could work with and manage graphics objects (such as sprites and other non animated objects), strings and scripts, music files, and general data files. Being able to group these things and define rules for conversion as well as provide a means for integration into the build process is a complex problem.
  • www.pernedit.com

Sprite editor

  • For editing sprites, to go along with PernEdit. It is recommended/preferred this be an addon to PernEdit, but that is not mandatory.

Novice Ideas

These ideas are aimed at the vast majority of people we expect to see participating from GSoC

3D model export/conversion tools

  • We need a standardized way of getting 3D models and textures from modeling applications such as Blender, LightWave, Wings3D, etc into a format which is easily usable on the NDS, Gamecube and Wii. Currently everyone who wants to write 3D applications has to either hobble along with partially working tools, or write their own from scratch. Having a full-featured, highly-compatible conversion/export tool would make 3D development accessible to many more people. Some work has been done on a collada parser which could be provided as a starting point.

libfat port to cube/wii

  • libfat is a library for NDS/GBA which provides access to FAT filesystems, mainly on SD and CF cards. The current SD card code in libogc is rather buggy and would benefit from being replaced with a tested FAT support layer.

ndstool enhancements

  • possible rewrite, objective to allow editing as well as extraction & creation.

ndstool is the application which builds a .nds file from it's component parts - the arm7 & arm9 binaries, icons, banner text and the embedded filesystem. Currently it cannot edit an existing file without first extracting the indvidual parts. There is also a feature request asking for separate banner & banner text manipulation.

A full-on rewrite utilizing OOP would be great.

Homebrew Launcher

  • Currently most NDS flash cards use a proprietary launcher menu and file browser. The homebrew scene would benefit a great deal from an open source launcher which could support additional features available in the toolchain like the latest argv support mechanism.

Online Homebrew Catelog

  • This would be browsable from the DS as well as the web and allow directly loading and launching applications from the DS. Amateur developers would be able to upload games and applications for peer review which would then be accessible via an application on the Nintendo DS. This would be similar in functionality to Xbox live arcade or the Wii channels.
  • The web site back end for this library is nearly complete and some work has gone into a browser for the DS.
  • A few backends are at about the same level of completeness for this project, one written in PHP and one in Python/DJango

Open Source replacement for SDload

  • SDload is a menu system for launching homebrew applications from an SD Adapter such as SDgecko. Unfortunately this is a closed source application and not easily updated for the Wii.

Advanced Ideas

Up for a challenge? These ideas are things we'd really like to see done, but feel that their scope or difficulty may lay outside of what can be accomplished in the time restraints of GSoC. That said, there are no laws stating that you must completely finish by the end of the summer, and afterwords can never work on it again.

GDB stub and host proxy

  • Something like Xboo Communicator for DS. This would allow developers to debug their applications on the target platform via a stub which communicates with GDB (GNU Debugger) running on a host PC. Being able to debug on hardware is very valuable, since currently all PC-based emulators are either lacking debug capability or lacking in emulation accuracy

Improve DS OpenGL interface

  • libnds attempts to mimic an OpenGL interface to the DS 3D hardware. While functional this implementation can use some work.
  • General bug fixing is needed to upgrade the existing portions of the library to gl compliant status.
  • The DS texture memory is limited and does not map very well to the gl style of texture management. As such, libnds would benefit greatly from a completely reworked texture memory management system.