Helo.

Its gone a while that the cartlib.c was modificated. Since we had published a
small how-to Tutorial about using the catlib.c on www.devgba.de we have futurer
problems with people that uses F2A flash modules and cannot test it.

Thats why we ask around on (r. ziegler, dady, jeff, ex. visolys) - can someone
send infomations about using the flash features of the f2a carts?
dady, maybe can u resend me that visoly extreme mod. from a year ago?

we glad about any help or infos, thx.

dummy NewBee

   ----- Original Message -----
   From: Pablo Bleyer Kocik
   To: gbadev@yahoogroups.com
   Sent: Wednesday, August 20, 2003 3:54 AM
   Subject: Re: [gbadev] gcc 3.2.3



     gcc-3.3. Here.

     Builds and works perfectly ;^)

     Which problems did you have?

     Regards.

   At 10:38 2003-08-19 -0600, you wrote:

   >Is anyone else having problems building gcc 3.2.3 under mingw (for arm)?
   >
   >I tried with ming 2.0.0 -3 and the latest 3.x rc4  and msys 1.9 I think it
   >is...binutils 2.14 wouldnt build under 2.0.0 -3 but does under the new one,
   >gcc appeared to not build under the new mingw...
   >
   >binutils 2.14 and gcc 3.2.3 and newlib 1.11.0 DOES build on the latest
   >Slackware...
   >
   >David

   --
   PabloBleyerKocik /"...I didn't want to be kissing Kevin Spacey.
     pbleyer        / Come on! Lying there naked with rose petals?"
      @embedded.cl /- Kirsten Dunst on turning down American Beauty



         Yahoo! Groups Sponsor
               ADVERTISEMENT




   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

gcc-3.3. Here.

   Builds and works perfectly ;^)

   Which problems did you have?

   Regards.

At 10:38 2003-08-19 -0600, you wrote:

>Is anyone else having problems building gcc 3.2.3 under mingw (for arm)?
>
>I tried with ming 2.0.0 -3 and the latest 3.x rc4  and msys 1.9 I think it
>is...binutils 2.14 wouldnt build under 2.0.0 -3 but does under the new one,
>gcc appeared to not build under the new mingw...
>
>binutils 2.14 and gcc 3.2.3 and newlib 1.11.0 DOES build on the latest
>Slackware...
>
>David

--
PabloBleyerKocik /"...I didn't want to be kissing Kevin Spacey.
   pbleyer        / Come on! Lying there naked with rose petals?"
    @embedded.cl /- Kirsten Dunst on turning down American Beauty

Is anyone else having problems building gcc 3.2.3 under mingw (for arm)?

I tried with ming 2.0.0 -3 and the latest 3.x rc4  and msys 1.9 I think it
is...binutils 2.14 wouldnt build under 2.0.0 -3 but does under the new one,
gcc appeared to not build under the new mingw...

binutils 2.14 and gcc 3.2.3 and newlib 1.11.0 DOES build on the latest
Slackware...

David

wow :)
i guess that if you have a good enough compiler, that kind of approach
will always work well...

though it's totally OT, did working in lisp help the development? and
why lisp? sorry- i'm just curious :)


alex:)


Eddie Edwards wrote:
> That's true (I worked on J&D) but the LISP dialect, GOAL, was actually
> compiled into R5900 native code, rather than being a scripting language.
> Even the graphics engine was written in LISP!!!
>
> Eddie
>
> -----Original Message-----
> From: lx [mailto:nal@...]
> Sent: 16 August 2003 21:00
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Re: Scripting on the GBA
>
>
> apparently jak&daxter (on the ps2) was mostly written in lisp
>
> ...well, i thought that was cool, anyway :)
>
>
>
> Julian Squires wrote:
>
>>Hi.  My two cents.
>>
>>On Tue, Aug 12, 2003 at 04:55:19AM -0000, Damian Yerrick wrote:
>>
>>
>>>What is the fundamental difference between scripts and C anyway?
>>
>>
>>In theory, not too much.  In practice, overhead -- scripts are generally
>>interpreted, usually at a bytecode level; scripting languages usually
>>have all the storage issues hidden from view, usually with automatic
>>variable creation (on a stack) and a garbage-collected memory allocator;
>>scripting languages almost always have a larger runtime support system
>>than C, especially if they support lisp-ish eval and similar.
>>
>>IMO, the real issue is that if you really want to push the boundries on
>>the GBA, you can't always afford those overhead issues.  A game like
>>Maniac Mansion is the perfect example of the style of game where
>>scripting is great... you're unlikely to be doing all that much in
>>realtime except some decompression, there's lots of special case game
>>logic for different areas, and the game's entities don't have much to do
>>in terms of AI.
>>
>>Also, scripting languages are often used with the consideration that the
>>designers can write in them, and test with them, more easily than they
>>could in C.  Of course, this only applies with a certain set of games.
>>
>>There will always be people who frown on any language that isn't C,
>>especially languages with the overhead of the typical scripting
>>language;  but on the GBA, for many games, they're right.
>>
>>(What I don't get is why no one considers any of the nice modern
>>languages for their game logic code, like modula3, or even ocaml or
>>sather)
>>
>>Cheers.
>>
>
>
>
>
> ________________________________________________________________________
> This email has been scanned for all viruses by the MessageLabs Email
> Security System. For more information on a proactive email security
> service working around the clock, around the globe, visit
> http://www.messagelabs.com
> ________________________________________________________________________
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>



