#20213 - Lord Graga - Tue May 04, 2004 9:35 pm
Heya. I made this thread to discuss what people want from a basic libary. This is for us to see what you all like, so that we can think about it when we write our own libs, because, lets face it: Nobody really uses a non-customized library.
And what do you feel is most important: Speed or size?
One of the things that I feel is mostly important is what's called "gba.h" by default. This is one of the least customized files, because it's so bloody important to be able to ask for basic help without fumbling it all up because of different names/addresses. Since it's only a bunch of #define's there isn't much to optimize.
Moving on to sprites. In a sprites.h, I will always need:
InitializeSprites (Which can basicly be nothing but a #define that points to a DMA function)
MoveSprite
RotateSprites
CopyOAM (Just like InitializeSprites)
These are the fundamental functions, and I've never ever needed anything else to work around with sprites (except for a good SIN/COS lookup table).
And about SIN/COS, I always find it clever to make two s16 arrays for them, instead of using the sin() and cos() functions. Basicly because sin() and cos() will take a huge amount of space required to make a huge, precise table. On GBA I would never see what that would be good for, since it's really not requirering total precise numbers anyway.
A simple function to look up Cos from SIN isn't that hard to write either.
I'd like to write more, but I'll go to bed now, and edit it tomorrow. I'd like it if you would write more about your experience with optimizing basic functions, etc.
#20218 - Gopher - Tue May 04, 2004 10:39 pm
I do GBA programming purely for the fun of it in my free time, so time is not a critical factor in my development. As a result I use my own libraries; my first month of dabbling with GBA I ran through various documentation & tutorials and built up my own base libraries. They're all written in C; Much of it needs rewriting now, since I didn't really know my way around GBA very well when I wrote much of it. The bits that need rewriting I'll eventually go back and rewrite in asm.
My sprite module includes a rather over-complicated dynamic memory system for allocating both OAM entries and charmem; the OAM allocator is quite smart, and if works fine if you needed to be able to create/destroy a lot of sprites (well, OAM entries anyway), but the charmem allocation system has too much memory overhead and isn't very fast. All I actually use usually is some #defines and typedefs, I rarely actually link GGBASprites.o into the exe.
My sin/cos functions are in a separate GGBAMath module; my 'angles' divide a circle into 256 units, so I have a table of 256 hwords (0.16) and some macros to pull out sin or cos from that table ( remember that cos(a) == sin(a+90))
Anyway, after my experience so far, I'd say size is more important in general, as most speed-critical routines I've had to write were very application-specific. There are exceptions, of course, such as reusable Mode7 libs which obviously require a fast hblank handler, but in most projects at least 90% of the code I reuse is macros and macro functions.
_________________
"Only two things are infinite: the universe, and human stupidity. The first is debatable." -Albert Einstein
#20227 - dagamer34 - Wed May 05, 2004 12:53 am
At this point, speed is more important in my lib, since I'm don't developing a multiboot ROM.
Often though, the problem when making a customized library is realizing that if you make another game/demo, some things will have to be re-worked later on. Often I just stare at the screen wondering if I should add a new module to my library or not.
Very low-level things should be in a library, other details can be covered by a game. And since most of us never profit from our efforts, re-usability is key!
_________________
Little kids and Playstation 2's don't mix. :(
#20229 - sajiimori - Wed May 05, 2004 1:07 am
Mike made a great post on this subject (or at least a closely related one) in the Game Design forum.
http://forum.gbadev.org/viewtopic.php?t=3250
#20274 - SmileyDude - Thu May 06, 2004 2:01 am
I've been building my own library over the past year or so for the GBA (originally named gbalib :) ). Some of the things that I included are:
gba.h: Actually, my gba.h is just a small wrapper that basically looks like this:
| Code: |
#if !defined _GBA_H_
#define _GBA_H_
#if !defined __ASSEMBLY__
#include "GBALibTypes.h"
#endif
#include "GBALibHWRegs.h"
#include "GBALibHWFlags.h"
#include "GBALibMemoryMap.h"
#endif /* _GBA_H_ */ |
The way I've set it up is that gba.h can be included from .c/.cpp and .S files. That way, I'm using a consistent set of defines for everything.
I broke down the traditional gba.h into 4 parts -- C/C++ Types, registers, flags for the registers, and a memory map of the GBA (i.e, VRAM, IWRAM, EWRAM, etc). So, my gba.h should be functionally equivalent to any other gba.h file out there.
From there, I added some other functionality, like BIOS calls (though, not complete at this time), debugging routines (print out via MBV2 cable or though Mappy calls), DMA macros, a standard font that can be used for small test programs (along with functions that can be used to actually print to the screen), a MOD tracker and 4 channel mixer (lotsa room for improvement here), some basic Sprite routines, some palette management code (palette fades, gamma correction), sin/cos tables, and utility functions that don't fit anywhere else (for example, simple PRNG routines, int to string functions, sprintf type function, Min/Max macros).
One thing that I encountered when working on this is that it's better to split up functions into multiple .c files when possible, so that unused functions don't get brought in at link time. So, even though I provide a standard font that can be used, it doesn't add any bloat to the ROMs generated if you don't use it.
As time goes on, I've been moving code that I have used in more than one place into the library. It certainly makes it much easier to start a new GBA project.
I'm eventually planning on releasing the library on my website, but I really want to get some things straightened up in it. Like the crappy MOD player :) If anyone has an interest, please feel free to reply back here.
_________________
dennis
#20385 - maximAL - Sun May 09, 2004 10:39 pm
seems everyone codes his own 'lil library, API or whatever, huh?
just like me *G*
me cute lil "System" framework - as much as possible forced into an OOP concept *G* - has now reached the stage where it starts to be indeed usable. by far not everything is completet (i especially lack any knowledge about sound), but so far sprites, backgrounds, tiles and everything you'd really need to supply the world with more tetris-clones is up and working. i just implemented an interrupt handler. still untestet, but seems to work for the moment - without one line of ASM ;-)