7 replies to this topic

[Heaven/TQA]

as some of you know i am writing an action rpg for atari computers. for the health/mana bars i would need following solution.

the health bar is 64 pixel wide so i want that this represents 100% of your max health while when got hit it will be reduced by the amount of hit points.

so as far as i remember i would need following routines. all calculations must be done in 16bit as i will use 8.8 fixed point maths.

assume that 10 is your max hp so actually i would calculate like this

64/10 = 6.4 pixel represent 1 hp.

so when got hit by 1 the healthbar would be adjusted by subtracting of 6.4 pixels. in 16 bit maths:

$4000/10 = $0666 = 1638. so hibyte of the result would be $06 which is the 6 pixel...

so when hit by 3 i would need to multiply $0666 * 3 = $1332 = 4914 = $13 = 19 pixel which seems to correct,,,

now another case

let assume our hero has 100 hp max.

64/100 = 0,64 = $4000/100 = 16384/100 = 163,84 = $00a3

so hit by 1 means a 16 bit subtraction by $00a3 and a hit by 3 means 3*$00a3 = $01e9

i think i am on the right track here BUT as it is a realtime action game i would need quick solutions for

16bit division
16bit multiplication

but without too many usage of tables like in 3d demos etc...

any ideas here from our 6502 maniacs? dont think in 2600 terms just in 6502 terms... as i am on atari 800...


Thanks a lot!

[Prodos8]

I'm not good with assembly, but in visual basic the following expression would solve problem:

bar_length = integer(64 * (curr_hp/max_hp))

If you can implement this is assembly your good to go.

[Heaven/TQA]

tss... yup. its simpler with your method... sometimes i am too complicated...so i now eliminated the 16 bit mul but i still need the division... thanks!

[Wrathchild]

Where does the 64 come from? the graphics mode you're using for that line or could you use P/Ms instead?

If using a bitmap background then I think just redrawing it would be quicker than calculating it, maybe use a 160 pixel wide mode and only use 100 pixels.

[Heaven/TQA]

i am using mode10 for the status line. and it has 80 pixels max. i thought 64 pixel could be handled more easily. in mode10 i might use some kind of colour cycling as i have all colour registers for that. and i do not have to use many DLIs for the colours... oh pixel adressing is much easier as well... i am not sure if gr.15 would be better...

so yes. actually i am using bitmap gfx...

[Wrathchild]

I'll write up and send some ideas on the P/M method I have in mind.
This could also have some colour control but the banding would have to be done by in a DLI - how many pixels high do you want them?

[Heaven/TQA]

small...max. 5 pixels per bar? i would need a nice looking one which does not consume too much time...

i guess horizontal needs less screenspace... of course in a ideal world i would like to have something like in diablo but thats not possible...

just let me know what you have in mind... i am open for everything. i just want to have some bars for the player and leave as many pms free for the main screen (for special fx and/or pm overlays for the player sprite (weapon/armor))

[djmips]

Your first idea of subtracting the adjusted number of pixels is not a bad idea. It's quite fast and fairly simple. For speed you could generate a table up to your maxHP and fill it with the pixel length. It's only a ten byte table for 10HP and if your HP only go up to 200 then it only grows to 200 bytes.

To do multiplication and division in 6502 without using 'large' tables you can find routines online - should be able to find something at 6502.org otherwise I can dig something up for you.