I havent found time to post recently as I’m on holidays and visiting family. Still visiting and reading drunkencoders, but less time for the computer. Hoping to be back in the new year
This post is more of a cautionary tale rather than showing progress. It documents my unsuccessful attempts to quickly retrofit palette support to my BMP drawing module, where I grossly underestimate how different the two modes are and so try to hammer the changes into my flipbook animation code. My first lunge produces odd colours, so I spend a large chunk of time searching for more information on the structure of the NDS BG_PALETTE, with no success. After evaluating my options, I decide that I’ve wasted a lot of time, so I should try another shortcut and widen my search to include GBA information, leading me to a GBA programming guide called tonc. Reading this illuminates some of my errors, but I finish the week with no progress. Adding to this I have other commitments that mean I’ll have no time to devote to this next week. When I return I’ll look at taking the long path and building the palette support from the ground up, rather than muddying the waters with a test program designed for animations. Read the rest of this entry »
This week I only had 50% of the time I usually play with the Tutorials, so I covered less ground than I hoped. It was pointed out that the way I was using memory was not practical, and although I’m happy with that just to try out these demos, I thought it would be a simple matter to correct. I consider the fact that I could make improvements in the size of the BMP file in Main memory, and also in the size of the video memory buffer I am using, then proceed to make changes to the input BMP files. These changes require new code to handle 4bit paletted BMP file format, and after tripping over an integer division bug, I make the necessary changes to the code. Improvements in the more critical Video Memory usage will be pushed into yet another post. Read the rest of this entry »
This week I have continued with the Animation Section of the Tutorial. I massage the given source code to create something that runs, before investigating my VRAM memory usage and making corrections. Finally I reflect on a few things I will try, but not write up. Read the rest of this entry »
This post covers my first steps to showing an animated image on the NDS. Again I take longer than intended as I follow the intent of the Tutorial, but have to search around for missing pieces of code and data. After I find and edit a sequence of frames to display, I then adjust my BMP display algorithm to handle 24bit images. With this working, I refactor the code and implement a loop that continously displays each of the frames. I burned through a lot of time searching for my source images, looking at old game sprites, so I’ve run out of time again and I’ll leave the implementation of the Double Buffering till my next post. Read the rest of this entry »
Fighting with WordPress last week meant that I extended “Displaying Pictures” into a third blog post. Last week I managed to get an example BMP file from the computer into my nds program. This week I read the last paragraph of the section, but find the source code fragment is optimized for a different BMP file. I rebuild the example program step-by-step to display my BMP file, and I see my image displayed on the main screen (woot!). Read the rest of this entry »
I’ve finally reached the next ‘significant milestone’ in programming the DS, putting a picture on the screen…. at least I can see it in the distance. I read a long stretch about the different segments of the BMP file, and how to get the BMP file from my computer into my program, before discovering that the demo is missing. I do a little research to find some BMP resources and put together my own File Format diagram. As a waypoint I create a program to only print out some information from the BMP header, which comes in handy later, and prepare to combine all the elements shown into a program. Sadly WordPress decides to reject any saves past this point, so I continue this section again into a third installment.
I look at the Tutorial using a 2D mode background layer to display a pixel buffer, rather than the more limited earlier mode with only a single layer. Halfway through I pause to start another post about using Mercurial’s merge to illustrate how the two sections are linked, but I mess it up and decide to just modify the code I use in part B to duplicate the functionality shown in the tutorial. Finally I upgrade DevKitPro and break everything due to my AV software causing much ado about (probably) nothing.
I copied and pasted the code from the tutorial into a new directory and the code built without problem. A new function from input.h is used along with a custom type from touch.h. All the code fits onto one screen so it would be wasteful to try to refactor the code.
After I loaded the nds file into the emulator I again had troubles getting the information from the ARM7-only inputs to work in the emulator. Once I tried the nds file on my DS Lite, the program worked as expected.
|iDeaS 22.214.171.124||Fail (cannot detect stylus input)|
|DualiS (ARM946E-S R25)||Fail (crashes emulator)|
|DeSmuME 0.9.6||Fail (no painting on screen)|
I’m not sure why ndslib is not working properly with the emulators that I have been using. I have tried with a couple of non ndslib ROMs which worked fine with iDeaS. They also failed badly with DualiS, so I think that I can assume that DualiS is broken, and that ndslib and iDeaS are not playing nicely for some reason. I think I’ll try out the issue management system in my Google Code Project to remind myself later to look into this.
After I initially wrote this, I received feedback on the previous Tutorial section from Corey Holcomb-Hockin. Apart from rightly pointing out the the only true test is on the hardware, he also recommended two superior emulators : no$gba and DeSmuME. Unfortunately DeSmuME was unable to run this program, but no$gba appears to have no trouble, so I’ll be using no$gba as my primary emulator from here on. I expanded the emulators section on my DevEnv Wiki page with links for information and downloading.
After I spent a long time on the previous section, this one was very compact with just a single new function looked at. I’m was having problems with the ARM7 inputs while using emulators, but the code is working fine on the DS Lite. I find it quicker to launch the emulator rather than the much slower process of putting the NDS file onto the DS Lite hardware, so I was pleased to receive a recommendation of no$gba from somebody who took the time to read a prior post and help me out.
Part D : DS Color Formats [Theory]
Continuing from the video setup, this section talks about how to specify the colour of a pixel on screen. The material covers
- 16bit RGB format
- RGB macro
- 16 bit RGBA format
- memory implications of using 16bit bitmaps
Part E : Frame buffer 101 [Theory]
The next part covers a fairly straightforward topic of how 1D (straight line) computer memory is mapped to pixels on screen, but is then a little confused by the wrong and missing graphics.
Looking at the diagrams above you can see several arrangements of 40 elements into 2D blocks, and one example of a ‘screen’ holding 192 rows of 256 pixels. The first example is 1×40 which is similar to one dimension memory array in a C program. If this was mapped to a screen that was 10 elements wide, then to access the 4th element in the third row we would say that this is at co-ordinate (X = 3, Y = 2) because we start counting from zero. Multiplying the Y co-ordinate by the width tells us how many elements to skip for the rows above our point, while adding the X co-ordinate skips the elements to the left.
Part F: Pixels and things [ Code ]
The final part of this section is another program that displays a moving star field and breaks the main function into discrete actions. I liked the way the program functionality was broken up and explained in small chunks and it worked fine as presented, but as usual I couldn’t help but to shuffle some portions around.
To get rid of the global variable I pushed the stars array into main, and then passed the stars array to InitStars. After that I pulled the global variable VRAM_A out of the stars function and replaced it with an argument screen_buffer, so that the stars functions did not know which VRAM buffer they were using. To cluster all the mentions of using VRAM_A together, I created a function SetupScreenBuffer that returned a pointer to the screen buffer. Finally, I created another #define STARS_BGCOLOR so that the color in InitStars would always match the color in EraseStar. If I’d spent longer on it I would have made another structure Starfield, that would know about screen width, height and color, and would hold the stars array, but that starts to involve a lot of typing for a program I’m pretty sure I wont have to edit again.
|Source Code||Revision bd895f8679|
Another nice tutorial section that was easy to read with some theory and then a program to put together.