![]() I have not used a 16-bit image yet, so I can't say what it takes to use them. Sprites and backgrounds can be 8-bit (256 color), or 16. Make sure the the files are saved with the right bit depth. bmp, run it through grit, and move the resulting files to our project folder. In order to use an image, we need to save it as a. It's still a good idea to keep track of these though, say, if we need to delete all sprites that use the "enemy" sprite map or something like that. Note that after creating a sprite, we no longer need the map ID or palette ID to reference it. ![]() We aren't actually passing around objects or anything. What it really wants is the sprite map ID number. In NFlib, the function arguments will ask for things like the "sprite map". This can get confusing since we now have 4 ID numbers that all refer to different things: screen, sprite, sprite map, and palette. Within each screen/engine, each sprite has an ID number. This is important as the DS has two graphics engines, one for each screen (it has more for 3D stuff, but that comes later). Part of telling the DS where to draw the image is specify which screen we want. With NFlib, RAM can hold 256 sprites/64 palettes and VRAM can hold 127 sprites/16 palettes This will be useful on level changes, new areas, etc. We do have the ability to change what sprites are in RAM. ![]() The idea behind these 2 memories is that everything is loaded into RAM at the start and things are only sent to VRAM as needed. Everything else like code and variables will stay in RAM. Sprite maps and palettes that are being used need to be in VRAM in order for the DS to use them. VRAM is very similar, but it is dedicated to graphics operations. RAM is much like the RAM in your computer. First, we must understand how the memory is organized. For our purposes, we need to be able to load the sprite map and palette into memory and tell the DS how and where to draw the image. Another famous example of this is Super Mario 3, where the clouds and bushes are actually the same sprite but with different colors. This can be seen in many RPGs where several enemies are just different colors. Different sprites can use the same palette to save memory space, and we can draw the same sprite several times, using a different palette each time. Sprites are stored in memory as a sprite map along with a color palette. ![]() The DS along with many older consoles use a sprite system for displaying things. The starting point for this is understanding sprites. NFlib abstracts a lot of the memory manipulation away, but we still need a high-level understanding of what it is doing so we know what functions to call and when to call them. This means that this project will also be a great exercise in developing a small framework to keep the code organized and efficient. This is great if you want to make something that isn't a game, but means there is more work on our end. ![]() These libraries only offer abstraction for the DS hardware. Neither libnds nor NFlib include any functions for a game loop, scenes, or levels. Also, the website for NFlib is in Spanish, but the download comes with an English version of the manual. If you aren't using NFlib, I would still recommend picking up the Grit scripts that come with it. NFlib also comes with Grit, a tool for converting BMP images into the proper file type for the compiler/linker to package into the ROM. Technically libnds is all you need to work with the DS, but NFlib makes the process a lot easier to get into. NFlib is another library that abstracts the DS hardware even further. The devkitARM installer includes the compiler and the libnds library. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |