| Name: | Player-following Air Meter |
| Authors: | HammerBrother, JackTheSpades, MarioE, mikeyk |
| Added: | |
| Version History: | View |
| Tool: | PIXI |
| Type: | Standard |
| Dynamic: | No |
| Disassembly: | No |
| Includes GFX: | Yes |
| Description: | Same As mikeyk original Air Meter But instead of following the screen's position, it follows the player's position. I submitted this because since sprites overlap in front of the meter (Its suppose to be in front of everything, like the HUD would), it obstruct the viewer from seeing it (especially in a level with no vertical or horizontal scroll), so when this meter follows the player, its easier to see the meter due to the position located next to the player and it moves with the player too. I ask Alcaro if I can submit this and he says yes. Credits: mikeyk, the original author of the graphical air meter MarioE, for helping me with the request of this meter JackTheSpades, same as above Now SA-1 hybrid. |
| Tags: | air meter lorom mario-following position sa-1 |
| Comments: | 11 (jump to comments) |
| Rating: |
Download
9.52 KiB | 1,197 downloads
Comments (11)
- Lunar Magic 3.40
- SA-1 Pack 1.40
- Snes9x 1.62.3, Bsnes-plus 05
- Pixi 1.40
- GPS 1.4.4
Notes:
The only substantive change to the code itself was the change from using $13 to $14, which doesn't really change the behavior much in practice. Also changed were the commenting out of an unused table (should probably just have been removed to avoid confusion), and the inclusion of a .json instead of a .cfg for the sprite. Made sure it still inserts and functions and accepted the update, however, there are some lingering issues with the overall design that I want to mention below.
- I changed instances of "
;>1 byte" to simply "; 1 byte". I realize this may go against your normal comment style. However, this can be confusing to anyone looking at this (including me), where a plain reading of this is "greater than 1 byte". More on free ram usage below also.- As long as you're updating the .cfg to a .json, you might as well give it display info for LM. Even for something like this, where the graphics are liable to get moved around, it'd be helpful to have a text display, especially since the exact position it's placed doesn't really matter.
- Please be aware that while comments and documentation are very good things to have, there are limits where excessive and unnecessary detail get in the way of more important information that should be presented. In the update, you added a table of dense calculations that just aren't needed. Does anyone really need to know that a setting of FF drains exactly 0.234375 points per second and lasts 18 minutes and 8 seconds? Is anyone ever going to actually use this? But this does wind up making it harder to notice the more important information below it. If you do want to want to include the total time for each setting, it could be done in a single line: 4.25s, 8.5s, 17s, etc.
- On that note, if the only valid values for a config setting are of the form 2^n - 1, it's generally preferable to simply have the user enter a value from 0–7 and then compute 2^n - 1 in the code. Moreover, this is unnecessarily restrictive anyway. There's no reason why you couldn't simply keep a separate timer and let the user specify the number of frames that should elapse between decrementing of the meter value. This would give at least a little more granularity on the low end (but not much...more could be added in other ways), and would avoid the whole $13/$14 issue and inconsistency between total time anyway.
- This sprite should not be using byte of free ram to keep the meter value. This could simply be kept in an unused sprite table instead; the free ram usage is completely unnecessary here. It uses another byte to decide if it should be draining or not, meant to be set from elsewhere. This one's a bit more understandable, but it could also be avoided (at the cost of a little extra processing time) by letting the block find the sprite and setting one of its sprite tables directly.
- The sound effect behavior could probably stand to be settable as an option to the user.
- Some of the options would probably make more sense as extra bytes, rather than compile-time options.
- I see this a lot, and it's probably just more a personal preference, so take the following with a grain of salt. But I see the included exgfx place the meter graphics with a specific sprite file (with chucks, platforms, etc). It's probably unlikely that someone wants to use this exact sprite set, sacrificing whatever got sacrificed exactly, so it might make more sense to just include a basic .bin with only the meter graphics, and then let the user arrange them as needed (along with making it easy to set up the tilemap). But again, this one happens a lot, and opinions vary, so this suggestion is a lot softer.
And, the link to the original sprite is broken.