A Small Edit: Here is the link to my post on how to disable the built in HUD, but I also need to update that post. If you follow the instructions there, it will disable the HUD, but there will still be some code elsewhere related to the HUD that is just taking up a little bit of space. So I'll hunt those down at some point and add them to that post.viewtopic.php?f=3&t=896

I am going to divide this post into 3 sections: The Pros and Cons of doing this, an attempt at a High-Level Explination on what the code does, and finally the code itself and How to Hook it Up. Read them all, or just the ones that are relevant to you.

Pros and Cons
Pros:
-Uses way less memory than the built in HUD to give you more room to work with other things.
-Gives an alternative look.

Cons:
-One less sprite available on the each scanline if you are just doing a health bar. Two less if you are also displaying a weapons bar.
-Less sprites to uses on screen in general. For me, I am using 8 sprites per bar, plus 4 sprites for the caps at the top and bottom which means 20 sprites are going to this health bar. Don't forget that you are limited to 64 sprites at a time. For me, I think that should be fine for what I have planned.
-You have to use some graphical space in either your game objects or each of your monster files. I went with putting the graphics in my game objects.
-Unless you're using also textboxes, the HUD graphics may end up going unused which means that some of your background graphics space will go to waste. I bet there is a way you could re-purpose that space, but I haven't looked into it, so I don't know what would be involved.
-More juggling of your sprite palettes.
-The way I have it written, the health bar goes from 0 to 255, but it only has 32 increments. This means if you are at full health and take 1 point of damage, you will not see a visual change. You need to take about 8 points of damage to see the bar go down 1 step. The easy "fix" to this is to have all enemies give at least 8 points of damage. It wouldn't be difficult modify the code to make the health bar have more divisions, but that would either mean more sprites on screen, more graphic space being used, or both.

Ok, I think you have been sufficiently warned. Now on with the show!

High-Level Explanation

The health bar is made up of 3 sections: Full bar segments, empty bar segments and sometimes one partial bar segment. Each bar segment is a sprite and there are 8 sprites used for the entire health bar. If you are unfamiliar with binary numbers, then here is a quick crash course on finding the value of a binary number. If a bit is equal to one then that adds a certain value to the total of binary number. Using the chart below, you can find out which bits add which value.

So this means that if you have 1000 0000, then the only on bit is bit 7 which has a value of 128, so the value of the number is 128. Or to make a more complex example, if you have 1010 1001, you have the bits on for the values 128, 32, 8, and 1 so you add them up to get 169. As I said, the health bar is made up of 8 sprites, each accounting for 32 health points. So if the player's health is 128 or 1000 0000 in binary then I already know that the total health bar is 4 bar segments full (because 128/32 = 4). Or another way you could look at it is that 128 is half of 255ish, so the health bar is half full. So by looking at the last 3 bits (the ones on the left), I can tell how many full bar segments the health bar needs. once I have the number of full bar segments, I can subtract that number from 8 to get the number of empty bar segments. If I have any remaining bits then I can do a check to see what kind of partial bar segment needs to be displayed between the full and empty bar segments. So here is that bit chart again, but this time also showing how much of the health bar each bit represents.

So all of that determines what needs to be displayed. From there we do a loop to display all the full segments, then display a partial segment if we have one, and finally do another loop to display the empty segments. And that's it. I skipped some finer details, but if you made it this far, you should be able to understand the rest from looking at the code.

How to Hook it Up
Step 1:
Open HandleUpdateObjects.asm which is in Routines/System. At line 31 you should see this line of code.

A brief explanation of what we're doing here.
You may recall in the Adventure module that when you get you sword, it will display a little sword sprite in the HUD. This is where that happens in the code, so we're going to use that. But first we need to do some modifications. The code for the sprite HUD bar is pretty long, so we need to set up a trampoline. When you use the JMP command you can only move 128 lines in either direction, and because the code is so long we need to use a JSR to "bookmark" our position so we can find our way back, to put it simply.

Step 3:
Go into NESmaker. Go to Project>Project Settings, then click on the Script Settings tab. Find which file is defined for "Handle Sprite Pre-Draw." Here is an image of what it looks like for me, but keep in mind that I have it pointing to a different location than the default. I think the default was in the Adventure module scripts.

Step 4:
Now that you know which file we're going to be working in, go ahead and open it up. If you're using 4.0.11, then this file is probably all commented out. We can add our code underneath it.

What we are doing here
First we're checking to see if the game is in the main game state. Then if it is, we go on to make draw the 4 sprites for the caps at the top and bottom of the bars. Next we check if the player is still alive because weird things happen after we die. And finally call my macros for drawing a status bar.

Here is the code for this step. The main thing you need to know is on the DrawSprite lines, you need to determine what values you want for your game. In particular, the 3rd argument determines which graphic it will use. If you put #$00, it will use the top left graphic of your game objects sheet. If you use #$FF, I will uses the bottom right graphic whatever monster sheet is currently loaded in game. Just remember the first digit represents the column of the graphic in your sheet, and the second digit represents the row. I had my graphics aroung the lower right of my game objects sheet.

Final Step:
This is a whopping huge macro, but it makes it easier to draw both a health bar and a magic bar, and any other bars you may feel inclined to include in your game. I left a comment at the top of the macro to explain what each argument does, so check that out. If you want to know how it works, just check out the High-Level Explanation section above. You can either put this code in the Macros.asm file in Routines/System, or do what I did and make my own Macro file. If you do the latter, be sure to include you file in around where Macros.asm gets included in MainASM.asm around line 8.

And that's it! I hope I didn't make too many typos writing up this post. At some point I will probably modify this macro to have a variable height so that the health bar can be expanded after getting items, but I probably won't make it handle more than 8 segment because I don't want to waste sprites. Instead I will probably make the health bar start short an then work up to 8 sprites tall. But for now I am eager to get back to programming mechanics for my game.

I will definitely be using this, and definitely will be trying to make it start small and grow larger(And probably failing a bunch before giving up, then someone else will have the answer, so it all works out in the end).

I like it a lot. This'll come in handy for a major project of mine down the road. What GPL does this fall under so I can make proper attribution/contribution if I use it.

Oh, I totally did not think that far ahead. Basically if you feel this warrants crediting, I'd be honored to be mentioned and you can list me as Joe Rossi. But I'm also not going to comb through your credits to make sure you credited me.

I will definitely be using this, and definitely will be trying to make it start small and grow larger(And probably failing a bunch before giving up, then someone else will have the answer, so it all works out in the end).

Awesome! I'll definitely be interested to see what you come up with. I have some ideas about how I'll go about it, but I'm very anxious to get back to programming mechanics and the health bar can be a later issue for me. Especially considering I barely have enemies at the moment.

I'm having the hardest time making this work....I want to make a copy of the HandleUpdateObjects.asm and replace what's needed and create a copy of it so it doesn't clash with the other games of mine and when exported it threw out label already defined error..... I'm like what!?!

I feel I need copies of these so it works as I tried to follow this code.

"Label already defined" means that you have made two or more labels with the same name. The console will tell you which line the error happened on, so you can find out with label it was and then search for where it has been repeated.