#18849 - dinmore - Wed Apr 07, 2004 2:17 am
Hi,
I'm thinking of learning to develop for the gba but I've never developed for anything where the resources are so limited. I was just wondering if someone could tell me how powerful the little thing is in terms I'd understand (something relating to how much code could be run per cycle and keep a game running at a good speed or something like that?) I'd be very grateful.
Thanks,
#18850 - dagamer34 - Wed Apr 07, 2004 2:24 am
Limitations don't come until you start pushing the system, and you can't start learning to push the system until you learn it.
So if you are beginning gba development, don't worry about that until you start seeing the effects of slow code.
_________________
Little kids and Playstation 2's don't mix. :(
#18852 - sajiimori - Wed Apr 07, 2004 2:57 am
That's right. If you are interested in GBA's exact specs, you can find them all over the net, particularly in the GBATek documentation. Also, see the FAQ for a broader overview.
#18860 - Sweex - Wed Apr 07, 2004 9:22 am
The dedicated graphics hardware of the GBA help you out a lot. It isn't too difficult to make ie. a platformer. Most of it comes down to filling memory during initialisation and changing certain registers (specific memory locations) to make the thing move.
Read some documents about it to get a basic idea of the hardware and you'll realise cool stuff can be done with very little!
_________________
If everything fails, read the manual: If even that fails, post on forum!
#19090 - darknet - Sun Apr 11, 2004 12:14 am
Unless you're trying to port Unreal 2004 to the GBA, don't be worried about the hardware limitations.
I was very concerned about the limitations at first too (I still am a newbie really, been working on my project for 5 or 6 months now), but I am finding that you can do quite a bit with the GBA if the different parts of memory and hardware are managed correctly.
That being said, the hard part (for me at least) was getting use to the tiny specifics of the hardware, like only being able to use the upper half of sprite memory in the bitmapped modes and so on (there's a number of these--the pern tutorials are particularly good at identifying those).
Another thing I would get comfortable with before really starting a project If I were you are the various tools out there-specifically those dealing with graphic converting (gfx2gba, pcx2sprite, gifs2sprites, etc...). I have had TONS of difficulties with those and, unless you want to write your own, you will be dependent on them for your entire project. Download em', draw tons of random stuff and move them around before starting anything at the logical level.
The people on these boards are very friendly and helpful if you don't get anything, so after making sure no one has already asked your question (that 'search' feature at the top is useful as is the FAQ), feel free to ask anything ya want.
Good luck,
-Mike
#19109 - Lupin - Sun Apr 11, 2004 1:42 pm
The gba has hardware limitations?!?! :o)
Seriously, you can do a lot of nice stuff on the gba, you just need a sense for optimizing your code if you start doing complex things.
darknet is right with the image converters, there are a lot of them and unfortunately most of them won't suite your needs :(
I wrote my own converter, it enables me to add features when i need them.
_________________
Team Pokeme
My blog and PM ASM tutorials
#19228 - dinmore - Wed Apr 14, 2004 6:33 pm
Thanks for the advice all. I wasn't expecting such a unianimous positive response in regards to the little thing's power.
Regarding graphics converters; A while ago I had a quick play with some converters and (using some borrowed headers until I've learnt the hardware properly) made a little prog to move my graphics about the screen. Could someone advise me what the difficult part is as I didn't have any problems so feel I must be making a mistake somewhere, is it common to fill the memory with junk for instance?
Thanks again,
#19229 - Lupin - Wed Apr 14, 2004 6:41 pm
The difficult part begins where you want to create a real game, when you have to write a level editor, create the game logic, save state system, editors, your own gfx, implement a sound engine, trying to implement hardware tricks like vblank effects, mode 7, bitmapped modes (eg. 3D engines), figure out interrupt handling...
Why do you want to fill memory with junk??
_________________
Team Pokeme
My blog and PM ASM tutorials
#19249 - LOst? - Thu Apr 15, 2004 9:15 am
I have seen a lot of the code released to the public here at gbadev and other places are based of a special style. It sets the modes and loads the data before going into the main game loop. It also use simply sprite movement and OAM copy with memset etc.
The main problem i had when I started was to get my game working like most of the official games.
Most of the official games are updating the screen mode every frame. It DMA's colors and sprites that's are updating all the time during the VBlank interrupt. Sprites are hidden by a flag and not moved outside the screen. The sprite entries are always updating and optimized every frame.
I saw this as a problem when I started. I wanted my games to be as close to the commercial ones and still there are a lot of things I can't do. The interrupts are in some way not working like they should. This may have to do with the crt0.s settings, but it may also be the code in crt0.s, and I'm not into ARM or Thumb assembler so I can't do these things.
So my game are so mixed with different techniques, and I guess I have to live with that.
Image converting programs are so different. Some of them, you have to add "const" after creating a header file. Some of them you must inclute gba.h, or do a typedef. Some even have to add a new line at the end of the files because GCC gives a warning.
And most of them tries to optimize the data so it get screwed in the end. That's a really big problem.
#19282 - darknet - Fri Apr 16, 2004 2:53 am
Fortunately, most people do not have the problems I did with graphic conversion programs. If anyone scans the forums for my cry for help posts, the majority of them have to do with getting garbage on the screen for my sprites.
To this day I do not know why I cannot get pcx2sprites to work. It simply doesn't for me-i've tried absolutley everything and written my code in every which way to get it to, but I just can't. However, gifs2sprites does finally work like a charm and that is what I use these days.
gfx2gba is a great program as well and seems to be the cleanest output of all of them. Like Lost mentioned, there is a problem sometimes with the programs trying to optimize things. If you choose to use gfx2gba, there is a '-x' option that will actually turn off all optimizations, which I suggest you do.
-Mike