(http://i.imgur.com/pK8idsM.jpg)
Coming soon to an online download near you...
(I think)
For those who don't remember what Tourn was (and I'm glad for that), it was a TI-84+CSE fighting game using ASCII characters and the Celtic II text-color-altering commands. I'm glad to be remaking it with proper sprites. Instead of bland characters represented by the shape of their head (an O, Q, G, 0, A, or θ), I plan to use characters from my old games. Of course, most of my old games used ASCII characters, so there will definitely be a fake-ASCII character as well. More info about the planned fighters, stages, and more coming soon.
(http://i.imgur.com/CJsd8Pt.gif)
The white tiles displayed after the initial "punch" animation are combo attacks. I haven't yet added the sprites for them yet. No collision has been implemented as of yet.
I like the upgrade in graphics, especially the varied terrain textures. As for the characters, I like that you went with larger ones. I'm curious about what you'll come up with in terms of character attack animations and stuff. How will combos work?
Is that tiny baby-trees in the grass? :D They're a bit small I guess ;D
But I like tha graphics, too ^^ Now add some amazing animated pixelstuff for fighting and I'm gonna buy it ^^ :thumbsup:
Looks brilliant
Why does it flicker? Can't you doublebuffer in TI_BASIC?
Quote from: p2 on August 29, 2016, 08:26:04 AM
Is that tiny baby-trees in the grass? :D They're a bit small I guess ;D
But I like tha graphics, too ^^ Now add some amazing animated pixelstuff for fighting and I'm gonna buy it ^^ :thumbsup:
Actuallty I think they're normal trees, but I agree that they're a bit small compared to the characters, unless the latter are mech-type fighters. Maybe he could re-use my Reuben Quest trees and put a string of leaves at the bottom?
Quote from: kotu on August 30, 2016, 12:08:14 AM
Looks brilliant
Why does it flicker? Can't you doublebuffer in TI_BASIC?
He can, by using xLIBC's double-buffer commands, but the emulator screenshot feature will still produce flicker no matter what. In CE games I have the same problem, where even with almost invisible flicker, in the screenshots it's severe enough to be annoying.
Quote from: DJ Omnimaga on August 30, 2016, 03:48:07 AMHe can, by using xLIBC's double-buffer commands, but the emulator screenshot feature will still produce flicker no matter what. In CE games I have the same problem, where even with almost invisible flicker, in the screenshots it's severe enough to be annoying.
*Poke* CEmu issue? Also, have you tried decreasing the frame skip amount? By default CEmu only records every third frame, you can easily customize this though ;)
I usually try multiple settings, but most still gives more flicker than through normal emulation or on the real calculator. Maybe the capture rate is just out of sync with the emulator frame rate? It's not a serious issue, though, it just makes the screenshots not do the original game's justice.
The weird part is that I often saw it happen with double-buffered ASM and xLIBC games in the past too, even if they were flickerless. So I started to wonder if CEmu was using jsTIfied screenshot capabilities lol. :P
Quote from: DJ Omnimaga on August 29, 2016, 06:09:39 AM
I like the upgrade in graphics, especially the varied terrain textures. As for the characters, I like that you went with larger ones. I'm curious about what you'll come up with in terms of character attack animations and stuff. How will combos work?
Yeah, I agree 2 sprites per character is nice. Character attack animations will mostly draw from the game(s) they were based on (except for the astronaut dude, I have a scrapped game with really good tiles that I wanted to use. Not much of that game was made yet). Probably the first punch will be longer range, 2nd hit a little less, 3rd even less. At any time after the 2nd punch I plan to make it so you can end the combo with a kick. You have to be closer to the opponent to hit with all 3 *punches* (which gives them more time to hit you) so it's a risk/reward deal. Hopefully, that is.
Quote from: p2 on August 29, 2016, 08:26:04 AM
Is that tiny baby-trees in the grass? :D They're a bit small I guess ;D
But I like tha graphics, too ^^ Now add some amazing animated pixelstuff for fighting and I'm gonna buy it ^^ :thumbsup:
The trees were just an idea to make it so that it wasn't a wall of that plain grass texture. I like to think of them more as bushes.
I do intend to add fancy pixelstuff.
Quote from: kotu on August 30, 2016, 12:08:14 AM
Looks brilliant
Why does it flicker? Can't you doublebuffer in TI_BASIC?
I can, and I'm doing that exact thing. Unfortunately, emulation isn't 100% accurate when it comes to screen timings.
By the way, do you use the sprite command that lets you display multiple sprites at once? That might be better than displaying sprites separately one by one. As for the animations do you mean the characters are based from previous games you made, Smash Bros style? I like the moves idea by the way. Good luck!
Quote from: DJ Omnimaga on August 31, 2016, 06:38:42 AM
By the way, do you use the sprite command that lets you display multiple sprites at once? That might be better than displaying sprites separately one by one. As for the animations do you mean the characters are based from previous games you made, Smash Bros style? I like the moves idea by the way. Good luck!
Yes, thankfully I do. Otherwise, it'd probably look to staggered to be playable. And yes, the characters are based on previous games (or in the case of the astronaut, previous projects). I thought the moves thing would give the game some element of skill without making it a flowchart fighter kinda like my others, where you always want to, for example, punch -> laser in the first Tourn, or something.
I think drawing sprites separately isn't too much of a speed drain with such small amount of sprites, but for a real-time action game you need every bit of speed you can get, so in your case it matters. I'm now curious about how your other 8x8 or ASCII characters will look like in 8x16. :)
Also xLIBC's support for multiple keypresses might be handy for special moves. For the HUD you could try using rectangles and make the HUD look a bit like Street Fighter or Mortal Kombat.
Quote from: DJ Omnimaga on August 31, 2016, 06:55:49 PM
I think drawing sprites separately isn't too much of a speed drain with such small amount of sprites, but for a real-time action game you need every bit of speed you can get, so in your case it matters. I'm now curious about how your other 8x8 or ASCII characters will look like in 8x16. :)
Also xLIBC's support for multiple keypresses might be handy for special moves. For the HUD you could try using rectangles and make the HUD look a bit like Street Fighter or Mortal Kombat.
Yeah, but like you said, you don't ever have enough speed in a CSE game :P
Also yeah, I'm looking forward to designing the last character. By the way, thanks for reminding me of the multiple keypresses thing. I could implement a more in-depth control scheme (at least for performing specials, like you said). I'm also looking forward to designing the HUD, since I remember an accurate health bar was one of the troubles of some of my other fighting games, and here it'll be a breeze.
For an acurate health bar, you could just use a fixed amount of HP, but different attack/defense attributes for each character. Or you could just take the character's HP and divide it in a way that it always ends up being the size of the energy bar. I think the former idea might be easier, though.
Quote from: DJ Omnimaga on September 02, 2016, 03:01:31 AM
For an acurate health bar, you could just use a fixed amount of HP, but different attack/defense attributes for each character. Or you could just take the character's HP and divide it in a way that it always ends up being the size of the energy bar. I think the former idea might be easier, though.
To make it easy, I'll probably give everyone X HP, and every time it goes down 1, it visually goes down 1 pixel. The defense and attack things are what I used for all of my fighting games, I'm pretty sure, so I'll probably do that too. If I can, I'm going to try to give every move from every character it's own range. IE, one character has more range but does less damage or knockback, and one has less range but does more damage/knockback. That way, you can choose a character that can play it safe, or do a lot of damage when up close. I think it'd be possible to do.
An interesting (sort of troll/joke) element could be to add Phantom hits, like in Melee, where if the move's hitbox and a character's hurtbox are aligned so a tangent line can run through, it does half damage and no knockback. If I implemented such a troll idea, it would be if a hitbox whiffed by a pixel.
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.
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.