8.8 division routine needed

[Heaven/TQA]

hi guys,

 

i was searching the whole site and the net and looked even in my source code archive but i havent found any useful 16bit div 16 bit = 16bit result routine for our lovely 6502...

 

can some of you share his code or point me to the correct source. actually i want or need to use 8.8 fixed point maths but the result must be 16bit as well... i want to use this for my game where i calculate the steps in my healthbar...

 

example:

 

the healthbar is 100 pixel long so if the player has f.e. 50 maximal health, 2 pixel will represent 1 player health point. (100/50=2)

 

but if player has f.e. 200 max health then i would need a result of $0080 in 8.8 fixed point maths and all routines i checked do not work like that.

(100/200=0.5 = 100*256 div 200*256 = $0080

 

any ideas?

[Rybags]

Couldn't you just pre-calculate the fractional part, and have a 16 bit counter with upper 8 bits representing how many pixels wide it is?

 

Then you just need to do a subtract op each time you decrement the health counter.

 

In any case, wouldn't a full-length health bar be deceiving if you had say a character with 200 health against one with 40, and both bars starting the same length?

Edited May 1, 2007 by Rybags

[djmips]

Just pointing out that the Apple Assembly Line archive has a lot of great code and articles relating to the 6502.

This is what I was raised with. I'm sure there's an equivalent for C64, Atari 800 and others.

 

Here's a link to an article from March '83 that includes an overview of a 16 bit divided by 16 bit

http://homepage.mac.com/bobsc/aal/1983/aal8303.html#a5

[Heaven/TQA]

ah. got it... i had a mistake... i must make following

 

max_health*256 div player_health

 

so a 16 bit div 8 bit would be enough... but thanks for the apple source which works right now...

 

rybags...can you describe in more detail what you mean? i havent got it...

[Rybags]

Thinking some more, you could implement a version of the OS Draw Line routine.

 

Imagine a players maximum possible health as a "Y" value.

 

Then imagine a diagonal line going from (159,Y) to (0,0).

 

Along that line, the highest X value where a point is set would correspond to what your health bar should read.

Of course, you don't need to draw the line, just do the calculations (steal the algorithm from the OS manual).

 

Problem is, it would probably require looping, and also might take more cycles than a simple 16 bit MULT or DIV routine.

 

 

With the "fractional" method I mentioned before.

 

Say the health bar = 0... 159 (X value), actual value of Health = 0 ... 400

 

400 = 160x 2.5 , so you'd want the health bar to decrement each time Health goes down by 2.5

 

So, 256/2.5 = 102.4 - 102.4 (or just 102) would be your "fractional" part.

 

So, each time you decrement Health, subtract 102 from your 16 bit counter (initial value would be 159,255 hi/lo bytes). Remembering, the High byte here represents what X value the health bar should end at.

 

Not quite exact, but you get that with integer maths.

Edited May 1, 2007 by Rybags

[Heaven/TQA]

rybags... thats exactly for what i need the div routine. simply to calculate the factor f.e. your 2.5.

 

rest is piece of cake as it is simply 8.8 fixed point maths... (or 16bit adc/sbc).

 

but the oss drawline methods is interesting approach as well but maybe the same what we are doing with the divs... (as the slope is the same kind of calculation)

[Thomas Jentzsch]

You know, you could easily avoid this problem by making the healthbar non-linear.

[Heaven/TQA]

thomas, what do you mean by non linear? it is right now non-linear in terms of the length of the bar is the amount of health...so nothing is "stretched"... or do you mean something different?

[Thomas Jentzsch]

If you have 100 pixel, you could e.g. use the first 50% for the first e.g. 10 healthpoints, 50% of the remaining pixels for the next 10 healthpoints and so on.

 

So the more total health you have, the longer the bar gets, but the resolution for the higher points is lower than for the lower points.

 

The math is very easy then.

[vdub_bobby]

If you have 100 pixel, you could e.g. use the first 50% for the first e.g. 10 healthpoints, 50% of the remaining pixels for the next 10 healthpoints and so on.

 

So the more total health you have, the longer the bar gets, but the resolution for the higher points is lower than for the lower points.

Are there games that do that? It seems confusing for the player..

[Thomas Jentzsch]

Are there games that do that? It seems confusing for the player.

Don't know. Others will.

 

But if you color code the various sections, it shouldn't be more confusing than a health bar which represent different healths with the same length.

[Rybags]

For the fractional method, you could just generate tables but at the cost of 2 bytes per entry.

 

But, I don't see the logic in having a Health bar that is full-width for any character.

 

Why not just have a maximum possible health of 255, then divide by 2 for the display?

 

Once Health reaches 15 or so, then have a red health bar with 4 pixels representing each increment or something.

[Heaven/TQA]

Rybags. simply because i want to have a health bar like in WoW, Diablo + any new RPGs... and at the moment i do not want to have a cap on the health/mana... not yet.

[Robert M]

hi guys,

 

i was searching the whole site and the net and looked even in my source code archive but i havent found any useful 16bit div 16 bit = 16bit result routine for our lovely 6502...

 

can some of you share his code or point me to the correct source. actually i want or need to use 8.8 fixed point maths but the result must be 16bit as well... i want to use this for my game where i calculate the steps in my healthbar...

 

example:

 

the healthbar is 100 pixel long so if the player has f.e. 50 maximal health, 2 pixel will represent 1 player health point. (100/50=2)

 

but if player has f.e. 200 max health then i would need a result of $0080 in 8.8 fixed point maths and all routines i checked do not work like that.

(100/200=0.5 = 100*256 div 200*256 = $0080

 

any ideas?

 

I had a minor brain spasm on this problem today. Since you are dividing by 100, what about using BCD? Then it is easy to divide Maximal health by 100. The lowest order byte just becomes the decimal fraction. Divide that into current health with decimal .00 added to the Health to get the number of pixels from 1 to 100.

 

Cheers!

[Heaven/TQA]

thanks. have to think about it... at the moment we expanded the healthbar to 128 pixels which migh easier to treat...but the sprite code for the bar got more complicated... but we see...