Hi,

I agree entirely.  The problem is that because of the ease of development in
C/C++ not a vast amount of people have, or more likely are given the time to
learn how to create tight routines in assembly.  On the Amiga you didn't
really have much of a choice.  I'm working on a commercial GBA product and
just don't have time to do anything in ASM, and optimising in C is not a
very strong point of mine, as I don't find it as intuitive as cycle counting
in raw ASM.  I know I could disassemble, but just don;t have time to
compile, disassmeble, rwcode, recompile etc.  It's strange to consider, but
probably the best and fastest programmers execution wise, are the guys doing
home brew GBA code.  They tend to have the time and inclination to get low
level.  Wish I had the time :(  The GBA has basically the same HW as the
SNES and a CPU that kicks the SNES's arse severely, yet the quality isn't
there yet to my mind.  Won't be long though.

FGL

-----Original Message-----
From: Mike Watts [mailto:starboy@...]
Sent: 02 October 2001 12:11
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Hardware 3D on GBA ?


That's pretty much the key word 'Tight' code. If you really try hard to get
an incredibly smooth piece of code,
you can do pretty much anything. People seem to have forgotten how to write
good code. Games companies
now just write and write and write, and if they reach the limit of their dev
systems, they just upgrade and turn the
sys. req. up a notch. If you take a step back to when the Amiga was king, or
even the BBC Micro, there were
people that could push it way beyond the limits, just by knowing the machine
and coding it right. Take the Elite series
They had the first version running on a BBC, and it was fantastic. The
second version happily ran on the old amiga
  and that was only 7.22MHz with no extra hardware (i think that's the right
number). The GBA is a very powerful
little beast, it just needs the right code!!

infact, i think i'm going to go write an Elite clone right now!!!

-Mike
----- Original Message -----
From: ninge <ninge@...>
To: <gbadev@yahoogroups.com>
Sent: Tuesday, October 02, 2001 9:52 AM
Subject: RE: [gbadev] Hardware 3D on GBA ?


> the GBA is more than capable of doing a doom style 3D game using nothing
but
> its own hardware coupled with some tight code!
>
> as for the superFX chip - the GBA on its own is WAY more capable than the
> super FX chip ever was - and by that i mean more polygons and at a better
> framerate :)
>
>
> -----Original Message-----
> From: D Green [mailto:fbs@...]
> Sent: 31 August 2001 22:49
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Hardware 3D on GBA ?
>
>
> Silly thought - but was the super nes capable? (without the FX chip)
>
> Now, in my eyes, the GBA is a souped up/enhanced snes, and seeing that it
> could just about handle 3D scenes with an FX add on, then seeing the GBA
> is - twice as powerful?
>
> I'd like to see 'how' this doom port is done, as the snes version used an
FX
> chip, is this version also following that route?
>
> Dan.
>
> P.s - Dont flame that I called the GBA a souped up SNES. In fact I am
quite
> fond of the snes, and this is one of the main reasons for buying a GBA :-)
>
> ----- Original Message -----
> From: "The Night Howler" <Night-Howler@...>
> To: <gbadev@yahoogroups.com>
> Sent: Monday, October 01, 2001 8:13 PM
> Subject: [gbadev] Hardware 3D on GBA ?
>
>
> > Hi all,
> >
> > We all know now that GBA isn't quite able of doing hardware-rendered 3D
> > scenes for games, as the viedo chipset is only aimed at 2D.
> > With software 3D rendering, one can manage to get around 50000 polygons
/
> > second (if I can remember well the figures), which is really not enough
> for
> > a big, real 3D game.
> >
> > So my question is, does anyone think it would be possible to incorporate
> > some kind of 3D video chipset in a cart, which would do the render of
> scenes
> > and blit it awesomely fast on the screen, for example in mode 3 or 4 ?
> >
> > Let me explain.
> > Aperture size for cartidge is 32 Mb. So what if one uses, for example,
28
> Mb
> > for the cartidge ROM, and the 4 last Mb would be to transmit data to
what
> > I'd call the "3D chipset" in the "special cart" ?
> > As I see it, the "3D chipset" would work like this :
> > - On the first bytes of its address space, we have some controls (such
as
> :
> > position of the camera for drawing, chipset enabled, chipset bliting
etc.)
> > in read and / or write states.
> > - On the next Mbs the user would have to DMA the scene polygons data,
and
> > then the texture data. The same data may remain for several frames
> > (background, wals etc.) or may be for just one frame (3D moving objects
> > etc.).
> > - The "3D chipset" would then do, when ordered (one control bit for
> "render"
> > maybe), the blitting of the resulting scene on the GBA display. The
> > rendering shall be made by the "3D chipset" without halting the GBA cpu
> (of
> > course).
> >
> > As I don't know anything about electronics, I'm just wondering if such a
> > chip is only an utopia or may be madeable. What do you think about it ?
> Does
> > anything similar exist for another game system ?
> >
> > Regards,
> >
> > Mathieu -- The Night Howler
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>




list rules: http://www.gbadev.org/rules.txt
unsubscribe: gbadev-unsubscribe@yahoogroups.com



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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> infact, i think i'm going to go write an Elite clone right now!!!

That is something i would LOVE to see :), one of the best games ever made.

- --
Tom "Tomahawk" Badran
Department of Computing, Imperial College
- --------------------------------------------------------------
PGP Public key available from keyserver.pgp.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7uaY/XCpWOla2mCcRAjRpAJ9mA/SSCwKHgLmKd4piJ0bfplLHggCdGFvV
0qgz0kdL53gIvUJ1dcEfDf0=
=R/bk
-----END PGP SIGNATURE-----

Very true, the AGB is a *very* fast bit of kit. I'm used to coding low level
for the old Atari ST, where a decent mod player would take 20-25%+ CPU time.
I wrote a mod player for the AGB using similar optimisation techniques and
it comes in at about 5%!

There will not be any problem in writing a 3D engine for the AGB to kick out
some Starfox quality visuals. I'd say the ARM CPU is at least 4x quicker
than the ST, especially when doing things like fixed point where barrel
shifting comes into it's own for optimisation. And that could do some good
3D games.... even though it had planar graphics modes, which are a bitch
compared to the byte / nibble per pixel of the AGB.

The AGB has awesome potential in every aspect of gaming, and is very easy to
optimise in assembler. Coding has never been so mcuh fun..... ;D

--Jim

Hello The,

TNH> So my question is, does anyone think it would be possible to incorporate
TNH> some kind of 3D video chipset in a cart, which would do the render of
scenes
TNH> and blit it awesomely fast on the screen, for example in mode 3 or 4 ?

entire possibly i'd say... there were games on snes that did exactly
that ... probably wont happen to soon though, ppl will push doom or
descent - alike engine to its limits before and then, if gba games
still promise enough profit, they'll consider adding special "fx
chips" (as they were called in snes times) - the whole manufacturing
process will be MUCH more expensive than it already is with standard
carts.

--
Best regards,
  groepaz                            mailto:groepaz@...

That's pretty much the key word 'Tight' code. If you really try hard to get
an incredibly smooth piece of code,
you can do pretty much anything. People seem to have forgotten how to write
good code. Games companies
now just write and write and write, and if they reach the limit of their dev
systems, they just upgrade and turn the
sys. req. up a notch. If you take a step back to when the Amiga was king, or
even the BBC Micro, there were
people that could push it way beyond the limits, just by knowing the machine
and coding it right. Take the Elite series
They had the first version running on a BBC, and it was fantastic. The
second version happily ran on the old amiga
  and that was only 7.22MHz with no extra hardware (i think that's the right
number). The GBA is a very powerful
little beast, it just needs the right code!!

infact, i think i'm going to go write an Elite clone right now!!!

-Mike
----- Original Message -----
From: ninge <ninge@...>
To: <gbadev@yahoogroups.com>
Sent: Tuesday, October 02, 2001 9:52 AM
Subject: RE: [gbadev] Hardware 3D on GBA ?


> the GBA is more than capable of doing a doom style 3D game using nothing
but
> its own hardware coupled with some tight code!
>
> as for the superFX chip - the GBA on its own is WAY more capable than the
> super FX chip ever was - and by that i mean more polygons and at a better
> framerate :)
>
>
> -----Original Message-----
> From: D Green [mailto:fbs@...]
> Sent: 31 August 2001 22:49
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Hardware 3D on GBA ?
>
>
> Silly thought - but was the super nes capable? (without the FX chip)
>
> Now, in my eyes, the GBA is a souped up/enhanced snes, and seeing that it
> could just about handle 3D scenes with an FX add on, then seeing the GBA
> is - twice as powerful?
>
> I'd like to see 'how' this doom port is done, as the snes version used an
FX
> chip, is this version also following that route?
>
> Dan.
>
> P.s - Dont flame that I called the GBA a souped up SNES. In fact I am
quite
> fond of the snes, and this is one of the main reasons for buying a GBA :-)
>
> ----- Original Message -----
> From: "The Night Howler" <Night-Howler@...>
> To: <gbadev@yahoogroups.com>
> Sent: Monday, October 01, 2001 8:13 PM
> Subject: [gbadev] Hardware 3D on GBA ?
>
>
> > Hi all,
> >
> > We all know now that GBA isn't quite able of doing hardware-rendered 3D
> > scenes for games, as the viedo chipset is only aimed at 2D.
> > With software 3D rendering, one can manage to get around 50000 polygons
/
> > second (if I can remember well the figures), which is really not enough
> for
> > a big, real 3D game.
> >
> > So my question is, does anyone think it would be possible to incorporate
> > some kind of 3D video chipset in a cart, which would do the render of
> scenes
> > and blit it awesomely fast on the screen, for example in mode 3 or 4 ?
> >
> > Let me explain.
> > Aperture size for cartidge is 32 Mb. So what if one uses, for example,
28
> Mb
> > for the cartidge ROM, and the 4 last Mb would be to transmit data to
what
> > I'd call the "3D chipset" in the "special cart" ?
> > As I see it, the "3D chipset" would work like this :
> > - On the first bytes of its address space, we have some controls (such
as
> :
> > position of the camera for drawing, chipset enabled, chipset bliting
etc.)
> > in read and / or write states.
> > - On the next Mbs the user would have to DMA the scene polygons data,
and
> > then the texture data. The same data may remain for several frames
> > (background, wals etc.) or may be for just one frame (3D moving objects
> > etc.).
> > - The "3D chipset" would then do, when ordered (one control bit for
> "render"
> > maybe), the blitting of the resulting scene on the GBA display. The
> > rendering shall be made by the "3D chipset" without halting the GBA cpu
> (of
> > course).
> >
> > As I don't know anything about electronics, I'm just wondering if such a
> > chip is only an utopia or may be madeable. What do you think about it ?
> Does
> > anything similar exist for another game system ?
> >
> > Regards,
> >
> > Mathieu -- The Night Howler
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

> GBA Map Editor b4: This the best one I have found, but it doesn't
> support tile flipping.

Write your own : they do not provide export in YOUR format,
they do not allow collosion box placement .. etc .. so write
ur own .. personally I use BC++ for quick & rapid intergface building


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

isnt tUME open source now? - perhaps you could make porting it to windows your
own little project? :0)


-----Original Message-----
From: Jerod M. Bennett [mailto:jerod@...]
Sent: 01 October 2001 23:52
To: gbadev@yahoogroups.com
Subject: RE: [gbadev] Decent Map Editor


Does anyone know of a plan to port tUME to windows... 320x240 is a
little restrictive.

-Jerry

-----Original Message-----
From: Greg Stewart [mailto:g_stewart@...]
Sent: Monday, October 01, 2001 3:00 PM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Decent Map Editor


One thing I think I should point out is that Open tUME does also support
PCX files.. however, this is not written anywhere in the docs that it
does (as far as I could tell).

My personal choice is Open tUME.... it's a well written piece of
software
that has many features builtin that work well with the GBA.      There
is
Tumeric for loading maps via C code insertion, or else you can write
your
own map loader that will load the map off the end of your rom.   That is
what I decided to do, and once you write a little tool to attach the
maps to the end of your ROM, and write a loader/reader, you're good to
go.  The time
spent on it is well worth it... it really didn't take me that long.
Just
make sure you study the docs well in understanding the tUME format.

I hope this helps a little.

         Greg Stewart
         http://www.sparklegameco.com






list rules: http://www.gbadev.org/rules.txt
unsubscribe: gbadev-unsubscribe@yahoogroups.com



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




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



       Yahoo! Groups Sponsor
             ADVERTISEMENT




list rules: http://www.gbadev.org/rules.txt
unsubscribe: gbadev-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
       This email has been virus scanned using Sophos Anti-Virus by intY
(www.inty.net)



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

the GBA is more than capable of doing a doom style 3D game using nothing but
its own hardware coupled with some tight code!

as for the superFX chip - the GBA on its own is WAY more capable than the
super FX chip ever was - and by that i mean more polygons and at a better
framerate :)


-----Original Message-----
From: D Green [mailto:fbs@...]
Sent: 31 August 2001 22:49
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Hardware 3D on GBA ?


Silly thought - but was the super nes capable? (without the FX chip)

Now, in my eyes, the GBA is a souped up/enhanced snes, and seeing that it
could just about handle 3D scenes with an FX add on, then seeing the GBA
is - twice as powerful?

I'd like to see 'how' this doom port is done, as the snes version used an FX
chip, is this version also following that route?

Dan.

P.s - Dont flame that I called the GBA a souped up SNES. In fact I am quite
fond of the snes, and this is one of the main reasons for buying a GBA :-)

----- Original Message -----
From: "The Night Howler" <Night-Howler@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, October 01, 2001 8:13 PM
Subject: [gbadev] Hardware 3D on GBA ?


> Hi all,
>
> We all know now that GBA isn't quite able of doing hardware-rendered 3D
> scenes for games, as the viedo chipset is only aimed at 2D.
> With software 3D rendering, one can manage to get around 50000 polygons /
> second (if I can remember well the figures), which is really not enough
for
> a big, real 3D game.
>
> So my question is, does anyone think it would be possible to incorporate
> some kind of 3D video chipset in a cart, which would do the render of
scenes
> and blit it awesomely fast on the screen, for example in mode 3 or 4 ?
>
> Let me explain.
> Aperture size for cartidge is 32 Mb. So what if one uses, for example, 28
Mb
> for the cartidge ROM, and the 4 last Mb would be to transmit data to what
> I'd call the "3D chipset" in the "special cart" ?
> As I see it, the "3D chipset" would work like this :
> - On the first bytes of its address space, we have some controls (such as
:
> position of the camera for drawing, chipset enabled, chipset bliting etc.)
> in read and / or write states.
> - On the next Mbs the user would have to DMA the scene polygons data, and
> then the texture data. The same data may remain for several frames
> (background, wals etc.) or may be for just one frame (3D moving objects
> etc.).
> - The "3D chipset" would then do, when ordered (one control bit for
"render"
> maybe), the blitting of the resulting scene on the GBA display. The
> rendering shall be made by the "3D chipset" without halting the GBA cpu
(of
> course).
>
> As I don't know anything about electronics, I'm just wondering if such a
> chip is only an utopia or may be madeable. What do you think about it ?
Does
> anything similar exist for another game system ?
>
> Regards,
>
> Mathieu -- The Night Howler

> Whats the alien mind can use @ as comment ;)

The same alien mind that can design the default Emacs key bindings.

Ed xxx

u8 | (u8 << 8) will work better, assuming C operator precedence.

-----Original Message-----
From: Dale Freya [mailto:dfreya@...]
Sent: Sunday, September 30, 2001 9:27 PM
To: gbadev@yahoogroups.com
Subject: RE: [gbadev] Stupid Mode 4


U16 = u8 | u8 << 8
Component 2 is shifted left 8 bits into the high part of the word.

- Dale


-----Original Message-----
From: Mr SDFG ASDG [mailto:cupcakus2000@...]
Sent: Sunday, 30 September 2001 12:50 AM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Stupid Mode 4


I figured it out with:
u16=u8*256+u8
There is probably a better way, like an operator that can do it, but for
the mean time the formula above works great.
  Mr SDFG ASDG <cupcakus2000@...> wrote: I have a 256 color bitmap
which I have processed into a u16 pallet array, and a u8 data array with
indexes to the pallet information.

The problem of course is that video memory only accepts writes in
16bits, so one would simply say:
"Write two pixels at once..."  I would love to! How do I combine the two
8 bit blocks of data into one 16bit block?

That's the spirit!  Let us know when it's available!  I can't wait to see it.
   pauls <pauls@...> wrote: Hey Collin,

Thanks for the cool reply,  you really should lighten up some what, I was
only joking around, injecting a little English humour ...  :-) ... I just
find it funny that people bag on free software so much.

I hardly warrent $20 sweat fee as a commerical business ... anyways as I
don't wish to go over old ground I'll be releasing it free in the near
future for anyone who is interested & liked the interface.

Mr "not so" Selfish ....



----- Original Message -----
From: "Collin van Ginkel" <collin@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, October 01, 2001 4:01 AM
Subject: Re: [gbadev] Decent Map Editor


> Hi,
>
> > Just as a tease I have many many new features in TIME now, but as $20
was
> > too much for anyone ... I ain't releasing it,  shall keep it for myself
> ...
> > Just call me Mr Selfish !!!
>
> Great attitude! We need more people like you..
>
> If you want to run a commercial business and no-one is willing to pay for
> your product you should ask yourself what's wrong and not annoy us with
this
> childish stuff.
>
> Greetings,
>
> Collin
>
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > From: <cupcakus2000@...>
> > To: <gbadev@yahoogroups.com>
> > Sent: Sunday, September 30, 2001 2:36 PM
> > Subject: [gbadev] Decent Map Editor
> >
> >
> > > Can someone point me to a decent Map editor...  Here are the problems
> > > I have with the ones I have tried...
> > >
> > > GBA Map Editor b4: This the best one I have found, but it doesn't
> > > support tile flipping.
> > >
> > > Open tUME: Runs in DOS, and wants tiles in a strange format.
> > >
> > > TIME: Exports tile data as 8bit, Map data as 16bit, I can't get
> > > anything this program generates to display.  If someone wants to help
> > > in this department... please do!  GBAME b4 exports map data as 8bit
> > > and I have no problems displaying maps from that program.

I know this has been novered before, but I must ask.

How do I set up a timer to stop playing a sound when the dma has reached the end
of the sample?

Thanks,
Dan



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

Does anyone know of a plan to port tUME to windows... 320x240 is a
little restrictive.

-Jerry

-----Original Message-----
From: Greg Stewart [mailto:g_stewart@...]
Sent: Monday, October 01, 2001 3:00 PM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Decent Map Editor


One thing I think I should point out is that Open tUME does also support
PCX files.. however, this is not written anywhere in the docs that it
does (as far as I could tell).

My personal choice is Open tUME.... it's a well written piece of
software
that has many features builtin that work well with the GBA.      There
is
Tumeric for loading maps via C code insertion, or else you can write
your
own map loader that will load the map off the end of your rom.   That is
what I decided to do, and once you write a little tool to attach the
maps to the end of your ROM, and write a loader/reader, you're good to
go.  The time
spent on it is well worth it... it really didn't take me that long.
Just
make sure you study the docs well in understanding the tUME format.

I hope this helps a little.

         Greg Stewart
         http://www.sparklegameco.com






list rules: http://www.gbadev.org/rules.txt
unsubscribe: gbadev-unsubscribe@yahoogroups.com



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




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

I have also made a little tool to convert tUME output to a format usable
by GCC.  it is capable of handling all tile modes, 8x8 and 8x16 tiles,
16-color and 256-color tiles, and soon collision detection and object
placement data.  I don't plan on releasing it right now until i'm
finished testing for bugs, but if you want to test it i'd be happy to
e-mail it to you.

aaron

> As I don't know anything about electronics, I'm just wondering if such a
> chip is only an utopia or may be madeable. What do you think about it ?
Does
> anything similar exist for another game system ?

the SuperFX from the SNES anyone??

[joke] I understand 3DFX are going cheap:-)


Stay Lucky, Graham "Mournblade" Reeds.
ICQ: 30514803
http://homepage.dtn.ntl.com/grahamr/

Silly thought - but was the super nes capable? (without the FX chip)

Now, in my eyes, the GBA is a souped up/enhanced snes, and seeing that it
could just about handle 3D scenes with an FX add on, then seeing the GBA
is - twice as powerful?

I'd like to see 'how' this doom port is done, as the snes version used an FX
chip, is this version also following that route?

Dan.

P.s - Dont flame that I called the GBA a souped up SNES. In fact I am quite
fond of the snes, and this is one of the main reasons for buying a GBA :-)

----- Original Message -----
From: "The Night Howler" <Night-Howler@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, October 01, 2001 8:13 PM
Subject: [gbadev] Hardware 3D on GBA ?


> Hi all,
>
> We all know now that GBA isn't quite able of doing hardware-rendered 3D
> scenes for games, as the viedo chipset is only aimed at 2D.
> With software 3D rendering, one can manage to get around 50000 polygons /
> second (if I can remember well the figures), which is really not enough
for
> a big, real 3D game.
>
> So my question is, does anyone think it would be possible to incorporate
> some kind of 3D video chipset in a cart, which would do the render of
scenes
> and blit it awesomely fast on the screen, for example in mode 3 or 4 ?
>
> Let me explain.
> Aperture size for cartidge is 32 Mb. So what if one uses, for example, 28
Mb
> for the cartidge ROM, and the 4 last Mb would be to transmit data to what
> I'd call the "3D chipset" in the "special cart" ?
> As I see it, the "3D chipset" would work like this :
> - On the first bytes of its address space, we have some controls (such as
:
> position of the camera for drawing, chipset enabled, chipset bliting etc.)
> in read and / or write states.
> - On the next Mbs the user would have to DMA the scene polygons data, and
> then the texture data. The same data may remain for several frames
> (background, wals etc.) or may be for just one frame (3D moving objects
> etc.).
> - The "3D chipset" would then do, when ordered (one control bit for
"render"
> maybe), the blitting of the resulting scene on the GBA display. The
> rendering shall be made by the "3D chipset" without halting the GBA cpu
(of
> course).
>
> As I don't know anything about electronics, I'm just wondering if such a
> chip is only an utopia or may be madeable. What do you think about it ?
Does
> anything similar exist for another game system ?
>
> Regards,
>
> Mathieu -- The Night Howler
>
>
>
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

Hi,

Of course this deserves a reaction from me :)

I'm glad to hear you didn't mean the things you said. I wasn't personally
offended or anything like that, I just hated the attitude.

Oh and the clever placement of a smiley could have alerted me to the 'little
English homur' you were injecting. ;)

Friendly greetings,

Collin van Ginkel
-
two tribes - digital happiness
visit http://www.twotribes.com


> From: "pauls" <pauls@...>
> Reply-To: gbadev@yahoogroups.com
> Date: Mon, 1 Oct 2001 10:21:25 -0700
> To: <gbadev@yahoogroups.com>
> Subject: Re: [gbadev] Decent Map Editor
>
> Hey Collin,
>
> Thanks for the cool reply,  you really should lighten up some what, I was
> only joking around, injecting a little English humour ...  :-) ... I just
> find it funny that people bag on free software so much.
>
> I hardly warrent $20 sweat fee as a commerical business ... anyways as I
> don't wish to go over old ground I'll be releasing it free in the near
> future for anyone who is interested & liked the interface.
>
> Mr "not so" Selfish ....
>
>
>
> ----- Original Message -----
> From: "Collin van Ginkel" <collin@...>
> To: <gbadev@yahoogroups.com>
> Sent: Monday, October 01, 2001 4:01 AM
> Subject: Re: [gbadev] Decent Map Editor
>
>
>> Hi,
>>
>>> Just as a tease I have many many new features in TIME now, but as $20
> was
>>> too much for anyone ... I ain't releasing it,  shall keep it for myself
>> ...
>>> Just call me Mr Selfish !!!
>>
>> Great attitude! We need more people like you..
>>
>> If you want to run a commercial business and no-one is willing to pay for
>> your product you should ask yourself what's wrong and not annoy us with
> this
>> childish stuff.
>>
>> Greetings,
>>
>> Collin
>>
>>>
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: <cupcakus2000@...>
>>> To: <gbadev@yahoogroups.com>
>>> Sent: Sunday, September 30, 2001 2:36 PM
>>> Subject: [gbadev] Decent Map Editor
>>>
>>>
>>>> Can someone point me to a decent Map editor...  Here are the problems
>>>> I have with the ones I have tried...
>>>>
>>>> GBA Map Editor b4: This the best one I have found, but it doesn't
>>>> support tile flipping.
>>>>
>>>> Open tUME: Runs in DOS, and wants tiles in a strange format.
>>>>
>>>> TIME: Exports tile data as 8bit, Map data as 16bit, I can't get
>>>> anything this program generates to display.  If someone wants to help
>>>> in this department... please do!  GBAME b4 exports map data as 8bit
>>>> and I have no problems displaying maps from that program.
>>
>>
>>
>> list rules: http://www.gbadev.org/rules.txt
>> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>>
>>
>>
>> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>>
>>
>>
>
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

try with mappy tile editor for win i use it and it's wonderful

> Can someone point me to a decent Map editor...  Here are the problems
> I have with the ones I have tried...
>
> GBA Map Editor b4: This the best one I have found, but it doesn't
> support tile flipping.
>
> Open tUME: Runs in DOS, and wants tiles in a strange format.
>
> TIME: Exports tile data as 8bit, Map data as 16bit, I can't get
> anything this program generates to display.  If someone wants to help
> in this department... please do!  GBAME b4 exports map data as 8bit
> and I have no problems displaying maps from that program.

Pete's triangle raster demo (www.gbadev.org) has working irq's - that's
where I got a lot of info.  I'm pretty sure at the time I was using ARM SDT.
-Vince

-----Original Message-----
From: cupcakus2000@... [mailto:cupcakus2000@...]
Sent: Monday, October 01, 2001 9:53 AM
To: gbadev@yahoogroups.com
Subject: [gbadev] ARM SDT Interrupts


I saw a question for this using GCC C++, can someone shout out how to
set up interrupts using ARM SDT.

One thing I think I should point out is that Open tUME does also support PCX
files.. however, this is not written anywhere in the docs that it does (as
far as I could tell).

My personal choice is Open tUME.... it's a well written piece of software
that has many features builtin that work well with the GBA.      There is
Tumeric for loading maps via C code insertion, or else you can write your
own map loader that will load the map off the end of your rom.   That is
what I decided to do, and once you write a little tool to attach the maps to
the end of your ROM, and write a loader/reader, you're good to go.  The time
spent on it is well worth it... it really didn't take me that long.    Just
make sure you study the docs well in understanding the tUME format.

I hope this helps a little.

         Greg Stewart
         http://www.sparklegameco.com

Hi all,

We all know now that GBA isn't quite able of doing hardware-rendered 3D
scenes for games, as the viedo chipset is only aimed at 2D.
With software 3D rendering, one can manage to get around 50000 polygons /
second (if I can remember well the figures), which is really not enough for
a big, real 3D game.

So my question is, does anyone think it would be possible to incorporate
some kind of 3D video chipset in a cart, which would do the render of scenes
and blit it awesomely fast on the screen, for example in mode 3 or 4 ?

Let me explain.
Aperture size for cartidge is 32 Mb. So what if one uses, for example, 28 Mb
for the cartidge ROM, and the 4 last Mb would be to transmit data to what
I'd call the "3D chipset" in the "special cart" ?
As I see it, the "3D chipset" would work like this :
- On the first bytes of its address space, we have some controls (such as :
position of the camera for drawing, chipset enabled, chipset bliting etc.)
in read and / or write states.
- On the next Mbs the user would have to DMA the scene polygons data, and
then the texture data. The same data may remain for several frames
(background, wals etc.) or may be for just one frame (3D moving objects
etc.).
- The "3D chipset" would then do, when ordered (one control bit for "render"
maybe), the blitting of the resulting scene on the GBA display. The
rendering shall be made by the "3D chipset" without halting the GBA cpu (of
course).

As I don't know anything about electronics, I'm just wondering if such a
chip is only an utopia or may be madeable. What do you think about it ? Does
anything similar exist for another game system ?

Regards,

Mathieu -- The Night Howler

hey, i wanted to buy it... i tried emailing to get it but the guy never
responded

Hi everybody!
Very big thanks all for advices!
I didn't understood your advices till I disassembly ROM IRQ vector - system
code under it do everything what is needed for calling interrupt! My work is
to define NORMAL c/c++ function and set up it at $300FFFC! That's all!
This reason GBA don't need to implement any special interrupt functions!
America is discovered again! ;-))

Best regards
Jerzy Kut


----- Original Message -----
From: <DekuTree64@...>
To: <gbadev@yahoogroups.com>
Sent: Sunday, September 30, 2001 7:45 PM
Subject: [gbadev] Re: gba interrupts with c/c++


> Interrupt functions have to be in ARM, so you need ARM/Thumb GCC for
> it to work. I was using Thumb GCC (which of course has no ARM
> support, but I didn't realize that at the time) from devrs.com, and
> it didn't work, so I tried downloading DevKitAdvance (it's at devrs
> too, but I got my compiler before it was released) and everything was
> fine. Or if you're using ArmSDT, then you don't have to worry about
> everything I just said^^
>
> All you have to do is write a function that checks if the interrupt
> flag you want is set, and if so do something.
> Then do something like
> REG_INTERRUPT = (u32)IrqHandler;
> REG_IE = flags; file://where flags is the bits for the interrupts you want
> to enable (check the Mappy SDK to see which bit does what)
> REG_IME = 1;
> int your main function and it should call IrqHandler every time one
> of the interrupts set IE happens.
> Also, the handler function should set IME to 0 (to disable
> interrupts) before it does anything, to make sure your interrupt
> doesn't get interrupted^^ Be sure to set it back to 1 at the end
> though.
>
>
> --- In gbadev@y..., "Jerzy Kut" <gephard-gbadev@w...> wrote:
> > Hi!
> > Is there possible making interrupt functions ? Something like
> >
> > /**
> >  * Interrupt service.
> >  */
> > interrupt void myInteruptService() {
> >     // somebody ;-)
> >     ;
> > } // interrupt void myInterruptService()
> >
> > Normal function calling and interrupt calling is quite different...
> > Has GCC support for them ?
> >
> > Regards
> >
> > Jerzy Kut
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Hey Collin,

Thanks for the cool reply,  you really should lighten up some what, I was
only joking around, injecting a little English humour ...  :-) ... I just
find it funny that people bag on free software so much.

I hardly warrent $20 sweat fee as a commerical business ... anyways as I
don't wish to go over old ground I'll be releasing it free in the near
future for anyone who is interested & liked the interface.

Mr "not so" Selfish ....



----- Original Message -----
From: "Collin van Ginkel" <collin@...>
To: <gbadev@yahoogroups.com>
Sent: Monday, October 01, 2001 4:01 AM
Subject: Re: [gbadev] Decent Map Editor


> Hi,
>
> > Just as a tease I have many many new features in TIME now, but as $20
was
> > too much for anyone ... I ain't releasing it,  shall keep it for myself
> ...
> > Just call me Mr Selfish !!!
>
> Great attitude! We need more people like you..
>
> If you want to run a commercial business and no-one is willing to pay for
> your product you should ask yourself what's wrong and not annoy us with
this
> childish stuff.
>
> Greetings,
>
> Collin
>
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > From: <cupcakus2000@...>
> > To: <gbadev@yahoogroups.com>
> > Sent: Sunday, September 30, 2001 2:36 PM
> > Subject: [gbadev] Decent Map Editor
> >
> >
> > > Can someone point me to a decent Map editor...  Here are the problems
> > > I have with the ones I have tried...
> > >
> > > GBA Map Editor b4: This the best one I have found, but it doesn't
> > > support tile flipping.
> > >
> > > Open tUME: Runs in DOS, and wants tiles in a strange format.
> > >
> > > TIME: Exports tile data as 8bit, Map data as 16bit, I can't get
> > > anything this program generates to display.  If someone wants to help
> > > in this department... please do!  GBAME b4 exports map data as 8bit
> > > and I have no problems displaying maps from that program.
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

I saw a question for this using GCC C++, can someone shout out how to
set up interrupts using ARM SDT.

Hi there everyone :)

Is there any documentation out there for attaching peripherals to the GBA,
I know that there are things like the FM radio effort (NOT to sure how it
works - as don't have one).... but any information about this like accessing
external hardware etc, would be MOST appreciated!

Thanks in advance.
Jamie (jamie@...)

Mr Selfish,

Good for you, I hope it works well.  I've decided just to write my
own over the next few weeks, and put it up for FREE...  The volume of
free tools, source, and help from kind folks on this group is more
than enough payment to produce a usable tool for them.

The whole reason there are home GBA coders is because big N is too
commercialized to let the little man have a chance.  If we start
commercializing we will be just as bad them.

--- In gbadev@y..., "pauls" <pauls@p...> wrote:
> Just as a tease I have many many new features in TIME now, but as
$20 was
> too much for anyone ... I ain't releasing it,  shall keep it for
myself ...
> Just call me Mr Selfish !!!
>
>
>
>
>
>
> ----- Original Message -----
> From: <cupcakus2000@y...>
> To: <gbadev@y...>
> Sent: Sunday, September 30, 2001 2:36 PM
> Subject: [gbadev] Decent Map Editor
>
>
> > Can someone point me to a decent Map editor...  Here are the
problems
> > I have with the ones I have tried...
> >
> > GBA Map Editor b4: This the best one I have found, but it doesn't
> > support tile flipping.
> >
> > Open tUME: Runs in DOS, and wants tiles in a strange format.
> >
> > TIME: Exports tile data as 8bit, Map data as 16bit, I can't get
> > anything this program generates to display.  If someone wants to
help
> > in this department... please do!  GBAME b4 exports map data as
8bit
> > and I have no problems displaying maps from that program.
> >
> >
> >
> > list rules: http://www.gbadev.org/rules.txt
> > unsubscribe: gbadev-unsubscribe@y...
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >

Hi all, I'm have been using devkitadvance gcc3.0.1 (C++) - and using the
info in the Devrs FAQ on including binary in your ROM (method 4) I've had no
problems. This method will define labels for the start, end and size of the
data you've included like so.

extern const usigned char _binary_outname_ext_start [ ];
extern const unsigned char _binary_outname_ext_end [ ];
extern unsigned long _binary_outname_ext_size;

All has been well, and then over the last couple of days I've converted some
stuff to plain ANSI C and I've now noticed that the compiler, when
generating accesses to these variables puts in an extra dereference, and so
returns 0 for values of size and for the data for that matter. Mappy will
disassemble like so

	 ldr r1, [PC,32]  (#08005d8c)
	 ldr r1, [r1]

Whereas under C++ it'd generate just the one line

	 ldr r1, [PC,32]  (#08005d8c)

Has anyone else had this problem and solved it? Am I missing something
simple here?
Any help would be great.

Cheers
Aaron

Hi,

> Just as a tease I have many many new features in TIME now, but as $20 was
> too much for anyone ... I ain't releasing it,  shall keep it for myself
...
> Just call me Mr Selfish !!!

Great attitude! We need more people like you..

If you want to run a commercial business and no-one is willing to pay for
your product you should ask yourself what's wrong and not annoy us with this
childish stuff.

Greetings,

Collin

>
>
>
>
>
> ----- Original Message -----
> From: <cupcakus2000@...>
> To: <gbadev@yahoogroups.com>
> Sent: Sunday, September 30, 2001 2:36 PM
> Subject: [gbadev] Decent Map Editor
>
>
> > Can someone point me to a decent Map editor...  Here are the problems
> > I have with the ones I have tried...
> >
> > GBA Map Editor b4: This the best one I have found, but it doesn't
> > support tile flipping.
> >
> > Open tUME: Runs in DOS, and wants tiles in a strange format.
> >
> > TIME: Exports tile data as 8bit, Map data as 16bit, I can't get
> > anything this program generates to display.  If someone wants to help
> > in this department... please do!  GBAME b4 exports map data as 8bit
> > and I have no problems displaying maps from that program.

U16 = u8 | u8 << 8
Component 2 is shifted left 8 bits into the high part of the word.

- Dale


-----Original Message-----
From: Mr SDFG ASDG [mailto:cupcakus2000@...]
Sent: Sunday, 30 September 2001 12:50 AM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Stupid Mode 4


I figured it out with:
u16=u8*256+u8
There is probably a better way, like an operator that can do it, but for
the mean time the formula above works great.
  Mr SDFG ASDG <cupcakus2000@...> wrote: I have a 256 color bitmap
which I have processed into a u16 pallet array, and a u8 data array with
indexes to the pallet information.

The problem of course is that video memory only accepts writes in
16bits, so one would simply say:
"Write two pixels at once..."  I would love to! How do I combine the two
8 bit blocks of data into one 16bit block?














function makeNewWindow(url) {var newWindow = window.open(url); }
list rules: http://www.gbadev.org/rules.txt
unsubscribe: gbadev-unsubscribe@yahoogroups.com



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



---------------------------------
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone with Yahoo! by Phone.

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



Yahoo! Groups Sponsor
ADVERTISEMENT




list rules: http://www.gbadev.org/rules.txt
unsubscribe: gbadev-unsubscribe@yahoogroups.com



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