Use INCBIN statement in an assembly file.
That way you can pad it yourself.

Aelius.

>-----Original Message-----
>From: Jason Emery [mailto:felixd@...]
>Sent: Thursday, January 31, 2002 23:18
>To: gbadev@yahoogroups.com
>Subject: Re: [gbadev] How to add binary data files to projects?
>
>
>
>  Here is my problem: I would like to convert a (large) binary data file into
an object file so I can insert it into my
>project, thr problem is that I can't find a proper way to do it. Here is the
alternatives I found so far: (note that I'm
>using Visual C++ 6.0 and ARM Developer Suite 1.1)
>
>  1/ Convert the file to an array and let the compiler create the object.
>          Pros: easy to do, even you dont have a converter, you can write one
in less than 15 minutes.
>          Cons: the size of the output .c file increases exponentially compared
to the input binary file. At some point
>compiling the file can take up to 1/2 hour and eat more than 1g swap memory.
(the input data files are 8megabytes+ in size)
>
>  2/ Convert the file using bin2o by Darkfader.
>          Pros: easy to use and fast.
>          Cons: the output object file is byte array-based so it won't be
padded by the compiler, and you can have
>unaligned reads if you read more than one byte at a time. Also, the output file
cannot be used with MS's compiler.
>
>  3/ Convert the file using objcopy.
>          Pros: err, i can't find any, except that it outputs an (unusable)
object file.
>          Cons: data is moved to .data section (iwram) so i can't really use
it, plus it's unaligned as Darkfader's bin2o.
>Same remark regarding Visual Studio.
>
>  Please note that i'm using Visual with the embedded compiler, not GCC. (not
using gcc at all for compiling)
>
>  If someone have an idea on how to do that, i'll be grateful.
>
>What I plan on doing is creating raw files and importing via assembly .s files,
then assigning them global variables
>through extern statements in my C code.  This is done using the INCBIN command
as mentioned in the assembly program, then
>writing an extern to the symbol you use.
>
>An example of this assembly file is:
>
>.code 16
>.align 4
>.text
>.global VariableName
>.type VariableName,"object"
>VariableName:
>.incbin "filename.raw"
>
>And in C, you'd type:
>
>extern const char const VariableName[];
>
>Or some similar array type, depending on what you need, though I have yet to
test this thoroughly.
>
>Also, I've just written a program to convert a .c/.h file array to a .raw file
for this purpose, so I can use whatever
>data or program I want (many don't convert to .raw).  If anyone wants it, feel
free to ask.
>
>(My sprite file was 8 megs uncompiled, which was taking about a minute or two
to compile.)
>
>Jason Emery
>World Tree Games
>
>
>[Non-text portions of this message have been removed]
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Here is my problem: I would like to convert a (large) binary data file into an
object file so I can insert it into my project, thr problem is that I can't find
a proper way to do it. Here is the alternatives I found so far: (note that I'm
using Visual C++ 6.0 and ARM Developer Suite 1.1)

   1/ Convert the file to an array and let the compiler create the object.
           Pros: easy to do, even you dont have a converter, you can write one in
less than 15 minutes.
           Cons: the size of the output .c file increases exponentially compared
to the input binary file. At some point compiling the file can take up to 1/2
hour and eat more than 1g swap memory. (the input data files are 8megabytes+ in
size)

   2/ Convert the file using bin2o by Darkfader.
           Pros: easy to use and fast.
           Cons: the output object file is byte array-based so it won't be padded
by the compiler, and you can have unaligned reads if you read more than one byte
at a time. Also, the output file cannot be used with MS's compiler.

   3/ Convert the file using objcopy.
           Pros: err, i can't find any, except that it outputs an (unusable)
object file.
           Cons: data is moved to .data section (iwram) so i can't really use it,
plus it's unaligned as Darkfader's bin2o. Same remark regarding Visual Studio.

   Please note that i'm using Visual with the embedded compiler, not GCC. (not
using gcc at all for compiling)

   If someone have an idea on how to do that, i'll be grateful.

What I plan on doing is creating raw files and importing via assembly .s files,
then assigning them global variables through extern statements in my C code. 
This is done using the INCBIN command as mentioned in the assembly program, then
writing an extern to the symbol you use.

An example of this assembly file is:

.code 16
.align 4
.text
.global VariableName
.type VariableName,"object"
VariableName:
.incbin "filename.raw"

And in C, you'd type:

extern const char const VariableName[];

Or some similar array type, depending on what you need, though I have yet to
test this thoroughly.

Also, I've just written a program to convert a .c/.h file array to a .raw file
for this purpose, so I can use whatever data or program I want (many don't
convert to .raw).  If anyone wants it, feel free to ask.

(My sprite file was 8 megs uncompiled, which was taking about a minute or two to
compile.)

Jason Emery
World Tree Games


[Non-text portions of this message have been removed]

hey all,

i have heard about lua and great a programming language it is.
has anyone used it for the gba and how?

thanks

Hi,

I used the ARM SDT evaluation version when I started GBA stuff, and the way
I did things was to have a .s (assembly) file where I put ALL my data using
the lovely incbin command that the ARM SDT has.  Mad life a lot easier for
me.  No conversion of data files, nothing extra to link.

"Take 2 steps to get data into my project, no I just incbin and go."

FGL

[cropped by mod]

Has anyone managed to get GASS compiling and running and would have
the time to provide a few answers to questions?

I think I'm pretty close, as everything now links in and compiles
properly, but it promptly crashes at the instruction:

