#49627 - aRsus - Mon Aug 01, 2005 12:41 am
I'd like to know what tool is best for converting images to sprites for devkitarm as i know devkitarm is a little stingy with some formats.
-Thanks.
#49628 - wintermute - Mon Aug 01, 2005 1:45 am
| aRsus wrote: |
I'd like to know what tool is best for converting images to sprites for devkitarm as i know devkitarm is a little stingy with some formats.
-Thanks. |
stingy in what way?
#49682 - aRsus - Mon Aug 01, 2005 6:21 pm
That is to say, it doesn't accept some formats. It can't interpret C arrays and doesn't recognize RAW files outputted by some sprite utilities and the like.
#49700 - wintermute - Mon Aug 01, 2005 8:12 pm
| aRsus wrote: |
| That is to say, it doesn't accept some formats. It can't interpret C arrays and doesn't recognize RAW files outputted by some sprite utilities and the like. |
You've been badly misinformed somewhere.
1. Compilers don't interpret things, that's why they're called compilers, not interpreters.
2. Any C compiler, including the one included in devkitARM, can handle C arrays just fine.
3. RAW files are a simple binary format and as such are not recognised by any toolchain.
4. Several of the examples in the devkitPro cvs exhibit various ways of including binary data within projects.
http://devkitpro.sourceforge.net/setup.shtml
http://www.double.co.nz/nintendo_ds/index.html
#49727 - aRsus - Tue Aug 02, 2005 1:51 am
OK... then how come devkitarm always responds with "junk at end of line, first unrecognized character valued..." when assembling with certain formats?
#49728 - wintermute - Tue Aug 02, 2005 2:06 am
| aRsus wrote: |
| OK... then how come devkitarm always responds with "junk at end of line, first unrecognized character valued..." when assembling with certain formats? |
what formats?
#49810 - aRsus - Tue Aug 02, 2005 7:06 pm
| wintermute wrote: |
| what formats? |
Haven't I made it clear? RAW files for one and C arrays. Of course arrays aren't a format but a bunch don't work.
#49811 - wintermute - Tue Aug 02, 2005 7:45 pm
| aRsus wrote: |
| wintermute wrote: | | what formats? |
Haven't I made it clear? RAW files for one and C arrays. Of course arrays aren't a format but a bunch don't work. |
You haven't made it even slightly clear.
Obviously you're doing something very, very wrong.
#49817 - aRsus - Tue Aug 02, 2005 8:07 pm
Don't you get it? Devkitarm won't compile w/o errors if there's a file that has data that reads 0x... and so forth that many utiilities output because they output it in a C array but Devkitarm can't read those. Clear yet?
#49823 - poslundc - Tue Aug 02, 2005 8:36 pm
| aRsus wrote: |
| Don't you get it? Devkitarm won't compile w/o errors if there's a file that has data that reads 0x... and so forth that many utiilities output because they output it in a C array but Devkitarm can't read those. Clear yet? |
...
*attempting to be helpful* What command-line utility are you using, and on what type of data file, and what error message are you getting?
Dan.
(P.S. FYI, DevkitARM "reads" C arrays just fine, but you need to process the C arrays with the C compiler, and link them in using the linker.)
#49829 - aRsus - Tue Aug 02, 2005 9:07 pm
poslundc wrote: | Quote: |
| P.S. FYI, DevkitARM "reads" C arrays just fine, but you need to process the C arrays with the C compiler, and link them in using the linker |
Darn it! Sorry for being so stupid. Could you tell me how to link using the C compiler?
#49832 - tepples - Tue Aug 02, 2005 9:13 pm
compile:
| Code: |
| gcc -mthumb -mthumb-interwork -c data.c |
The -c switch means to compile a C file into an object code file without doing any linking.
link:
| Code: |
| gcc -mthumb -mthumb-interwork -specs=gba.specs game.o data.o -o data.elf |
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#49837 - poslundc - Tue Aug 02, 2005 10:08 pm
And if that doesn't get it working for you... post what you entered as well as any error messages you got.
Saying the devkit can't handle it is unlikely to be helpful in locating an error that is almost certainly at your end, and not the fault of the devkit.
Dan.
#49863 - aRsus - Wed Aug 03, 2005 1:37 am
Alright, after compiling with the compiler and then linking, I get the following errors while assembling. Spr.o is the converted C file.
Here's what I typed.
arm-elf-gcc -mthumb -mthumb-interwork -c spr.c
arm-elf-gcc -mthumb -mthumb-interwork -specs=gba.specs demo.txt spr.o -o data.elf
And here's what i got:
spr.o: Assembler messages:
spr.o:0: Warning: end of file not at end of a line; newline inserted
spr.o:1: Error: junk at end of line, first unrecognized character valued 0x7f
spr.o:1: Error: junk at end of line, first unrecognized character valued 0x1
spr.o:1: Error: junk at end of line, first unrecognized character is `('
spr.o:1: Error: junk at end of line, first unrecognized character valued 0x1
spr.o:1: Error: bad instruction `? '
spr.o:1: Error: junk at end of line, first unrecognized character valued 0x4
spr.o:1: Error: junk at end of line, first unrecognized character is `4'
spr.o:1: Error: junk at end of line, first unrecognized character is `('
spr.o:1: Error: junk at end of line, first unrecognized character valued 0x6
spr.o:1: Error: bad instruction `???τ?╧?│???????τ?╧?│????⌂~⌂f⌂N⌂2⌂'
Can you please tell me why this is?
#49867 - tepples - Wed Aug 03, 2005 2:13 am
How did you generate demo.txt ?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#49926 - aRsus - Wed Aug 03, 2005 6:49 pm
How do you mean?
#49941 - tepples - Wed Aug 03, 2005 8:28 pm
What is the content of demo.txt? If it is long, what are the first dozen lines or so?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#49959 - aRsus - Wed Aug 03, 2005 11:57 pm
It's really short. Just displaying a sprite.
.arm
.text
.global main
main:
bl vblank
ldr r0, =0x4000000
ldr r1, =0x1000
str r1, [r0]
ldr r0, =0x7000000
ldr r1, =0x2005c00f @ sprite x=5 y=15 size 64 * 64, 256 col pal
str r1, [r0], #4
ldrh r1, =0x0000
strh r1, [r0]
ldr r0, =pal
ldr r2, =0x80
ldr r1, =0x5000200
pal_loop:
ldr r3, [r0], #4
str r3, [r1], #4
subs r2, r2, #1
bne pal_loop:
ldr r2, =0x200
ldr r1, =0x60010000
ldr r0, =spr
spr_loop:
ldr r2, [r0], #4
str r2, [r1], #4
subs r2, r2, #1
bne spr_loop
loop:
b loop
vblank:
mov r6, #0x4000000
add r6, r6, #0x6
ldrh r7, [r6]
cmp r7, #161
bhs vblank
mov r15, r14
spr:
.include "spr.o"
pal:
.include "spr.pal"
#49968 - tepples - Thu Aug 04, 2005 1:43 am
If it is assembly language code, then it should be named with file name suffix .s not .txt.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#49969 - aRsus - Thu Aug 04, 2005 2:04 am
tepples wrote: | Quote: |
| If it is assembly language code, then it should be named with file name suffix .s not .txt. |
Now I get these errors.
-o data.elf
:\devkitarm\bin\..\lib\gcc\arm-elf\3.4.
t: file format not recognized; treating
:\devkitarm\bin\..\lib\gcc\arm-elf\3.4.
t:2: parse error
ollect2: ld returned 1 exit status
#50042 - poslundc - Thu Aug 04, 2005 7:25 pm
Okay, you've got a number of problems here.
1. You ought to break up your build steps into compiling and linking. This means having an additional line as follows:
| Code: |
arm-elf-gcc -mthumb -mthumb-interwork -c spr.c
arm-elf-gcc -mthumb -mthumb-interwork -c demo.s
arm-elf-gcc -mthumb -mthumb-interwork -specs=gba.specs demo.o spr.o -o data.elf |
Technically you could combine the first two lines but you usually don't want to mix C code and assembly code.
2. Your line .include "spr.o" is causing lots and lots of trouble. The .include statement is just like C's #include pre-processor directive. It means you are taking the contents of spr.o - which is already-assembled binary data - and attempting to paste it into the middle of your unassembled source file. The assembler doesn't know what to make of it; it's just garbage data... like mashing the keyboard with your fist in the middle of writing a C program. Bad idea.
That part should be removed. The whole reason you've compiled spr.c as a separate unit is so that you don't have to literally paste its contents into any other file that references it.
3. I don't know what format the file "spr.pal" is in, but unless it's written as assembly code you're going to have the exact same problem.
Dan.
#50077 - aRsus - Fri Aug 05, 2005 2:46 am
So do I refer to the contents of spr.o by the name of the array inside of it?
#50078 - poslundc - Fri Aug 05, 2005 2:53 am
Yes.
Dan.
#54015 - kusma - Wed Sep 14, 2005 5:08 pm
(i know this is late, but what the heck) you could also allway use the .incbin "filename"
this is how i usually include data in my sources
.global some_data
.align
some_data:
.incbin "some_data.raw"
#54017 - poslundc - Wed Sep 14, 2005 5:14 pm
| kusma wrote: |
(i know this is late, but what the heck) you could also allway use the .incbin "filename"
this is how i usually include data in my sources
.global some_data
.align
some_data:
.incbin "some_data.raw" |
If you are doing this, I hope it's in its own file as a separate compilation unit, and not something that you repeat throughout multiple source files.
Dan.