I'm not going to write another tutorial here on how to do all that, plenty of info on the web for all that. Some folks following this blog may be real technocrats when it comes to games and consoles, and some others may be greener then Kermit the Frog's butt (insert my family members...they're just curious about what I'm doing). I'll try to explain things in a middle ground. If anyone out there happens to stumble across this blog ("My name is Rod Haxton and I will be broadcasting on this frequency..." ahhh...okay, had an "I Am Legend," moment) and wants more detail info, I will try to give it to them.
So, some basic info about the DS is that it can do both 2D and 3D. Currently, I'm focusing on the 2D because the style of game I'm thinking of doing is 2D and thus the major thing I have to get going first is a "tiling," engine. What is a "tiling," engine?
Tiles are an economical way of storing and displaying the bitmap images on the DS. The DS screen sizes are 256 x 192 pixels. The memory to store an image on the screen is 256x256 bits. Yes the pixel equals the bit. Thus, if I were to scroll the screen over the background, in one byte shift left or right (horizontal scroll), I would already have scrolled over the border of the image, and if were to do a vertical scroll down, I would be only 8 bytes (64 bits/pixels) away from scrolling over the bottom border (256 pixels - 192 pixels = 64 pixels / 8 bits = 8 bytes)
Fortunately, the DS has 64 background storage areas split into 2, 32 sections of graphic character base and character map base.
So, in the Graphics Base area one stores the background data (tiles). In the Map Base area one stores the tile offsets that make up the picture we want to display. I know for those unfamiliar this still isn't clear, hold on..The graphics base area is commonly filed with 16x16 (can be other sizes as well) postage stamp size pics. These individual pics are shoved into the Graphics (character) base. The Map Base area tells the DS 2D renderer how to arrange those pics (tiles) into a screen picture.
The following image example and text (italicized) is pulled from the DevScene NDS tutorial...
Below is all the graphics used to construct the entire overworld of the original Zelda.
You may recognize these little 16x16 chunks as pieces of the Zelda world and perhaps you could imagine that in order to describe the look of the overworld all one would have to do is store which tile goes where. For instance the following familiar scene could be represented by an array of tile numbers.
short map[] = {
64,64,64,64,64,64,64,06,06,64,64,64,64,64,64,64,
64,64,64,64,07,64,62,06,06,64,64,64,64,64,64,64,
64,64,64,62,06,06,06,06,06,64,64,64,64,64,64,64,
64,64,62,06,06,06,06,06,06,64,64,64,64,64,64,64,
64,62,06,06,06,06,06,06,06,63,64,64,64,64,64,64,
06,06,06,06,06,06,06,06,06,06,06,06,06,06,06,06,
64,67,06,06,06,06,06,06,06,06,06,06,06,06,64,64,
64,64,06,06,06,06,06,06,06,06,06,06,06,06,64,64,
64,64,06,06,06,06,06,06,06,06,06,06,06,06,64,64,
64,64,66,66,66,66,66,66,66,66,66,66,66,66,64,64,
64,64,64,64,64,64,64,64,64,64,64,64,64,64,64,64
};
Thus, the image with all the different tiles scrambled about is the Graphics Base data. The array of shorts is the Map Base data. If you look closely at the array of shorts you see that the number 64 represents the grass bushes in the image above.
Through code I would instruct the DS which area of Graphics, and Map Base data to address to paint my image on the screen. The "tiling," engine, needs to keep track of Map Base data and where on the screen correlates in the array, and when have I crossed boundaries and then need to index into another map array to keep the images on the screen seamlessly flowing (smooth scrolling both horizontally and vertically). The engine has to know where graphic maps that make up the world are stored in memory, where the tiles that describe how to be displayed are stored, where the screen is currently in relation to the world (screen to world coordinate translations) and when to pull new tiles into the map base memory area.
When I first got into game programming this was my first task to figure out, and imagine, I didn't have blogs, internet, or anything like that to figure it out. Luckily, I did have Ray (I forget Ray's last name). We worked for a company that did things, lets say, on the cheap. So, we had one manual for the GameBoy, and one development system, again for the GameBoy, Ray joined the company a month before me and so wisely he chose the documented and developer friendly system. However, I was doing Sega GameGear. No manual, no dev system, just a card that I could plug into the GameGear and slap an eprom chip onto it. Talk about flying blind, I had to flash the screen to let me know yes or no, but then with all those blinks happening I couldn't tell if it was one or two blinks, and what was I asking.
So, trying to write a complex algorithm (oh did I mention, in Z80 assembly) without a debugger, I wasn't going to get my tile scrolling algorithm to work within the two week period I was given. Ray saw me sweating and came to the rescue. He figured it out on his system, and gave me the code. Of course, I had to tweak somethings here and there to get to run on the GameGear. Fortunately, after much bitching and moaning on my part, the owner spent a few dollars and cobbled together a system that would allow me to debug the Z80 code...not the official dev kit, but hell of a lot better than flashing screens.
Therefore, the "tiling," engine is the major thing to figure out. Everything else from here in the 2D world is gravy.
Off to tile!
No comments:
Post a Comment