32bit Graphics Development File Repository
/File/en/Outdated content.png
Out of Date
This article or section is outdated. Some of its content may no longer be accurate due to changes in the latest release. Please update this article.
References outdated forum threads etc. The 32bpp project referred to in this section is, as of 2017, dead

Early March 2009 saw the release of a public file repository for the 32bit Graphics Development effort. The repo was written and is hosted and administered by Jupix. He takes suggestions and advice at tt-forums.

It began as a simple file hosting tool that took in uploads and printed lists of files for users. Since then more features have been implemented and it currently supports:

Additionally, Jupix has written a few tools around the repository, including the 32bit automated nightly bundle compiler and a diff tool for squashing dupes.

For information on how to use the features at the repository, read the user manual.


Content guidelines

Target audience: developers

The repository is for 32bit graphics developers. The point is to have a single place for all development files for the 32bit base set conversion project, and also free hosting for the rest of the 32bit development effort, based on the principle that sooner or later, all artists grow disinterested, and unless their work files can be found in a repository like this, they can never be properly improved again. All files being hosted in a central place also makes version management and distribution easier.

In other words, if you are an artist, you should upload absolutely everything that has to do with your works... Textures, models, sprites, plans, readme files, everything. And all versions, too. Works just started or in progress, testing releases and finals. The more content, the better for the project - if someone wants to change something, they suddely can! That's the spirit of an open game.

If you are worried you would be uploading "useless" or duplicate data, don't be - the administrators will keep the repository organized.

Package format

All tars should be packaged into the 32bit standard tar format and include sources, and z0, z1 and z2 sprites. The sources are deleted from release packages aimed at players.

Tars should contain individual models. This rule of thumb is based on the assumption that the target audience of the repository are developers looking to either change something in a model, or run pngcodec on a model. Therefore the more models in a bundle, the more downloading has to occur over a slow WAN connection, and the harder it is to find just the right .blend, for example.

Example entry

Take a look at the iron ore mine by Zephyris. It is an example of a correct repository entry. Entry type and status is set correctly, licensing information is available an verifiable (via the wiki), notes are reasonably informative, screenshot is present and of good quality, everyone related to the development of the item has write rights, and most importantly, the file itself is a standard tar with sources and sprites for all zoom levels included.

Distributing content to players

Big bundles aimed at players will hopefully go into the game's internal content delivery system in the future. Currently, the 32bit automated nightly bundle provides a method for publishing graphics to the end user in an easy-to-use format. Bundles can also be built manually.

Become an administrator

Contributors are needed at the repository to do administrative tasks on entries. The content needs to be kept organised and format guidelines need to be enforced. Contact Jupix at tt-forums and he'll set you up.

Tasks for administrators

See also