Views: 722,517,520
12 users online: Bille, BlueZy, chickaDEE Magazine, ECS.98, ExONightZ, JP32, Kazzzy, Maarfy, Manus, ReaLifePlumber, o tcdw, Telinc1 - Guests: 44 - Bots: 135Users: 37,744 (1,794 active)
Latest: bcupp76
Tip: When you're about to release your hack, make a patch first, patch it to a clean ROM, and then test that. This way, you are testing both the hack AND the patch.Not logged in.
Details for Player Health meter v4.0
SMW Patches - Player Health meter v4.0
File Name: Player Health meter v4.0
Version History: View
Authors: GreenHammerBro, Iceguy, K3fka, Ladida
Tool: Asar
Requires Free Space: Yes
Bug Fix: No
Featured: No
Description: This patch will add a health system based on the "numerical HP bar". However its has been heavily edited and added new features by GreenHammerBro:

-Custom blocks to damage, heal, and increase max HP.
-16-bit HP and max HP, you can now have up to 65535HP, Good for hacks that have made collectibles HP upgrades items that are being saved or RPG-styled hacks. Of course, you can change that to 8-bit for HP being less than or equal to 255 to save memory.
-display HP also as a bar in percentage (based on the HP meter for sprites in the patch section).
-display HP on overworld border, so the player know how much HP they have without the need to be in a level.
-All kinds of sprites (normal, custom, cluster, and extended) now have customizable damage, no more several sprites dealing 1HP of damage.
-perfect knockback, when hit, rather than the need to have higher backward speed, Mario loses control until he's back on the ground. Also, its programmed to knock away from the sprite rather than backwards.

Read the readme and VersionHistory.txt for more info.

Note that the bob-omb explosion itself share the damage as the bob-omb, since the explosion is actually the bob-omb sprite.

-Super status bar patch (recommended, should work with any status bar patches)
-uberasm tool
-GPS (if using blocks)
-Overworld Border plus (if your hack uses the overworld border)
Tags: health bar, hitpoints, hp bar, knockback, lifebar, needs remoderation, pokemon, rpg, sa-1
Download: Download - 400.58 KiB
Can you give me a single example of multiplication with unecessary size when using sa-1?

EDIT: I've found the issue, all of the unnecessary bit size and using SA-1 without processing SA-1 are found exclusively on the graphical bar code. The other codes that calls the graphical bar are fine.

I've updated to version 3.15 here.

This define now lets you force it to use SNES multiplication should the user ONLY uses this routine not executed anywhere else using SA-1:

 !Setting_SNESMathOnly = 0
 ;^Info follows:
 ;-Set this to 0 if your code gets processed by SA-1 and calls this graphical bar routine.
 ; If you have codes with at least one using SA-1 and other at least using SNES processing,
 ; also set this to 0.
 ;-Set this to 1 if *all* codes that call this routine are not using SA-1 processor.
 ;The reason for this is because if the user only uses the graphical bar routine on a SA-1
 ;ROM, but never processed the routine by SA-1, using SA-1's math registers is useless as
 ;the SNES's math registers ($4202, $4203, $4216-$4217) become available.
 ;Things to note:
 ;-SNES' math handles 8bit*8bit = 16bit numbers, all unsigned. This will be unavailable to
 ; be used if processing SA-1.
 ;-SA-1's math are 16bit*16bit = 32bit, all *signed*. The register is always available
 ; to use regardless if SNES or SA-1 being used.
Posted by: GreenHammerBro -
Have you read my comment? I wrote that SA-1 doesn't run on UberASM and needs to be invoked manually. You're therefore free to use WRAM and SNES registers because SA-1 simply does not process UberASM codes automatically (it's the same reason why the SA-1 pack hasn't remapped all of SNES registers and WRAM address ‒ the SNES processes them, not SA-1). If you have invoked SA-1 then sure, I could have understand the decision but your code doesn't.

Also, my point was that if you perform a 16-bit * 16-bit multiplication but clear out the high byte in both factors, you perform an 8-bit * 8-bit multiplication but time wasted resources because of the unnecessary processing of four bytes, not two. That was done multiple times and has nothing to do with the bar length or 16-bit addressing of HP.
Posted by: MarioFanGamer -
Oops, yeah, the routine that calculates the bar assumes 16-bit in case if the user were to have a large number of pieces/8x8 tile and/or a very long bar, which is possible to have more than 255 pieces filled. It is a reuse of the graphical bar code made to handle large values.

The reason why the graphical bar routine uses SA-1 multiply and divide registers is because in case if the user needs to use the routine in SA-1 mode; you cannot use WRAM and SNES registers in the SA-1 world.

For initalizing, thankfully that is easy with using uberasm tool's init feature.
Posted by: GreenHammerBro -
Moderation-PTSD... Moderation-PTSD... Moderation-PTSD...

Given how complex the patch is, it surely .