________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

Hi all,

The Apex Audio System (AAS) is an extremely efficient audio mixer and
Protracker MOD player for the GBA. Its main features are a low memory
footprint and record breaking performance. It is designed to allow
developers to easily make full use of the GBA's sound hardware with
little overhead.

It supports up to 8 channels and takes an average of just 2.8% CPU to
play a 4 channel MOD at 16 KHz. It's free for non-commercial use and can
be downloaded here:

http://www.apex-designs.net/tools_aas.html

Feedback welcome!
--
Cheers,
James.

     /\  apex                                 James Daniels
    //\\  designs            james.daniels@...
   //__\\                       http://www.apex-designs.net

That's true (I worked on J&D) but the LISP dialect, GOAL, was actually
compiled into R5900 native code, rather than being a scripting language.
Even the graphics engine was written in LISP!!!

Eddie

-----Original Message-----
From: lx [mailto:nal@...]
Sent: 16 August 2003 21:00
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Re: Scripting on the GBA


apparently jak&daxter (on the ps2) was mostly written in lisp

...well, i thought that was cool, anyway :)



Julian Squires wrote:
> Hi.  My two cents.
>
> On Tue, Aug 12, 2003 at 04:55:19AM -0000, Damian Yerrick wrote:
>
>>What is the fundamental difference between scripts and C anyway?
>
>
> In theory, not too much.  In practice, overhead -- scripts are generally
> interpreted, usually at a bytecode level; scripting languages usually
> have all the storage issues hidden from view, usually with automatic
> variable creation (on a stack) and a garbage-collected memory allocator;
> scripting languages almost always have a larger runtime support system
> than C, especially if they support lisp-ish eval and similar.
>
> IMO, the real issue is that if you really want to push the boundries on
> the GBA, you can't always afford those overhead issues.  A game like
> Maniac Mansion is the perfect example of the style of game where
> scripting is great... you're unlikely to be doing all that much in
> realtime except some decompression, there's lots of special case game
> logic for different areas, and the game's entities don't have much to do
> in terms of AI.
>
> Also, scripting languages are often used with the consideration that the
> designers can write in them, and test with them, more easily than they
> could in C.  Of course, this only applies with a certain set of games.
>
> There will always be people who frown on any language that isn't C,
> especially languages with the overhead of the typical scripting
> language;  but on the GBA, for many games, they're right.
>
> (What I don't get is why no one considers any of the nice modern
> languages for their game logic code, like modula3, or even ocaml or
> sather)
>
> Cheers.
>



________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________





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

Hey, nice demo. The link in your message doesn't work, so I just went
through the files on scene.org and found it at
http://www.scene.org/file_dl.php?
url=ftp://ftp.scene.org/pub/parties/2003/assembly03/mobile_demo/counting_clouds_\
by_brainwave_team.zip&id=193021 (for anybody else that
wants to see it). Great background music, do you have a
MOD/XM/whatever of it I could download?
Thanks,
~Dennis

