Quote from: DJ Omnimaga on September 07, 2016, 05:47:54 AM
Just don't make HP drop by 1 at a time when you take like 10 damage, though, else that will generate lag, although the bar dropping gradually might look cool. As for knockback, maybe some characters could have an higher chance of falling down and/or take longer to get back up. Don't make it too complicated, though, lol.

MAKE IT SO COMPLICATED NO ONE CAN UNDERSTAND OR PLAY IT.

/DJ Omnimaga smacks Kotu for all-caps.

Anyway yeah I was saying so that the project doesn't become a burden to code.

Quote from: DJ Omnimaga on September 07, 2016, 05:47:54 AM
Just don't make HP drop by 1 at a time when you take like 10 damage, though, else that will generate lag, although the bar dropping gradually might look cool. As for knockback, maybe some characters could have an higher chance of falling down and/or take longer to get back up. Don't make it too complicated, though, lol.

If I wanted to add the bar "draining" (which I'll have to see if I do), I'll probably put it on a For( loop that removes 1 pixel of the bar at a time, after the move finishes. And yeah, I won't make it too complicated.

But the issue with removing 1 bar at a time is that it's kinda slow if your character loses 25 HP in one hit. You will need to camouflage this by making for example the character be knocked out for a few seconds while the bar drops, else it would look weird if everything stopped moving for a second or two while the bar decreases. Hence my suggestion

I agree. It makes no sense to see someone get shanked, do nothing at all, and then start bleeding a minute later. 

Quote from: DJ Omnimaga on September 11, 2016, 06:52:01 AM
But the issue with removing 1 bar at a time is that it's kinda slow if your character loses 25 HP in one hit. You will need to camouflage this by making for example the character be knocked out for a few seconds while the bar drops, else it would look weird if everything stopped moving for a second or two while the bar decreases. Hence my suggestion

That does make sense. I'll try to figure out a way to increase the bar dropping speed, since I'm not sure if I have enough room in my tileset for a knocked down pose, for each character. If I do, I'll be sure to use this technique.

That makes me wish xLIBC supported sprite rotation using an extra final parameter.

Quote from: DJ Omnimaga on October 21, 2016, 04:26:09 PM
That makes me wish xLIBC supported sprite rotation using an extra final parameter.

That would be really great, for a lot of games, but if it doesn't exist in xLIBC there must be a reason why.

Maybe @tr1p1ea didn't think of it at the time and no one suggested it, or Kerm ran out of app space. Flipping was available in the original monochrome xLIB, though.

It was planned but never made it into the code.

I should be able to include it in the CE version with any luck.

That would be cool, especially for animations and saving space.

Quote from: tr1p1ea on October 24, 2016, 01:06:58 AM
It was planned but never made it into the code.

I should be able to include it in the CE version with any luck.

That would be awesome for CE developers! To maintain a similarity between both color xLIB versions, would it be possible to go back and add it for CSE? That would save a ton of graphics space in my projects.

And don't forget to compact it too!

Quote from: 123outerme on October 25, 2016, 09:35:27 PM

Quote from: tr1p1ea on October 24, 2016, 01:06:58 AM
It was planned but never made it into the code.

I should be able to include it in the CE version with any luck.

That would be awesome for CE developers! To maintain a similarity between both color xLIB versions, would it be possible to go back and add it for CSE? That would save a ton of graphics space in my projects.

I agree it would be a nice idea, assuming Kerm is still willing to update Doors CSE 8.