That being said, the bar code can take some massive optimisations. Specifically, SA-1 doesn't run during gamemode codes at all! (or even in UberASM altogether).
This means for example, you're free to use SMW's multiplication and division registers to perform a them.
Furthermore, when you need to perform a 8-bit * 8-bit multiplication, you performed a 16-bit * 16-bit one. No need to do that. SNES multiplication registers are unsigned and SA-1's ones are 16-bit so it 8-bit multiplication is unsigned by nature because the high byte is clear in these cases. Likewise, even the forced 32-bit * 32-bit multiplication for an unsigned 16-bit * 16-bit multiplication is overkill just to have an unsigned 16-bit * 16-bit multiplication. There is a much better way to perform an unsigned 16-bit * 16-bit multiplication.
I also dislike the idea that certain variables are saved SRAM. They could be initialised somewhere else as well.

I also have leaved the SA-1 because the patch itself, the blocks and the UberASM codes work with SA-1 but BW-RAM plus doesn't want to initialise the values on my end.
Posted by: MarioFanGamer -

The spazzing is actually due to licecap's framerate recording (up to around 30fps it can record). In actuality, the bar flickers at 60fps to look like a transparent segment representing HP loss (jumps between your previous HP and your current HP). Its common that video games that display HP as bars display the amount loss. Kirby Super Star Ultra have done this.

For the damage for every block. Each block in this package deal fixed damage, therefore if you need a scaling system, you would make duplicate blocks (best to give them different graphics for the player to know that the blocks deal different damage).

Of course, if you wanted to reuse the same block, you have to edit the code to check the level number to determine damage.
Posted by: GreenHammerBro -
Why does the bar spazz around when you take damage? In the screenshots

And also do you need to setup the damage for every block? What if you want damage to scale?
Posted by: Dorothy -

Uh, No. Mario will remain at least super reguardless of his HP. It doesnít follow the SMB2 health-to-Mario-Status gimmick.

Also, itís rare to land on 1HP without dying, as damage often deal more than 1HP loss.
Posted by: GreenHammerBro -
will health 1 turns back into small mario
Posted by: Guscraft808Beta2 -
Entering a door/pipe doesn't cancel the countdown (resumes in the next room), but the goal does stops the HP from counting down (to prevent unfair situations) as well as start+select. If you want to cancel the countdown, in gamemode 14 init (under the init: label in GM14.asm), add this line:

	LDA !Freeram_PlayerHP_MotherHPDirection		;\Don't cancel healing
	BNE ..Healing					;/
	REP #$20
	LDA #$0000					;\Cancel damage
	STA !Freeram_PlayerHP_MotherHPChanger		;/
	SEP #$20

Remove the REP and SEP #$20 as well as turning LDA #$0000 into LDA #$00 if you have !Setting_PlayerHP_TwoByte set to 0.

Healing on the other hand doesn't unfairly cancel out on these situations.

I don't recommend HP countdown during game lock; because it would be inconsistent with the timing of other things (like a glitch with koopas ignoring $9D when they fall and interacting with layer), they shall be affected indiscriminately.

Maybe the game can freeze / lock ($9D) when Mario takes his final hit:
- Mario's death animation will be presented, but he won't fall off the screen yet.
- HP can continuously decrease to 0 while the game is locked.

would be weird. The player will have to wait till the HP hits zero before the animation kicks into gear.
Posted by: GreenHammerBro -
SUGGESTION: On screenshots 6 and 7, when Mario takes damage at 5 HP, his HP gradually decreases to 0 as opposed to instantly killing him. I was wondering, what would happen if a player took their final hit and entered a door / pipe, touched a goal? Would the player's HP continue to decrease in the other location, killing him off, or would the HP freeze in place? (i.e. 1-4 HP)

Maybe the game can freeze / lock ($9D) when Mario takes his final hit:
- Mario's death animation will be presented, but he won't fall off the screen yet.
- HP can continuously decrease to 0 while the game is locked.

When Mario's HP goes to 0, then his death animation resumes and he proceeds to fall offscreen.
Posted by: chineesmw -
-First picture shows the feature of HP being saved.
-Second picture shows the “rolling HP” from Mother/Earthbound.
-Third picture shows the traditional standard damage unlike above.
-Fourth picture shows max HP increased.
-Fifth shows you can have up to 65535 if you have set HP to 16-bit.
-Sixth shows the knockback when set to “remain stunned until StunTimer hits 0 or lands on the ground”
-Seventh shows a knockback that remains stun until the timer hits 0 reguardless if the player is on the ground or not (noticeable that the player gets knocked further).
-Eighth shows you recover 1/2 HP after death when returning to the map.
Posted by: GreenHammerBro -

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2019 - SMW Central
Legal Information - Privacy Policy - Link To Us

Total queries: 28


Follow Us On

  • Facebook
  • Twitter
  • YouTube


  • Talkhaus
  • SMBX Community
  • GTx0
  • Super Luigi Bros
  • MFGG
  • Gaming Reinvented