Language…
7 users online: Ashura4126, ASMagician Maks, Aurel509,  BeeKaay, DuDuchE, FedoraFriday, PANDARF - Guests: 97 - Bots: 106
Users: 69,762 (2,525 active)
Latest user: GeryU

Player HP meter v4.2

SMW Patches → Player HP meter v4.2

LinkShow random

Submission Details

Name: Player HP meter v4.2
Authors: HammerBrother, Iceguy, K3fka, Ladida
Added:
Version History: View
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.

Requirements:
-Super status bar patch (recommended, should work with any status bar patches)
-uberasm tool
-SRAM/BWRAM plus
-GPS (if using blocks)
-Overworld Border plus (if your hack uses the overworld border)
Tags: health bar hitpoints hp bar knockback lifebar lorom pokemon rpg sa-1
Comments: 29 (jump to comments)
Download 403.75 KiB | 676 downloads

Screenshots

View all

Comments (29)

Skewer Link
For something as fine tuned and specific as this is; you need to make sure you go over your readme and correct things as needed. For instance, Step 3 asks you to patch PlayerHPPatch_4_0.asm when that doesn't exist inside of your download; it is instead PlayerHPPatch.asm. Now this may seem obvious to more experienced people, but people who are new to this are going to be looking for what the Readme lists, not something similarly named. Also with how specific this is, if one thing goes wrong, there's no telling if it's because of a lack of maintenance on the readme or something else.
Dark Mario Bros Link
that's interesting, and looks similar to some games I know
like Cave Story for example
 Major Flare Link
Its insertion is a bit of a hassle, but it works. So, no harm done in approving this.
HammerBrother Author From older version: Player Health meter v4.0 Link
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:

Code
 !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.
 MarioFanGamer From older version: Player Health meter v4.0 Link
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.
HammerBrother Author From older version: Player Health meter v4.0 Link
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.
 MarioFanGamer From older version: Player Health meter v4.0 Link
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.
Guscraft808Beta2 From older version: Player Health meter Link
HP1 turns back into small mario
HammerBrother Author From older version: Player Health meter v4.0 Link
@Dorothy

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.
Dorothy From older version: Player Health meter v4.0 Link
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?
HammerBrother Author From older version: Player Health meter v4.0 Link
@Guscraft808Beta2

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.
Guscraft808Beta2 From older version: Player Health meter v4.0 Link
will health 1 turns back into small mario
HammerBrother Author From older version: Player Health meter v4.0 Link
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:

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

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.

Quote
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.
chineesmw From older version: Player Health meter v4.0 Link
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.
HammerBrother Author From older version: Player Health meter v4.0 Link
-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.
 MarioFanGamer From older version: Player Health meter Link
Something like this:
Code
; Where 
!CallRoutine = $01EEEE	; Random value, you have to replace it to a value containing actual freespace from banks $00-$0F

org !CallRoutine
JSL Routine

freecode	; By which I don't mean you should necessarily put the routine in a new freespace, it can be on an existing freespace too.

Routine:
; The routine's code
RTL

A couple patches like Extended No More Sprite Tile Limits and Shared Subroutines do it that way.
HammerBrother Author From older version: Player Health meter Link
Originally posted by MarioFanGamer
For GHB: You could have added a dummy JSL somewhere into the ROM. That way, the user don't have to write down the value for cluster sprite damage. In fact, the same can apply for extended sprites too especially sicne PIXI now supports.


what do you mean dummy JSL?
 MarioFanGamer From older version: Player Health meter Link
A very complicated set up only to have a new counter. But despite that, I would chose this patch if I need an HP system.

For GHB: You could have added a dummy JSL somewhere into the ROM. That way, the user don't have to write down the value for cluster sprite damage. In fact, the same can apply for extended sprites too especially sicne PIXI now supports.

A couple notes for the users: Be careful if you use Iggy and Larry since their platform causes some problems with the knockback and can cause you to die instantly. The other bosses should work fine since they a solid ground and not one which tilts.
Also, if you use SA-1, remember tp change the value at "!Ram_CustSprBit" to $400040 and "!Ram_CustSprNum" to $400083. It would have been better if the patch detected it but... w/e.
thewhiskas27 From older version: Player Health meter Link
Me : GHB ! What is the Max health's power level ?
You : IT'S OVER 9000
Me : WHAT!?!?!?!
TheOrangeToad From older version: Player Health meter Link
it's over 9000
DiscoTheBat From older version: Player Health meter Link
While this is a bit complicated to set up, it is a fine patch to add a HP system for SMW. I'd recommend that next time, you include the list files for UberASM tool, to help users in setting this bar faster. Nevertheless, it is a fine job.
HammerBrother Author From older version: Player Health meter Link
To update list:
-fix the default freeram issue, I realized its using level tile RAM address.
-use the new bar display
-display bar on OW border
--improve the routine that writes tiles to ow display
-use ObjecTool for the game to remember if a max hp upgrade is picked up.
DiscoTheBat From older version: Player Health meter Link
A good pokémon-like HP bar, can fit several situations that the hacker can create, making a different hack.
DiscoTheBat From older version: Player Health meter Link
You should really fix the syntax here. JSR : RTS that could have been replaced with JMPs for example. Still a sweet fix.
Vitor Vilela From older version: Player Health meter Link
No SA-1 support bane
DiscoTheBat From older version: Player Health meter Link
The patch works as is however, it can get users that aren't experienced in ASM pretty confused due to the confusing syntax and pretty much copypasting from the SMWDisC.

Nevertheless, it is a really good patch, just have these issues in mind for the possible next version.
HammerBrother Author From older version: Player Health meter Link
Have a better knockback, loses controls until landing back on ground, or if you change the settings, you'll also gain control if the timer expires. Useful (you could call it "evil") for narrow platforms where enemies can easily knock you off into a bottomless pit.
HammerBrother Author From older version: Player Health meter Link
Now fixes two possible glitches:
-The heal block is was checking if it's healing over the maximum incorrectly: "if the added HP value (before storing it into current HP RAM) is greater than current HP, set hp to maximum". It should now check if the added value is larger than maximum, rather than the current.
-on the overworld, in case you have a lot of vram writing on the boarder, I made it write the meter only ONCE during overworld load init (as in, 1 frame just like the level load), and keep running during "overworld" (the time the player has controls), but not run during save prompt. This reduces the chance of windowing HDMA bugs and top-of-screen flickering.
HammerBrother Author From older version: Player Health meter Link
Greenhammerbro stats:
Codename: programmer
HP: 20/20
ASM: 40
Music: 0
Let's play hacks skill: 25
Opcode tricks: 1
Ability: code understanding. Be able to understand what a block of code does and purpose without comments.