gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Beginners > How do I get started with GBA development? [Renamed]

#161677 - eon89 - Sun Aug 10, 2008 3:20 am

I have NEVER tried doing anything like this before so ANY help is appreciated.

Just to give you a idea of what I know: Nothing

I downloaded HAM because I heard it was a easiest to use.

Any links or videos that may help me on my way would help.

Is HAM really the easiest?

#161685 - gauauu - Sun Aug 10, 2008 10:39 am

eon89 wrote:
Just to give you a idea of what I know: Nothing


Did you read the Beginner's faq? Also read this recent thread: http://forum.gbadev.org/viewtopic.php?t=15924

Quote:
I downloaded HAM because I heard it was a easiest to use.


It may be slightly easier to use, but as far as I know, it's rather out of date. And it's not all that much easier to use. Your best bet is to learn how the stuff actually works, and use devkitArm like most everyone else.

But like those two posts above will tell you: if you don't know how to code reasonably well in C or C++, go away and learn on your PC for awhile, then come back when you do.

#161697 - Ruben - Mon Aug 11, 2008 8:52 am

Well, you don't ALWAYS have to pre-learn computer languages as I'm self taught at C, C++, ASM, etc... but anyway...

"I have NEVER tried doing anything like this before so ANY help is appreciated. "

Read TONC. The best GBA programming tutorial one could ask for.

"I downloaded HAM because I heard it was a easiest to use."

Well... if by "easiest to use" you mean HIGHLY inefficient code, but that is a bit like the OpenGL drivers (glLoadBitmap, or whatever), then yeah, it is the most.. um... familiar one. But if you want to have efficient code and learn good programming ethics, read TONC. Saves you a lot of headaches later on.

#161753 - sgeos - Wed Aug 13, 2008 1:49 am

Ruben wrote:
Well... if by "easiest to use" you mean HIGHLY inefficient code,

Your code only needs to be efficient enough. Often times programmer efficiency is more important that processor efficiency.

-Brendan

#161759 - Ruben - Wed Aug 13, 2008 4:42 am

sgeos wrote:
Your code only needs to be efficient enough. Often times programmer efficiency is more important that processor efficiency.

-Brendan

What I was referring to was how slow HAM was. For example, in one of the examples, they had a function like this:

Code:
u8 ix, iy;
for(ix=0;ix<240;ix++) {
 for(iy=0;iy<160;iy++) ham_plotm4(ix, iy, 0);
}

And supposedly, that code was faster than HAM's code for filling. There are at least 4 optimizations I see there (using int's instead of u8's, making ix=240, then use a while(ix--), same with iy, and plotting using the registers). These are just minor issues but still worth considering. Probably the worst part of HAM is how it handles V-Blank. It installs an interrupt, but instead of using "swi 5", it uses a code similar to this (since it doesn't acknowledge the BIOS interrupt flags):

Code:
bool vblank = false;

void main(void) {
 ham_installInterrupt(vbl, VBL_INTR);
 
 while(1) {
  while(!vblank);
  //code
  vblank = false;
 }
}

void vbl(void) {
 vblank = true;
}

I know that still works, but this drains the battery real quick.

#161776 - sgeos - Wed Aug 13, 2008 9:14 pm

Ruben wrote:
I know that still works, but this drains the battery real quick.

This is a very considerate way of thinking. I'm sure there are plenty of commercial shops out there who could care less about battery life when they are trying to get something out the door.

My point is that, sometimes things just need to work. There are probably better ways to go about any given task, but there are other things to do too. My two favorite quotes from Knuth are "premature optimization is the root of all evil", and "you can rewrite forever if you want to" (actually, he quoted someone else on the second one, but my copy of AOCP was lost in a flood).

As far as optimizations go, often times just writing code that works, without worrying about what will be faster, actually makes things easier for the compiler to optimize your code. For this very reason, ints should be used instead of u8 because there is no reason to use u8. (If two bytes push you over the limit, you have more important things to worry about. )

If you want to make really nice programs, you probably want to write your own custom libs. The cost performance (in time) is too high for someone who just wants to get their feet wet.

-Brendan

#161782 - tepples - Wed Aug 13, 2008 10:32 pm

Another benefit of optimization is that it makes programs more responsive if your PC is old. If your program drains the battery less, then it will generally run faster in emulation on slow PCs, and vice versa. You'll need less frameskip to keep the audio going smoothly. But then my perspective is colored by using a 7.5 year old PC with an 0.86 GHz Pentium III CPU as my primary PC.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#164119 - wintermute - Tue Oct 21, 2008 3:35 am

sgeos wrote:
Ruben wrote:
I know that still works, but this drains the battery real quick.

This is a very considerate way of thinking. I'm sure there are plenty of commercial shops out there who could care less about battery life when they are trying to get something out the door.


For what it's worth, not using the appropriate battery saving functions *will* result in a commercial GBA or NDS game failing lot check & never getting out the door.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#164122 - elwing - Tue Oct 21, 2008 8:01 am

wintermute wrote:
For what it's worth, not using the appropriate battery saving functions *will* result in a commercial GBA or NDS game failing lot check & never getting out the door.

would hope it was right, but I doubt much less people would buy, let's say the latest final fantasy tactics, if they were not taking care of the battery... for customers it's more like an added feature if the game is good...

that said I'm quite surprised that the moto about "premature optimization" and "root of all evil" wasn't mentioned yet :)
but in my mind, using interupt to catch Vblank is not a better way to do it, nor an optimisation, it is the only way to do it...

#164141 - tepples - Tue Oct 21, 2008 7:56 pm

wintermute wrote:
For what it's worth, not using the appropriate battery saving functions *will* result in a commercial GBA or NDS game failing lot check & never getting out the door.

Then I wonder why TOD, which uses a mode 7* projection similar to that of Mario Kart, uses significantly less battery than most cinema scenes and microgames of WarioWare Inc.: Mega Microgame$, which are 2D. My tests on NO$GBA, VisualBoyAdvance, and GBA hardware bear this out. I guess lot check for third-party games must be stricter than lot check for Nintendo's own games.


*enum { MODE_7 = 0x0001 };
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#164144 - Dwedit - Tue Oct 21, 2008 8:22 pm

Warioware just uses a busy waiting loop, so you don't know how much CPU they're really using.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#164146 - Miked0801 - Tue Oct 21, 2008 9:30 pm

The rules are always different for 1st and 2nd party games...