What's the reason for the fixed limit on polys/scene in the DS?

[Guden Oden]

Is it perhaps some fixed buffer size in the hardware itself, for example to hold the display list of draw commands, or of vertices to be transformed or such?

What's a good site on the lo-down on the hardware in the DS anyway? I read the 2D engine(s) in the machine are even more capable than the ones in the GBA (which in turn is more capable than SNES's); what are the exact differences? Anyone know?

I seem to recall there's some kind of maths co-processor in the DS, or at least T&L processor... Is it a hardwired device, or can it do skinning and such too? If not, do either of the CPUs in the DS have a FPU to handle such matters, or is it all done with fixed point?

 

[Teasy]

DS's GPU has a programmable matrix processor. So its T&L is reasonably flexible (more so then Flippers for instance). The polygon display limit I believe is per scanline, around 120,000 for the whole frame. However its a display limit not a transform or setup limit so with a peak transform rate of 4 million polygons per second there should be a lot of scope for more complex polygons and scene's with heavy overdraw (if the fillrate can take it that is).

 

[Corwin_B]

If not, do either of the CPUs in the DS have a FPU to handle such matters, or is it all done with fixed point?

The T&L unit is fixed point, IIRC.

 

[darkblu]

The T&L unit is fixed point, IIRC.

indeed.

 

[Guden Oden]

Thanks guys, but what about my other questions?

Oh, also, can the DS's 3D hardware do alpha blending? I don't own one (yet), so I've no idea...

 

[Rolf N]

Is it perhaps some fixed buffer size in the hardware itself, for example to hold the display list of draw commands, or of vertices to be transformed or such?

Maybe it's just that 4MB (plus a few kBs extra here and there) of RAM isn't enough for really complex scenes in real-world games? Who knows

What's a good site on the lo-down on the hardware in the DS anyway?

Now that's a good question ...
This one is pleasant to read, but incomplete in many areas.
DSTek is more complete but awfully formatted IMO.

Neither give you real tutorials nor comprehensive example code though.

If you're not just poking around for information but rather intend to start doing stuff with the machine, it might actually be easier to sign up with Nintendo to get the official stuff.

I read the 2D engine(s) in the machine are even more capable than the ones in the GBA (which in turn is more capable than SNES's); what are the exact differences? Anyone know?

It has more (simultaneous) and larger rotate/scale backgrounds. AFAICS sprite support appears to be roughly the same. The "big" difference is that the NDS supports single-bit transparency between background layers, and also between sprites, by virtue of that previously unused sixteenth bit in the palette entries.

But don't rely on me too much, I'm more of a sound guy currently, and haven't really come to grips with the DS yet anyway.

I seem to recall there's some kind of maths co-processor in the DS, or at least T&L processor... Is it a hardwired device, or can it do skinning and such too? If not, do either of the CPUs in the DS have a FPU to handle such matters, or is it all done with fixed point?

As the others have said it's fixed point.
Re "coprocessors", there is actually some machinery in place for division, reciprocals and square roots. But it's really just poking input values into hardware registers and picking up the results some amount of cycles later.
(the two ARM CPUs there lack any division support)

 

[Guden Oden]

Maybe it's just that 4MB (plus a few kBs extra here and there) of RAM isn't enough for really complex scenes in real-world games? Who knows

Hehe, yeah, there's that hard limit. Still, 4MB is more than enough to hold enough polys to fill the DS's display list limit (or wherever the barrier resides).

I wonder where that 3D core comes from anyway, is it a gutted and cost-reduced Reality Engine (though improved in some ways too I might add, seeing as it seems to allow 1k*1k pixel textures), or is it something custom Nintendo cooked up themselves, or did they buy a custom or off the shelf design from some 3rd party?

Neither give you real tutorials nor comprehensive example code though.

Doesn't really matter to me because unfortunately I can't program anything more complex than the simplest VB you can imagine lol...

I was hoping there was something in plain text, as I recall, the ZSNES emulator (or was it SNES9x?) includes - or did in the past anyway - a really thorough description of pretty much the entire SNES hardware, including explanations of HDMA and all kinds of techy stuff.

Something similar for the DS would have been awesome, but of course that is a huge amount of work, and I guess not all aspects of the hardware are known either. Hell, SNES is rougly 15 years old now and still has enough timing quirks and such to cause some games to glitch. Or well, used to anyway last time I kept myself up to date of the SNES emu scene anyway.

If you're not just poking around for information but rather intend to start doing stuff with the machine, it might actually be easier to sign up with Nintendo to get the official stuff.

Ha ha, um, and how much money don't they want to have for that then? Then again, a full DS SDK is "almost" affordable, though I somehow doubt they'd sell them to just anyone.

It has more (simultaneous) and larger rotate/scale backgrounds. AFAICS sprite support appears to be roughly the same.

Hm, both DS and GBA "only" support a max of 4 hardware backgrounds, just like SNES, though I do know GBA does have 2 layers of mode 7 rather than just 1... Not sure if DS increases that or not. Then again, DS can have one 3D background along with 2 or maybe even 3 2D layers it seems, so it could just draw extra parallaxed layers with its 3D engine if neccessary. Then again, I guess you could get enough layers with just plain ol sprites and raster trickery, but it's a cool idea... Heh.

DS does have zoom and rotation for sprites, yes? GBA too? The docs you linked to seemed to say that is the case, but either they were a bit fuzzy on the subject or I'm not enough of a programmer to understand them, heh.

The "big" difference is that the NDS supports single-bit transparency between background layers, and also between sprites

What does that mean though? Even SNES supported several forms of transparency, but this must be something else I guess.

Re "coprocessors", there is actually some machinery in place for division, reciprocals and square roots. But it's really just poking input values into hardware registers and picking up the results some amount of cycles later.

That's cool!

The ol' Amiga CD32 bastard thingy actually had a somewhat similar feature... Or well, not really. It was just a thing shoehorned in sideways, where you wrote 16 pixels in "chunky" format to a register, it spat out the same data but in bitplane format instead at the other end for display by the quirky Amiga graphics hardware. "Chunky" pixels of course being much faster to manipulate for creating software rendered 3D graphics, while bitplanes were more suited for older (even at the time, hah!) 2D stuff...

Thanks for your reply!

 

[Grumpy]

while bitplanes were more suited for older (even at the time, hah!) 2D stuff...

I wouldn't say "more suited", but rather a more memory-efficient way to represent graphics when the bit-depth was low, and therefore something the coders just had to live with.

 

[Rolf N]

I wonder where that 3D core comes from anyway, is it a gutted and cost-reduced Reality Engine (though improved in some ways too I might add, seeing as it seems to allow 1k*1k pixel textures), or is it something custom Nintendo cooked up themselves, or did they buy a custom or off the shelf design from some 3rd party?

No idea really if it was based off of the N64, or what that would mean anyway, if true
I'd just like to say that it appears to me that Nintendo develops these things themselves, because otherwise I'd bet that someone, somewhere, would be spewing press releases about how they partnered up with Nintendo for the 3D core. That has happened with the GameCube as we all know, but AFAIK it never happened for the N64 nor the DS.

Doesn't really matter to me because unfortunately I can't program anything more complex than the simplest VB you can imagine lol...

Oh my ... then your posts make you appear to be much more of a programmer than you really are
It's not "wrong" at all of course, but I find it unusual that someone who isn't really a programmer would be so interested in detailed machine specs.

I was hoping there was something in plain text, as I recall, the ZSNES emulator (or was it SNES9x?) includes - or did in the past anyway - a really thorough description of pretty much the entire SNES hardware, including explanations of HDMA and all kinds of techy stuff.

The DS is not well documented publically. It's still somewhat of a frontier for the homebrew folks. Of course there are some homebrew programs out there, but to me they don't look like they push the machine much at all yet (as they do on the GBA). In fact I believe that most of the things that already do work are "ported" over from the GBA. If you take random GBA code and throw it onto the DS there is a reasonable chance that it works okay, because many of the hardware registers behave the same, and are in the same places. The last few percent could be achieved by simple cargo-cult fixing.

This might explain why it's so hard to find any DS homebrew program with 3D graphics.

Ha ha, um, and how much money don't they want to have for that then? Then again, a full DS SDK is "almost" affordable, though I somehow doubt they'd sell them to just anyone.

Money isn't much of a problem. However, now that you reveiled yourself, I have doubts they'll let you in
They'll basically review your company to judge the chance that you'll be able to make a quality game. Ie you must demonstrate financial stability, sufficient coverage of sound/graphics/code/design/art roles, game industry experience, successful published games are a huge plus obviously, etc. This is all public. Here.

Hm, both DS and GBA "only" support a max of 4 hardware backgrounds, just like SNES, though I do know GBA does have 2 layers of mode 7 rather than just 1... Not sure if DS increases that or not. Then again, DS can have one 3D background along with 2 or maybe even 3 2D layers it seems, so it could just draw extra parallaxed layers with its 3D engine if neccessary. Then again, I guess you could get enough layers with just plain ol sprites and raster trickery, but it's a cool idea... Heh.

DS does have zoom and rotation for sprites, yes? GBA too? The docs you linked to seemed to say that is the case, but either they were a bit fuzzy on the subject or I'm not enough of a programmer to understand them, heh.

What does that mean though? Even SNES supported several forms of transparency, but this must be something else I guess.

Scale/rotate "backgrounds" are fully opaque on the GBA. You can have two, but you can't have them on the screen at the same time, as they're inherently full-screen. You can scissor them into rectangular regions AFAIK, so you can e.g. have a "ground" layer and a "sky layer", but if that's not what you want the second one appears to be pointless.
(in fact if you want ground and sky, which is a perfectly horizontal division, you can just hack the appropriate registers when the center of the screen is scanned out. For this you need only one scale/rotate background)
(still take note that I'm more of a sound guy ...)

That's why I think the transparency is so important. It makes the additional rotate/scale bg capability much more useful. Now you can layer them on top of another, with independent parameters, and you can give them arbitrary (non-plane-like) shapes, a proper silhouette.

The GBA supported transparency only between a sprite and the background. Not between two overlapping backgrounds (backgrounds, by definition, always overlap anyway), and not between two overlapping sprites: in transparent pixels of the "first" sprite, the background pixels are visible, totally irrespective of the color of the "second" sprite.

The DS "fixes" all of this.

And finally, yes, the GBA can rotate/scale sprites. There are certainly some problems and limitations with that, and I don't know them right now, but I'm 100% sure that it is at least possible.

 

[see colon]

I'd just like to say that it appears to me that Nintendo develops these things themselves, because otherwise I'd bet that someone, somewhere, would be spewing press releases about how they partnered up with Nintendo for the 3D core. That has happened with the GameCube as we all know, but AFAIK it never happened for the N64 nor the DS.

with the N64 there was much press about SGI designing the graphics part, and some press about rambus supplying the memory.

 

[Guden Oden]

...And MIPS doing the CPU.

Frankly, I don't think there was much Nintendo did themselves in that thing except design the casing and the controller... Possibly draw up specs for the serial controller ports and the cartridge/expansion slots.

Anyway, thanks a lot for the infos you've given, Zecken!

As for transparency on the Mode7 playfields, GBA did have colorkey ability at least, because in F-Zero there's two layers stacked with "city landscape" and the top has openings down through to the bottom one. There's no real alpha transparency, just 'stippling'. Maybe that's what DS hardware adds?

 

[Fox5]

I'm assuming the graphics engines are integrated into the arm9 and arm7 cores, so just check who manufactures the chips. IIRC, it's not well known who made the GBA's video hardware either, other than that it's pretty similar to the SNES's. (which was Sony I believe?)

I'd place a guess on it being made by Samsung or Texas Instruments, but the GBA's 2d part was pretty powerful yet never found its way into any cellphones where it could have been put to good use.

Who designed the NES's graphics? The original Gameboy? I think both were Nintendo modifications of widely available hardware, back at a time when practically any company could design a graphics processor. The DS's graphics processor is probably a bit complex for a homegrown Nintendo team to have done though.

 

[ninzel]

When you guy's look at the feature set they gave the DS over the GBA, does that bode well for what the Wii VPU might have over the GC? I keep hearing that the Wii VPU will just be faster that's all.

 

[Guden Oden]

I'm assuming the graphics engines are integrated into the arm9 and arm7 cores, so just check who manufactures the chips.

Both CPUs and both 2D processors are located on the same die. They're obviously not located INSIDE the CPU cores though, that'd been pointless and weird.

IIRC, it's not well known who made the GBA's video hardware either

Nintendo in-house. It's just mildly tweaked SNES hardware anyway...

similar to the SNES's. (which was Sony I believe?)

Sony only did the sound chips in SNES.

Who designed the NES's graphics? The original Gameboy?

Definitely Nintendo in-house for both. Gumpei Yokoi (and likely colleagues) designed the GB for sure, and I think he worked on the NES hardware too.

...Which for the time was pretty damn radical actually. The NES CPU and PPU are both highly integrated devices for the time, CPU features the CPU core itself, timers, sound hardware and SRAM all on the same chip.

 

[Rolf N]

When you guy's look at the feature set they gave the DS over the GBA, does that bode well for what the Wii VPU might have over the GC? I keep hearing that the Wii VPU will just be faster that's all.

I don't think anyone can say for sure, and to not be hugely disappointed we should not expect a totally new chip, also taking into account the various hints towards it being just a faster GameCube overall ... but ... in a way, yes.

If the Wii graphics hardware is to the GameCube's as the DS's is to the GBA's, it could be a pleasant explanation for those "pessimistic" statements.

Like this: the DS graphics core is almost backwards compatible to the GBA graphics core at the hardware level. All the old hardware registers are still there, at the same addresses, and if you access them like you would on a GBA, basically the same things happen. The new functionality in the DS graphics core (which is significant, I might add) exists as an extension alongside the old functionality.

If the same thing is true for the Wii hardware, people with early access to the early kits might just have thrown their GameCube software onto the kits, and as they found that it still runs they might have believed that there are no changes, there is no new functionality, while in reality there are new things and they just don't know about them yet.

To be clear, I'm only speculating, trying to answer the question. I have absolutely no idea if the hardware was really improved.

 

[Rolf N]

I'm assuming the graphics engines are integrated into the arm9 and arm7 cores, so just check who manufactures the chips. IIRC, it's not well known who made the GBA's video hardware either, other than that it's pretty similar to the SNES's. (which was Sony I believe?)

I'd place a guess on it being made by Samsung or Texas Instruments, but the GBA's 2d part was pretty powerful yet never found its way into any cellphones where it could have been put to good use.

I don't think the CPU tells you anything about the origins of the other hardware.
ARM cores are soft IP. Anyone can license them, integrate arbitrary other stuff and manufacture the resulting SoC. E.g. Intel does, TI does, Samsung does, and so do lots of other companies. It's targetted for embedded devices, so this license model is the only one that makes sense really.

ARM provides just the core, and they won't stand in your way if you add ... whatever you want, for your specific SoC. You can totally roll your own graphics (or license other soft IP, such as a PowerVR core).

 

[Fafalada]

I wonder where that 3D core comes from anyway, is it a gutted and cost-reduced Reality Engine (though improved in some ways too I might add, seeing as it seems to allow 1k*1k pixel textures), or is it something custom Nintendo cooked up themselves, or did they buy a custom or off the shelf design from some 3rd party?

It's got pretty much nothing in common with N64 on that side - and the 3d part is far too weird to be anything but a completely custom design.
It does a number of things completely different then any "normal" rasterizer - but at the same time it supports a number of very modern GPU features. And it doesn't end there - there's texture compression which again - is quite different from the approaches that have been common for past 10 years. Actually I'd love to hear Simon's take on this one - since it's still VQ based approach, but with a pretty strange spin on it.

Anyway the whole architecture feels very oldschool and Saturn like (dual CPUs, dual blitters, segmented memory with a bazillion of memory banks etc.), so I think it's pretty safe to say it's highly customized.
But hey, it also follows modern trends - since it's SoC design, that makes it a multicore CPU too

 

[Guden Oden]

Thanks Faf, brilliant post as usual.

Can you say something about what it is the DS does that is so quirky compared to other stuff? Is it just different, or is it cumbersome, poorly designed or stuff like that? You mention Saturn, hee hee... Would this 'differentness' indicate Nintendo itself designed the 3D hardware, and it became 'different' because they don't have any real experience dealing with 3D?

Or is it different because maybe it tries to save as much on transistors to give as small a chip as possible while maintaining a decent performance level?

Dual *blitters* in the DS? I was unaware it had even one! I thought it was plain hardware sprites and playfields, with no blitting abilities whatsoever. Well, other than perhaps some simple DMA mechanism that probably's limited to transferring data from the cartridge interface and into main memory...

Many questions, I know. Sorry.

 

[Squeak]

It's got pretty much nothing in common with N64 on that side - and the 3d part is far too weird to be anything but a completely custom design.
It does a number of things completely different then any "normal" rasterizer - but at the same time it supports a number of very modern GPU features. And it doesn't end there - there's texture compression which again - is quite different from the approaches that have been common for past 10 years. Actually I'd love to hear Simon's take on this one - since it's still VQ based approach, but with a pretty strange spin on it.

Anyway the whole architecture feels very oldschool and Saturn like (dual CPUs, dual blitters, segmented memory with a bazillion of memory banks etc.), so I think it's pretty safe to say it's highly customized.
But hey, it also follows modern trends - since it's SoC design, that makes it a multicore CPU too

C'mon, if you are going to spill the beans do it properly, don't tease us like that. That's just plain cruel!
For example:
What kind of blending does is support (if any)?
What are those modern features you speak of?
The texture compression is not just plain palette textures?
How the feck is that perspective correction done?

 

[Darkon]

It's got pretty much nothing in common with N64 on that side - and the 3d part is far too weird to be anything but a completely custom design.
It does a number of things completely different then any "normal" rasterizer - but at the same time it supports a number of very modern GPU features. And it doesn't end there - there's texture compression which again - is quite different from the approaches that have been common for past 10 years. Actually I'd love to hear Simon's take on this one - since it's still VQ based approach, but with a pretty strange spin on it.

Anyway the whole architecture feels very oldschool and Saturn like (dual CPUs, dual blitters, segmented memory with a bazillion of memory banks etc.), so I think it's pretty safe to say it's highly customized.
But hey, it also follows modern trends - since it's SoC design, that makes it a multicore CPU too

Like what ?