--- In gbadev@yahoogroups.com, "Aleksey N. Malov" <vivid@b...> wrote:
> Hello gbadev,
>
>   We released our first GBA demo at Assembly'2003.
> It took the last (9th) place but this is pretty nice demo.
> Just download and enjoy.
>
> http://www.scene.org/file.php?file=%2Fparties%2F2003%2Fassembly03%
2Fmobile_demo%2Fcounting_clouds_by_brainwave_team.zip&fileinfo
>
> np: Fat Boy Slim - Soul surfing
> -- [ZX][GBA][Scene][Anime][Ot.A.Ma.][B.A.K.A. S.T.][Powered by
Jenechka]
> Best regards,
>  Vivid / Brainwave Team                    mailto:vivid@b...

apparently jak&daxter (on the ps2) was mostly written in lisp

...well, i thought that was cool, anyway :)



Julian Squires wrote:
> Hi.  My two cents.
>
> On Tue, Aug 12, 2003 at 04:55:19AM -0000, Damian Yerrick wrote:
>
>>What is the fundamental difference between scripts and C anyway?
>
>
> In theory, not too much.  In practice, overhead -- scripts are generally
> interpreted, usually at a bytecode level; scripting languages usually
> have all the storage issues hidden from view, usually with automatic
> variable creation (on a stack) and a garbage-collected memory allocator;
> scripting languages almost always have a larger runtime support system
> than C, especially if they support lisp-ish eval and similar.
>
> IMO, the real issue is that if you really want to push the boundries on
> the GBA, you can't always afford those overhead issues.  A game like
> Maniac Mansion is the perfect example of the style of game where
> scripting is great... you're unlikely to be doing all that much in
> realtime except some decompression, there's lots of special case game
> logic for different areas, and the game's entities don't have much to do
> in terms of AI.
>
> Also, scripting languages are often used with the consideration that the
> designers can write in them, and test with them, more easily than they
> could in C.  Of course, this only applies with a certain set of games.
>
> There will always be people who frown on any language that isn't C,
> especially languages with the overhead of the typical scripting
> language;  but on the GBA, for many games, they're right.
>
> (What I don't get is why no one considers any of the nice modern
> languages for their game logic code, like modula3, or even ocaml or
> sather)
>
> Cheers.
>



________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

Hello gbadev,

   We released our first GBA demo at Assembly'2003.
It took the last (9th) place but this is pretty nice demo.
Just download and enjoy.

http://www.scene.org/file.php?file=%2Fparties%2F2003%2Fassembly03%2Fmobile_demo%\
2Fcounting_clouds_by_brainwave_team.zip&fileinfo

np: Fat Boy Slim - Soul surfing
-- [ZX][GBA][Scene][Anime][Ot.A.Ma.][B.A.K.A. S.T.][Powered by Jenechka]
Best regards,
  Vivid / Brainwave Team                    mailto:vivid@...

--- William Mallouk wrote:
> If you still want to use scripts after Colin's email, I know of a
> scripting language called LUA that can be easily adapted to be
> used on the GBA, with the advantage that you can compile scripts
> to a bytecode format, so you are at least saving space using it.
>
> Here goes the URL http://www.lua.org/
>
> It's a great piece of software, and it's open source. And besides
> that, you can easily use it at any platform. Worth taking a look.

Yup -- 100% portable ANSI C. I don't know if anyone has mentioned
it here yet, but Lua is also tiny, and it's one of *the* fastest
interpreted scripting languages there is. It's also well written,
easy to modify, designed specifically for embedding and extending,
and very modular. You can leave out the compiler and the standard
libraries simply by not linking them in, and end up with a ~24KB
VM. Lua has probably seen more use in games than any other single
scripting language.

Cheers,
Eric


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Hey,

Colin really had a good point there.

If you still want to use scripts after Colin's email, I know of a scripting
language called LUA that can be easily adapted to be used on the GBA,
with the advantage that you can compile scripts to a bytecode format,
so you are at least saving space using it.

Here goes the URL http://www.lua.org/

It's a great piece of software, and it's open source. And besides that, you
can easily use it at any platform. Worth taking a look.

Bill

----- Original Message -----
From: "Colin Brown" <user@...>
To: <gbadev@yahoogroups.com>
Sent: Friday, August 08, 2003 9:56 AM
Subject: [gbadev] Re: Scripting on the GBA


> --- In gbadev@yahoogroups.com, "JC Matthews" <kreedskulls@y...> wrote:
> > Hello I were wondering if there is any info on Scripting for the
> GBA.
>
> to an extent, i'm being devils advocate here!
>
> exactly what would the advantage be in using a scripting language
> implementation on the gba?
>
> I can see the point for a pc or next gen console game:
> * scripts can be used unchanged for different platforms
> * script changes and tweaks can be made during program execution
> * keeping a sandbox environment for safe script execution
> * scripts can be used without making a build, so non programmers can
> easily add functionality
>
> these things are IMO not easily applicable to gba:
>
> * porting a gba game to other platforms: the gba is so different to
> most other gaming hardware that it seems like it would be better to
> just do a total re-write anyway.
>
> * making changes during program execution would require either an
> interpreted language(too slow) or compilation on the fly (on a gba?)
> you would also need a console and some way of hooking up a keyboard.
>
> * a safe sandbox virtual machine would surely have too big an impact
> on performance for the puny gba cpu
>
> * not having an interpreter or a normal file system makes it kind of
> difficult to add scripts without compiling and linking.
>
> * there will also be resource issues related to having to keep and
> environment(stack etc) for each active script...
>
> Ok, i'm sure there are ways to deal with the above points (i'd really
> like to here them :)) but in the end even if there are work-arounds
> and this stuff is doable, what extra does a scripting language give
> you that is really worth the inevitable dent in performance? (and the
> cost in implementing the scripting and learning to use the language?)
>
> cheers
>
> Col
>
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Not a complete newbie to programming.. have experience with 80x86
assembly and pascal / c++.. It's been awhile since those days, but I
don't have any trouble grasping the concepts so far, so I think I'll be
ok..

I've been reading the gbajunkie docs and they've been pretty good so far
so I'll continue with those..

Thanks for the reply tom..

James

-----Original Message-----
From: Tom Badran [mailto:tb100@...]
Sent: August 12, 2003 10:48 AM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Re: Scripting on the GBA

On Tuesday 12 Aug 2003 15:39, James Acres wrote:
> http://www.gatesboy.com/Lua/Documentation/
>
> It looks like there's actually a LUA implementation for the GBA that
you
> may want to check out.
>
> Btw, I'm a complete newbie to GBA and I've been going through some
> tutorials on gbadev.org - are there any that you guys have ran across
> that would have made your learning experience a bit easier?

The gbajunkie docs i remember being very good. Are you a complete newb
to th
gba or programming in general? If its programming in general the gba is
not
the easiest way to start out, however saying that im sure there are many
here
who learnt the basic tenants of programming in z80/6502 assembler.

Tom

--
  ^__^               Tom Badran
  (oo)\______        Imperial College
(__)\       )\/\
     ||----w |
     ||     ||       Using Debian SID

hi list,

yup, there is an implementation of lua for gba. i made gbalua a long time
ago mostly because i was wondering if it was possible, rather than because
of any possible benefit of using scripts on gba.

however, i anounced the project here on this list, but the response was
quite non-existing and to be perfectly honest, i havn't myself really found
any good use for it either. i'm not saying that scripts for gba is
nececarily a bad thing, it's just that it stopped interest me so that's why
the project has come to a complete halt and the site hasn't been updated for
ages. if anybody want's to pick up the stick and run with it, just contact
me...

sorry for poor spelling, grammar and stuff...

         /dan


----- Original Message -----
From: "James Acres" <james@...>
To: <gbadev@yahoogroups.com>
Sent: Tuesday, August 12, 2003 16:39
Subject: RE: [gbadev] Re: Scripting on the GBA


> http://www.gatesboy.com/Lua/Documentation/
>
> It looks like there's actually a LUA implementation for the GBA that you
> may want to check out.
>
> Btw, I'm a complete newbie to GBA and I've been going through some
> tutorials on gbadev.org - are there any that you guys have ran across
> that would have made your learning experience a bit easier?
>
> Cheers,
>
> james
>
> -----Original Message-----
> From: Emil Arkman [mailto:emil_arkman@...]
> Sent: August 12, 2003 3:44 AM
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Re: Scripting on the GBA
>
> How does small compare to LUA?
>
> Emil
>
>   ----- Original Message -----
>   From: Groepaz
>   To: gbadev@yahoogroups.com
>   Sent: Monday, August 04, 2003 7:55 PM
>   Subject: Re: [gbadev] Re: Scripting on the GBA
>
>
>   On Sunday 03 August 2003 15:19, Raleigh Cross wrote:
>   > There aren't any scripting languages in the Unix shell replacement
>   > sense, nor are
>   > there any 'interpreted' languages that I
>   > know of. But, there is Dragon Basic [ http://www.simforth.com ].
>   > That's about as close as you get.
>
>   there are actually a bunch of "embedded" script interpreters
> around.... i
>   would personally suggest to have a look at "small", which is (as the
> name
>   suggests :)) a pretty small script interpreter with the capability of
> calling
>   external/custom C-routines. quite a bunch of games use that one afaik,
> its
>   easy,nice,small,free :)
>
>   gpz
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

GBAtools is a new software development company, we specialize in asset
creation tools and applications for professional Gameboy Advance
developers.

We are pleased to announce the launch of our flagship product, Level
Mapper, a powerful and flexible map creation and design tool.

Level Mapper is the perfect tool for creating your GBA game level maps.
We have a FREE trial version of Level Mapper on our site for you to try.

We also have a range of other new and exciting products awaiting
release. For more information please visit out web-site at:
http://www.gbatools.com.

On Tuesday 12 Aug 2003 15:39, James Acres wrote:
> http://www.gatesboy.com/Lua/Documentation/
>
> It looks like there's actually a LUA implementation for the GBA that you
> may want to check out.
>
> Btw, I'm a complete newbie to GBA and I've been going through some
> tutorials on gbadev.org - are there any that you guys have ran across
> that would have made your learning experience a bit easier?

The gbajunkie docs i remember being very good. Are you a complete newb to th
gba or programming in general? If its programming in general the gba is not
the easiest way to start out, however saying that im sure there are many here
who learnt the basic tenants of programming in z80/6502 assembler.

Tom

--
  ^__^               Tom Badran
  (oo)\______        Imperial College
(__)\       )\/\
     ||----w |
     ||     ||       Using Debian SID

On Tuesday 12 Aug 2003 15:10, Julian Squires wrote:
> (What I don't get is why no one considers any of the nice modern
> languages for their game logic code, like modula3, or even ocaml or
> sather)

You can find many games written in python (not for the gba btw), which i think
is great. Here you have the best of both worlds - a language which has a well
defined imperative structure, but gives you the advanced list processing and
functional programming features of languages like haskell.

See the pygame libraries for more info on this.

Tom

--
  ^__^               Tom Badran
  (oo)\______        Imperial College
(__)\       )\/\
     ||----w |
     ||     ||       Using Debian SID

http://www.gatesboy.com/Lua/Documentation/

It looks like there's actually a LUA implementation for the GBA that you
may want to check out.

Btw, I'm a complete newbie to GBA and I've been going through some
tutorials on gbadev.org - are there any that you guys have ran across
that would have made your learning experience a bit easier?

Cheers,

james

-----Original Message-----
From: Emil Arkman [mailto:emil_arkman@...]
Sent: August 12, 2003 3:44 AM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Re: Scripting on the GBA

How does small compare to LUA?

Emil

   ----- Original Message -----
   From: Groepaz
   To: gbadev@yahoogroups.com
   Sent: Monday, August 04, 2003 7:55 PM
   Subject: Re: [gbadev] Re: Scripting on the GBA


   On Sunday 03 August 2003 15:19, Raleigh Cross wrote:
   > There aren't any scripting languages in the Unix shell replacement
   > sense, nor are
   > there any 'interpreted' languages that I
   > know of. But, there is Dragon Basic [ http://www.simforth.com ].
   > That's about as close as you get.

   there are actually a bunch of "embedded" script interpreters
around.... i
   would personally suggest to have a look at "small", which is (as the
name
   suggests :)) a pretty small script interpreter with the capability of
calling
   external/custom C-routines. quite a bunch of games use that one afaik,
its
   easy,nice,small,free :)

   gpz

Hi.  My two cents.

On Tue, Aug 12, 2003 at 04:55:19AM -0000, Damian Yerrick wrote:
> What is the fundamental difference between scripts and C anyway?

In theory, not too much.  In practice, overhead -- scripts are generally
interpreted, usually at a bytecode level; scripting languages usually
have all the storage issues hidden from view, usually with automatic
variable creation (on a stack) and a garbage-collected memory allocator;
scripting languages almost always have a larger runtime support system
than C, especially if they support lisp-ish eval and similar.

IMO, the real issue is that if you really want to push the boundries on
the GBA, you can't always afford those overhead issues.  A game like
Maniac Mansion is the perfect example of the style of game where
scripting is great... you're unlikely to be doing all that much in
realtime except some decompression, there's lots of special case game
logic for different areas, and the game's entities don't have much to do
in terms of AI.

Also, scripting languages are often used with the consideration that the
designers can write in them, and test with them, more easily than they
could in C.  Of course, this only applies with a certain set of games.

There will always be people who frown on any language that isn't C,
especially languages with the overhead of the typical scripting
language;  but on the GBA, for many games, they're right.

(What I don't get is why no one considers any of the nice modern
languages for their game logic code, like modula3, or even ocaml or
sather)

Cheers.

--
Julian Squires

G> whats LUA ? :=P

http://www.wikipedia.org/wiki/Lua


--
   porneL

Have you ever imagined a world with no hypothetical situations? [
http://pornel.ldreams.net ]

GG 989217, icy cucumber 145671338, #amigapl (irc.pl)

On Tuesday 12 August 2003 09:43, Emil Arkman wrote:
> How does small compare to LUA?

whats LUA ? :=P

gpz

On Tuesday 12 August 2003 06:55, Damian Yerrick wrote:

> What is the fundamental difference between scripts and C anyway?

scripts are interpreted (also true if they are precompiled to bytecode), while
C is compiled into actual machine language. other than that there is no real
difference, whatever you can do in C you can do with a script (with varying
degree depending on your scriptlanguage/interpreter etc)

the only real difference is that script languages can be designed specificilly
for a task, and made as simple as possible at the same time so "designers"
(not "pogrammers") can edit them. (very common in larger development teams)

gpz

How does small compare to LUA?

Emil

   ----- Original Message -----
   From: Groepaz
   To: gbadev@yahoogroups.com
   Sent: Monday, August 04, 2003 7:55 PM
   Subject: Re: [gbadev] Re: Scripting on the GBA


   On Sunday 03 August 2003 15:19, Raleigh Cross wrote:
   > There aren't any scripting languages in the Unix shell replacement
   > sense, nor are
   > there any 'interpreted' languages that I
   > know of. But, there is Dragon Basic [ http://www.simforth.com ].
   > That's about as close as you get.

   there are actually a bunch of "embedded" script interpreters around.... i
   would personally suggest to have a look at "small", which is (as the name
   suggests :)) a pretty small script interpreter with the capability of calling
   external/custom C-routines. quite a bunch of games use that one afaik, its
   easy,nice,small,free :)

   gpz



         Yahoo! Groups Sponsor
               ADVERTISEMENT




   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

--- In gbadev@yahoogroups.com, Groepaz <groepaz@g...> wrote:
> many games can work by just rewriting the actual graphics part.
> imagine anything along the lines of point-and-click adventures
> for example.

Likewise, the core gameplay code (tetanus.c) of Tetanus On Drugs
changed much less from PC to GBA than the I/O code did.  Even on
a 16 MHz machine, I/O abstraction can be affordable.

> On Friday 08 August 2003 14:56, Colin Brown wrote:
>
> > * making changes during program execution would require
> > either an interpreted language(too slow)
>
> who tells you that its to slow? maniac mansion uses interpreted
> scripts on the c64 (1mhz,8bit cpu) and it obviously works ok.

Likewise, many e-reader games are written in bytecode that
resembles the machine language of the 6502 processor,
accessing I/O similar to that of the old Famicom game console.

> > or compilation on the fly (on a gba?)
>
> self modifying code?

Dynamic recompilation is relatively common in emulators.

> and unless you are writing an action-filled
> hi-tech shooter/arcade/whatever you can live with that.

Do Gradius and its ilk run at full speed in PocketNES?

> bugs in scripts can be located more easily (the script interpreter
> can help with finding them by itself, printing ill-conditions to
> console, whatever).

In debug builds of my GBA projects, I usually print ill-conditions
to an unused part of the layer I'm using for the status bar.

What is the fundamental difference between scripts and C anyway?

--
Damian

On Friday 08 August 2003 14:56, Colin Brown wrote:

> these things are IMO not easily applicable to gba:
>
> * porting a gba game to other platforms: the gba is so different to
> most other gaming hardware that it seems like it would be better to
> just do a total re-write anyway.

not really...many games can work by just rewriting the actual graphics part.
imagine anything along the lines of point-and-click adventures for example.

> * making changes during program execution would require either an
> interpreted language(too slow)

who tells you that its to slow? maniac mansion uses interpreted scripts on the
c64 (1mhz,8bit cpu) and it obviously works ok.

> or compilation on the fly (on a gba?)
> you would also need a console and some way of hooking up a keyboard.

