#30171 - phantom-inker - Mon Nov 29, 2004 4:01 am
I have attempted to use what little information is known about the DS to determine some useful details about its graphics capabilities. I have based my theories below partially on what can be observed while using a DS, partially on the leaked register list, and partially on my own knowledge of how 3-D rendering works (in the late 1990s, I worked for a now-defunct game company, as the lead programmer building a 3-D software rendering engine).
Much of what you read here is speculation, since no official specifications are known. However, it is an attempt at good speculation: I will do my best to state to what degree a statement is fact or fiction.
Because I have a somewhat unordered mind, the various thoughts below are also fairly unordered. I've assigned them numbers only so that they may be more easily referenced in the ensuing discussion.
- Both screens on the DS have resolution of 256x192 pixels (larger than 240x160), and their data appears to be stored separately in VRAM.
- The DISPCNT register appears to have been extended to 32 bits and controls both screens. The screens appear to rendered in lockstep (always on the same scan line together), because there is only one DISPSTAT and one VCOUNT register.
- The upper half of DISPCNT appears to mirror the lower half in many ways; this suggests that the MODE field is comparable to the BGMODE field, and that each controls one screen separately, or something like it. That the MODE field is 2 bits while BGMODE is 3 suggests that whatever is controlled by MODE is less flexible than what is controlled by BGMODE.
- The BG02D3D field of DISPCNT can be toggled to turn on 3D for BG0. This necessarily implies that hardware 3D can only be performed when the display is set to a "tiled" mode --- likely only GBA modes 0 and 1, with all their abilities and limitations.
- There is only one set of window bits; this implies that the window feature may only be used on one screen at a time.
- The hardware does not seem to use a frame buffer to store the rendering output (claimed by the DS Wiki). If there is no frame buffer, this necessarily implies that like the tiled modes on the GBA, and unlike most polygon hardware, you may not alter pixels after the frame rendering is complete. Oddly, if there is no frame buffer, this suggests that either all polygons are being rendered in parallel, or that there is a maximum limit to the number of polygons that may appear on a single scan-line. If the latter is true, it may necessitate some "unusual" programming tactics.
- The hardware appears to render full polygons, likely limited to triangles (or possibly planar convex quadrilaterals?). It does not appear to require separate programming per-scan-line or to render scan-line-aligned quads. Polygons appear to be multiplied by a camera matrix, perspective-transformed, and clipped before rendering, entirely by the hardware --- none of these operations need be performed in software.
- Because the hardware does not seem to use a frame buffer to store rendering output, it appears that, as with tiled modes on the GBA, you must fully construct your frame's layout a priori, and provide it to the DS polygon renderer during the vertical blanking interval. This hypothesis is reinforced by the existence of the LISTRAM_COUNT and VTXRAM_COUNT registers, which most likely exist to tell the hardware how many polygons and vertices, respectively, are to be rendered in the next frame.
- That each of LISTRAM_COUNT and VTXRAM_COUNT are 12 bits long necessarily implies that you may have a maximum of 4095 polygons sharing a maximum of 4095 vertices, per frame. Nintendo advertises 120,000 polygons per second, which is 2000 polygons per 1/60 of a second --- 2000 polygons per frame. A limit of 4095 polygons per frame suggests that the hardware was designed to be just capable enough to render a full load of polygons every 1/30 of a second.
- Is polygon data provided via VRAM or via registers? The jury's still out on this, but given the existence of registers like TEXCOORD and VTX_XY, and a lack of dedicated VRAM for polygon structures, it appears that you must provide your polygon details via registers, not via VRAM. However, this counters the notion that LISTRAM_COUNT and VTXRAM_COUNT are used for telling the hardware how many polygons you want rendered. So it's hard to say on this one, and most likely, the answer is a mix of both registers and VRAM.
- Most scenes in 3-D games have overdraw between 1.5 and 3.0 (overdraw is a measurement of how many times each pixel is drawn, on average). This suggests that, given a maximum of 2000 polygons per frame, you may practically have at most 600-1300 polygons per scene. A pixel fill rate of 30,000,000 pixels per second implies a maximum practical overdraw of 13.0 (=30000000/60/(240*160)).
- The built-in division hardware appears to have fairly straightforward behavior. Load the 64-bit numerator into DIV_NUMER_L and DIV_NUMER_H; load the 32-bit denominator into DIV_DENOM; set DIVCNT to 1, 2, or 3 depending on what kind of division you want performed (division, modulus, or both, possibly not in that order); and read DIVCNT until bit 15 becomes 0. When it does, your 32-bit result(s) are in DIV_RESULT and/or DIVREM_RESULT. Square-root is likely performed similarly.
- The built-in vector-matrix hardware appears to be very low precision. This is borne out by the behavior of the hardware in real games: The polygons appear to jitter slightly as the camera moves in Mario 64 DS, for example (though the jitter is not as bad as that of a PlayStation 1, which used integer rounding everywhere). Polygon vertices appear to have a variety of available formats, but appear mostly to be signed 3.6 fixed-point numbers --- thus ranging from -8.0 to +8.0, with approximately one and a half digits after the decimal point. 8 bits of precision is just barely enough precision for the resolution of the display, which explains the occasional endpoint jitter of polygons in the available games.
- Camera transform matrices appear to have a limited stack available, either 16 or 32 levels deep (see size of index field in MTX_STORE and MTX_RESTORE registers). There appears to be only one matrix in use at any given time. If this is true, implementing the multi-matrix model of OpenGL could be a project and a half.
- Registers whose meaning would be very strongly worth knowing: DISP3DCNT, RDLINES_COUNT, GFXFIFO, POLYGON_ATTR, TEXIMAGE_PARAM, GXSTAT, and LISTRAM_COUNT and VTXRAM_COUNT. Each of these registers is either a control register with many fields or a count of some attribute of the 3-D hardware's state. I suspect a detailed knowledge of these mere eight registers would explain the complete behavior of most of the 3-D hardware, and I would put them at the top of the list for future analysis.
References: Leaked DS Register List; DS Wiki; Korth's GBATek
In short: It appears that the DS, at least from a video perspective, is approximately what you'd get if you took two GBAs, physically glued them together, allowed them to share some of their RAM, and allowed one of them to display some 3-D polygons instead of one background in its tiled modes.
Well... those are my thoughts on what I see. Anyone else care to comment, or fill in details I might've missed?
_________________
Do you suppose if I put a signature here, anyone would read it? No? I didn't think so either.
#30174 - benjamin - Mon Nov 29, 2004 4:17 am
Good breakdown. The overall crux of your thoughts suggests that 3D is done completely via hardware, through registers and RAM.
Given that, I am wondering why there seems to be rumblings on #dsdev and even on this forum that the 3D is being done using a software layer (either a linked lib or a library that's in the DS' ROM).
I am not sure where that rumor came from or what its basis is in, but given the register leaks and the points you've made, I find it highly dubious.
Truthfully I am more concerned with how sound will be done on the DS homebrew, but still this is a pretty good breakdown.
#30175 - phantom-inker - Mon Nov 29, 2004 4:30 am
Thanks. That said, I do have one oops up there, which is claiming the video resolution is 240x160 like the GBA. This is wrong; multiple sources (Nintendo included) confirm that both screens are natively 256x192, rendered in 18-bit color.
_________________
Do you suppose if I put a signature here, anyone would read it? No? I didn't think so either.
#30176 - benjamin - Mon Nov 29, 2004 4:33 am
Speaking of 18bit color, has there been any conclusion on why the screen has 18bits of color but the VRAM has 15bits? At least that is what I remember hearing recently.
#30178 - phantom-inker - Mon Nov 29, 2004 4:37 am
The most likely rationale for this is to have reasonable support for alpha effects, including transparency and fog. Those ideally require more precision than the colors are natively stored at; alpha in 15 bits looks very, very ugly.
_________________
Do you suppose if I put a signature here, anyone would read it? No? I didn't think so either.
#30182 - rapso - Mon Nov 29, 2004 5:23 am
| phantom-inker wrote: |
| The most likely rationale for this is to have reasonable support for alpha effects, including transparency and fog. Those ideally require more precision than the colors are natively stored at; alpha in 15 bits looks very, very ugly. |
but the blending is done in the vram, so you've still just 16bit.
but maybe the DS is doing some kind of hardware dithering like the Voodoo from 3DFx did (they called it 18bit rendering)
greets
rapso
#30189 - Abscissa - Mon Nov 29, 2004 8:30 am
| rapso wrote: |
| but maybe the DS is doing some kind of hardware dithering like the Voodoo from 3DFx did (they called it 18bit rendering) |
I think the N64 did that too. On certain parts of certain games (like Starfox 64) you could see some dithering-looking stuff, generally when there's some kind of blending going on, like fog.
#30194 - phantom-inker - Mon Nov 29, 2004 10:52 am
| rapso wrote: |
| but the blending is done in the vram, so you've still just 16bit. |
Do you have proof of this? If there is no framebuffer, as the DS Wiki claims, then there is nowhere in VRAM to perform the blending because if there were a place, it would be a framebuffer. If there is no framebuffer, then the surface pixels from the polygons are likely promoted to 18 bits before being combined together (using Z-ordering and alpha) and then altered by the fog.
Rendering the polygons without a framebuffer is decidedly an unusual way to design the video hardware, but in many ways, it's very similar to how the GBA handles sprites (objects). Sprites can be considered mini-polygons, with identical Z-orders across all their pixels, and the Z-orders are defined solely by the sprite's index. From that perspective, the GBA sprite hardware is actually a polygon renderer that supports up to 128 polygons per frame, without using any (visible) external buffers for mixing. Going from 128 to 4096 is a fairly significant jump (32 times larger), but not beyond reason. And thus once the data is not constrained by the size of bytes in VRAM, it can be any intermediate size you want.
_________________
Do you suppose if I put a signature here, anyone would read it? No? I didn't think so either.
#30196 - rapso - Mon Nov 29, 2004 11:26 am
| Quote: |
LCDC VRAM: 0x06800000 - 0x068A0000
|
that is the place you store the frame... I'd call it framebuffer ;)
but 18bit are an odd number for computer-graphics. maybe the lcd supports it, but there are a lot of handys that have 18bit displays and have just 16bit vram.
maybe it's just easier to produce 18bit displaces than 16 or 15 bit.
greets
rapso
#30200 - ector - Mon Nov 29, 2004 12:02 pm
Just a small correction: Your info on the screen resolutions is wrong. The screens are both 256x192.
#30201 - rapso - Mon Nov 29, 2004 12:32 pm
| phantom-inker wrote: |
| Thanks. That said, I do have one oops up there, which is claiming the video resolution is 240x160 like the GBA. This is wrong; multiple sources (Nintendo included) confirm that both screens are natively 256x192, rendered in 18-bit color. |
#30202 - phantom-inker - Mon Nov 29, 2004 1:08 pm
| rapso wrote: |
| Quote: |
LCDC VRAM: 0x06800000 - 0x068A0000
|
that is the place you store the frame... I'd call it framebuffer ;)
|
I wouldn't be so sure. The leaked DS specs say pretty plainly that there's:
- Main memory: 4 megabytes (in debugger systems, 8 megabytes)
- ARM9/ARM7 shared: 32 kilobytes (16 kilobytes x 2)
- ARM7 internal work RAM: 64 kilobytes
- VRAM: 656 kilobytes
Now compare those numbers to the DS memory map on the register list, which I've reproduced below:
| Code: |
ITCM: 0x01ff8000 - 0x01ffffff (32K)
Main memory: 0x02000000 - 0x02400000 (4M)
Main ext: 0x02000000 - 0x02800000 (4M)
WRAM: 0x037f8000 - 0x037fffff (32K)
I/O regs: 0x04000000 - 0x05000000
BG Palette: 0x05000000 - 0x05000200 (0.5K)
OBJ Pal: 0x05000200 - 0x05000400 (0.5K)
DB BG Pal: 0x05000400 - 0x05000600 (0.5K)
DB OBJ Pal: 0x05000600 - 0x05000800 (0.5K)
BG VRAM: 0x06000000 - 0x06080000 (512K)
DB BG VRAM: 0x06200000 - 0x06220000 (128K)
OBJ VRAM: 0x06400000 - 0x06440000 (256K)
DB OBJ VRAM: 0x06600000 - 0x06620000 (128K)
LCDC VRAM: 0x06800000 - 0x068A0000 (640K)
OAM: 0x07000000 - 0x07000400 (1K)
DB OAM: 0x07000400 - 0x07000800 (1K)
Cart ROM: 0x08000000 - 0x0A000000
Cart RAM: 0x0A000000 - 0x0A010000 (64K)
|
Now, the question is, how do you add up the memory sections shown above to arrive at the reported 656K of VRAM? Fact is... you can't. (Go ahead, try! :P) Thus there's either a gross discrepancy in the numbers (possible, but not likely), or there's a memory mapper at work (very likely). I'd say it's very likely that among the registers we haven't seen, there are probably memory-map registers.
So what does all this have to do with the LCDC VRAM? Simple: It means that all bets are off when it comes to VRAM allocation. We have no solid guarantees of any kind right now that VRAM is allocated in any predictable fashion. The best we have to go on is this data, collected by Chris Auby (possibly from someone else?), and repeated in the DS Wiki, that says very plainly "3d renders directly to lcd, no framebuffer."
This is also backed up by the LISTRAM_COUNT and VTXRAM_COUNT registers, which appear to count polygons and vertices. Why have registers to count them if the polygons can be rendered individually into a framebuffer? Normally, if you have a framebuffer, you can simplify the hardware by making it only render one polygon at a time; so why go to the extra effort to handle multiple polygons if you don't need to?
So if you have other solid evidence to suggest otherwise, I'd still claim that there is no framebuffer backing the 3-D rendering.
_________________
Do you suppose if I put a signature here, anyone would read it? No? I didn't think so either.
#30860 - EaDS Milliways - Sun Dec 05, 2004 5:08 pm
| phantom-inker wrote: |
there is a maximum limit to the number of polygons that may appear on a single scan-line. If the latter is true, it may necessitate some "unusual" programming tactics.
|
You know, I've seen something that I thought looked like the same kinda thing you'd see on the Genesis and NES when you got too many sprites on the same scanline. If what I've seen in SM64DS is what this is, how big of an impact do you think this will be for 3D games on the DS? I mean, if your characters have to be low poly just to make sure you don't have too many polys on the same line instead of on the screen, will that limit the amount that can be done with it?
#30863 - mymateo - Sun Dec 05, 2004 6:18 pm
It wouldn't surprise me if two of the tactics to avoid complications are:
1) Clipping -- Don't draw the polys you can't see and there'll inheritantly be less per line -- I think the DS does this in hardware automatically
2) "Black&White" zooming -- The closer the object, the more polys -- the farther the object, the fewer the polys.
The thing with #2 is that you have to be creative with your textures if you want to hide the fact you're changing the polys, and it still doesn't guarantee there's less polys per line.
Any other ideas? :)
#30869 - tepples - Sun Dec 05, 2004 6:48 pm
| mymateo wrote: |
| 2) "Black&White" zooming -- The closer the object, the more polys -- the farther the object, the fewer the polys. |
It's likely that DS games implement this technique of storing models at various levels of detail and switching among them based on distance from the camera. Even the N64 promotional video distributed to Nintendo Power subscribers mentioned the N64's LoD management.
Sprite dropout/flicker was never as bad on the Genesis as it was on the NES, as the Genesis had roughly the same sprite processing power as the Super NES (1x overdraw in both cases, 320 pixels/line for Genesis or 256 for Super NES). The GBA has roughly 4x overdraw for unscaled sprites (954 pixels/line on 240 pixel screen) even with CPU access to OAM during hblank turned on (as enabled in DISPCNT), so one could almost tell where Nintendo was headed with the architecture.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#30877 - phantom-inker - Sun Dec 05, 2004 7:50 pm
| tepples wrote: |
| The GBA has roughly 4x overdraw for unscaled sprites (954 pixels/line on 240 pixel screen) even with CPU access to OAM during hblank turned on (as enabled in DISPCNT), so one could almost tell where Nintendo was headed with the architecture. |
These were my thoughts exactly. That Nintendo chose to set up the GBA to allow nearly 4x sprite overdraw was, in my opinion, rather unusual, but it does strongly suggest that they prefer to perform graphics computations at scan-time rather than in a pre-built buffer. It would not be surprising if the DS followed suit on this, and if it did, that does have certain obvious consequences for your game's design:
Down side: Polygons must be carefully counted; certain "buffer tricks" simply aren't doable; implementing an OpenGL-compatible layer will be fairly difficult, and some gl() functions simply won't work; and, as with the GBA, the setup still must be performed in the vertical blanking interval (of course, this could be as easy as feeding out the polygon list you built during the previous frame(s), giving you much more time, just as on the GBA).
Up side: I suspect that one need not worry about polygon ordering (hallelujah!), because if the Z-values are implict in the render, the hardware likely can correctly ensure that depths come out correctly regardless of the polygon order. This would suggest that techniques like BSP trees, which perform fancy "artificial" deconstruction of polygons primarily to make renderers happy, would likely be unnecessary.
_________________
Do you suppose if I put a signature here, anyone would read it? No? I didn't think so either.
#30906 - EaDS Milliways - Mon Dec 06, 2004 12:18 am
Just picked up Asphalt GT and between this game and SM64DS, I'm hoping that the redraw problems are due to an abrupt dev cycle and that some of the tricks described here will be implemented in later releases without a dramatic decrease in polygon count.
I just finished a race and there's just three vehicles (and the backgrounds of course) with one coming towards me. It's the end of the race so it's paused like a "photo finish" except for the oncoming car's headlights are winking at me! And it's not an even blink, maybe 7 or 8 blinks then a quick double flash.
#32002 - bertil - Thu Dec 16, 2004 10:17 pm
I just saw a very peculiar thing in Feel the Magic.
On one level there's a classical H-blank wave effect - on a 3D scene.
If it really has no framebuffer, doesn't this mean they're recalculating the cordinates for all the polygons on every line? But doesn't that seem rather unlikely?
It seems more likely that it renders all the 3d onto one background layer and just scrolls this at h-blank. There's also other other graphics (only 2D stuff) on the screen that's not wavey at the same time so I guess there can't be a framebuffer for all the graphics.
#32011 - mike260 - Fri Dec 17, 2004 1:44 am
This is all a bit reminiscent of the Dreamcast:
- Scene-capture based (ie. you specified the entire scene before it started rendering)
- Could be configured to run without a conventional framebuffer
- Huge (but meaningless) fillrate numbers
No, I'm not suggesting there's a PowerVR in there. But perhaps it is doing something similar to the DC's strip-buffer mode, eg: rendering narrow strips of the screen into a double-buffered pair of buffers that track the current LCD scanline. The fact that there are registers for clear-colour and clear-depth suggests there's *some* kind of framebuffer anyway.
Also very interesting to spot GXFIFO in the register list. The Gamecube's graphics API is called GX, and it's based around a FIFO. You throw rendering-commands, vertices and suchlike at a fixed address, and they get put into a large, circular FIFO buffer, from where they get consumed by the graphics hardware.
#32024 - tepples - Fri Dec 17, 2004 8:59 am
| mike260 wrote: |
| No, I'm not suggesting there's a PowerVR in there. But perhaps it is doing something similar to the DC's strip-buffer mode, eg: rendering narrow strips of the screen into a double-buffered pair of buffers that track the current LCD scanline. |
That's what I was guessing; I just didn't know about the Dreamcast. It is pretty much known that every sprite-based Nintendo console (NES, GB/C, SNES, VB, GBA) has a buffer in which it stores retrieved sprite cel data, and the way each system's BG/sprite compositor works suggests that it might be a 1-scanline-tall frame buffer.
| Quote: |
| The fact that there are registers for clear-colour and clear-depth suggests there's *some* kind of framebuffer anyway. |
The GBA has a clear-color too, at location 0x05000000, entry 0 of palette RAM. It also appears to have a Z-buffer, and each background or sprite has a Z-value; if you want more info on this conjecture, PM me.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#32057 - sgeos - Fri Dec 17, 2004 4:40 pm
| phantom-inker wrote: |
| The screens appear to rendered in lockstep (always on the same scan line together), because there is only one DISPSTAT and one VCOUNT register. |
Could scanlines 0-191 be the first screen and lines 192-383 be the second?
-Brendan
#32065 - EaDS Milliways - Fri Dec 17, 2004 7:17 pm
Just a thought to those wiser than I,
Knowing the possible hardware limitations, do you think there's a particular game genre that it would be difficult if not impossible to do on the DS?
Given the nature of what is known about the video hardware, what would NOT prove to be a convincing simulation?
#32092 - AdamW - Sat Dec 18, 2004 2:48 am
since every game genre currently in existence has been around since well before the creation of hardware on the ds's level (except the MMORPG, but that's only 'new' due to connectivity, not processing power), no, there's no genre you couldn't do on the ds. Before MMORPGs the last new genres were real-time strategy (Dune II) and real-time first person games (Ultima Underworld and Wolf3D if you want texture maps, a few earlier games if you don't). the GBA can do both of those, let alone the DS.
#32103 - EaDS Milliways - Sat Dec 18, 2004 4:29 am
| AdamW wrote: |
| since every game genre currently in existence has been around since well before the creation of hardware on the ds's level, no, there's no genre you couldn't do on the ds. |
What I'm speaking of specifically is "quality" of the game experience. Adventure for the Atari 2600 was an action/adventure game. While that can be easily accomplished on the DS, graphics of that level wouldn't sell any copies today. It's easy for me to believe that the sky is the limit and there's nothing it can't do. However, I was wondering if there's something in the specifications that makes a coder think "I wouldn't want to have to write a -game- for this."
#32125 - netdroid9 - Sat Dec 18, 2004 6:47 am
The only thing would be screen size, the rest is powerful enough to make a decent game.
If it's mean't to be portable, not really.
#32143 - Cleon I - Sat Dec 18, 2004 12:20 pm
I think Dance Dance Revolution would probably be too difficult to port to the DS... though now that I think about it, they did have a gameboy version...
Also, like netdroid9 said, games that require more screen real estate would be difficult. That would include some types of RTS games and possibly flight simulators or something where you have to keep track of several indicators at once. However, both genres are definitely do-able.
#32146 - mymateo - Sat Dec 18, 2004 1:42 pm
The nice thing about the DS is that even though the screens are a little small, you don't need to worry about having your view obscured by stats and meters. Most good developers will keep only the most critical info displayed on the screen showing the main action, and keeping everything else on the 2nd screen. So yeah, you have a lot smaller screen to work with than on any other more powerful system (PSP, GameCube, PC), but you have more of that screen to see who's shooting at you, etc.
Hooray for two screens!
#32151 - mike260 - Sat Dec 18, 2004 5:40 pm
| EaDS Milliways wrote: |
| I was wondering if there's something in the specifications that makes a coder think "I wouldn't want to have to write a -game- for this." |
Put it this way, the current generation of consoles hasn't really had many games that couldn't have been done in some fashion on the PS1 or the N64. GTA3's the only big one that springs to mind, and even that's debatable.
#32240 - sillyb - Mon Dec 20, 2004 12:00 am
Personally I dont think anything with a long viewdistance in mind is at all feasable....
so that means most space games, and certain unique fps's
#32246 - netdroid9 - Mon Dec 20, 2004 2:55 am
A long view distance *might* not be feasable, but most space games aren't going to need you to see something all the way across the 3D map. I don't know about FPs though.
#32247 - ravuya - Mon Dec 20, 2004 3:09 am
| sillyb wrote: |
Personally I dont think anything with a long viewdistance in mind is at all feasable....
so that means most space games, and certain unique fps's |
Why bother? It's not like you can really tell pop-in all that well with such a small screen.
_________________
Rav (Win/Mac/Linux games for free)
#32248 - AdamW - Mon Dec 20, 2004 4:28 am
mike260: there's that guy porting gta3 to the NES...:)
#32251 - mike260 - Mon Dec 20, 2004 5:04 am
Some findings and random speculations to complement Mr. phantom-inkers breakdown:
- You get to specify a polygon ID between 0 and 63 for each polygon you draw, and also one for the screen to be cleared to. I reckon this is for hit-testing; it's a touch-screen system after all, and it'd be *extremely* useful to be able to flag objects with different id's, and quickly detect what object is under the stylus.
- I'm getting the feeling that the ARM7s main role might be as a frontend to the graphics chip. Rendering dynamic geometry on the DS appears to involve a lot of packing verts into nasty formats and repeatedly stuffing them into registers which is a waste of time for the ARM9. Whereas if the rumours that the ARM7 isn't directly programmable are true, it's not got much else to keep it busy has it?
- You get 4 directional lights in hardware. On any poly you can mask out any or all of these lights.
- You can set per-vertex RGBs but only per-polygon alpha
- You can submit 3-4 types of geometry (the VTX_BEGIN reg has a 2-bit TYPE field)...one of these is surely tri-strip, I'm guessing tri-fan, tri-list and quad-list for the others.
- I'm hoping the TGEN field in TEXIMAGE_PARAM is texture-coord generation. On Gamecube this allowed you to multiply a vertices position, normal or input texcoord by a matrix and use the result as that verts texcoord. The fact that there are at least 3 matrix stacks also points towards the existance of a texcoord matrix.
- There are 3-4 texture formats; these are bound to include 4-bit and 8-bit palettised, I'm guessing it also does RGBA5551 and S3TC.
- As phantom-inker pointed out, basic vertex precision totally sucks. However, matrix precision is ok so you can still smoothly animate rigid geometry. Plus, there's a VTX_DIFF register with less range and more precision; I'm guessing this adds the value you passed in onto the last specified vertex instead of replacing it. So if you're careful about how you lay out your geometry, you can get precision gains here too. However, neither of these facts helps much with skinning.
- There's a TOON_TABLE set of registers that could well be a lookup-table for cel-shading. Bring on Wind Waker DS!
- DISP3DCNT looks a lot like a pixel-pipeline settings register...
- GO: ?
- RO: ?
- FOG_SHIFT: fog=z>>FOG_SHIFT?
- FME: fog (something) enable?
- FMOD: fog mode?
- EME: environment mapping enable
- AAE: anti-alias enable
- ABE: alpha-blend enable
- ATE: alpha-test enable
- THS: toon-something-something? texture-something-something?
- TME: texture-mapping enable (toon-mapping enable?)
However, if the system does have anti-aliasing, it's either (a) slow, (b) difficult to use or (c) crap because I've seen no evidence of it in any screenshots. Has anyone spotted it?
Ok, time for bed.
#32253 - Abscissa - Mon Dec 20, 2004 5:31 am
| mike260 wrote: |
| However, if the system does have anti-aliasing, it's either (a) slow, (b) difficult to use or (c) crap because I've seen no evidence of it in any screenshots. Has anyone spotted it? |
I'd highly doubt it does anti-aliasing, since from what I've seen (the Metroid demo) it doesn't even seem to do bilinear-filtering. Plus, with the pixels as small as they are on a handheld, I'm not sure the difference anti-aliasing makes would be very noticable to most people. Although then again, I don't know what else 'AAE' could be. Maybe anti-aliasing on lines for wireframe stuff rather than polygon-edges?
#32254 - mike260 - Mon Dec 20, 2004 5:48 am
| Abscissa wrote: |
| I'd highly doubt it does anti-aliasing, since from what I've seen (the Metroid demo) it doesn't even seem to do bilinear-filtering. Plus, with the pixels as small as they are on a handheld, I'm not sure the difference anti-aliasing makes would be very noticable to most people. Although then again, I don't know what else 'AAE' could be. Maybe anti-aliasing on lines for wireframe stuff rather than polygon-edges? |
Your right, it's pretty weird for the hardware to try and do AA when it can't even handle texture-filtering. But I do think that good AA makes sense on small screens; the fewer pixels you have, the more you need to do with them to make things legible.
#32257 - ravuya - Mon Dec 20, 2004 6:07 am
I don't think AAE stands for anti-alias enable; the screen's resolution is too small to worry about that and it wastes hardware time that could be used rendering polygons.
I don't have a competitive recommendation for what it could be; I'd just be grasping at straws firing out all my graphics-programming vocabulary starting with A ("anisotropic, antialiasing, ...").
I'll check around, see if there's anything I can figure out from some console developers.
_________________
Rav (Win/Mac/Linux games for free)
#32280 - mike260 - Mon Dec 20, 2004 4:06 pm
| ravuya wrote: |
| I don't think AAE stands for anti-alias enable; the screen's resolution is too small to worry about that and it wastes hardware time that could be used rendering polygons. |
I take it back - looking at some Mario 64 DS screens there definitely is anti-aliasing going on there (it's most obvious on near-vertical edges). Looks quite good too. It's also visible in Metroid, although it's less obvious cos it's so visually noisy.
#32282 - ravuya - Mon Dec 20, 2004 5:11 pm
Well, if it is AA, good thing it's optional: what a waste of GPU/CPU time that is.
_________________
Rav (Win/Mac/Linux games for free)
#32286 - Abscissa - Mon Dec 20, 2004 6:16 pm
| mike260 wrote: |
| Abscissa wrote: | | I'd highly doubt it does anti-aliasing, since from what I've seen (the Metroid demo) it doesn't even seem to do bilinear-filtering. Plus, with the pixels as small as they are on a handheld, I'm not sure the difference anti-aliasing makes would be very noticable to most people. Although then again, I don't know what else 'AAE' could be. Maybe anti-aliasing on lines for wireframe stuff rather than polygon-edges? |
Your right, it's pretty weird for the hardware to try and do AA when it can't even handle texture-filtering. But I do think that good AA makes sense on small screens; the fewer pixels you have, the more you need to do with them to make things legible. |
Normally yes, but I figured that being a handheld the pixels were so small that a lower resolution looks better than it would on a TV or monitor.
#32289 - dagamer34 - Mon Dec 20, 2004 7:37 pm
I hope the DS does a decent job of texture filtering and it just hasn't been used to the fullest yet. You can actually see the pixels from the textures on the trees in SM64DS and when you get really close up to a wall in Metroid Prime Hunters: First Hunt. I am really hoping it's because of rushed development.
_________________
Little kids and Playstation 2's don't mix. :(
#32302 - Alex Atkin UK - Mon Dec 20, 2004 11:32 pm
I doubt it does texture filtering at all. Low development time or not, I dont see why they WOULDNT have used it, if it was available.
Plus its been said that other issues (some of accuracy) are far more relevant than if you can see the pixels on a wall or not.
I cant help thinking Nintendo really should have pushed a bit more into the DS when it comes to its graphics capabilities. It doesnt stand up even slightly against the PSP. Now I know its not supposed to (and im one of the people supporting that the PSP is just going to be boring because its those PS2 games you play once and never again) but I still think just a little more effort on the 3D capabilities would go a long way. The lack of texture filtering certainly seems an oversight as the screen might be small but you can still spot it quite easily.
_________________
[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]
#32345 - Abscissa - Tue Dec 21, 2004 5:43 am
| Alex Atkin UK wrote: |
| I doubt it does texture filtering at all. Low development time or not, I dont see why they WOULDNT have used it, if it was available. |
Yea, I can't really see any way that turning on filtering, if available, would be anything but trivial. Only thing I can think of is maybe it takes more time for the hardware to do, and they didn't have time to do more visibility optimisations. But bilinear filtering hasn't been any slower than point sampling in hardware rendering since before the 3DFX Voodoo 1.
| Alex Atkin UK wrote: |
| I cant help thinking Nintendo really should have pushed a bit more into the DS when it comes to its graphics capabilities. It doesnt stand up even slightly against the PSP. Now I know its not supposed to (and im one of the people supporting that the PSP is just going to be boring because its those PS2 games you play once and never again) but I still think just a little more effort on the 3D capabilities would go a long way. The lack of texture filtering certainly seems an oversight as the screen might be small but you can still spot it quite easily. |
It does seem kinda like a super-powered PS1 at times, particularly with the point-sampled textures. Not that I mind, though, it still looks a lot better than the N64/PS1 era.
#32352 - tepples - Tue Dec 21, 2004 7:53 am
Would random texture coordinate jitter combined with the comparatively slow response of the LCD help in creating an illusion of bilinear texture filtering?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#32358 - arbitrary - Tue Dec 21, 2004 10:25 am
| tepples wrote: |
| Would random texture coordinate jitter combined with the comparatively slow response of the LCD help in creating an illusion of bilinear texture filtering? |
Definitely not at 30fps! Probably not at 60fps, either...
The LCD isn't exactly slow, as the difference between 30fps and 60fps is clearly visible.
#32361 - mike260 - Tue Dec 21, 2004 11:57 am
| tepples wrote: |
| Would random texture coordinate jitter combined with the comparatively slow response of the LCD help in creating an illusion of bilinear texture filtering? |
A random per pixel texcoord jitter (as opposed to jittering input STs) could work well, but it'd need hardware support. Not much support though, it's just a dither really.
Come to think of it, why doesn't the DS do this? It has no impact on memory bandwidth (unlike bilinear), and would presumably be pretty easy to implement.
#32362 - Darkain - Tue Dec 21, 2004 12:03 pm
just as a random note:
it appears that Feel the Magic is indeed using AA in some minor areas. it can be most easily seen on the scene selection screen w/ the chick on the left. the polys inside of the model appear to be AA, whereas her outer edge is not. possibly suggesting that the model is being rendered to a non frame buffer location at higher detail, and then BLTed in?
the easist area to see (depending on your outfits) is to look at the blackness around the chick compared to a light/white outfit, and you can see the AA blending in action.
i'll try to get access to a decent digital cam tomorrow and take some pics.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#32363 - arbitrary - Tue Dec 21, 2004 12:13 pm
Something interesting I noticed in Mario64 was the shadows.
When Mario's translucent, octagonal shadow overlaps other shadows, they don't double-darken. It's amost like the translucent polys are on a separate 'layer' - and don't blend with each other?
To see the effect, walk up to one of the signposts right at the start, outside the castle, or the butterflies in the same area. (ignore the tree shadows, which are obviously textured and done differently)
It's much more noticable with the '?' blocks in-game, though, as Mario can walk right under them.
Could be a useful little feature, anyway...
#32364 - mike260 - Tue Dec 21, 2004 12:20 pm
| arbitrary wrote: |
Something interesting I noticed in Mario64 was the shadows.
When Mario's translucent, octagonal shadow overlaps other shadows, they don't double-darken. It's amost like the translucent polys are on a separate 'layer' - and don't blend with each other? |
Well spotted.
Is Mario's shadow obviously a flat poly, or does it follow the contours of what's underneath it?
What does it do when you're casting a shadow onto a vertical or near-vertical ledge?
#32446 - EaDS Milliways - Wed Dec 22, 2004 11:23 pm
I think his shadow and the shadow of moving objects are polys. On the one level with the really high pole (don't have the game on me right now so don't know exactly where it is) there is a tower that has platforms that slide in and out. if you climb on that pole and change your perspective so that you can see that tower, the shadows under the platform shows streaking (perhaps indicative of the DS having a polygon per line limit).
#32502 - Advancer - Thu Dec 23, 2004 12:51 pm
I believe the DS has a 64 polygon per line limit.
#32523 - tepples - Thu Dec 23, 2004 4:39 pm
That'd be a b****. Such a low limit of polys per line would force games to software-render high-poly models as they did in Tony Hawk's Pro Skater for GBA.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
![[Images not permitted - Click here to view it]](http://csdprojects.co.uk/banners/linuxusers.png){kind=link}
![[Images not permitted - Click here to view it]](http://csdprojects.co.uk/banners/segagaming.png){kind=link}