mov pc,lr

(which I presume is trying to copy the return address for the
function call to assembly into PC)

(and yes, I can 'fix' it with bx lr, but there are more complex uses
of pc later on that I can't seem to correct)

I know there'll likely be other problems, hence why I'm reluctant to
ask too many questions of the list.  Searching elsewhere doesn't seem
to reveal any tutorials on this, or even what compiler was being used
at the time.  I can only imagine what settings

But at the same time, days of constant effort are starting to be
tiring. ^.^

Jason Emery
World Tree Games

> Please note that i'm using Visual with the embedded compiler, not GCC.
(not using gcc at all for compiling)

As you're using the ARM SDT why not just INCBIN the data from an assembler
file?

.
.
.

label:
     INCBIN    file.bin

.
.
.


--Jim

Hello,

Here is my problem: I would like to convert a (large) binary data file into an
object file so I can insert it into my project, thr problem is that I can't find
a proper way to do it. Here is the alternatives I found so far: (note that I'm
using Visual C++ 6.0 and ARM Developer Suite 1.1)

1/ Convert the file to an array and let the compiler create the object.
         Pros: easy to do, even you dont have a converter, you can write one in
less than 15 minutes.
         Cons: the size of the output .c file increases exponentially compared to
the input binary file. At some point compiling the file can take up to 1/2 hour
and eat more than 1g swap memory. (the input data files are 8megabytes+ in size)

2/ Convert the file using bin2o by Darkfader.
         Pros: easy to use and fast.
         Cons: the output object file is byte array-based so it won't be padded
by the compiler, and you can have unaligned reads if you read more than one byte
at a time. Also, the output file cannot be used with MS's compiler.

3/ Convert the file using objcopy.
         Pros: err, i can't find any, except that it outputs an (unusable) object
file.
         Cons: data is moved to .data section (iwram) so i can't really use it,
plus it's unaligned as Darkfader's bin2o. Same remark regarding Visual Studio.

Please note that i'm using Visual with the embedded compiler, not GCC. (not
using gcc at all for compiling)

If someone have an idea on how to do that, i'll be grateful.

Cheers,
Alex.



[Non-text portions of this message have been removed]

Hello,

I'm trying since some time to get my DirectSound stuff working - on the
emulators I use everything works fine (BoycottAdv. & VisualBoyAdv.), but on
the
real Hardware nothing works  (I don't have a GBA/flash||mbv2 yet)

Ok.. code says more than 1000 words:

my ds-init:  (only done 1 time)
--------------------

Init_DirectSound

         mov r0,#0

         ldr r1,=0x40000C6 ;DM1CNT_H  DMA1 Control

         strh r0,[r1] ;OFF

         ldr r1,=0x40000D2 ;DM2CNT_H  DMA2 Control

         strh r0,[r1] ;OFF



;u16*)0x4000084 = 0x0080; //sound enable ( SGCNT1 )

         ldr r0,=0x008F          ;all sound enable

         ldr r1,=0x4000084 ;SGCNT1

         strh r0,[r1]

; HIGHNIBBEL

;  1    DS FIFO B Clear and Sequencer reset

;  0    DS B  Timer 0

;  0    DS B  NO OUTPUT TO L

;  1    DS B  OUTPUT TO R

;9

; LOWNIBBEL

;  1    DS FIFO A Clear and Sequencer reset

;  0    DS A  Timer 0

;  1    DS A  OUTPUT TO L

;  0    DS A  NO OUTPUT TO R

;A

         ldr r0,=0x9A0E

         ldr r1,=0x4000082       ;SGCNT0_H

         strh r0,[r1]

	 mov r0,#0

	 ldr r1,=0x4000102 ;TM0CNT  Timer0 Control

	 strh r0,[r1] ;disable timer



;DA_TIMER = 65536-(2^24/FREQ))



DA_TIMER EQU 0xFB81

	 ldr r0,=DA_TIMER

	 ldr r1,=0x4000100 ;TM0D  Timer0 Data

         strh r0,[r1]



;--- SET DMA1 & DMA2 Src/Dest addresses ---

;  DMA1

         ldr r0,=LEFT_BUFFER1

         ldr r1,=0x40000BC       ;DMA1 Address Src

         str r0,[r1]

         ldr r0,=0x040000A0      ;Sound FIFO A

         ldr r1,=0x40000C0       ;DMA1 Destination

         str r0,[r1]

;  DMA2

         ldr r0,=RIGHT_BUFFER1

         ldr r1,=0x40000C8       ;DMA2 Address Src

         str r0,[r1]

         ldr r0,=0x040000A4      ;Sound FIFO B

         ldr r1,=0x40000CC       ;DMA2 Destination

         str r0,[r1]

;----------------------



;--- SET DMA1 & DMA2 Control ---

; 1  DMA Enable

; 0  Irq request disable

; 11  start on request

; 0   -

; 1  32bit

; 1  Repeat=ON

; 00 source incr. after

; 00 dest. incr. after

      	 ldr r0,=0xB600

      	 ldr r1,=0x40000C6 ;DM1CNT_H DMA1 Control

      	 strh r0,[r1]

      	 ldr r1,=0x40000D2 ;DM2CNT_H DMA2 Control

      	 strh r0,[r1]

;-------------------------------

         mov r0,#0x80 ;timer enable,irq request disble ...

         ldr r1,=0x4000102     ;TM0CNT  Timer0 Control

         strh r0,[r1]

         mov PC,LR



;----- END OF DS-Init -------------------------------------------------



