#24622 - gooms9 - Sun Aug 08, 2004 2:41 am
hey, how is 3d done on the GBA? Is there any tutorials? I havn't been able to find any information on it. I want to code a demo with a 3d character walking around on a 2d background (like final fantasy 7). Would a 3d character be the best way to do this?
#24625 - Krakken - Sun Aug 08, 2004 3:53 am
The GBA has no native 3D chip. All 3D that is done is emulated by the coder using mathematics. It's not easy at all.
#24626 - gooms9 - Sun Aug 08, 2004 3:59 am
is there anywhere that shows some basics on how it's done? Are there any other alternatives for my idea? Would the gameboy hold sprite data for like, 24 different positions per sprite? This is all still quite new to me so I dont exactly know the limitations of the GBA.
#24627 - dagamer34 - Sun Aug 08, 2004 4:28 am
| gooms9 wrote: |
| is there anywhere that shows some basics on how it's done? Are there any other alternatives for my idea? Would the gameboy hold sprite data for like, 24 different positions per sprite? This is all still quite new to me so I dont exactly know the limitations of the GBA. |
You can either copy a frame to VRAM as it is needed, or you can store all the frames in VRAM and simply change the tile index in OAM memory.
_________________
Little kids and Playstation 2's don't mix. :(
#24635 - sajiimori - Sun Aug 08, 2004 6:51 am
For general software 3d techniques, the black book is pretty comprehensive. It focuses on x86 but the principles are the same.
#24647 - ScottLininger - Sun Aug 08, 2004 5:04 pm
You'd be much better off designing your 3D character in another tool, then exporting to flattened frames to display inside a sprite.
As dagamer said, you usually have more than enough cycles every game frame to copy a fresh character frame from the cart ROM to your sprite VRAM. So you could have hundreds and hundreds of frames for your character if you're willing to make a multi-megabyte game.
Of course, managing all of those frames and when to display them might be ugly.
By the way, OAM Memory is a section of the GB's memory where information about sprites in stored. VRAM (video ram) is the section where actual graphics are stored.
I first learned from the PERN tutorials: www.thepernproject.com
:)
Scott
#24648 - f(DarkAngel) - Sun Aug 08, 2004 5:09 pm
#24650 - gooms9 - Sun Aug 08, 2004 5:48 pm
wow! Thanks you guys, this is more then I expected. I have one more question. Is it possible to change the spritepalette during the game? Like say I have one sprite in one scene with 256 colors, and then the next scene I want to swap it with a different sprite that has different colors. Does tha make sense?
#24651 - keldon - Sun Aug 08, 2004 6:38 pm
yes, that's not a problem at all
#24657 - col - Sun Aug 08, 2004 9:36 pm
| gooms9 wrote: |
| wow! Thanks you guys, this is more then I expected. I have one more question. Is it possible to change the spritepalette during the game? Like say I have one sprite in one scene with 256 colors, and then the next scene I want to swap it with a different sprite that has different colors. Does tha make sense? |
You can only have 256 colours for all sprites at any one time (assuming no fancy hblank interrupt tricks). These can be used as 1 x 256 colour palette and/or 16 x 16 colour palettes. So if you want to dynamically alter the palette for individual sprites, it is important to divide up the available colours between the different sprites and alter only the palette entries for the sprite in question.
Most commercial games use the 16 x 16 colour palettes setup.
cheers
Col