Search

[johnny9562001]

me im my brother are having an argument. he saids that the n64 has better graphics then nds, specially the game zelda ocarina of time and majoros mask.
i say that the ds has better graphics specially mariokart, metroid and the new zelda. Word?

[mrEkli]

DS has better graphics. Just look at all the games now. Also the N64 had pathetic 2D processing, didn't it?

[bitblt]

The N64 has better graphic capability . . .

CPU: 64-bit R4300i RISC (93MHz)
Co-processor: 64-bit RISC (62MHz)
RAM: 4MB (36Mb) upgradeable
Colors: 16.7 million
Polygons: 150,000 per second
Resolution: 640x480 pixels

However the N64 doesn't have two screens, a touch interface, or fit in your pocket.

The DS specs . . .

CPU: 32-bit ARM9 RISC (67MHz)
Co-processor: 32-bit ARM7 RISC (33MHz)
RAM: 4MB (36Mb) expandable
Colors: 260,000
Triangles: 120,000 per second
Resolution: 256x192 pixels for each screen

[omaemad]

im afraid you are wrong bitblt

the n64 was upgradagle to only 8mb of ram

the ds is slightly more powerful than the n64 see why:
-its has 675kb of DEDICATED vram
-16 hardware sound channels
-the ds deals with more inputs
-it has built in toon shaders and motion blur
-it operates at 60 fps if the polygon limit is below 1200 perframe (30 can be used to double pol count but requires buffering of frames)
- buitin ultra fast primitive renderer (thats why the wheels in mk are so smooth
-the ds lighting and transformation (T&L as know on pcs) are done on the hardware the nintendo 64 didnt have such capapbility and these calculations were done on the cpu not the gpu and light showed up as vertex clours

btw how can you expand the ds ram =p
n64 only operate at that res when in 8mb mode
it used to be 320x res when first games came out

[bitblt]

. . . he saids that the n64 has better graphics then nds . . . i say that the ds has better graphics specially mariokart, metroid and the new zelda.

Read the specs and the topic post, the N64 has better graphics.  Think about it omaemad, why do you think most games for DS use isometric 3D?

[bitblt]

btw how can you expand the ds ram =p

By directly mapping RAM into DS address space through the GBA port.  Nintendo will offer a RAM upgrade for the Nintendo DS web browser.

[sneef]

why do you think most games for DS use isometric 3D?

lazy coders.  

[filozof]

DS has smaller screen that's why you think it has better graphics  

[bitblt]

why do you think most games for DS use isometric 3D?

lazy coders.  

Exactly, the problem with DS and 3D performance is FLOPS.  Even with hardware integer math support, the DS is naturally weak in 3D.  I realize the DS might be able to paint a better looking 3D image, but N64 has the raw power (FPU) to pull off better/faster 3D graphics.

im afraid you are wrong bitblt

the n64 was upgradagle to only 8mb of ram

(for N64)
RAM: 4.5MB (36Mb) upgradeable
4.5MB = 36Mb

(for DS)
RAM: 4MB (32Mb) expandable
4MB = 32Mb

read this omaemad . . .
http://n64.icequake.net/mirror/www.white-tower.demon.co.uk/n64/

[omaemad]

hehe sory about that mbits typo but i still see the ds as a better desgined game oriented machine =p see why:

comparision
n64=wrestler(fat strong not very stylish or effective)
ds=kungfu fighter(smaller but lethal per blow)

enough of that here is the crunch the ds 3d system
its not just the number that count since the ds is a SCANLINE not framebuffer system which gives many advantages

your full vram can be used for all the stuff you want (n64 games needed memory expansions for higher res mode since the framebuffer (which the ds doesn’t need when doing 3d)takes a huge chunk from the unified n64 ram see this


24 bit coulor would take 6 bytes per pixel

On 640*480 res *6
=1.8 megs approx

Hehe we just wasted 1.8 megs just to render a blank screen

Now we have our friend the z buffer (on the n64)

Maybe that takes 200kb for a nice large scene zbuffer overfills result in really bad artefacts

Another plus for the ds

Ok back to the polygon count as we all know polygon counts are a pile of useless junk on standard 3d systems since “cheats can be used”

Is that 15000/s flats shaded ?
Wireframe?
Textured?
Lit?

Each one of those takes a big impact on the fps(esp the textures when rembering the n64 poor fillrate)

But on our little ds with its scanline system we can do all this for NO COST YEP 60FPS
-antialias(on poly edges)
-toonshaders
-4 hardware lights
-2048 polygons if quads are used (the n64 was very slow at quad drawing and therefore tris were used but double the polygons were needed since a square can be rendered vai 2 tris)
-textures nomatter howcomplex don’t slowdown (have to fit in the vram though

the ds also has hardware compressed textures ( which means they can remain compressed in the vram while the n64 had to keep texures full size.... thats why n64 textures where blurly (the texture filtering was hiding that they are very low res thru blurring) while the ds (see mario kart can hold high res compressed textures so high res infact the look as if the are texture filtered (even though the ds cant do that buts its a small screen so they wont show up)

Oyyeah floating point thing…… whats wrong with fixed pt? do you need precision more than .0000001 nope not really especially since the LIGHTING AND TRANSFORMATION (mentioned as t&l in my previous post)OF matrices is done on hardware for you unlike the n64 meaning better scenes on the ds with no cpu cycle costs(lighting on the n64 was done on the cpu not gpu since t&l was in its infancy backthen and not mainstream)

Phew im so tired but must carry on

Ok the ds kicks n64 butt in the 2d dept (which helps in 3d games for GUIS)
The  ds has multiple 2d layers even in 3d mode allowing nice guis at no speed loss and no frambuffer needed = less ram taken up

The n64 didn’t have the 2d layers in 3d mode meaning the 3d images where mapped to a framebuffer asscessed by the cpu then the cpu searched through all the pixels in one big framebuffer array till it found the right pixels postions to place the pixels of the gui one by one)

The ds you just copy the stuff to the mem location once of the 2d layer and its done! No frambuffer memory hogging

And built in outline + toon shaders


i used to have the same misunderstandings but dovoto cleared them up
Read this

Quote:
dovoto

Joined: 30 Dec 2002
Posts: 252
Location: Oregon
Posted: Wed Oct 19, 2005 8:12 pm    Post subject:


________________________________________
/*omaremad wrote:
opps

Btw you still have to do the bone calculations on the cpu Hardware transform means that the hardware calculates the transformation of the vertices but you still have to do stuff on the cpu to tell the vertices where to go.
*/

Is it not just draw root: rotate/translate child draw child: rotate/translate child, draw child etc...?

The DS has a very openGL (ish) pipeline which allows you to specify your rotation and scale and these get applied to the verticies as you push them in. You do not need to manual rotate and scale the verticies.

Maybe i just dont understand how boned animation works (definatly possible).
/*omaremad wrote:

Here is a question to every one . what up withe the vertex limits cant you just push it harder and get slower speeds. I mean factor 5 said the gc can do upto 15m polygons /s while nintendo said 6-12m polygons/s

and what about textured polygons they require more power so would we be allowed to draw less polygons

its so confusing!! */

DS does not render into a frame buffer (it does it per scan line, although you can direct this render into a framebuffer which is not quite the same thing) and has an internal vertex limit likely due to only being able to store so many verticies at once. This means it takes what ever verticies are loaded into video memory and renders line by line to the screen(or memory) and not poly by poly. This was how it was explained to me and it seems likely given the small amount of video memory the DS posseses.

If it were frame buffer you could just render polys till the scene was complete then move onto the next frame and pretty much ignore the refresh rate of the video hardware and get the quility vs speed trade-off you are looking for.

As far as I have been able to determin there is no effect on polygon performance due to texturing. Perhaps someone could confirm.
/*omaremad wrote:

btw
the loadmatrix4x4 function doesnt work!
*/

hmm...on hardware? I will look at this.
/*omaremad wrote:

one last thing, can the Homebrew devkit blend vertex colours with textures ?
that the way they lightmapped most games on the n64 and the metroid demo too.*/


of course..it also has 4 hardware lights that can be used (directional only).

look at this post it a summary of all what i said
http://forum.gbadev.org/viewtopic.php?t=6665&highlight=vertex+limit

TAKE THAT

[omaemad]

MUST ADD MORE

ok look at nintendgogs ( dolls and balls) have physics better than on the n64 (dolls incorporate ragdoll physics) and see nfsu2 its physics are pretty decent too

i never seen physics that good on a n64...... so floats dont matter unless you want really high accracy =p

clock speeds dont really indicate anything

[sneef]

clock speeds dont really indicate anything

I Second that!!!  as I've said before, it's almost pointless to use clock speeds to compare different systems.

[omaemad]

i was reading the spec sheets and i saw this 4 the n64


# Hardware Anti-aliasing
# Hardware Texture Mapping (32x32 pixel texture maps)
# Tri-Linear filtered MIP Mapping

32x32 textures that is pretty small

in the homwbrew ds games we can display upto

// size bits
#define TEXTURE_SIZE_8     0
#define TEXTURE_SIZE_16    1
#define TEXTURE_SIZE_32    2
#define TEXTURE_SIZE_64    3
#define TEXTURE_SIZE_128   4
#define TEXTURE_SIZE_256   5
#define TEXTURE_SIZE_512   6
#define TEXTURE_SIZE_1024  7

[bitblt]

TAKE THAT

:lol:

Well, Dovoto is going to be a tough act to follow.

Dovoto's explanation is not black and white.  Yes, the DS is more efficient with 2D.  I will agree the DS has a more modern rendering pipeline with hardware T&L and pixel shaders.  However, when you benchmark your PC for 3D graphics performance do you only measure how pretty the picture is? No.  To measure 3D graphics performance the entire system must be taken into account, including CPU and FPU performance.  Why?  Because we want to render complex 3D worlds with high polygon count, and we want these worlds to be dynamic.  What happens to DS performance when we apply transformations to our polygon list, like walking through a 3D world?  The DS will sweat and groan even with fixed point math, look-up tables, BSP trees, and hardware assisted polygon rendering.  The N64 can also benefit from these code optimizations, but N64 will do so at a higher clock rate, and with 64bit bandwidth.

Btw you still have to do the bone calculations on the cpu Hardware transform means that the hardware calculates the transformation of the vertices but you still have to do stuff on the cpu to tell the vertices where to go.

Exactly.  Again, I realize the DS might be able to paint a better looking 3D image, but N64 has the raw power (and FPU) to pull off better/faster more complex 3D graphics.

Let us compare Zelda DS with Zelda N64 and let Nintendo experts show us by example what platform has better 3D graphics performance.  :wink:

[scootdog]

Word?

Word Up ! :lol: