#30605 - oblivi0n - Thu Dec 02, 2004 7:17 pm
I'm starting to research/create my first game for GBA and I am thinking about creating an Adventure from the Atari 2600 clone. Except I expect to have slightly better graphics, using one of the tile and map modes with sprites on top of it. That said, any tips/suggestions about what to read or consider? One of the things I've been thinking about lately has been collision detection. The only viable solution that I have come accross so far has been to have a collision layer for the map. Also I have one question that may be dumb, but bare with me, is it really necessary to create an interrupt handler? I think my game will be simple enough that I will not need one...but perhaps I am overlooking something.
thanks,
~doug
#30606 - angelfly - Thu Dec 02, 2004 7:29 pm
The gba game programming crash course is something you should consider going through. It teaches alot of stuff like collision detection, AI, and dealing with sprites and background. It also makes it easier to understand other guides. The best thing is when your done with it you'll have a fully working game and you'll understand how every part works.
#30607 - oblivi0n - Thu Dec 02, 2004 7:40 pm
Yes, thank you for the suggestion. I have read most of that and the collision detection that it uses is much like I've used when I've written pong games for different platforms. I've read through the first 3 days of the Pern project have found that to be the most helpful resource so far. One thing that I have been looking at also is to find a really good map editor. So far I have been using a Mac for my coding, but there isn't much (that I can find) as far as tools for that platform. Soon I'll start looking into things for windows.
#30608 - poslundc - Thu Dec 02, 2004 7:43 pm
If you are serious about coding a game, you will probably end up writing your own tools sooner or later.
Dan.
#30610 - abilyk - Thu Dec 02, 2004 7:48 pm
If you later need to write an interrupt handler (or just want to gain some insight), check this topic: http://forum.gbadev.org/viewtopic.php?t=4063. But that aside, no, you don't need to create an interrupt handler. I've got a nice sidescroller up and running, and although I've coded the handler, I'm not using it at all yet. I will use it later on for things like visual scanline effects, sound library integration, and Vblank detection (to save battery power, as opposed to my current wait for Vblank while loop).
Regarding collision detection, I'd recommend one of three options for your first project.
1) In the same format as your visual tile map (some sort of array), store a corresponding collision tile map. Most simply, each tile can be turned on or off, but since you've got at least a byte for each entry, you can have lots of collision states, allowing for slopes and such.
2) In a similar fashion to the above, you'd store a collision "map" that corresponds to your visual map. But instead of storing this collision map as a standard array, store it as a "bit array" of sorts. For each 32x32 tile image map, you could have an array of 32 unsigned ints (32 bits each), in which each bit signifies that the corresponding image tile is collidable or not. You'd need to use bitwise shifts and ANDs to extract the bits you want. This uses less space than the above method, but it's more complicated and has less functionality. But there it is anyway.
3) Don't store a separate collision map at all. Use your visual tile map as your collision map. You'll need an array that has an entry for each unique image tile. Each of these entries holds the image tile's collision state (on, off, slope, etc.). Now, each time you want to test for collision, use your image tile's index as the index into this collision state array. This also takes less space than method one, and it has less functionality as well. In the above two methods, you could potentially have walls you could walk through, since the collision map and image map are independent. In this, the image map IS the collision map, so every instance of a unique tile has the same collision.
#30613 - identitycrisisuk - Thu Dec 02, 2004 8:30 pm
| abilyk wrote: |
1) In the same format as your visual tile map (some sort of array), store a corresponding collision tile map. Most simply, each tile can be turned on or off, but since you've got at least a byte for each entry, you can have lots of collision states, allowing for slopes and such.
|
For this option my personal recommendation would be MapEd. I've only been using it for a short while but I found it very easy to use and the fact that you can control what files it outputs is very useful. As mentioned, the bonus of a collision layer is that the visual layer does not have to determine the collisions. I worked on a project using quake3 maps and we decided to have a visual map and a collision map so that we could get it doing what we wanted more easily.
_________________
| Code: |
| CanIKickIt(YES_YOU_CAN); |
#30677 - oblivi0n - Fri Dec 03, 2004 2:26 pm
Thank you for the tips and recommendations. I'm sure the methods for doing collision detection will be very useful. I'll have to check out MapEd and see if it will be good for my purposes.
#30884 - dj-ceejay - Sun Dec 05, 2004 8:35 pm
My advice is to think about sound from day one.
It affects lots of timing issues and requires lots more work than graphics does (yes, I was shocked too!).
Start with direct sound then try using one of the mod players out there.
Good luck, it's worth the effort.
Chris.
_________________
Fruit Machine Games:
http://www.fmsoftware.info/