| File Name: | Powerup Selector + Status Bar Indicator |
|---|---|
| Submitted: | by Nitrocell Inc. |
| Authors: | Nitrocell Inc. |
| Type: | Level, Game Mode |
| Includes GFX: | No |
| Includes Hijack: | No |
| Featured: | No |
| Description: | This UberASM will enable selecting powerups by pressing Select button. It contains two files, one for just powerup selection, and other the same but has modifications that adds "next powerup" indicator to the status bar. NOTE: For current version, I only supported powerup selection when player is on the GROUND. So pressing Select when in air will not change powerup. For more info and list of values of that indicator can be read in readme.txt file. |
| Tags: | game mode 14, level, lorom, power-up, sa-1, select, status-bar |
| Screenshots: |    |
Some specific things I noticed that should be addressed before resubmitting:
- In the non-status bar version, there's an incorrect comment that up should be pressed instead of select.
- First, a general note for UberASM resources: defines for
!addr and such are automatically provided by UberASM Tool, so you don't need to repeat this in resource files.- In both files, there's no
RTL in the init: routine. There are times when you want to fall through and also execute the main code at the same time, but that doesn't seem to be intentional here.- You have some checks like
if !foo = 0. This works with current Asar, but it probably won't in the future. It should use if !foo == 0 instead. Check out the Asar documentation for further detail.- You have two separate files in the submission, but they essentially provide the same function, just that one also draws a letter on the status bar. It would probably make more sense to simply combine these into a single file with a define that either enables or disables this feature. (On a side note about this feature, I'm not sure how useful it is in the first place. Mario's powerup status is already pretty apparent from just looking at Mario)
- Also relating to ease of use, in several places you have comments that say something like "Comment this if you want to ___". It's not reasonable to expect someone to scan the code in this level of detail to notice this. If you want to have a configurable feature, make a define for it at the top of the file with other configuration options and then use use an
if/endif block to implement it.- (Speaking of configuration options, it would probably be a good idea to have the sound effect as one of them. People might want to use a different (or no) effect instead.)
Some specific optimization-related stuff:
- Stuff like
LDA #$00 : STA $0DC2|!addr should be replaced by STZ $0DC2|!addr instead. Similarly, LDA $19 : CMP #$00 : BNE + should just omit the CMP.- In one spot, you have
Code
BNE .changeMarioPowerup ; / JMP .return ; If not, return .changeMarioPowerup:
but the
BNE/JMP should just be a BEQ instead here. And if you do need an unconditional branch, use BRA instead of JMP if it's close enough.- In the status bar version, you have a table:
Code
PowerupsTable: db $00,$01,$02,$03
which you index with the powerup state to get the....powerup state? This doesn't actually do anything. On the other hand, it might make sense to keep a table like this if you want to make the order though which to cycle customizable by the user. On top of that, when you do actually need a table for the tile number to use, you instead do a bunch of CMP/BEQs instead of just looking it up.
I think that's most of what I wanted to say here. I know having a submission rejected can be discouraging, but please feel free to reach out to me if you have any questions or would like some help.