Ordered list of getting the HP bars to increase on the party screen:

1) Calculate current HP %, *100, /4. Add value to 3+52(Z>3), store to var1.

2) Increase HP via potion or other item, check HP does not exceed HPmax.

3) Calculate new HP %, *100, /4. Add value to 3+52(Z>3), store to var2.

4) For loop with var1,var2 to increase hp bar.

I've started writing out the code for it, hopefully will have it done soonish. It's going to be another bit of code that will be a pain in the butt to write.

At last, a 2012 topic! And only one-quarter of the year gone first. What about those items is particularly challenging, would you say? Also, what are you picking for var1 and var2?

There HAS been a 2012 topic, just on TI-Freakware, where no one goes :p

The hardest part is just writing this dynamic bit of code so it can fill in the proper bar and all that.

The first line of code for it is "|LP"+sub("123456",Z,1)->Str7. This basically gives you which |LP# list you're working with. So you have to build the whole string of code around that, which is fun.

Code:


That's what I have thus far to get it so it will increase the HP bar and values at the same time.

I'm still at a loss on whether I should loop through with a For( loop and recalculate the length of the hp bar through each pass or figure out some other way of doing things. Trying to be as memory efficient as possible while still being completely dynamic.


Edit:

After some thought, I'm thinking about removing the numerical values of HP/HPMax shown on the party screen. This would shrink the program a small amount, allow the display to be faster, and would make it easier to change the HP values on that screen via just updating the bar instead of doing both bar and numbers. Thoughts?

I can see the reasoning for that. However, I think that people might like to see HP numbers simply to know how powerful their Pokemon are and exactly how effective their Potions and things will be. For the latter case, I'd recommend that when you are using a health restoring item on the Party screen, you show a blinking extension of the health bar as a preview of how much health the item will heal.

As much as I'd like to offer that, that would be beyond difficult for my current set up to do, since I have to keep the lists in archive. I'll keep the numbers, then, and find a way to update both numbers and bar at the same time.

So, I guess I should update here that I've mostly thought of a way to update both the numbers and bar at the same time. I just have to figure out how to do the equation properly for a conditional to know when to increment the bar. I might end up just cheating and using additional variables to increment and every nth one, increment the bar.

Of course you should! What was that way? Well, if you're using lines for the bar, you can simply draw out the lines' length as BAR_LENGTH*(CUR-MIN)/(MAX-MIN), where the value being measured has current, minimum, and maximum values CUR, MIN, and MAX. If you're using pixels, and you only want to update the bar when it will show another column of dark pixels, say for example that your variable range is 0-100 and the bar is 50 pixels long. You would want to update it when not(fPart(X/2.

Well, the bar is 25 pixels in length. The idea is to store hp, hpmax, hpgained, curbarlength, newbarlength, barlengthgained and pixelperhp in separate variables. Then in a For( loop, where I'm incrementing from hp,hp+hpgained, every nth value hp goes up in the loop, it increments the bar by one pixel. It doesn't have to do anything fancy with it beyond that point, because if you go back to the party screen again, it will recalculate and display that stuff brand new.

I hope this makes sense

Also, I thought about that, but I'm not sure that will work correctly.

I'd say it's unnecessary to store newbarlength, barlengthgained, and pixelperhp anywhere. I'd probably just turn on the next pixel, in this case, any time you increment the health, as BASE_COLUMN+25*(hp/hpmax); there's nothing wrong with turning on the same pixel multiple times.

But it would slow down the whole process every time it ran through that equation, though. Not working with asm here :p

It would only need to update the HP bar every once in a while anyway, imho; I think the conditional to decide whether to re-draw it or not would be more overhead than just going ahead and drawing.

Well, I guess I can try it both ways in their own programs and see what happens. Would be the best to get down what is faster than what.

But really, how often are you redrawing the HP bars? It's not like it's inside the getKey loop or something. I feel like it wouldn't be worth your time and headaches to worry too much about the extra millisecond every dozen seconds.

I'll write the code up to do that, then, and throw it in its own program to see what it looks like.

Edit:

What I've written so far to test, hopefully it works the first time, once I make it look like a normal program.


Code:

Is that nested Text a typo or some amazing technique that I've never seen before?

Oh, whoops. Yeah, a typo on my part. Not really sure how that happened, but I was half asleep when typing that code up lol

Fair enough. Other than that, though, that looks like very tight code; I hope it works.

note to self.

So, here are a few screenshots:



These two screenshots above show, in a perfect world when the amount of HP_Gain is either increased by 1 or increased by 5, with the HP_Gain being 200.



Now the above two show what happens when you have an HP_Gain of a non divisible by 5 number, 74. Because everything is wrapped in a For( loop, it doesn't complete the loop properly.

I'm thinking about possible fixes right now, because doing it by +5 is an obvious need, because +1 just takes a long time with larger values. :/

Thoughts on the screenshots?