4.0.5 device skill effect

[PowerDiver]

I'm trying 4.0.5 in the comp, and when I inspect devices I see mention of increased damage due to device skill. When I use the items, I don't observe the increases. E.g. I just used a wand of dragon flame 200 +58% on a demonic Q avg 420 and did 4 *s of damage.

Could the Q have 600+ hp?

Does device skill affect damage?

[PowerWyrm]

It would be nice to have damage output displayed for spells the same way there's damage output displayed for melee/missiles.

[Ingwe Ingweron]

It would be nice to have damage output displayed for spells the same way there's damage output displayed for melee/missiles.

See Nick's answer when I asked this question some time ago. http://angband.oook.cz/forum/showpos...&postcount=401

Essentially, imagine a ball or beam spell. How do you display the damage when it hits multiple monsters?

[Pete Mack]

Display the damage at the target. If there's no selected target, display no damage.

[Pondlife]

That sounds similar to what was reported in this post:

http://angband.oook.cz/forum/showpost.php?p=109424&postcount=174

That was in 4.0.4.

[PowerDiver]

That sounds similar to what was reported in this post:

http://angband.oook.cz/forum/showpost.php?p=109424&postcount=174

That was in 4.0.4.

Thanks. That's what I was expecting, but it is nice to get confirmation.

It would be even better if there was an announcement this was done on purpose. I've never liked the device skill damage modifier.

If any of the dev team ever look at my spell code and think I've lost my mind, one of the reasons for my architecture was to make bugs like this impossible.

[Nick]

The damage boost is indeed applied:

	if (use_boost)
		final *= (100 + context->boost) / 100;

So if (your device skill - your level) is greater than 100, your damage is doubled, otherwise nothing happens.

I'll fix that shortly. As to the question of whether it should be there, I'll probably leave that to the player/race/class shakeup in 4.2.

[Pondlife]

The damage boost is indeed applied:

	if (use_boost)
		final *= (100 + context->boost) / 100;

If both sides of that division are integer, you'll end up with integer division. That's rarely what you want (e.g. 10/3 = 3). I'd normally force something to be float or double, e.g:

final *= (100.0 + context->boost) / 100.0;

Note that I know nothing about the Angband source; so I may well be talking out of my backside. But I've been burnt by integer division in C before so I thought I'd mention it.

[Derakon]

If both sides of that division are integer, you'll end up with integer division. That's rarely what you want (e.g. 10/3 = 3). I'd normally force something to be float or double, e.g:

final *= (100.0 + context->boost) / 100.0;

Note that I know nothing about the Angband source; so I may well be talking out of my backside. But I've been burnt by integer division in C before so I thought I'd mention it.

Yeah, that should be written as

final = (final * (100 + context->boost)) / 100;

It's important that we do all multiplications before we do any divisions, or else we'll only ever be multiplying by 1 or, rarely, 2 (if context->boost >= 100).

[Nick]

If both sides of that division are integer, you'll end up with integer division. That's rarely what you want (e.g. 10/3 = 3). I'd normally force something to be float or double, e.g:

final *= (100.0 + context->boost) / 100.0;

The thing is that most things in Angband are integers - HP, XP, etc - so it's usually cleanest to just keep everything as integers and be careful with what that means.

The fix in this case was

	final *= (100 + context->boost);
	final /=  100;

which keeps full precision for as long as possible, so we're rounding down to the nearest hitpoint (as we want to) rather than to an integer multiple of the original damage (which is just silly).

[PowerWyrm]

http://angband.oook.cz/forum/showpost.php?p=109444&postcount=177

I was pretty sure that was fixed in 4.0.4, but apparently not...

[kandrc]

If both sides of that division are integer, you'll end up with integer division. That's rarely what you want (e.g. 10/3 = 3). I'd normally force something to be float or double, e.g:

final *= (100.0 + context->boost) / 100.0;

Note that I know nothing about the Angband source; so I may well be talking out of my backside. But I've been burnt by integer division in C before so I thought I'd mention it.

Floating point is sloooooowwwwww. 10s (or on some architectures even 100s) of cycles of latency, versus one cycle of latency for integer. Roguelikes have enough complicated stuff going on that this actually does matter. It's easy to end up with a compute-bound roguelike game simply by using floating point.

Today's processors are fast enough that you could get away with expressions like the above here and there, but back in the day it would have made the game unplayable. Maintainers have made the wise decision (whether or not they understood it (no implication intended)) to stick with an integer only design philosophy, thus avoiding painful FP creep.

If your integer division gives you unacceptable rounding errors, the solution is not to convert to float; it's to multiply all numerator terms by 10 (or 100, or whatever value gives you enough decimal places) and treat it as fixed point.

[Derakon]

Floating point is sloooooowwwwww. 10s (or on some architectures even 100s) of cycles of latency, versus one cycle of latency for integer. Roguelikes have enough complicated stuff going on that this actually does matter. It's easy to end up with a compute-bound roguelike game simply by using floating point.

This might have been the case way back in the day when Angband was first written, but is really not the case any more. Certainly it is possible to make a slow roguelike by making unwise choices, but it's not going to be because you decided to use floating-point math instead of fixed-point, it's going to be because you decided to have hundreds of units all running A* pathfinding every turn, or because you're using software rendering to draw thousands of letters, one at a time, every time any aspect of the screen changes. Dumb algorithmic decisions are what will wreck you, not dumb formulaic decisions.

And the problem with the "just avoid floating point" mindset is that now every single computation you do, you have to worry about whether you're screwing things up. It's easy to introduce bugs like the above. If you just let yourself use floats then things get a lot simpler.

As always, obey these rules of optimizing:

* Is it slow? If not, don't optimize.
* Figure out what part is slow.
* Measure how slow it is.
* Optimize that part.
* Measure it again.

Optimizing almost always sacrifices clarity of code for efficiency of code, and it always results in more work being spent on a given piece of code that's otherwise functional. These are both substantial costs, so you should only optimize when it proves to be necessary.

That doesn't mean that you shouldn't be aware of broad-scale runtime implications, of course. Don't use bubble sort, that kind of thing. But your #1 concern for your code should always be does it do the right thing? Code that provides the wrong answer is worse than useless; code that is correct but slow is merely annoying.

[Pete Mack]

Or you can just do
final += final* boost/100
like any other normal integer calculation.

[Nick]

This might have been the case way back in the day when Angband was first written, but is really not the case any more. Certainly it is possible to make a slow roguelike by making unwise choices, but it's not going to be because you decided to use floating-point math instead of fixed-point, it's going to be because you decided to have hundreds of units all running A* pathfinding every turn, or because you're using software rendering to draw thousands of letters, one at a time, every time any aspect of the screen changes. Dumb algorithmic decisions are what will wreck you, not dumb formulaic decisions.

You are, of course, correct in principle, although at this point in its development starting to use floating point in Angband would be a great source of bugs. There's also the consideration that we don't know for sure exactly what architecture the game will "need" to run on in the future. So it will be staying integer only for now.