Ive noticed that many people here wanted to get into game development, but dont know where to start. So Im going to try and supply you with the best methods for learning to write your own console games. Here we will use the Gameboy Advance and C++. I dont reccomend that you use ARM7 assembly because it provides almost no perfmormance bennefit(unless you are not using hardware acceleration) and makes it hard to maintain code. And yes, I do know that the GBA is not a console, but it is programmed just like a console. 1. First if you dont know C++ then you should learn that first, and try to make some example programs. You should also learn the entire language(including pointers and bitwise operators) before you start making a game. The best C++ tutorial is on this site, but dont expect to learn everything or be an expert after just doing these http://www.cplusplus.com/doc/tutorial/ 2. Download Devkit Advance, which is just a precompiled version of cygwin with gcc and a few gba libs. This can compile C++, C, and ARM7 code. http://devkitadv.sourceforge.net/index.html 3. Become familliar with the GBA architecture. This Cowbite documentation is the best for that. You will need to understand bit manipulation to get this stuff down. http://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm 4. Look at some other GBA tutorials such as these ones. Try them out and try to change them a little bit. http://www.thepernproject.com/index.php?system_id=2&page=Tutorials 5. Download the GBA emulator Visual Boy Advance. This way you can run your code quickly without having a GBA. http://vba.ngemu.com/index.shtml Here is an example I made a few years ago. There is already a compiled .GBA file. If you want to get it to compile just update the bat file. If you want to see an example I did a few years ago then here is one http://www.geocities.com/greensprite555/GBA_Example.zip
Never tried the NES. Does it have good hardware acceleration? Update: Well that thing has a very small bit of ram. 8x8 or 8x16 for each sprite. So that means that most ok looking characters are actually devided into 4 sprites. I think that mario 3 had bigger sprites than that. Having to move two sprites around like that would be anoying. Especially if you had some characters that were one sprite and others that where multiple sprites.
Here: Here's a site I've been going to for years now with lot's of good NES tutorials & programs: http://nesdev.com
Here is a site that I stumbled onto a while ago: http://www.jharbour.com/gameboy/ The site contains a PDF version (in parts, but complete) of an unreleased Premier Press book entitled "Programming the Nintendo Game Boy Advance: The Unofficial Guide". Apparently, Premier Press decided not to release it due to pressure from Nintendo, but the author of the book has been kind enough to put it up for download.
This book uses a library called HAM which simplifies development, having read the book cover to cover (I have a printout) I’ve found it very useful as a hardware and concept guide but It really does hide away lots of details (often not difficult) that you should know when working with hardware like this. Few points: The pernproject tutorials are good, but sadly outdated. Devr’s site is a must - http://www.devrs.com/gba/ So is gbadev.org – www.gbadev.org Also the forums at gbadev are very good, the beginners forum is full of info and has the following great FAQ thread which should answer most of the beginner questions - http://forum.gbadev.org/viewtopic.php?t=418 Html version (Extracted from no$gba version 2.0 ) - http://nocash.emubase.de/gbatek.htm Edit: Those looking to move to the DS should checkout the following site http://www.double.co.nz/nintendo_ds/index.html
"Heresy!" :smt043 Well I like ARM assembly too. I even wrote an assembler in it a few years ago. But there is really no need to use it for conventional things like sprites, tiles, music, and input, because the GBA has hardware acceleration for that. But if you want to try making a 3d engine or making some particle effects then you'll see a small benefit. 256k is a ton or ram. Ive written detailed engines that . are not even 200K. If you wind up with large executables then either you're including the graphics in huge arrays or your compiler is set up like shit. In most cases you can just put the engine in the internal memory(I think the GBA has 32k) and read the graphics off the cart memory witch is usually 8 MB. AniPasta must be a C programmer that got taught the evils of C++ and OOP. There really is not much of a speed loss with objects unless you pass all your objects as copies instead of references. Just wondering: What proceduaral and OOP languages do they teach the CS students in Leiden?
Ive read that "Programming the Nintendo Game Boy Advance: The Unofficial Guide" and it really is not a good book. It is a re-hash of everything that has been on the net for a few years. And they spend so much time talking about the basics and the philosophy, that they run out of time and gloss over the important stuff. Also. I dont reccomend using HAM because it uses too many goddamn macros and shady code. Or atleast it did a few years ago. But if are a super elite C programmer than it should be second nature to you. But if you are a beginner then stick with DevkitAdvance and C++.
It's hard to beat ARM assembly! It just slightly edges out 68000 assembly, due to the conditional store type instructions.
Nope. The assembler I wrote was part of a compiler I am writing for a new programming language. I chose to write the first assembler (first because the language is going to be platform independent) in ARM7 assembly because it is so much easier than Intel x86 assembly. I used Goldroad when I was first learning ARM7 for the GBA. I remember it having some issues with requiring # in front of some literal constants, and used some other command instead of MOV when it was actually using MOV. But otherwise it's a good assembler with many easy-to-follow tuits.
