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.

Coding > Of API's and Such

#66642 - snowsquirrel - Thu Jan 12, 2006 5:19 pm

Last night I installed devkitarm, and made a hellow world with libSocrates.

I am just trying to decide which API I want to learn.
My only two requirements are:
1. C/C++
2. actively developed

I can't seem to find a breakdown of what is out there.
I suspect libSocrates is not actively maintained?
Is libGBA part of Hamlib?
How low level is hamlib? Just h/w abstraction? or more?
HEL looks like it provies some higher functionality on top of hamlib, are there any performance issues?
Are there other API's to consider?
What are your opinions on them?

If it helps, my background is: I wright OO-C++ for a living. I think Qt and Java are the too nicest API's I have used, although they are very large.

Thanks,

~S

#66657 - poslundc - Thu Jan 12, 2006 6:59 pm

snowsquirrel wrote:
Last night I installed devkitarm, and made a hellow world with libSocrates.

I am just trying to decide which API I want to learn.
My only two requirements are:
1. C/C++
2. actively developed

I can't seem to find a breakdown of what is out there.
I suspect libSocrates is not actively maintained?


That's correct.

Quote:
Is libGBA part of Hamlib?


No, it's part of devkitARM.

Quote:
How low level is hamlib? Just h/w abstraction? or more?


It's my understanding that most notably HAMlib provides management routines for managing resources like VRAM, objects and palettes in addition to hardware abstraction.

Quote:
HEL looks like it provies some higher functionality on top of hamlib, are there any performance issues?


There are always performance issues.

Quote:
Are there other API's to consider?


HAMlib is the only one I'm aware of that either offers any level of completeness and has had any recent, active development.

That said, most people don't bother with the development libraries as sooner or later you will find you need to discard them and learn the low-level stuff anyway if you want to make sufficient progress.

Quote:
If it helps, my background is: I wright OO-C++ for a living. I think Qt and Java are the too nicest API's I have used, although they are very large.


O_o It's a good thing you don't wright English for a living.

Dan.

#66660 - snowsquirrel - Thu Jan 12, 2006 7:30 pm

Thanks for the thorought reply.
Looks like Hamlib is what I want for now.

Quote:
O_o It's a good thing you don't wright English for a living.

You'd think that at a game dev forum, I might get away with a typo. :-) Actually my colleague sitting next to me, his last name is Wright, and I was talking to him, as I typed that. Weird.

~S

#66666 - poslundc - Thu Jan 12, 2006 8:14 pm

snowsquirrel wrote:
You'd think that at a game dev forum, I might get away with a typo. :-)


Just one, maybe. Let me know if you manage to find something better than QT and Java that won't be excessively nice. ;-)

(Don't get me started on apostrophes.)

Dan.

#69565 - Peter - Tue Jan 31, 2006 3:37 pm

poslundc wrote:

Quote:
HEL looks like it provies some higher functionality on top of hamlib, are there any performance issues?

There are always performance issues.


That's not 100% correct in this case. HEL requires HAMlib to function, that's true so far, but it needs them only for a few initializations.

HEL has a lot of functions developed from scratch because of performance issues in HAM. For example, HEL's object system is about 70 times faster than the one in HAM, the map system is also quite faster. All time critical routines have been written from scratch with performance in mind.

HEL also extends the HAM framework with features such as dynamic tile reloading, "unlimited" large map support and all this stuff usually found in these kind of libs.