gbadev.org forum archive

[Images not permitted - Click here to view it] [Images not permitted - Click here to view it]
Hugo Smits has released two 3d demos that both include source code:

I want to release 2 demos on gbadev.org,
a simple vector demo and a simple voxel demo.
Both include full sourcecode. I used them to learn myself 3D.
So the code is not superb (since it was the first time I tried 3D)
but maybe some other newbie can learn from it, just like I did :)

Both of the demos come complete with source code in C format.

You can grab the CuteCube and Voxel demos from the main site!

eeeeeeeeeek.

lots of errors in that cute cube:

1) Learn to set your PATH in your OS instead of doing it in the batch file
2) Don't use batch files, learn to use makefiles. It took me a day, but it's absolutely brilliant to play around with them. GBADev has becomed so much easier, and compiletime has been set down.
3) Do not point your PATH at /devkitarmdirwhatever/arm-elf/bin, but at /devkitarmdirwhatever/bin, and use the arm-elf- prefix when calling GCC
4) Try to learn to recieve the SIN/COS table from the BIOS
5) I think it's incredibly unsafe to INCLUDE an S file into the project. Like, higly highly unwise, because it's also unwise to put C code your source by including it.
6) There's lots and lots of other errors/things that could be fixed, like, you should update devkitarm.

Take this as a guideline, not as a personal critism.

Lord Graga wrote:

1) Learn to set your PATH in your OS

Not everybody who uses a particular Windows machine is an Administrator. Can non-Administrators set the PATH, especially given that different projects for different platforms may use different PATHs?

Quote:

2) Don't use batch files, learn to use makefiles

Then you get all sorts of path-separator ('/' vs. '\') and "sh.exe not found" issues that change whether you use MinGW make, MSYS make, or Cygwin make.

Quote:

4) Try to learn to recieve the SIN/COS table from the BIOS

How precise is this table? Is it just 8-bit?

Otherwise, I agree with your suggestions.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Yeah, the built in tables are 8-bit. At least the only way you can acces them is, I don't know how they're handled internally but you just use the OBJ affine set SWI with an angle, and no scaling, and then check PA/PD for the cosine of the angle, or PB for sine. Now that I think about it, I'm a little curious as to what would happen if you scale the object smaller, say, 1/4 normal size, would you get 4 times the accuracy on the cosine, or would it just be 4*the 8-bit one?
I'll report back in a minute after I run a quick test...
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

Ok, the SWI calls DO have higher accuracy than 8-bit. You can safely go up to 14 bits before you overflow the 16-bit PA/B/C/D parameters for OAM, although I think it would only be 1 that overflows, so you could get 15 bits and special case cos(0).
Here is the test code for generating a 16-bit table with 14-bits of accuracy:

Code:

void MakeTrigTable(s32 *table)
{
BgAffineSrc bgSrc[256];
BgAffineDest bgDest[256];
s32 i;

for(i = 0; i < 256; i++)
{
   bgSrc[i].x = 0;
   bgSrc[i].y = 0;
   bgSrc[i].tX = 0;
   bgSrc[i].tY = 0;
   bgSrc[i].sX = 256<<6; // 14 bits
   bgSrc[i].sY = 256<<6;
   bgSrc[i].theta = i << 8;
}
BgAffineSet(bgSrc, bgDest, 256);
for(i = 0; i < 256; i++)
   table[i] = bgDest[i].pa << 2; // +2 bits = 16 bits
}

_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

gbadev.org forum archive

News > basic 3D stuff

#25263 - krom - Thu Aug 19, 2004 5:16 pm

#25271 - Lord Graga - Thu Aug 19, 2004 6:32 pm

#25297 - tepples - Fri Aug 20, 2004 6:00 am

#25299 - DekuTree64 - Fri Aug 20, 2004 7:35 am

#25305 - DekuTree64 - Fri Aug 20, 2004 8:24 am