So for my game, I am attempting to draw a health bar on the screen. The health bar is a gray capsule on the side of the screen that contains blue squares separated by black space. Each time the player is hurt, I want one of the blue squares to go away.

I am trying to determine the most efficient way to go about redrawing my health bar after the player is hurt.

If I have a total of 10 squares, I wouldn't want to draw 11 different health bars (1 for empty) in paint (currently my sprite-creation program) and load a new image each time the player is hurt. That is dumb. And I considered making a small bitmap the size of a square that is black, which would be drawn over a blue square every time the player is hurt.

I also considered creating one blue square bitmap, and drawing that to certain locations within the health bar to make it fill up. Once the player is hurt, that draw_sprite() function corresponding to that square could be skipped over.

But again, this procedure seems... not right. I don't know why.

Any suggestions?

Thank you,
opiaboy

I'd either go with that last option, or using rectfill() instead to draw the health blocks.

Also if you're double buffering, you're probably going to be redrawing the entire screen each frame, so you won't need to draw over other colors, just draw blue bitmaps or rects for each health square the player still has, and none or black for ones the player doesn't have.

In fact, you could draw a translucent black rectangle that covers the entire health meter, then for the area that the player still has, draw a solid colored rectangle over top of that. That should look a little fancier. If you get fancy with drawing a couple rectangles for the colored part, you can even make it look shiny or glassy.

This method would work perfectly! I mean, I was thinking about something like this (I forgot a about the rectfill function though). But the reason I didn't do so was because I was worried that it wasn't the most straightforward or efficient method. Is there anything else that would be more efficient? If there is I have no clue what it would be.

Thank you for your help!

EDIT: Oooh, making it look glassy would be neat!

When the game is COMPLETELY finished (meaning, I have no clue when I would get to this) I want to only redraw sections of the screen that need to be redrawn. So... would that change anything?

It's too early to really worry about how efficient your program is. Get your program working first, and then profile it to see if/where you need to optimize it.

Let's say that you have 10 health bar 'boxes' to indicate health.

If the player gets hit once, does an entire health 'box' disappear, or does it only fill part of the way?

[x] [x] [x] [x] [x] [x] [x] [x] [x] [x] // full health
[x] [x] [x] [x] [x] [x] [x] [x] [x] [ ] // hit once (last one is empty)

...or...
[x] [x] [x] [x] [x] [x] [x] [x] [x] [/] // hit once, only 1/2 of last bar is filled

If these will simply be "10 hits" and the player is dead, you can simply loop from 0..9 and print the health 'box' next to each other (with a small offset for the gap between then).

Otherwise, you will want to use rectfill() or similar, like Thomas suggested, and fill up the each 'box' the appropriate amount (1/2 per box, or even 1/10th so 10 boxes of 10 gives a total of 100% health).

Thank you all for your help!

That is the reason I love using Allegro; not only are there about a billion examples and tutorials floating around the internet, but the forums here are filled with people who respond promptly and are willing to help aspiring programmers.

Thank you again... and Edgar, what do you mean by "profile"?

A profiler is a special tool that measures the time each of your function takes. If you're using MinGW then you compile your sources with the -pg flag, run your program and then use gprof to analyze the profiling log produced by your program (when a program compiled with -pg is run, it produces a file called a.out, which contains the profiling information).

>mingw32-g++ -Wall -O2 -pg -o main.exe main.cpp -Wl,--subsystem,windows
>main.exe
>gprof a.out > main_profile.txt
>type main_profile.txt

Aaaah, got it. I'm using Visual Studio C++ 2008 Express Edition... if that helps?

Express doesn't include a profiler.

Give Very Sleepy http://www.codersnotes.com/sleepy a try, it is my favorite profiler.

If you like a good IDE, that is free and has a profile, I recommend netbeans.

Netbeans and MS visual Studio are the best IDEs that I have used as far as interpreting the source code goes (such as correctly colouring and fading pasts based on macro definitions in conditional compilation blocks and the like). I use Visual Stuodio 2010 Express wit the win7 sdk 7.2 for 64bit pe compilation support on windows 7, and netbeans on archlinux (I do profiling and debugging mostly on linux but I further develop the same code on both platforms interchangeably because the IDEs are of the same high tier AFAIC).

Either that or +1 to trying very sleepy

But seriously I slightly prefer netbeans' interface and it has a heap usage profiler visible by default while it is running your program. Just create a makefile project with it and write your own Makefiles, that's what I do. The only project configuration I do in netbeans beyond telling it to call my makefile is telling it which preprocessor defines I have as active by default so I can see my code as it will usually compile.

For Intellisense on Visual Studio I use Visual Assist

You GOTTA have Visual Assist X for Visual Studio. Otherwise, you shouldn't be using Visual Studio . Really; it makes that much of a difference.

I've been doing all of my programming in a regular text editor that at least supports regular expression Search And Replace. Then, I've just compiled my projects from the command line. I know that it isn't very efficient, but it makes more sense to me. Then when I really need to work in an IDE that builds for me, I actually know what's going on "behind the scenes" and I can troubleshoot any errors that surface.

Netbeans IS awesome, although it's a bit slower. But it's almost the top performer for context-sensitive code completion.

In the 90s, this was a valuable technique and was called 'dirty rectangles'. These days, computers are powerful enough that most people just render the whole screen from scratch every frame. It's good because it enables you to move things around more flexibly (e.g. for parallax, camera shake and the like) without worrying about losing any efficiency.

I just wanted to say that I disagree with this 100%. Always write code with efficiency in mind.

Have you ever complained about Flash sucking? It's because the programmer who wrote that particular applet was not thinking about efficiency.

I'm not saying write inefficient code just so you can get your project done, I'm saying that it's more important to get things working first and not worry about how uber efficient your code is. If you spend all your time perfecting and optimizing your code, that's time taken away from actually finishing a project. Most optimization won't actually have a visible effect on your program execution, because only small sections of code are actually time critical and are potential bottlenecks.

I say, get a prototype working first, and then go back over it to see what you could do better. Once you have more experience, your initial code will be more efficient and effective in the first place anyway.

My gut feeling is you're doing OK and you're not going to have too many problems with efficiency, so don't worry.

When it comes to Flash, I think there are plenty of things Macromedia could have done to encourage people to write efficient code. If you design an editor for artists and then expect them to have the approach that an experienced old-school programmer would have, you're doing it wrong.

Efficient, sure. But don't spend hours thinking about a micro-optimization problem for a function that will probably not use up more than 0.5% of the total render time per frame, regardless of how poorly written it is.

The road to madness is paved with premature optimization

filling a rectangle is a bit ugly. Why not create yourself a decent image in a paint program then crop the image based on the health level onto the target buffer.