And this is my swap_sound_buffers stuff (I calculate the new data in a
work-buffer and play the previous buffer... just the standard way)
which is done every vbl.


;refering to this data-structure:

	 MAP 0x02040000

bflag   # 4             ;flag which soundbuffer is used

LEFT_W  # 4             ;current soundbuffer written to

RIGHT_W # 4             ;               "



; DIGIT BUFFERS (2 for each channel)

LEFT_BUFFER1    # 512

LEFT_BUFFER2    # 512

RIGHT_BUFFER1   # 512

RIGHT_BUFFER2   # 512









swap_sound_buffers



; *bflag indicates which LEFT/RIGHT_BUFFER is

; currently played/mixed



         ldr r12,=bflag

         ldrh r9,[r12]

         eor r10,r9,#512

         strh r10,[r12],#4

         ldr r0,=LEFT_BUFFER1

         add r0,r0,r9

         add r1,r0,#(RIGHT_BUFFER1-LEFT_BUFFER1) ;ldr r1,=RIGHT_BUFFER1



	 mov r11,#0x4000000

         str r0,[r11,#0xBC]   ;DMA1 Address Src

         str r1,[r11,#0xC8]   ;DMA2 Address Src

;------------------ previous versions ended here ---



;-- SET DMA DESTINATION ADDRESS

;  DMA1

         ldr r1,=0x040000A0      ;Sound FIFO A

         str r1,[r11,#0xC0]      ;DMA1 Destination

;  DMA2

         ldr r1,=0x040000A4      ;Sound FIFO B

         str r1,[r11,#0xCC]      ;DMA2 Destination



;--- SET DMA1 & DMA2 Control ---

; 1  DMA Enable

; 0  Irq request disable

; 11  start on request

; 0   -

; 1  32bit

; 1  DMA Repeat=ON        (has to be ON in DirectSound)

; 00 source incr. after

; 00 dest. incr. after    (DS: dest.addr. fixed, setting has no effect)

      	 ldr r1,=0xB600

      	 strh r1,[r11,#0xC6]     ;DM1CNT_H DMA1 Control

      	 strh r1,[r11,#0xD2]   ;DM2CNT_H DMA2 Control



	 sub r0,r0,r9

	 add r0,r0,r10

         add r1,r0,#(RIGHT_BUFFER1-LEFT_BUFFER1) ;ldr r1,=RIGHT_BUFFER1

         stmia r12!,{r0,r1}      ;LEFT_W , RIGHT_W

         mov pc,lr




mhh..  I also did some 'research' in some sound-docs and also some reversing
in some players by other people - but they looked quite similiar to my code.
The people that tested my stuff on a real gba (thanks Gbcft & Groepaz !!)
reported that there's a short chhchzzz (or whatever ... :) in the beginning
and
then nothing.
Something I saw in the 'Hitmen-AFM' and the 'Serge-modplayer' that they use
DMA3 for ... ?!?

I hope anyone has a answer to my problem - would be really great!


Best regards,
Defjam.




--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

an Interesting Read, but alas by static I mean static in the C way
all functions are externally linkable.
thus they may be inlined within the module but the code still has to be
there for call from other modules. and it is that code where gcc get it
wrong and ouputs invalid thumb instructions.

C++, what a fantastic language, I though Self was a bit over the top by
allowing you to change your superclass at runtime, I completely forgot about
placement.

Mike.

----- Original Message -----
From: "John Seghers" <johnse@...>
To: <gbadev@yahoogroups.com>
Sent: Tuesday, January 29, 2002 8:51 PM
Subject: [gbadev] Variations on a theme (was: GCC -O3 -mthumb strb Rn, [SP
#N] BUG ?)


> From: "Mike Wynn" <mike.wynn@...>
>
> > FYI: I tried '-02 -frename-registers -finline-functions' which, no
supprise,
> > gave the same error, but it was not -frename-registers that causes the
bug,
> > but -finline-functions !
> > but the code has NO static functions.
>
> I don't know if GCC implements this, but there are C++ optimizations
whereby
> the compiler can turn a virtual function call into a non-virtual, and
therefore
> allow it to be inlined.  MSVC 1.0 and the Borland C++ of the same vintage
> implemented this one (and it's still there).
>
> Assume A is a class derived from B,
>
> B* pB = new A;
> ... code that doesn't modify pB ...
> pB->SomeVirtualFunc();
>
> Since the compiler can "prove" that pB must hold an instance of A, it can
call
> SomeVirtualFunc() without dereferencing through the virtual function
table.
>
> There is a case where this fails, however.
>
> Imagine an array of data read in from some media.  It has a structure:
> struct Foo
> {
> int type;
> ...some set of data...
> };
>
> If you create a base class:
> class B
> {
>     void AStrangeFunc(int type);
>     virtual void SomeVirtualFunc();
>     ...all of Foo's data except the type...
> };
>
> And a bunch of derived classes, one for each type of object that can be
represented
> by the data: C, D, E, F, etc...
>
> void B::AStrangeFunc(int type)
> {
>     switch (type)
>     {
>     case 1:    new(this) C; break;
>     case 2:    new(this) D; break;
>     case 3:    new(this) E; break;
>     case 4:    new(this) F; break;
>     }
> }
>
> and run the code
> Foo* pFoo = ItemToMunge;
> int type = pFoo->type;
> B* pB = new(pFoo) B;
> pB->AStrangeFunc(type);
> ... code that doesn't modify pB ...
> pB->SomeVirtualFunc();
>
> Then the type of the object changes during the execution of AStrangeFunc()
and the
> non-virtual call to B::SomeVirtualFunc() is incorrect.
>
> This allows one to "construct" an object that may have complex
initializers directly in-place.
> One can even extend this to properly aligned, variable length structures,
where each of the
> interpreting classes (C,D,E,F...) understands how to find the end of its
structure and then
> having a Next virtual function that returns the address of the next entry.
>
> You mention you don't have any STATIC functions...  I first interpreted
that as Non-virtual,
> which is why I wrote the above...  Inlining (even opportunistic inlining
such as may have been
> performed in your case) is not limited to static functions.  Normal member
functions (and virtual
> ones the compiler believes can't be called virtually (from
constructor/destructor or as above)
> are fair game for inlining.
>
> - John
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

> Your declaration of menu_options is of an array pointers to const chars.
   Note that the pointers
   > themselves are not const.  That would be const char const *
   menu_options[]....
   >

   unless gcc changes the const keyword
   const char const * menu_options[].... is const char * menu_options[]
   you need
   const char  * const menu_options[]
   to make the pointers const .
   if you've been using const char const * menu_options[] you have not been
   declaring constant pointers.

Now, I've already gone over and converted all variable declarations of pointer
types to something else (u32 integers or encoded single strings), but I'm still
interested in why, of course, the newest gbadevkit would do this (using the
patch, btw).  It seems to be quite a lot more picky (though admittedly using
less assumptions forces the code to be more correct) than previous GCC compilers
I've used.  Ah well, must be the options it was compiled under.

For everyone's edification, as I noticed several different answers, I'm posting
the answer here as I try the different methods:


--------With declaration:

const char const* menu_options[] = {

   {"New Game"},
   {"Load Game"},
   {"Extras"},
   {""}


   *(u32*)(VRAM)=&menu_options[a+(menunum<<2)];  while(1) {}

...evaluates to 0x8000004

   *(u32*)(VRAM)=menu_options[a+(menunum<<2)];  while(1) {}

...evaluates to 0x0000000


--------With declaration:

const char* menu_options[] = {

   {"New Game"},
   {"Load Game"},
   {"Extras"},
   {""}


   *(u32*)(VRAM)=&menu_options[a+(menunum<<2)];  while(1) {}

...evaluates to 0x8000004


--------With declaration:

const char* const menu_options[] = {

   {"New Game"},
   {"Load Game"},
   {"Extras"},
   {""}

   *(u32*)(VRAM)=&menu_options[a+(menunum<<2)];  while(1) {}

...evaluates to 0x8256024   (this is the pointer to the string pointer, when one
browses to the destination address)

   *(u32*)(VRAM)=menu_options[a+(menunum<<2)];  while(1) {}

...evaluates to 0x8256000   (this references the string 'New Game' directly)



And there we have it.  The new compiler won't make as many assumptions as
before, and requires 'const char* const'.  Pity, actually, as I believe I tried
this configuration before, but probably left the '&' in without realizing it. 
Of course, I wouldn't have figured this out too easily without everyone else's
encouraging emails!  Thanks.


Jason Emery
World Tree Games


[Non-text portions of this message have been removed]

Well, depending on the complexity of your graphics, you can feasibly put
anything that can be collided (is that right?.. :) with in one layer, and
place everything else in the other layers.

Another possibility is to use sprites -- you do have 128 of them, which is
more than enough to cover the screen with all the platforms you'll need.
Then, you can just check for collisions between the sprites (which may or
may not be simple).

In the game I'm working on, it's pretty simple -- if the tile number is not
0, then it's something I need to check for collision.  The background is in
another layer, and therefore, doesn't interfere with my collision detection.

Of course, the game I'm working on is a really simple platform type game --
no fancy tricks. ;)

dennis

From: "Mike Wynn" <mike.wynn@...>

> FYI: I tried '-02 -frename-registers -finline-functions' which, no supprise,
> gave the same error, but it was not -frename-registers that causes the bug,
> but -finline-functions !
> but the code has NO static functions.

I don't know if GCC implements this, but there are C++ optimizations whereby
the compiler can turn a virtual function call into a non-virtual, and therefore
allow it to be inlined.  MSVC 1.0 and the Borland C++ of the same vintage
implemented this one (and it's still there).

Assume A is a class derived from B,

B* pB = new A;
... code that doesn't modify pB ...
pB->SomeVirtualFunc();

Since the compiler can "prove" that pB must hold an instance of A, it can call
SomeVirtualFunc() without dereferencing through the virtual function table.

There is a case where this fails, however.

Imagine an array of data read in from some media.  It has a structure:
struct Foo
{
int type;
...some set of data...
};

If you create a base class:
class B
{
     void AStrangeFunc(int type);
     virtual void SomeVirtualFunc();
     ...all of Foo's data except the type...
};

And a bunch of derived classes, one for each type of object that can be
represented
by the data: C, D, E, F, etc...

void B::AStrangeFunc(int type)
{
     switch (type)
     {
     case 1:    new(this) C; break;
     case 2:    new(this) D; break;
     case 3:    new(this) E; break;
     case 4:    new(this) F; break;
     }
}

and run the code
Foo* pFoo = ItemToMunge;
int type = pFoo->type;
B* pB = new(pFoo) B;
pB->AStrangeFunc(type);
... code that doesn't modify pB ...
pB->SomeVirtualFunc();

Then the type of the object changes during the execution of AStrangeFunc() and
the
non-virtual call to B::SomeVirtualFunc() is incorrect.

This allows one to "construct" an object that may have complex initializers
directly in-place.
One can even extend this to properly aligned, variable length structures, where
each of the
interpreting classes (C,D,E,F...) understands how to find the end of its
structure and then
having a Next virtual function that returns the address of the next entry.

You mention you don't have any STATIC functions...  I first interpreted that as
Non-virtual,
which is why I wrote the above...  Inlining (even opportunistic inlining such as
may have been
performed in your case) is not limited to static functions.  Normal member
functions (and virtual
ones the compiler believes can't be called virtually (from
constructor/destructor or as above)
are fair game for inlining.

- John

RC5Stint wrote:

> The new GCC is a fully compliant C++ compiler.  String is a standard
> class.  You are naming the char * parameter to DrawString by the very
> same name, right down to the uppercase S.  If ever you port this to
> C++ and libstdc++, you'll go crazy trying to diagnose this apparent
> non-error. :-)


The string class defined by the C++ standard library is:

     string  (actually, it's std::string)

It does not use an upper-case 's'.  In fact, I can't think of any C++
standard types or keywords that use upper-case letters for anything.
So there is no problem there.

In fact, with 3.0's compliance to the C++ standard (include the std::
namespace), you are able to define your own "string" types or
variables without fear of name collisions.

That is, of course, unless you use a "using namespace std" directive
in your code to force all "std::" symbols into the global namespace.

With gcc version 2.95.x (and earlier), by default, symbols in the
"std::" namespace were also in the global namespace, in essence making
the namespace prefix "optional" for standard C++ types.  As mentioned,
this is no longer the case with gcc 3.0.x.

--
Tony Wetmore
mailto:wetmore@...

Personnally I would use a simple dirty way :
put your variable as a global one.

Because there is not so many things that need to be static AND in RAM and
local...

Just add a good comment to the declaration explaining why its global...
finished.

Anyway a compiler will problably always tranform a local static into a
global var if it is not ROMIZED...
(somebody correct me if I am wrong... its just an intuition...)

R.

----- Original Message -----
From: "TIMMY!" <tweisser@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, January 31, 2002 8:39 AM
Subject: [gbadev] compile option for statics


>
> Is there some kind of compile or precompile option that can be changed
with
> gcc (version 2.9-arm-000512) so that it doesn't put non-const statics in
the
> ROM area? Can't seem to find the option or any info about this.
>
> This is a real pain to have to setup init functions or the like to not
have
> this happen.
>
> ex.
>
> static u32 nCount = 0;
> nCount++;
>
> (nCount still equals 0, not 1)
> --
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> Timothy L. Weisser              Tel: 720.564.1051 (Direct Dial)
> Programmer                      Fax: 720.564.1090
> VR1 Entertainment               email: tweisser@...
>
>
> "You'll be able to tell it sucks from the get-go, and
>  won't want to play more than 20 minutes of it.
>  Hmmm... even that's a stretch. [...] I fail to
>  understand how this disaster even came to market."
>   -Azurik review, Nightcaster competition, GameNow, 11/2002
>
> "WOW. I love the spells, each spell has wonderful eye candy
>  and fit well into the atmosphere the game projects. Polys are
>  pretty high on everything and the bump mapping is nice. I havent
>  seen a framerate drop yet and I have had up to 15 or so
>  creatures onscreen during battle. AGAIN I love the spells. [...]
>  The still shots just don't do the spell graphics any justice at
>  all - during game play they're pretty cool. "
>   -teamxbox.com, Nightcaster forum
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

I think that you have an old linker script. Try downloading the
latest linker and ctr0 scripts. (This problem has been reported
before..)

O

--- In gbadev@y..., "Fausto" <faustus@l...> wrote:
> A way to avoid this is to write your own linker script...
>
> Ciao ciao,
> Fausto
> ----- Original Message -----
> From: "TIMMY!" <tweisser@v...>
> To: <gbadev@y...>
> Sent: Thursday, January 31, 2002 12:39 AM
> Subject: [gbadev] compile option for statics
>
>
> >
> > Is there some kind of compile or precompile option that can be
changed
> with
> > gcc (version 2.9-arm-000512) so that it doesn't put non-const
statics in
> the
> > ROM area? Can't seem to find the option or any info about this.
>
>
> [cropped by mod]

just try the arj-mode4 conversion I did for the gba, little and handy
http://defjam.atari.org/gba/arjm4/index.htm

regards,
defjam.

--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

>
> Your declaration of menu_options is of an array pointers to const chars.
Note that the pointers
> themselves are not const.  That would be const char const *
menu_options[]....
>

unless gcc changes the const keyword
const char const * menu_options[].... is const char * menu_options[]
you need
const char  * const menu_options[]
to make the pointers const .
if you've been using const char const * menu_options[] you have not been
declaring constant pointers.

Mike.

A way to avoid this is to write your own linker script...

Ciao ciao,
Fausto
----- Original Message -----
From: "TIMMY!" <tweisser@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, January 31, 2002 12:39 AM
Subject: [gbadev] compile option for statics


>
> Is there some kind of compile or precompile option that can be changed
with
> gcc (version 2.9-arm-000512) so that it doesn't put non-const statics in
the
> ROM area? Can't seem to find the option or any info about this.


[cropped by mod]

From: "Jason Emery" <felixd@...>
> Anyway, the one problem I can't seem to figure out yet is what changed
regarding the string variables (char*)?
>
> (variable data)
> const char* menu_options[] = {
>   "New Game",
<snip>
> (code)
> DrawString((u8*)&menu_options[a+(menunum<<2)],17,12+(a<<1));

Your declaration of menu_options is of an array pointers to const chars.  Note
that the pointers
themselves are not const.  That would be const char const * menu_options[]....

I'm assuming from the code that menunum is an index into menus, each of which
are four items
long, a ranges from 0 to 3 for displaying a single menu.

So, menu_options[expr] evaluates to a const char*.
The & operator on the front of that turns it into a const char* * and is the
address that holds
the pointer to the string.

Rather than trying to cast it to a u8*, I'd suggest making the declaration of
the strings const unsigned char *.
If you're trying to force the pointer array into ROM, you may need to use const
unsigned char const *

> (declaration)
> void DrawString(const unsigned char* String,u8 x,u8 y);

- John

From: "maurky" <maurky@...>
> There is a problem, I think (correct me if is wrong, please) the
> internal memory is used for the stack.

I believe you are correct that the internal memory hosts the stack.
For most games you either don't do much recursion or can code to
avoid deep recursion, so you don't need 32K of stack.  Heck, on the
Atari 2600, they had 128 bytes of ram, period.

> Writing in any location of this memory can generate many runtime
> errors in variables and/or dead locks in jumps.

I don't know what the bios routines use of this memory, perhaps someone
can enlighten us.

> 1) allocate memory from end (0x3007FFF) backward.
> example:
>
> unsigned int internal_malloc_ptr = 0x3007FFF;
> #define internal_malloc(size) internal_malloc_ptr-=size
>

In order to be compatible with Thumb mode, the stack must be a "Full Decending"
stack (growing down and with the stack pointer pointing at the last item
written--
writes use Decrement Before, reads use Increment After).  Therefore, you don't
want to allocate memory from the end as this will immediately clobber the stack.

>    But is possible for the stack pointer reach allocated space.

This is true.  You can make some runtime checks for this by writing a set of
guard
bytes with a known pattern (fdfdfdfd, for example) and occasionally check that
this pattern is still there.  If it isn't, then you know that either the stack
grew too large
or you have a wild pointer.

> 2) declare local or global array for temp storage.
>    Is good, but arrays must be fixed size and I don't know how much
> can be preallocated.

It is perfectly reasonable to simply predefine what is going to be in this ram.
There is nothing magical about allocating memory.  The memory is there whether
it's
been "allocated" or not.  You can simply define that certain addresses are used
for
certain things and other chunks of memory are buffers, etc.

Other than keeping out of the way of memory the bios might use--if you're making
any bios calls--is the only thing you have to keep in mind.

One easy way of defining your memory layout is to do it in assembly.  Then for
those
you're using in C, define the symbols to be exported in the asm, and use
extern "C" in your C headers.  The linker will resolve the references.

         .export SomeBuffer
SomeBuffer:    .foobar (512 bytes reserved)

(I'm spacing on the syntax for defining a buffer here and right now
I'm writing this on my laptop whilst sitting in the dark because of a power
failure, so I
don't have access to my GAS documentation :)
You can also use equates, as in

SomeOtherBuffer .equ 0x03000010

but using the allocation keywords lets the compiler adjust the addresses for
you.

In the C/C++ file:

extern "C" u16 SomeBuffer[256];  // a 512 byte buffer, used for 16 bit unsigned
in C/C++.

- John

On Wednesday, January 30, 2002 5:30 PM, Jason Emery wrote:
>
> Anyway, the one problem I can't seem to figure out yet is what
> changed regarding the string variables (char*)?
>
> Setting up arrays of strings like this no longer appears to work
> properly in devkitadv (I'm using the latest version).  Has anyone
> encountered this?

> (variable data)
> const char* menu_options[] = {
>   "New Game",
>   "Load Game",
>   "Extras",
>   "",
>
> (code)
> DrawString((u8*)&menu_options[a+(menunum<<2)],17,12+(a<<1));

The expression menu_options[a+(menunum<<2)] already evaluates to a
pointer to char.  Remove the ampersand, and it should work.

> (declaration)
> void DrawString(const unsigned char* String,u8 x,u8 y);

The new GCC is a fully compliant C++ compiler.  String is a standard
class.  You are naming the char * parameter to DrawString by the very
same name, right down to the uppercase S.  If ever you port this to
C++ and libstdc++, you'll go crazy trying to diagnose this apparent
non-error. :-)

- --
RC5Stint <rc5stint@...>
PGP Key ID: 0x3B4BEC6F

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (MingW32) - WinPT 0.5.1
Comment: For info see http://www.gnupg.org

iD8DBQE8WL1sifMcQztL7G8RAvTbAJ9frdPwvpM/JHGYbzVt4oJSHmLKKwCcD+n3
N+sr82eJ5dUqlbVpW5mk+24=
=VDb3
-----END PGP SIGNATURE-----

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Is there some kind of compile or precompile option that can be changed with
gcc (version 2.9-arm-000512) so that it doesn't put non-const statics in the
ROM area? Can't seem to find the option or any info about this.

This is a real pain to have to setup init functions or the like to not have
this happen.

ex.

	 static u32 nCount = 0;
	 nCount++;

	 (nCount still equals 0, not 1)
--
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Timothy L. Weisser              Tel: 720.564.1051 (Direct Dial)
Programmer                      Fax: 720.564.1090
VR1 Entertainment               email: tweisser@...


"You'll be able to tell it sucks from the get-go, and
  won't want to play more than 20 minutes of it.
  Hmmm... even that's a stretch. [...] I fail to
  understand how this disaster even came to market."
   -Azurik review, Nightcaster competition, GameNow, 11/2002

"WOW. I love the spells, each spell has wonderful eye candy
  and fit well into the atmosphere the game projects. Polys are
  pretty high on everything and the bump mapping is nice. I havent
  seen a framerate drop yet and I have had up to 15 or so
  creatures onscreen during battle. AGAIN I love the spells. [...]
  The still shots just don't do the spell graphics any justice at
  all - during game play they're pretty cool. "
   -teamxbox.com, Nightcaster forum

----- Original Message -----
From: "Jason Emery" <felixd@...>
To: <gbadev@yahoogroups.com>
Sent: Wednesday, January 30, 2002 9:29 PM
Subject: [gbadev] Strings in newer GCC (devkitadv)


>
> I've recently updated my GCC compiler to the devkit, so I'm going in and
changing all sorts of things to const and the way variables are addressed
(must have had a really old compiler).
>
> Anyway, the one problem I can't seem to figure out yet is what changed
regarding the string variables (char*)?
>
> (variable data)
> const char* menu_options[] = {
>   "New Game",
>   "Load Game",
>   "Extras",
>   "",
>
>
> (code)
> DrawString((u8*)&menu_options[a+(menunum<<2)],17,12+(a<<1));

shouldn't this be
> DrawString( menu_options[a+(menunum<<2)],17,12+(a<<1));
pass the (a+menunum<<2) char * from the array
> const char* menu_options[] = { ... }
is a array of variable pointers to const char. thus is an array of the
addresses of the const strings.
did you also mean
     const char* const menu_options[] = { ... }
is a array of const pointers to const char.

> (declaration)
> void DrawString(const unsigned char* String,u8 x,u8 y);
>
> Setting up arrays of strings like this no longer appears to work properly
in devkitadv (I'm using the latest version).  Has anyone encountered this?
>
> An obvious kludge would be...
>
> char menu_options[] = "New Game|Load Game|Extras||text|text|text"
>
> Or something to that effect, with an array, or just fixed string lengths.
But I prefer arrays of variable-length strings, and I have quite a lot of
them already in the codebase.
>
> I'm sure it's just a simple formatting error/change.
>
> Jason Emery
> World Tree Games

> It may be better to stick with overloading the tile set, rather than
> introduce a new poly-line representation of the collision. The background

Both collision methods have their merrits. Personally I would go for the
collision tileset method for a platformer, but would implement the control
point based collision for cases where spline segments would be more
appropriate. Such as preset enemy paths for one....

> data space efficiently)? An example would be: "I'm standing on a small
> platform and I jump off" - How do you quickly find where you are on other
> control point lines?

Quad tree containing line / spline segments springs to mind. Quick and easy.

--Jim

I was also in the need of a memory allocator when someone
here posted a request.
So I have written one 2 days ago and I have tested it in
my own projects. It seems to work, so I have updated
my website and you can download it from there.

Cheers,

Codac/Apex
http://hferradj.nerim.net



______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif

It may be better to stick with overloading the tile set, rather than
introduce a new poly-line representation of the collision. The background
will dynamic and this surely dictates that the collision rep. will also be
dynamic. Therefore if you do collision based off of tiles, then when you
update one the other will be updated implicitly.

How would you actually implement the "control point" method? I'd be curious
to know how you find where you are on the line (in terms of searching the
data space efficiently)? An example would be: "I'm standing on a small
platform and I jump off" - How do you quickly find where you are on other
control point lines?



-----Original Message-----
From: Christian Votava [mailto:cvotava@...]
Sent: Wednesday, January 30, 2002 9:04 AM
To: gbadev@yahoogroups.com
Subject: RE: [gbadev] Collision detection for a platform game


Another way is used in PSX plateform game, and easy to use on GBA I think...
I never tryed this way, but it could be nice:
You can use control points. Each control point are linked with line. The
ground is the line.


-----Message d'origine-----
De : Mike Wynn [mailto:mike.wynn@...]
Envoyé : mercredi 30 janvier 2002 13:10
À : gbadev@yahoogroups.com
Objet : Re: [gbadev] Collision detection for a platform game


you can use the tiles the sprite overlaps,
i.e. if (tile & 0x80 == 0) makes the first 32 sprites in every 128 (16
colour) solid
this allows a 2d layout of you bitmap or use a tile range.
or you can look at the palette, i.e palette 0 is solid, all others are
hollow.
failing that create a table in memory that gives the available platfrom
heights for any give on screen x location. if you only need per tile
granularity and 2 layers
that's just 62 bytes (two sets of 31 as there can be 31 tiles on screen if
you have scrolled). (well its easier to use 64 entrys that are cached from
whatever you use to generate you background map, as a cyclic buffer)

Mike.
[cropped by mod]

I've recently updated my GCC compiler to the devkit, so I'm going in and
changing all sorts of things to const and the way variables are addressed (must
have had a really old compiler).

Anyway, the one problem I can't seem to figure out yet is what changed regarding
the string variables (char*)?

(variable data)
const char* menu_options[] = {
   "New Game",
   "Load Game",
   "Extras",
   "",


(code)
DrawString((u8*)&menu_options[a+(menunum<<2)],17,12+(a<<1));

(declaration)
void DrawString(const unsigned char* String,u8 x,u8 y);

Setting up arrays of strings like this no longer appears to work properly in
devkitadv (I'm using the latest version).  Has anyone encountered this?

An obvious kludge would be...

char menu_options[] = "New Game|Load Game|Extras||text|text|text"

Or something to that effect, with an array, or just fixed string lengths.  But I
prefer arrays of variable-length strings, and I have quite a lot of them already
in the codebase.

I'm sure it's just a simple formatting error/change.

Jason Emery
World Tree Games


[Non-text portions of this message have been removed]

Make sure that the implementation file (.c file) is compiled separately with
the -c option and the output file is given the .text.iwram.o extention. Then
just link it with gcc and everything should be okay.

>From: "Ben Hopkins" Reply-To: gbadev@yahoogroups.com To: Subject: Re:
>[gbadev] Procedures in IRAM getting balnked with 0 Date: Wed, 30 Jan 2002
>13:56:16 -0000
>
>Sorry, because I know that this topic has been discussed but I can't find
>it on the archive...
>
>Basically I'm defining a procedure of mine as being in IRAM just before it
>in the C, but the ctr0 does not copy it (into the correct location, it just
>leaves 0's in the iram). Obviously it is not being put in the correct
>section...
>
>Please help, Owain
>
>-----------------------------------------------------------------------
>
>This is how I'm doing it and it appears to be workin fine:
>
>void Line( int iX1, int iY1, int iX2, int iY2, unsigned short usColour) {
>-sum line rendering type code here- }
>
>The above is in a seperate file which I compile to "line.text.iwram.o" the
>".text.iwram.o" is the important part as this tells the linker to put the
>function into internal work ram. Then in my header file I have this:
>
>#define IN_IWRAM __attribute__ ((section (".iwram"), long_call))
>
>void Line( int iX1, int iY1, int iX2, int iY2, unsigned short usColour)
>IN_IWRAM; void Cls(void) IN_IWRAM;
>
>Then I just call the function... Its working for me as far as I can tell.
>
>-= T:H:E:O:R:Y =-
>
>
>
>
>[Non-text portions of this message have been removed]
>
>

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Another way is used in PSX plateform game, and easy to use on GBA I think...
I never tryed this way, but it could be nice:
You can use control points. Each control point are linked with line. The
ground is the line.


-----Message d'origine-----
De : Mike Wynn [mailto:mike.wynn@...]
Envoyé : mercredi 30 janvier 2002 13:10
À : gbadev@yahoogroups.com
Objet : Re: [gbadev] Collision detection for a platform game


you can use the tiles the sprite overlaps,
i.e. if (tile & 0x80 == 0) makes the first 32 sprites in every 128 (16
colour) solid
this allows a 2d layout of you bitmap or use a tile range.
or you can look at the palette, i.e palette 0 is solid, all others are
hollow.
failing that create a table in memory that gives the available platfrom
heights for any give on screen x location. if you only need per tile
granularity and 2 layers
that's just 62 bytes (two sets of 31 as there can be 31 tiles on screen if
you have scrolled). (well its easier to use 64 entrys that are cached from
whatever you use to generate you background map, as a cyclic buffer)

Mike.

----- Original Message -----
From: "rbeverlo" <rbeverlo@...>
To: <gbadev@yahoogroups.com>
Sent: Wednesday, January 30, 2002 11:21 AM
Subject: [gbadev] Collision detection for a platform game


> I'm making a platform game just like mario with scrolling. The
> problem i have is collision detection. I use c++. Is there some
> example code or a tutorial, because everything i try it won't work.
> So if the character is falling after a jump he must land on platform,
> but there are more than 1 platforms. Any suggestion's?




Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

As long as your character's sprite will not move at a rate greater than 8
pixels per frame, you can just do what Ben said and see what tile your
sprite is over at any given time. If it's over a foreground tile, assign the
top y-coordinate of that tile to your sprite (plus or minus whatever offset
the sprite needs.)  If the speed could potentially become greater than
8pix/frame, you could do something like have an extra variable that contains
the last tile your sprite was over. Then just have a simple loop to look for
any foreground tiles in between the last one and the current one. (make sure
to take direction into consideration). I must confess that I have yet to
implement c/d in my game, but I have a feeling that should work decently.
;-).

----- Original Message -----
From: Ben Hopkins <gbtheory@...>
To: <gbadev@yahoogroups.com>
Sent: Wednesday, January 30, 2002 5:40 AM
Subject: Re: [gbadev] Collision detection for a platform game


> >I'm making a platform game just like mario with scrolling. The
> >problem i have is collision detection. I use c++. Is there some
> >example code or a tutorial, because everything i try it won't >work.
> >So if the character is falling after a jump he must land on >platform,
> >but there are more than 1 platforms. Any suggestion's?
>
> at the absolute simplest level you could find out what tiles your sprite
is over and then act accordingly eg.
>
> if( tile == sky)
>     no collision;
> else if( tile == backgroundtile)
>     no collision
> else if( title == brick)
>     collision
>
> you could then take this further by doing pixel level collision,
triangular collision (see the post from a few days ago) or some other
collision detection on the position in the tiles your sprite is over.
> There are HUNDREDS of dox on the net covering HUNDREDS of different
aspects of collision detection - shouldn't be toooo hard to find something.
> Just remember that collision detection is in general a pretty
hardware-independent topic - ie the theory is applicable regardless of the
system so take a look at:
> http://www.programmersheaven.com/
> http://www.flipcode.com/
> http://www.cfxweb.net/
> http://www-cs-students.stanford.edu/~amitp/gameprog.html#Tiles
>
> hope thats some sorta help :o)