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/