Hmm about float, then I think I should use int for most of my numerical variables then right? Such as timers and ammo, the ones that need to be precise.

You should be using float if you want any kind of precision.

But they just said that adding and/or subtracting a float sometimes won't give you the same number back/the one you expect.

Quote:Original post by Antonym
Hmm about float, then I think I should use int for most of my numerical variables then right? Such as timers and ammo, the ones that need to be precise.

Quote:
But they just said that adding and/or subtracting a float sometimes won't give you the same number back/the one you expect.

I think you may be being misled by the word precise. Don't confuse it with the word accurate. Floating point numbers can represent decimals precisley, eg 3.14. An integer could only approximate it to 3. However, because of the way floating point numbers are stored, their accuracy cannot be relied on beyond (I think) the sixth decimal place. eg in 12345678.901, you can't garuntee that anything after 6 will be correct. However, for games this is usually sufficient.

Integer values, on the other hand, are not very precise but absolutley accurate. Provided you don't ask an integer to represent a value it can't (too big, or a decimal) it will represent it perfectly.

For keeping track of something that should stay as whole numbers, such as ammo or health, you should use integers. You don't need a decimal for ammo since you won't be using half bullets, and you don't need a float for health unless you're doing something very unconventional (and really, if you were going to use floating point health values it'd be easier to just shift everything up a few decimal places and have giant health values).

Using floats for health is unconventional? Why? I suppose then damage too would have to be in ints.

Quote:Original post by Antonym
Using floats for health is unconventional? Why? I suppose then damage too would have to be in ints.

Well concepts like health would've started in pen and paper games. If you represent a number as an integer you limit the precision, which makes storing it easier. Imagine this scenario...


Health: 100
*Goblin hits you for 3 damage
Health: 97
*Goblins mace of smiting reduces your health by 5%!
Health: 92.15
*Goblin hits you for 3 damage
Health: 89.15
*Goblins mace of smiting reduces your health by 5%!
Health: 84.6925
...


Pretty soon your health will be a long number. So you'll probably end up just shortening it to a few decimal places anyway. So why bother using a float?

It's far easier to say "all health is in integers. Round decimals down".

Oh I see, thanks a lot ^_^.

1) I don't think powerups necessarily have to do anything. The powered-up thing can hold a container of power-up objects, and when you call a member function that calculates one of its current statistics, it looks through the container for powerups that affect the stat, and applies the necessary adjustments.

2)

Quote:Is it normal to have this amount of variables?

SpriteInstance sprt_instance; // don't use words like 'Instance' in class or// variable names. The class isn't an instance; the instances are. And you // already know the instance is an instance, so you don't need to say it.b2Body *body;obj_type type; // consider using polymorphism instead of remembering a "type"float hp_max; // make a struct to represent "X out of Y" type values and usefloat hp; // it for these twofloat dmg; // what is this?float pts; // what is this?bool hit; // calculate this on demandbool dead; // calculate this on demandDWORD show_health; // what is this?DWORD last_show; // what is this?DWORD last_homing; // put these last two into a struct probablyDWORD homing_duration;

You can imagine similar changes/questions for the other classes. :)

Quote:
Heal: Replenishes hit points.
Score: Gives you score points.

Okay, so those take effect instantly, and just once, and don't need to be held onto or timed out. You'll want to allow for that possibility too. :)

Quote:It's just I am handling about 30 variables per major object and it already scares me a bit. Great idea, having a class per 'stat' would really help and crunch things.

Yep. Decomposing things hierarchically is a good way of managing that. :)

Oh the reason it's called 'SpriteInstance' is because there is a 'Sprite' class that holds the texture along with its width and height, the spriteinstance class holds a pointer to a an instance of the Sprite class and also holds the frame width, height, current column and row along with other animation related functions. If there are better ways to handle this I'd love to hear.

The object_type variable is mostly check variable, collision related. For example I removed hp from the object class and passed it on to the ship class(since only ship uses it). I don't want any damage involved in a collision that doesn't involve the ship class(Otherwise I'd get an error).

the show_health variable is because I only want to display an object's health bar if it suffers damage.
I already added several classes.
cStat: has a base value and a modified value for a stat. This also has a vector to store buffs, each stat of the object is now iterated through on each game iteration to check if any buffs have expired, if so then the buff is removed from the vector and the stat is recomputed(set back to base and each buff's effect is added again to the mod value).
cBar: inherits from cStat. Has a baseMax and modMax members(To know max hit points/energy/shield).Has 2 spriteinstance members(To show the empty health bar and the full health bar). Also has a duration member to know wether to display the bar or not(if <= 0 don't display).
cBuff: a class with a generic 'amount' member and a virtual function called 'effect' that takes a cStat as a parameter. The effect function is defined on the different buff classes that inherit from cBuff.

pts is how many points the object is worth.

About the bool hit and bool dead. The first was to know wether to display the health bar or not(Problem seemingly solved above) and the dead was to not involve the object in several function calls. What did you meant with 'calculate this on demand'? Any suggestions to improve this are appreciated.