#38813 - musicman3320 - Fri Apr 01, 2005 12:45 am
Hi all. I have been reading over some tutorials, and I am starting to think that writing all the basic GFX routines and such would be a real pain. There are so many things to consider and so many functions to write in order to take full advantage of all available registers. I am sure that someone has already taken the time to write these for general use, but I am having trouble finding them. I have heard of two possibilities so far: SGADE and HAM. I have tried using SGADE before, but it a lot of the seemingly necessary functions seem to be missing i.e. there are only two gfx modes supported, sound, etc., and because I am developing on a mac, I cannot get the tools to work. The other option is HAM, but again, I am programming on a Mac, and HAM only works for PC and Linux, so I am stuck. If there was a place that I could get the source to the HAM functions, or just a library to link my programs to, I would be set, but all I can find is Visual HAM, and that is only for PC and Linux. Are there any that I am missing? My hope is to dive right into game progamming without having to write all the basic functions, but the way it looks right now, I might have to. Any help in the general direction of a good library would be greatly appreciated.
Thank you in advance,
-Chris
P.S. Is anyone still updating SGADE? The website says that it hasn't been updated in almost a year and a half, but I find it hard to believe that someone would just drop it after all the work they put into it, what with the extensive documentation and code.
#38814 - poslundc - Fri Apr 01, 2005 12:59 am
I've never used it, but HAMlib should be entirely independent of the development platform.
SGADE is, as far as I know, abandonware. Sorry.
Dan.
#38874 - Kyoufu Kawa - Fri Apr 01, 2005 4:33 pm
| poslundc wrote: |
| SGADE is, as far as I know, abandonware. Sorry. |
In that case, my tearing it apart like a vulture on crack is no problem, right?
#38880 - musicman3320 - Fri Apr 01, 2005 4:46 pm
So what do most people use in their programs? Do they usually write their own libraries? I find it hard to believe that with all of the programs that have been written for the GBA, that they all wrote basically the same functions for themselves. Or then again, I am probably just being lazy and not wanting to take the time to write what I need.
It is too bad that no one works on SGADE anymore. I think it had a lot of potential, and it seems a shame that it was just dropped out of the blue. Does anyone know why it became abandonware?
Thanks again,
-Chris
#38896 - ScottLininger - Fri Apr 01, 2005 6:55 pm
I think most people do code their own libraries. It's really not all that much work if you code functions as you need them. Plus, it gives you a chance to really understand the hardware.
Yes, developing a library from scratch that supports every graphic mode and every conceivable action is a huge undertaking. But most games don't need all that, so it's reasonable to "code as you go."
That being said, there have been some posts from people offering up their libraries for public consumption. Try some forum searches and see what you find.
Cheers,
Scott
#38899 - Quirky - Fri Apr 01, 2005 7:30 pm
| musicman3320 wrote: |
| So what do most people use in their programs? Do they usually write their own libraries? I find it hard to believe that with all of the programs that have been written for the GBA, that they all wrote basically the same functions for themselves. |
But what functions do you need? In general you could just use defines and macros, no real taxing stuff for graphics.
Sound libraries are more common - there are a few "free" ones, krawall, AAS, etc - as sound is a bit trickier to get right.
#38901 - poslundc - Fri Apr 01, 2005 8:06 pm
It has been my observation that most API libraries for platforms like the GBA end up creating more work than they prevent.
For an API to be really useful, it needs to be robust enough feature-wise to give access to all or most of the GBA's features, which means it has to be low-level enough that it basically creates an unhelpful middleman between you and the hardware.
There have been several good stabs made at it, but in the end it just usually results in people learning an interface to code that they don't really need or benefit from.
Most programmers in this forum would rather manually write code that says REG_DISPCNT |= BG2_ENABLE; rather than call a function like EnableBackground(2);. The former reads just as easily as the latter, but provides more information as to what is actually being done.
There are some legitimate, useful places for external libraries, such as things like sound, and tepples' AGBTTY. But a general, all-encompassing library for GBA graphics programming? I believe it's ultimately self-defeating.
Dan.
#39020 - Steve++ - Sun Apr 03, 2005 5:59 am
| Quote: |
| There are some legitimate, useful places for external libraries, such as things like sound... |
For sound I'm using krawall. You have to pay ?12 to use it noncommercially, but it's worth it.
For graphics, I'm just coding my own stuff because it's dead easy. Read the specifications. I've had a look at HAMlib, but it just gets in the way. However, I'm using the ASSERT function it provides because it's extremely useful - error output on the GBA screen. HAMlib doesn't actually do too much as far as graphics go. You'll find yourself writing a set of graphics routines whether or not you use HAM. At the moment, I'm in the last stages of coding a tilemap scrolling engine with dynamic tile loading - something I haven't seen any publicly available library do, yet something that many people on these forums have coded up.
Think of it this way - If most people here have coded up their own routines, how hard can it be? I like to think of the registers as an API. All you need to do is pass the appropriate parameters and something happens as a result. So there really is no need for something like HAM or SGADE. You just need to read the GBA specifications. If you were using a library, you would have to read its documentation anyway, so what's the difference?
On a side note, I'll publish my scrolling engine when it's complete.
EDIT: I also recommend using something like Allegro or SDL in a prototyping environment. Sometimes when you program directly to the GBA (or emulator), your code doesn't work and it's not always apparent why that's happening. At least on a PC you can do some printfs to keep track of what's happening.
One example of prototyping: I'm using Allegro to develop my sprite-to-sprite interaction/messaging system. The screen is in 1024x768 mode and as I move the mouse, a 240x160 box moves around, which represents the GBA screen. That way I can see what happens on- and off-screen.
#39023 - tepples - Sun Apr 03, 2005 6:46 am
Another method of prototyping is to make your entire game in Allegro and redo the graphics and sound for the GBA, preserving the game logic. For example, TOD for GBA was ported from TOD for PC (which in turn was a cross-platform clone of Mute Fantasies' Tetripz).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#39026 - Steve++ - Sun Apr 03, 2005 9:13 am
Yet another usage of Allegro is making a level/world editor with lua scripting support. The game can be played and tested directly in the editor before being built as a gba file.
#39041 - musicman3320 - Sun Apr 03, 2005 6:02 pm
Actually, you are probably right. The reason I thought it would be such a pain was because I had been reading through some tutorials and the Cowbite Spec, and it just seemed really overwealming. Now that I have had some time to let it sink in, I don't think that it will actually be that difficult to do. Thank you all for the encouragement.
-Chris