self modifying code?

> * a safe sandbox virtual machine would surely have too big an impact
> on performance for the puny gba cpu

no, thats just an assumption - have you ever tried? it would for sure kill
*some* performance, but not much. and unless you are writing an action-filled
hi-tech shooter/arcade/whatever you can live with that.

> * not having an interpreter or a normal file system makes it kind of
> difficult to add scripts without compiling and linking.

load them to SRAM ? (and who's telling you that you cant have a "normal"
filesystem? i'd assume that most real dev-environments actually DO have that)

> * there will also be resource issues related to having to keep and
> environment(stack etc) for each active script...

not more than for a usual c-compiled program. probably even less.

> Ok, i'm sure there are ways to deal with the above points (i'd really
> like to here them :)) but in the end even if there are work-arounds
> and this stuff is doable, what extra does a scripting language give
> you that is really worth the inevitable dent in performance? (and the
> cost in implementing the scripting and learning to use the language?)

with scripts you can usually develop your stuff much faster than without one.
bugs in scripts can be located more easily (the script interpreter can help
with finding them by itself, printing ill-conditions to console, whatever).

i'd personally suggest you to think about how you would write a graphical
adventure thingy (like maniac mansion) _without_ using some sort of scripting
- you'll answer all your questions yourself

gpz

--- In gbadev@yahoogroups.com, "JC Matthews" <kreedskulls@y...> wrote:
> Hello I were wondering if there is any info on Scripting for the
GBA.

to an extent, i'm being devils advocate here!

exactly what would the advantage be in using a scripting language
implementation on the gba?

I can see the point for a pc or next gen console game:
* scripts can be used unchanged for different platforms
* script changes and tweaks can be made during program execution
* keeping a sandbox environment for safe script execution
* scripts can be used without making a build, so non programmers can
easily add functionality

these things are IMO not easily applicable to gba:

* porting a gba game to other platforms: the gba is so different to
most other gaming hardware that it seems like it would be better to
just do a total re-write anyway.

* making changes during program execution would require either an
interpreted language(too slow) or compilation on the fly (on a gba?)
you would also need a console and some way of hooking up a keyboard.

* a safe sandbox virtual machine would surely have too big an impact
on performance for the puny gba cpu

* not having an interpreter or a normal file system makes it kind of
difficult to add scripts without compiling and linking.

* there will also be resource issues related to having to keep and
environment(stack etc) for each active script...

Ok, i'm sure there are ways to deal with the above points (i'd really
like to here them :)) but in the end even if there are work-arounds
and this stuff is doable, what extra does a scripting language give
you that is really worth the inevitable dent in performance? (and the
cost in implementing the scripting and learning to use the language?)

cheers

Col

On Sunday 03 August 2003 15:19, Raleigh Cross wrote:
> There aren't any scripting languages in the Unix shell replacement
> sense, nor are
> there any 'interpreted' languages that I
> know of. But, there is Dragon Basic [ http://www.simforth.com ].
> That's about as close as you get.

there are actually a bunch of "embedded" script interpreters around.... i
would personally suggest to have a look at "small", which is (as the name
suggests :)) a pretty small script interpreter with the capability of calling
external/custom C-routines. quite a bunch of games use that one afaik, its
easy,nice,small,free :)

gpz

There aren't any scripting languages in the Unix shell replacement
sense, nor are
there any 'interpreted' languages that I
know of. But, there is Dragon Basic [ http://www.simforth.com ].
That's about as close as you get.

--- In gbadev@yahoogroups.com, "JC Matthews" <kreedskulls@y...> wrote:
> Hello I were wondering if there is any info on Scripting for the
GBA.

I had talked to Jeff a while back about adding support for programming my flash
carts.  I have been busy for a while and Im shure he has too.  Can someone tell
me how the visloy cart is Identified by the flash linker software?  Perhaps I
can add this to my firmware so it will program on a flash linker..

Thanks,
Daniel

Hello I were wondering if there is any info on Scripting for the GBA.

Heya,

While things are slow on the list I might as well
send a little msg about the development competition
at http://gbadev.org...

Quick facts:
Two categories (one demo & one game)
Deadline is 14/15th of September
No theme (do whatever the hell you want :)
Nice prizes
Rules can be found on http://gbadev.org/compo.php

Feel free to mail me with any questions that you
may have.

Best wishes

Simon
gbadev.org