#18276 - darknet - Tue Mar 23, 2004 11:33 am
I see that this question has come up before, and yes, I have read that post, but am having a difficult time understanding it. Hopefully I am not being obnoxious by starting a new thread on the topic and I apologize if I am =/
So i, like a lot of beginners, am making a breakout clone. I am in mode 0, I got 2 sprites, one for the paddle, the other for the ball. The collision between the ball/walls and ball/paddle works fine, so now I am going to start drawing bricks and I want to make them a background and somehow check for collisions between the ball sprite and the background bricks.
Heres where I get confused...
I've read on a few tutorials that the tiles are 8x8. Does that mean that each of my bricks has to be 8x8? That doesn't seem to make sense? If they expand more than 8x8, how would i check for a collision between a ball and one brick? How do i go about properly updating the background? (thats where i got lost on the post that was similar to this one).
BTW, I plan on using mappy for developing the background of bricks. Is that overkill? Should I just draw it in photoshop and convert it using gfx2gba or another similar program?
Loaded post, I know. Any help or response would be greatly appreciated.
Thanks for your time,
-Mike
#18278 - Cearn - Tue Mar 23, 2004 3:02 pm
What you have to remember is that the tiles are graphics data ONLY! That is, the only determine how your objects and backgrounds will appear on screen. The GBA is blissfully unaware that there's any collision detection to be done; if you want things to bounce off each other, you have to tell your code to do so.
The simplest way of collision detection is using bounding boxes. Each game object has a box around it. When two boxes overlap, they're said to be in collision. WHat you do with this information is entirely up to you, of course. In breakout you'd bounce the ball off the other object. But you probably know all that, since you got the ball/paddle collisions working already.
For tiles it's the same thing: you define the bounding box of each brick and check for collisions with the ball. That the bricks are made up of background tiles is completely irrelevant, that's just to let the player know that there are things like bricks.
And if you want bricks that are larger than 8x8, so be it: use multiple tiles for one brick then. To make them disappear when the brick's hit, simply erase all the associated tiles from the map.
Now, in principle collision detection is separate from the tiles and the map, but practice you can the tile-map for collision detection as well if you stick to multiple of 8 sizes.
For example, if you're bricks are 16x8 in size, that's 2 tiles. The brick at position (x,y) would use the map entries (x,y) and (x+1,y). For collision, you could check whether the ball's and bricks bounding boxes overlap (Or, you could find out if the ball covers the background tiles of the brick with some SHIFTs and ANDs. It's faster, but also more advanced). If the ball hit the brick, clear both map-entries and remove the brick from the check list. Yes, I know there are better ways of collision detection, but this should do.
| Quote: |
BTW, I plan on using mappy for developing the background of bricks. Is that overkill? Should I just draw it in photoshop and convert it using gfx2gba or another similar program? |
Kinda depends on how many different level you want to have, really. If it's the same layout of bricks every time (like in the Atari breakout), why not create an array manually?
#18313 - darknet - Tue Mar 23, 2004 9:49 pm
in terms of updating the map afterwards, would I just call a function to redraw the entire thing? How else could that be done? What would I draw in place of the brick? (nothing I assume...)
Thanks alot for your reply, however I sense that you don't really care for this form of collision detection =) The only other alternative I could think of is to make each brick a sprite and simply hide that brick (or clear that particular entry) when it collides with a ball. However, i thought the overhead of doing that is greater than the background overhead...or is it not?
I guess the argument breaks down to whether or not redrawing the background is better than hiding a sprite? I dunno....
-Mike[/i]
#18317 - Miked0801 - Tue Mar 23, 2004 10:35 pm
Depends how many blocks you want to display. You get a bunch so sprites would proably be better (imagine hitting the target and having the tile drop or explode or whatever. Also allows non char alignment if you wish.)
#18395 - Cearn - Thu Mar 25, 2004 2:49 pm
| darknet wrote: |
in terms of updating the map afterwards, would I just call a function to redraw the entire thing? How else could that be done? What would I draw in place of the brick? (nothing I assume...)
|
No, you don't have to redraw the entire thing ... unless ... what video mode are you in? A tiled mode (0-2) or bitmapped mode (3-5)?
In a tiled mode it's dead simple. say you have a map that looks like this
| Code: |
wwwwwwwwwwwwwwww
w..............w
w.aabbaabbaabb.w
w.bbaabbaabbaa.w
w.aabbaabbxxbb.w
w..............w
|
This more or less represents what you should have in your screen-blocks. 'w' is the wall, '.' is empty space and 'aa', 'bb', 'xx' are the bricks,
16x8 pixel bricks to be precise. Say you've determined that the tile labeled 'xx' has just been hit. To update the screen to indicate that, simply replace the 2 map-entries on the screen block of that brick with the ones representing empty space, so that afterwards it looks like this
| Code: |
wwwwwwwwwwwwwwww
w..............w
w.aabbaabbaabb.w
w.bbaabbaabbaa.w
w.aabbaabb..bb.w
w..............w
|
Of course, this only works if you're using a tiled video mode. If you're in a video mode it's a little trickier; using sprites would be the easiest method. And has the benefits that Miked0801 mentioned.
#18441 - tepples - Fri Mar 26, 2004 12:59 am
Of course, you could do what Super Mario Bros. and Bust-A-Move do: keep each block as tiles and then, once the ball has hit a block, erase the block's tiles and spawn a "dying block" (falling? explosion?) sprite from where it was.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#18468 - LOst? - Fri Mar 26, 2004 9:22 pm
| tepples wrote: |
| Of course, you could do what Super Mario Bros. and Bust-A-Move do: keep each block as tiles and then, once the ball has hit a block, erase the block's tiles and spawn a "dying block" (falling? explosion?) sprite from where it was. |
That's a smart way of using tiles. I didn't think of it. When I'm looking at Puzzle Bobble the arcade version, the bubbles look like sprites because they are not tile aligned. Arcade machines are more powerful, but still having so many sprites shouldn't work right?
#18476 - tepples - Sat Mar 27, 2004 3:48 am
(For those playing at home where home != USA, Puzzle Bobble is the Japanese name for the USA's Bust-A-Move. In Japan, Bust-A-Move is a dance simulation called Bust-A-Groove in the States.)
Puzzle Bobble and Zoop for Super NES used a background, modifying the tile memory to draw non-aligned game pieces. The Super NES didn't have a linear bitmap mode analogous to GBA display modes 3-5.
Puyo Pop for GBA uses 12-pixel-wide tiles on two background layers offset by 12 pixels. It draws even columns on one layer and odd columns on the other layer. It also uses raster effects (writes to the layers' V scroll during Hblank) to cut off the bottom 4 pixels of each 16-pixel space.
Puzzle Bobble for Neo-Geo, on the other hand, seems to use sprites for the game pieces. So do Super Puzzle Fighter II, Pac-Attack, and Panel de Pon for GBA. Games that need to show more than 128 sprites on the GBA screen at once will stream sprites into OAM during horizontal blank to sort of emulate the Neo-Geo's 384-entry OAM. This may be a bit more complicated for a beginner than just using tiles.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#18564 - LOst? - Sun Mar 28, 2004 11:38 pm
| tepples wrote: |
(For those playing at home where home != USA, Puzzle Bobble is the Japanese name for the USA's Bust-A-Move. In Japan, Bust-A-Move is a dance simulation called Bust-A-Groove in the States.)
Puzzle Bobble and Zoop for Super NES used a background, modifying the tile memory to draw non-aligned game pieces. The Super NES didn't have a linear bitmap mode analogous to GBA display modes 3-5.
Puyo Pop for GBA uses 12-pixel-wide tiles on two background layers offset by 12 pixels. It draws even columns on one layer and odd columns on the other layer. It also uses raster effects (writes to the layers' V scroll during Hblank) to cut off the bottom 4 pixels of each 16-pixel space.
Puzzle Bobble for Neo-Geo, on the other hand, seems to use sprites for the game pieces. So do Super Puzzle Fighter II, Pac-Attack, and Panel de Pon for GBA. Games that need to show more than 128 sprites on the GBA screen at once will stream sprites into OAM during horizontal blank to sort of emulate the Neo-Geo's 384-entry OAM. This may be a bit more complicated for a beginner than just using tiles. |
Thanks for the info. I had no idea how much you can do with some hacking during the drawing period.