Language…
16 users online:  Ahrion, Anas,  Anorakun, Apple Boy, Chip, Dilshacking, DimeR, Duraner Hawkeye, genk, J0hnBoB0n, Jukeboxi_, MagneticHibiscus, Rykon-V73, X11Gbyte, Zatara,  zuccha - Guests: 112 - Bots: 169
Users: 67,566 (2,006 active)
Latest user: Baschfire

Submission Guidelines

The pages here detail all of SMW Central's submission guidelines for all resource sections and for submitting hacks. They contain information on quality expectations and important points regarding the site's core values.

Blocks

Block Submission Guidelines

All blocks submitted in a valid format will be tested and reviewed by a staff member. Rejected submissions or removals will be logged here.

  1. Your block must work with the latest version of GPS (Gopher Popcorn Stew) and be in the .asm format.
    We no longer accept blocks designed for old block insertion programs such as Jonwil's BlockTool or smkdan's BTSD. You can find the latest version of GPS here.

  2. Make sure to fill out the Act As field correctly.
    Please use three digit values (025, 130, etc.) when completing the Act As field in your submission. Alternatively, enter "Any" if your block does not require a specific setting. If your blocks work with or require a specific amount of act-like values, please enter "Various" and include a readme file detailing proper usage.

  3. Blocks must have a db $42 or db $37 header directive at the top of the file.
    GPS requires one of these two header directives, as well as the corresponding 3-byte long jumps per offset. You can find a template block here.
    You can use db $42 if your block doesn't execute wallrunning code to save space; otherwise, use db $37.

  4. The value of RAM address $0F must be preserved and restored if used under the SpriteV or SpriteH labels, unless modified deliberately.
    This scratch RAM address is used by the sprite/object interaction routine that runs after GPS runs its code; failure to preserve $0F can cause interaction bugs.

  5. You must use GPS' shared subroutine system when applicable.
    Commonly utilized block subroutines are included with GPS in the "routines" folder and are shared amongst inserted blocks; these routines must be utilized whenever possible, barring specialized adaptations specific to your block. Routines are generally called as macros (e.g. %kill_sprite()), but some have special setup conditions as described in the routine's .asm file.

  6. Do not submit unoptimized or overly specific Blockreator blocks.
    Blocks created using Blockreator must be optimized and made to use GPS' shared subroutines prior to submission. Furthermore, blocks deemed to be too niche will be rejected (ex. "solid to Player 2 if less than 40 coins collected").

  7. Include a print statement in the .asm file containing an appropriate description of the block's function.
    GPS generates .dsc list files that allow the user to preview a custom description of the blocks you add for user convenience. A description may be added to your block if missing, and may be altered if useless or misleading at a moderator's discretion.

  8. If submitting a pack of blocks dependent on one another to function (ex. slope setups), please include a sample list.txt and map16 file.
    For ease of use to the average user, submissions that require more than 5 blocks to work (eg. not packs of individual blocks) must include a base list file to work from, as well as a map16 page with the same order as the list.

Review the General ASM Guidelines as well before submitting your resource.