Language…
17 users online: 1LE, AJ1Ayrton, Alewx_, AnkisethTheMonk, codfish1002, Cracka, deported, drkrdnk, dylanthebluekoopa,  Eden_, Ice Man,  MarioFanGamer,  MarkAlarm, revolug, Swaguy14256, tigerten350, Zatara - Guests: 112 - Bots: 198
Users: 67,566 (2,007 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.

Patches

Patch Submission Guidelines

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

  1. Your patch must work with the latest version of Asar.
    We no longer accept patches designed for any other assemblers such as xkas or wla. You can find the latest version of Asar here.

  2. Patches that consist exclusively of simple hex edits must be of sufficient functional depth.
    Generic singular edits such as "modify Banzai Bill's X speed" are better posted in the Tweaks section. Refer to the Tweaks Section guidelines to determine whether your code is best suited as a patch or a tweak.

  3. Your patch must set freespace correctly if applicable.
    A patch that inserts code in freespace must use an autoclean command behind one or more labels present in freespace, as well as a freecode or freedata command as appropriate where the inserted code begins.

  4. Patches that hijack timing-insensitive run-every-frame routines are best converted to and submitted as UberASM code.
    It is highly recommended - but not strictly required - that a patch hijacking a single routine for the sole purpose of running every frame be converted to code to be inserted with UberASM Tool and submitted in its respective section. This applies to code meant to run in-game or in NMI.

  5. Patches that hijack during a blank will be moderated for efficiency much more strictly.
    Code that runs during NMI or in an IRQ must be very cycle-friendly to avoid overflows (see: black bars, graphical glitches), and optimization will be given significantly more weight as a rejection criterion during moderation; consider submitting NMI-only code as UberASM.

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