#119676 - daxtsu - Sun Feb 25, 2007 6:50 am
I'm trying to get the background from the Crash Course Tutorial(http://www.webbesen.dk/gba/default.asp):
[Images not permitted - Click here to view it]
and it shows up like this:
[Images not permitted - Click here to view it]
and I'm not sure why(I converted it myself using GFX2GBA 0.13 as: gfx2gba -f src bg.pcx).
Here's my code:
Code: |
#include "gba.h"
#include "testpicture.h"
#define SCREEN_WIDTH 240
#define SCREEN_HEIGHT 160
#define COLOR_NUM 256
#define MEM_VRAM 0x06000000
#define PALETTE_RAM 0x05000000
#define frontBuffer ((u16*)MEM_VRAM) //(screen in modes 3-5)
#define palette_mem ((u16*)PALETTE_RAM)
int main(void)
{
SetMode(MODE_4 | BG2_ENABLE);
for(int i = 0; i < COLOR_NUM; i++)
palette_mem[i] = master_Palette[i];
for(int i = 0; i < SCREEN_WIDTH * SCREEN_HEIGHT; i++)
frontBuffer[i] = testpicture_Bitmap[i];
// continuous loop
while(1) {}
// end program
return 0;
}
|
Contents in testpicture.h:
Code: |
const unsigned char testpicture_Bitmap[38400] = {
0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02,
...
0x02};
unsigned short master_Palette[256] = {
0x0000, 0x0000, 0x7fff, 0x0000, 0x0000, 0x0000,
...
0x0000};
|
As my code mostly matches the tutorial's, I have no idea what's wrong. Any advice is appreciated.
EDIT: Wait a sec for the rest of this post, hit submit by accident. :P
EDIT2: Fixed the weird picture to the right one. XD
#119699 - Cearn - Sun Feb 25, 2007 10:54 am
testpicture_Bitmap is a byte array, frontBuffer is a halfword array. The mistmatch between source and destination is causing the gaps in the outcome. You can either a) cast to identical datatypes and then copy, or b) use a dedicated copy routine like memcpy, DMA or CpuFastSet.
One potential problem with all of these: the data might be misaligned because you're #including the data instead of compiling separately and linking later.
#119711 - tepples - Sun Feb 25, 2007 2:37 pm
Even compiling the data separately might still result in misalignment.
The only way to make a const char array and guarantee that it is aligned is to use a GCC attribute (or the equivalent in assembly language). As soon as I learned this, I started putting the relevant attributes in my own conversion program "bin2s", which wintermute has incorporated into the devkitARM distribution.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#119721 - Cearn - Sun Feb 25, 2007 4:01 pm
tepples wrote: |
Even compiling the data separately might still result in misalignment. |
You sure? According to the map-file, most of my files right now are word aligned. If I add a byte or two, file is padded (*fill*) until the next word-aligned address. Seems to work for C and asm files, so what am I missing?
Fair enough, inside those separate files things might be misaligned if you have non-multiples of four in the arrays somehow. But in nearly all cases, graphics conversions will use tile-sizes or screen-sizes, which are always multiples of four again. As long as you don't add single global bytes or halfwords, everything should be fine.
#119726 - daxtsu - Sun Feb 25, 2007 4:25 pm
Old post: If it's not too much to ask, could either of you write a short example perhaps on both ways of doing it(with really small arrays perhaps, so it fits on the forum)? My C is a bit rusty, so I've been having a little trouble remembering all this stuff.
EDIT: I did manage to get it working with PCX2GBA output instead, but if I ever needed to use GFX2GBA, any help would be appreciated. Thanks.
#119732 - Cearn - Sun Feb 25, 2007 6:23 pm
daxtsu wrote: |
Old post: If it's not too much to ask, could either of you write a short example perhaps on both ways of doing it(with really small arrays perhaps, so it fits on the forum)? My C is a bit rusty, so I've been having a little trouble remembering all this stuff. |
Code: |
const unsigned char testpicture_Bitmap[38400] = {
0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02,
...
0x02};
// with casting (to u32 because it's faster):
u32 *src= (u32*)testpicture_Bitmap, *dst= (u32*)frontBuffer;
for(int ii=0; ii< sizeof(testpicture_Bitmap)/4; ii++)
dst[ii]= src[ii];
// with memcpy:
memcpy(frontBuffer, testpicture_Bitmap, sizeof(testpicture_Bitmap));
|
For other examples: see tonc's demos, like this. See tonc anyway, as the crash course teaches bad coding habits and is very much out of date.
daxtsu wrote: |
EDIT: I did manage to get it working with PCX2GBA output instead, but if I ever needed to use GFX2GBA, any help would be appreciated. Thanks. |
There's also a tool called 'git', which can all of the work of the former (and more), and most of the work of the latter. It's also part of the latest version of devkitPro.
#119735 - tepples - Sun Feb 25, 2007 6:29 pm
I thought git was a revision control system used for the Linux kernel.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#119751 - gauauu - Sun Feb 25, 2007 9:57 pm
That too. But Cearn's git is the best graphics tool for gba that I've used....it has all the power of Usenti and Wingit, but from a nice scriptable/makefile-able command line interface.
#119756 - tepples - Sun Feb 25, 2007 11:29 pm
But can a user who develops Linux and a user who develops GBA games both have their git installed on one machine?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#119761 - keldon - Sun Feb 25, 2007 11:45 pm
Git [according to the site] should be able to compile cross platform with a few changes to the makefile.
#119766 - Cearn - Mon Feb 26, 2007 12:27 am
About the name: yeah, wintermute already informed me of the clash with the Linux tool. We're still considering new names, possibly congit (console git), analogous to the gui tool, or grit (Graphics to Raw Image Transmogrifier). Feel free to provide other suggestions. Preferably by PM or mail, as this thread is about something else.
On the alignment of separate files, some additional testing reveals this: the alignment of a file is related to the largest datatype inside it. So if you have any ints (words) in there, it'll align to a 4-byte boundary. If there are no ints, but there are shorts, it'll align to a 2-byte boundary, and if there's only byte-sized elements, it's byte-aligned. These things are probably ordered by sections, rather than file items: a RAM int wouldn't affect the ROM alignment and such.
This type of alignment is much like the aggregate alignment that EABI uses; maybe older the devkits did align files to word boundaries, just not DKP r19 and onwards.
#120045 - daxtsu - Wed Feb 28, 2007 4:04 pm
I recently decided to move to Eclipse so I have an IDE to work with. However, whenever I try to use my testpicture header, it just says that my arrays are undefined references, even though they're clearly defined in the header(now in a C file! ;D). Why is this?
Code: |
#include <gba.h>
#include "testpicture.h"
int main()
{
for(int i = 0; i < 256; i++)
palette_mem[i] = testpicturePal[i];
while(1){}
return 0;
}
|
Code: |
#ifndef __TESTPICTURE__
#define __TESTPICTURE__
#define testpicturePalLen 512
extern const unsigned short testpicturePal[256];
#define testpictureBitmapLen 38400
extern const unsigned short testpictureBitmap[19200];
#endif // __TESTPICTURE__
|
EDIT: Nevermind. I forgot to include the header in the testpicture.cpp file. :)
Last edited by daxtsu on Wed Feb 28, 2007 6:13 pm; edited 1 time in total
#120059 - Cearn - Wed Feb 28, 2007 5:54 pm
daxtsu wrote: |
I recently decided to move to Eclipse so I have an IDE to work with. However, whenever I try to use my testpicture header, it just says that my arrays are undefined references, even though they're clearly defined in the header(now in a C file! ;D). Why is this?
Code: |
#include <gba.h>
#include "testpicture.h"
int main()
{
for(int i = 0; i < 256; i++)
palette_mem[i] = testpicturePal[i];
while(1){}
return 0;
}
|
Code: |
#ifndef __TESTPICTURE__
#define __TESTPICTURE__
#define testpicturePalLen 512
extern const unsigned short testpicturePal[256];
#define testpictureBitmapLen 38400
extern const unsigned short testpictureBitmap[19200];
#endif // __TESTPICTURE__
|
|
They're not defined in the header, they're declared in the header. Definitions and declarations are two different things. Declarations just indicate that something of a given name exists, either in that file or another. The definition is where the actual data is, in this case inside testpicture.c.
The problem is probably that you're not compiling / linking testpicture.o to the project. Check your makefile to see it's included in the compilation and linking steps.
ETA:
In the makefile you should have a list of object files somewhere. something like
with is then used in the project's compilation and link rules. All you 'd hav eto do is add testpictures.o to that list and it will (should) take care of things automatically. It's possible that Eclipse does things a little differently, but there should be something similar there.
#120060 - daxtsu - Wed Feb 28, 2007 6:14 pm
I figured it out, like I said in my edit: I forgot to #include the header file in the corresponding C file. Lol.
EDIT: Yet another problem now..the picture just shows up as a weird green on my screen, with nothing else. Is this an alignment issue?
EDIT2: Man, I really need to read up on how this stuff works.. I fixed it..