benjaminsantiago wrote:
You could do something simple like Pong/Columns/Breakout, but have more complex animations/graphics.
Do I really need 128 objects? (That's how much I am currently supporting, but if it ever does get there, there will be flicker, because of how some objects will use multiple sprites. I might lower it to 112 or something, above 96 at least though.) If I ever did do this, it would be like Pong on super steroids. I could leave a flame trail behind the ball or some crazy thing.
benjaminsantiago wrote:
Ahhhhh sorry, I thought psycopathicteen had posted the gunforce/metal slug screenshot. I was going to ask, have you looked at the sprite work in Earthworm Jim, Boogerman or Shaq-Fu? It's not quite Metal Slug but its pretty nice.
The game is GunForce 2, and yes I've seen them all. I personally think GunForce 2 looks better than Metal Slug, due to the fact that they had seemed to have tried to make things look more "cartoony", making simple things like window frames non rectangular and greatly distorting body parts. I find the blood and generally what's going on to greatly clash with the art style they were going for. I feel they only amplified the problem in 2 and then 3, adding mummies and other dumb stuff. The first one was easily the best to me, but I would have much rather seen a Gun Force 3. (To anyone who thinks I'm bias, I played Metal Slug 2 before I played Metal Slug or Gun Force 2, with Gun Force 2 being the last one.)
This is what I mean about the structures being deformed to add to the "cartoony" look:
(Personally, I think the stupid stuff like soldiers getting split in half after being ran over more humourous, just because it's just so absurdly ridiculous. I couldn't find a picture of it, so here's something else.)
benjaminsantiago wrote:
Yeah that wasn't too hard to implement, I remember the issues I had....vaguely...being determining when the "ball" hit on the side rather than the top and what appeared to be "normal", and I didn't fully understand the "high-xbit" component of the sprites so I encountered some unexpected behavior on the edges of the screen.
Do a simple bcc or bcs check on the top and bottom for just the x coordinate, and flip the high bit for the velocity to make it negative or positive. One problem I could see is seeing exactly where to pull it out of the floor to in checking for collisions, unless you want to check every pixel the ball moves. With the paddles, you'd probably do a more complicated approach; something that you'd actually use in a game, with both things having hit boxes (or rather hit lines?) because you wouldn't want to check the top and bottom of the paddle, would you? The whole game can definitely be hardcoded. Doesn't the trajectory of the ball actually depend on how the paddle was moving when it hit it? After doing a collision check, you can look at what the paddle that hit the ball's vertical velocity was and influence the ball using it. One last thing, you also need to check the sides of the screen, which you could do the same thing for the top and bottom, except x instead of y, and when a hit is detected, the game pretty much resets itself and increases the score counter for the appropriate player by one.
(About the 9th x bit, psychopathicteen seemed to have come up with an idea where you essentially have x be a 2 byte 16 bit number and before you upload the thing to oam, you translate it into the correct format.)